Mechanizmy zwiększania niezawodności DNS

DNS w kontekście globalnego rozwiązywania nazw spełnia swoją rolę używając wielu różnych mechanizmów – ich znajomość jest kluczowa z punktu widzenia administrowania rozwiązywaniem nazw w kontekście serwisów wysokiej niezawodności.

Rozważymy kilka ze sposobów dostarczania stref do klientów. Ponieważ klient może używać więcej niż jednego serwera nazw jednocześnie konfiguracja serwisów oraz wymiana informacji między nimi jest istotna. Nie można dopuścić do sytuacji w której dwa serwery DNS odpowiedzialne za utrzymywanie jednej strefy różniły się rekordami. Utrzymywanie spójności między serwerami zapewniany jest na różne sposoby – zależnie od stosowanego rozwiązania DNS.

Tu dotykamy tematu różnych rodzajów stref: Primary, Secondary, Stub, Forwarding oraz w przypadku systemów Windows stref Primary AD-Integrated.

Primary czyli strefa podstawowa – serwer który jest autorytatywny (przechowuje rekordy strefy i o niego oparte jest rozpoznawanie nazw dla strefy) utrzymuje strefę podstawową. W najprostszej konfiguracji (bez zapewniania mechanizmów replikacji) może istnieć tylko jedna strefa Primary – ponieważ strefa ta jest niezależna i najwyższa w hierarchii.

Celem zapewnienia jakiejś niezawodności w usługach używane są także strefy Secondary – czyli zapasowe strefy które kopiują konfigurację ze stref Primary przy użyciu mechanizmu nazywanego transferem. Transfer jest cechą konfiguracji serwera DNS/Strefy – należy uważać komu (jakim adresom IP / serwerom DNS) pozwala się na dokonywanie transferu naszej strefy. Charakterystyczne dla strefy zapasowej jest to, że nie można zmieniać jej rekordów – są one pobierane i nadpisywane ze strefy podstawowej. Pomimo to – serwer posiadający strefę Secondary posiada wszelkie rekordy (aktualizuje je ze strefy podstawowej w oparciu o numer seryjny rekordu SOA) i obsługuje żądania jak każdy inny serwer DNS.

Istnieją również mechanizmy o charakterze hybrydowym tzn. umożliwiające używanie stref typu multiple Primary. To oznacza, że nie używają one standardów określonych w RFC pomiędzy strefami Primary i Secondary – nie używają mechanizmu transferu. Musi zatem istnieć dedykowany mechanizm transportu informacji o zmianach w tych strefach. Microsoft oparł tego typu rozwiązanie na produkcie który z powodzeniem używany jest w każdej szanującej się korporacji/firmie – Active Directory. To usługa katalogowa posiadająca dane o usługach, użytkownikach i maszynach a także wielu innych elementach definiujących strukturę firmy (atrybuty), kóra od czasu powstania rozrosła się do tego stopnia, że stanowi nośnik wielu innych technologii Microsoft. Umożliwia m.in. tworzenie stref DNS AD-integrated. Oznacza to, że strefa znajduje się w strukturze katalogowej Active Directory i jest replikowania między wszystkimi (lub wybranymi o czym zaraz) kontrolerami DC. Z punktu widzenia administratora jest to wyłącznie kwestia zaznaczenia opcji „Integrate zone with Active Directory”. Co to nam daje? Strefa jest wysoko dostępna (replikowana). Można ją zmieniać na dowolnym kontrolerze domeny a zmiana zostanie zreplikowana do reszty kontrolerów. Strefa jest wszędzie oznaczona jako Primary AD-integrated i posiada własny system uprawnień na rekordach.

Czy to oznacza, że jeśli mamy np. 10 DC to musimy replikować strefę między wszystkimi? Oczywiście nie – istnieje mechanizm nazywany partycjonowaniem Active Directory – który umożliwi stworzenie nam subkontenera w usłudze katalogowej, który będzie zreplikowany na wskazane kontrolery. Kontener taki można stworzyć np. przy użyciu komendy

dnscmd <server> /createdirectorypartition <nazwa partycji>

Dodatkowe serwery które mają trzymać partycję dodajemy

dnscmd <server> /enlistdirectorypartition <nazwa partycji>

Teraz pozostaje tylko w usłudze DNS zmienić zakres replikacji partycji w jej właściwościach na nowo stworzona partycję i tadam!

Oczywiście nie tylko Microsoft wpadł na pomysł replikowania swoich stref. Produkty dedykowane również wykorzystują takie podejście – chociażby Infoblox – całościowy produkt DDI (DHCP/DNS/IPAM) używa struktury którą nazwano GRID (siatka na którą składają się jej maszyny – members, która odpowiada za utrzymywanie i replikowanie bazy wraz z informacjami) . Replikacja w ramach GRID działa na podobnej zasadzie co w AD, umożliwiając propagację stref między skonfigurowanymi memberami.