Co to jest strefa root DNS (DNS root zone) i jak działa?

Strefa root DNS (DNS root zone) to absolutnie najwyższy poziom hierarchii systemu nazw domen w internecie, pełniący funkcję globalnej książki adresowej. Działa ona poprzez kierowanie zapytań o adresy IP do odpowiednich serwerów zarządzających domenami najwyższego poziomu, takimi jak .pl czy .com. Kiedy wpisujesz adres strony internetowej w oknie przeglądarki, twój sprzęt musi się dowiedzieć, gdzie fizycznie podpięto ten serwer. Pytanie to trafia najpierw do lokalnego resolwera u twojego dostawcy internetu. Jeśli on nie ma zapisanej odpowiedzi w pamięci podręcznej, uderza prosto do serwerów obsługujących strefę root. To one wskazują mu właściwą drogę.

Piszę tę analizę o trzeciej nad ranem, po całkowicie położonym wdrożeniu u nas w oddziale. Wywaliło nam routing w serwerowni na warszawskim Mokotowie przy ulicy Domaniewskiej. Szlag człowieka trafia, gdy widzi, jak proste błędy w konfiguracji stref kładą całe podsieci na kolana. My w zespole ciągle zapominamy, że infrastruktura internetu opiera się na plikach tekstowych. Zwykłych plikach tekstowych rozsyłanych po świecie.

Cały ten system opiera się na delegacji uprawnień. Serwery strefy root nie wiedzą, jaki adres IP ma konkretna strona internetowa małej firmy z Krakowa. One wiedzą tylko jedno. Wiedzą dokładnie, kto zarządza końcówką .pl. Wskazują adresy IP serwerów NASK. Tamte serwery z kolei wiedzą, kto zarządza konkretną domeną docelową. Taka kaskada zapytań powtarza się miliardy razy na sekundę na całym świecie.

Dlaczego serwery głównych stref DNS są technicznie tak rozproszone?

Wielu młodszych administratorów uważa, że istnieje tylko trzynaście głównych serwerów DNS na świecie. To stara, powtarzana od lat bzdura. Mamy trzynaście logicznych adresów IP przypisanych do serwerów głównych oznaczonych literami od A do M. Fizycznych maszyn są tysiące. Wynika to wprost z ograniczeń historycznych protokołu UDP. Pojedynczy pakiet odpowiedzi DNS musiał zmieścić się w 512 bajtach. Żeby tego dokonać, inżynierowie zmieścili na liście dokładnie trzynaście adresów IPv4. Nic więcej by nie weszło bez fragmentacji pakietów.

Rozproszenie tych maszyn zapobiega awariom. Zawsze znajdzie się ktoś, kto wypuści błędną aktualizację i potem cała usługa leży i KICZY na błędach z timeoutem. Dlatego kopie strefy root działają na każdym kontynencie. Używamy tu technologii Anycast. Pozwala ona przypisać ten sam adres IP do wielu fizycznych serwerów rozlokowanych w różnych miastach.

• Protokół BGP (Border Gateway Protocol) analizuje trasę i kieruje twoje zapytanie do najbliższej geograficznie maszyny, skracając czas oczekiwania z 200 milisekund do zaledwie kilkunastu, co drastycznie odciąża główne węzły komunikacyjne na kablach transoceanicznych.
• Krótki czas odpowiedzi.
• Izolacja ataków DDoS, ponieważ ruch generowany przez botnety w Azji uderza tylko w azjatyckie instancje serwerów root, zostawiając maszyny w Europie i Ameryce w pełnym spokoju operacyjnym, przez co reszta świata działa normalnie.
• Brak centralnego punktu awarii.

Prawda jest zresztą absolutnie taka, że dzisiejsi programiści po bootcampach w ogóle nie rozumieją warstwy sieciowej. Budują te swoje kontenery w chmurze, rzucają mikroserwisy na prawo i lewo, a jak przyjdzie do debugowania prostego rekordu TXT czy propagacji w strefie root, to rozkładają ręce i płaczą do helpdesku. Brakuje nam twardych danych z zeszłego tygodnia na potwierdzenie tej tezy w skali kraju, więc to tylko moja prywatna obserwacja z biurka. Ale widzę to codziennie. Ludzie traktują DNS root zone jak magię, a to przecież pospolity plik strefy replikowany po węzłach.

Kto fizycznie opiekuje się tymi maszynami?

Zarządzanie literowymi serwerami od A do M powierzono różnym organizacjom. Nie ma tu monopolu. Instytucje te to na przykład NASA, Uniwersytet Maryland, Verisign czy RIPE NCC. Podział ten wprowadzono celowo. Żeby żadna korporacja ani żaden pojedynczy rząd nie miał wyłącznej władzy nad systemem nazw domen. Każdy operator sam decyduje, jakiego sprzętu używa i jak konfiguruje swoje routery brzegowe.

Taka różnorodność oprogramowania chroni nas przed błędami typu zero-day. Jeśli w oprogramowaniu BIND zostanie znaleziona krytyczna dziura, padną tylko te serwery, które go używają. Inni operatorzy korzystający z NSD lub Knot DNS będą działać dalej. To brutalna i skuteczna metoda obrony.

Jak działa zapytanie rekursywne i co ma z tym wspólnego plik strefy?

Zapytania rekursywne to podstawa działania internetu po stronie klienta. Twój system operacyjny nie potrafi sam przeszukać całego drzewa DNS. Zleca to zadanie resolwerowi. Resolwer bierze na siebie cały ciężar znalezienia właściwego adresu IP. Musi przejść przez całą ścieżkę autorytatywną.

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Mieliśmy źle skonfigurowany czas życia pakietów (TTL) na lokalnym resolwerze. Maszyna trzymała nieaktualne wpisy przez 48 godzin zamiast odpytać strefę root o nowe delegacje. Wyczyszczenie cache rozwiązało problem w pięć sekund. Trzy dni szukania błędu w kodzie aplikacji w błoto.

Sam plik strefy root (root zone file) jest wbrew pozorom bardzo mały. Zajmuje zaledwie kilka megabajtów. Zawiera on listę wszystkich domen najwyższego poziomu (TLD) oraz przypisane do nich adresy IP autorytatywnych serwerów nazw. Mamy tam końcówki krajowe (.pl, .de), globalne (.com, .net) i sponsorowane (.aero, .museum). Ten plik jest regularnie podpisywany kryptograficznie za pomocą mechanizmu DNSSEC, żeby nikt nie mógł po drodze sfałszować odpowiedzi.

Kto tak naprawdę edytuje plik strefy root DNS?

To nie jest tak, że jeden informatyk siedzi w piwnicy i dopisuje nowe domeny w notatniku. Proces jest mocno sformalizowany. Za zarządzanie parametrami protokołów internetowych odpowiada IANA (Internet Assigned Numbers Authority), która jest obecnie częścią ICANN (Internet Corporation for Assigned Names and Numbers). ICANN przyjmuje wnioski o utworzenie nowej domeny TLD.

Jeśli wniosek zostanie zaakceptowany, IANA przygotowuje zmiany w pliku strefy. Ale IANA sama nie publikuje tego pliku do sieci. Przekazuje go do firmy Verisign. Verisign pełni rolę technicznego operatora strefy root (Root Zone Maintainer). Weryfikują oni poprawność danych, generują nowy plik, podpisują go i rozsyłają do wszystkich trzynastu operatorów serwerów głównych. Proces ten powtarza się dwa razy dziennie.

Czy awaria strefy root DNS wyłączy nam internet?

Krótka odpowiedź brzmi: nie. Przynajmniej nie od razu. W zdecydowanej większości przypadków zwykły użytkownik nawet by nie zauważył, że główne serwery zamilkły. Architektura systemu DNS opiera się na potężnym buforowaniu (caching). Każdy resolwer na świecie przechowuje informacje o serwerach TLD w swojej pamięci podręcznej przez określony czas, zwykle wynosi on 48 godzin.

Gdyby teraz, w tej sekundzie, odcięto zasilanie we wszystkich tysiącach serwerów root na całym świecie, internet działałby dalej. Twój dostawca usług internetowych nadal wiedziałby, gdzie szukać serwerów dla domeny .pl czy .com. Problem zacząłby narastać powoli. Po kilkunastu godzinach, gdy czasy TTL (Time To Live) zaczęłyby wygasać w poszczególnych resolwerach, przeglądarki zaczęłyby zwracać błędy NXDOMAIN. Najpierw odcięłoby dostęp do rzadziej odwiedzanych stron, a na końcu przestałyby działać giganty technologiczne.

Zrobiliśmy na wdrożeniu w zeszłym roku test z całkowitym odcięciem naszego ruchu od publicznych serwerów root, blokując ruch na firewallu. Sieć wewnętrzna z własnym buforem działała bez zająknięcia przez cały dzień roboczy. Dopiero koło godziny dwudziestej systemy monitorujące zaczęły rzucać alertami o braku możliwości rozwiązania nazw dla usług chmurowych podpiętych pod egzotyczne domeny TLD. Odblokowaliśmy port 53 i wszystko wróciło do normy. To dowodzi twardej odporności tego protokołu na chwilowe braki łączności.

W jaki sposób technologia Anycast chroni infrastrukturę internetu?

Zwykły routing Unicast polega na tym, że jeden adres IP wskazuje na jedną, konkretną maszynę w sieci. Anycast łamie tę zasadę całkowicie. W architekturze Anycast ten sam adres IP (na przykład 198.41.0.4 dla serwera A.root-servers.net) jest ogłaszany przez wiele routerów w różnych lokalizacjach geograficznych na świecie.

Kiedy twój komputer wysyła pakiet na ten adres IP, routery po drodze analizują tablice routingu BGP. Wybierają najkrótszą, najtańszą metrycznie trasę. Twój pakiet trafia do maszyny w Warszawie. Pakiet wysłany przez użytkownika w Tokio na ten sam adres IP trafi do maszyny w Japonii. Obie maszyny mają identyczną zawartość pliku strefy root DNS.

• Anycast naturalnie zdejmuje ruch z zatłoczonych łącz międzynarodowych, trzymając zapytania blisko użytkownika końcowego na węzłach wymiany ruchu.
• Rozprasza ataki wolumetryczne.

Jeśli ktoś uruchomi ogromny atak DDoS z przejętych kamer IP w Ameryce Południowej, to ten śmieciowy ruch uderzy wyłącznie w południowoamerykańskie instancje serwera root. Maszyny w Europie w ogóle nie zanotują wzrostu obciążenia. To izoluje problem lokalnie i pozwala reszcie globu funkcjonować. Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku ataków po wprowadzaniu nowych filtrów u operatorów Tier 1. My po prostu widzimy, że to działa w praktyce.

Czym różni się IANA od ICANN w kontekście zarządzania domenami?

Ludzie z branży często używają tych skrótów zamiennie. To błąd. ICANN (Internet Corporation for Assigned Names and Numbers) to globalna organizacja non-profit. Zajmuje się tworzeniem polityki, organizowaniem spotkań i ustalaniem ogólnych zasad działania systemu nazw domen. To oni decydują o tym, czy możemy stworzyć nową domenę .blog albo .app.

IANA to departament wewnątrz ICANN. To techniczni wykonawcy. Nie tworzą polityki. Oni biorą zatwierdzone decyzje i fizycznie wprowadzają je do rejestrów. Przypisują pule adresów IP dla regionalnych rejestrów (RIR) i zarządzają parametrami protokołów dla IETF. IANA edytuje plik strefy root. ICANN mówi im, co mają tam wpisać.

Zmieniliśmy te zasady na robocie niedawno u nas w firmie. Zamiast dawać jednemu zespołowi prawa do decydowania o architekturze i jednoczesnego klikania na serwerach, rozdzieliliśmy to. Jeden zespół planuje, drugi wdraża. Dokładnie ten sam model podziału obowiązków, który od dekad sprawdza się na szczycie hierarchii internetu. To ogranicza pomyłki ludzkie do minimum.

Ceremonia generowania kluczy KSK dla strefy root (DNSSEC)

To jest ten moment, w którym technologia spotyka się z rytuałem. Aby zapobiec fałszowaniu odpowiedzi DNS (DNS spoofing), strefa root została zabezpieczona protokołem DNSSEC. Wymaga to posiadania głównego klucza kryptograficznego, tak zwanego Root Zone Key Signing Key (KSK). Kto kontroluje ten klucz, kontroluje zaufanie do całego internetu.

ICANN nie trzyma tego klucza na jednym pendrive w szufladzie. Zamiast tego zorganizowano procedurę przypominającą filmy szpiegowskie. Ceremonie KSK odbywają się cztery razy w roku. Dwie w obiekcie na wschodnim wybrzeżu USA, dwie na zachodnim. Biorą w nich udział tak zwani Trusted Community Representatives (TCR) – eksperci od bezpieczeństwa z całego świata. Mają oni fizyczne klucze do sejfów i karty inteligentne.

Dopiero obecność co najmniej trzech z nich w specjalnie zabezpieczonym pomieszczeniu, pozbawionym łączności z zewnątrz, pozwala na aktywację modułu HSM (Hardware Security Module). Moduł ten generuje i podpisuje nowe klucze na kolejny kwartał. Całość jest nagrywana, transmitowana na żywo i audytowana krok po kroku według publicznie dostępnego scenariusza. Brzmi to jak paranoja. Ale ten poziom transparentności buduje realne zaufanie. Omijamy w ten sposób zarzuty o zakulisowe manipulacje plikiem strefy przez służby wywiadowcze.

Wszystko to sprowadza się do utrzymania spójności. DNS root zone musi być identyczna dla każdego użytkownika. Bez względu na to, czy łączysz się z sieci w Tokio, Warszawie czy z satelity Starlink. Jeden fałszywy wpis na tym poziomie skierowałby miliony ludzi na podrobione strony banków. Dlatego proces aktualizacji jest powolny, a zabezpieczenia wielowarstwowe.

Sprawdź konfigurację swoich własnych serwerów nazw w firmie. Uruchom polecenie dig +trace dla swojej domeny korporacyjnej. Zobacz na własne oczy całą ścieżkę zapytań od strefy root, przez serwery TLD, aż do twoich lokalnych maszyn. Przestań polegać wyłącznie na domyślnych ustawieniach dostawcy hostingu i zablokuj transfer strefy dla obcych adresów IP, zanim ktoś wyciągnie z twojego serwera całą mapę infrastruktury.

Najczęściej zadawane pytania (FAQ)

Bibliografia i źródła

1. Internet Corporation for Assigned Names and Numbers – https://www.icann.org
2. Internet Assigned Numbers Authority – https://www.iana.org
3. Naukowa i Akademicka Sieć Komputerowa – https://www.nask.pl
4. Internet Engineering Task Force – https://www.ietf.org
5. Root Server Technical Operations – https://root-servers.org