Hierarchia DNS – jak jest zbudowany system nazw domen?

Hierarchia DNS to rozproszony system nazw domen zbudowany na strukturze odwróconego drzewa, który tłumaczy czytelne dla człowieka adresy internetowe na numeryczne adresy IP zrozumiałe dla maszyn. Na samym szczycie tej struktury znajdują się serwery korzenia, poniżej nich serwery domen najwyższego poziomu, a na samym dole autorytatywne serwery nazw przechowujące konkretne rekordy dla poszczególnych witryn. I to jest w zasadzie cała definicja. A teraz wejdźmy w szczegóły, bo wczoraj na produkcji padł nam resolver i musieliśmy ręcznie czyścić cache dla strefy. Prawda jest absolutnie taka, że system nazw domen trzyma cały internet przy życiu.

Bez DNS wpisywalibyśmy w przeglądarkę ciągi liczb typu 142.250.190.46 zamiast adresów wyszukiwarek. Zmieniliśmy te zasady na robocie lata temu i nikt już nie pamięta numerów IP. Architektura opiera się na delegacji uprawnień. Rekursywny resolver u twojego dostawcy internetu pyta po kolei maszyny z wyższych warstw o to, kto ma ostateczną odpowiedź. To działa szybko. Bardzo szybko. Mimo to, awarie konfiguracji kładą największe biznesy na łopatki w ułamku sekundy.

Jak działają serwery korzenia i dlaczego jest ich tylko 13?

Zacznijmy od góry. Serwery korzenia to punkt startowy każdego zapytania w internecie. Historycznie narosło wokół nich mnóstwo mitów. Mówi się, że jest ich 13. To technicznie bzdura. Mamy 13 logicznych adresów IP przypisanych do tych maszyn, oznaczonych literami od A do M. Fizycznie to tysiące serwerów rozsianych po całym świecie dzięki technologii Anycast. Anycast pozwala na rozgłaszanie tego samego adresu IP z wielu lokalizacji geograficznych jednocześnie. Twój router pyta ten węzeł, do którego ma najbliżej pod kątem topologii sieci.

W ogóle muszę wam powiedzieć, że w zeszłym miesiącu siedziałem nad rekonfiguracją strefy dla małego biurowca na warszawskich Włochach. Niby prosta sprawa. Dostawca leciał w kulki z propagacją, TTL ustawione na 86400 sekund, a klient dzwoni z pretensjami. Siedzę o 3 nad ranem, wklepuje polecenia w terminal, a resolver dalej zwraca stary adres. Krew człowieka zalewa. To pokazuje, jak bardzo jesteśmy uzależnieni od buforowania na serwerach ISP, o których nie mamy żadnego pojęcia i nad którymi nie mamy kontroli. Te maszyny trzymają odpowiedzi w pamięci i ignorują nasze zmiany na produkcji.

Wracając do korzenia. Te serwery nie wiedzą, jaki adres IP ma konkretna strona. Mają jedno zadanie. Wskazują adresy serwerów odpowiedzialnych za domeny najwyższego poziomu (TLD). Przechowują plik strefy root, który waży niewiele, a zawiera delegacje do rejestrów zarządzających końcówkami takimi jak .pl, .com czy .org. Zarządza tym organizacja ICANN. Zresztą prawda jest taka, że bez sprawnych serwerów korzenia ruch w sieci staje w miejscu. Zastosowaliśmy Anycast po to, by uchronić tę warstwę przed atakami DDoS. Atakujący musiałby zalać ruchem tysiące maszyn naraz.

Czym różni się domena najwyższego poziomu od domeny drugiego poziomu?

Zaraz pod korzeniem mamy TLD. To są te końcówki na końcu adresu. Podmioty zarządzające TLD to rejestry. W Polsce domeną .pl zarządza NASK. Rejestry trzymają informacje o tym, do jakich autorytatywnych serwerów nazw przypisana jest konkretna domena drugiego poziomu. Zastanawiacie się pewnie, jak to wygląda na łączach. Zapytanie trafia do serwera TLD. Maszyna sprawdza swoją bazę i mówi resolverowi, gdzie ma szukać dalej.

Domena drugiego poziomu to po prostu nazwa twojej firmy lub bloga. To fragment adresu przed kropką i końcówką. Kupujesz ją u rejestratora, który jest pośrednikiem między tobą a rejestrem. Rejestrator wpisuje adresy twoich serwerów nazw do bazy TLD. I tu często pojawiają się błędy wpisu. Ktoś pomyli literę w nazwie serwera NS i domena znika z internetu. Mieliśmy taką sytuację w czwartek. Klient literówkę zrobił, a potem pretensje do IT.

Wyróżniamy dwa główne typy TLD. Krajowe (ccTLD) i funkcjonalne (gTLD). Krajowe mają dwie litery, na przykład .pl, .de. Funkjonalne to .com, .net, .info. Ostatnio namnożyło się tych nowych końcówek typu .app czy .dev. Wymuszają one szyfrowanie HTTPS na poziomie rejestru. To jest bez mała najgorsza opcja z wszystkich, jeśli testujesz coś lokalnie bez certyfikatu. Przeglądarka od razu blokuje połączenie.

W strukturze DNS domena drugiego poziomu jest w pełni pod twoją kontrolą. Tworzysz pod nią kolejne poziomy, czyli subdomeny. Sklep, blog, poczta. Ogranicza cię tylko długość całego adresu, która wynosi 253 znaki. Możesz delegować subdomeny na zupełnie inne serwery nazw. To przydaje się w korporacjach. My oddajemy strefę dla subdomeny marketingowej zewnętrznej agencji, a główną trzymamy u siebie w chmurze.

Rekordy DNS w praktyce – co dokładnie przechowuje autorytatywny serwer nazw?

Doszliśmy na dno odwróconego drzewa. Autorytatywny serwer nazw to maszyna, która ma ostateczną odpowiedź na zapytanie o adres IP. Przechowuje plik strefy. Plik strefy to po prostu tekstowa lista rekordów. Każdy rekord mówi o innej usłudze. Kiedy modyfikujesz ustawienia domeny u swojego hostingodawcy, edytujesz ten właśnie plik. Zobaczmy, co tam dokładnie siedzi.

To jest po prostu baza mapowań. Nie ma w tym magii. Poniżej zestawienie najczęściej używanych typów wpisów, z którymi pracujemy na co dzień.

Istnieją też rekordy TXT. Służą do weryfikacji własności domeny i konfiguracji bezpieczeństwa poczty. Mówię tu o SPF, DKIM i DMARC. Wrzucasz tam ciągi tekstowe, a serwery odbiorcze sprawdzają, czy mail faktycznie pochodzi od ciebie. Jeśli tego nie skonfigurujesz poprawnie, twoje maile lądują w spamie u klientów. Widziałem to setki razy na audytach. Ludzie kupują domenę, stawiają pocztę i dziwią się, że nikt nie odpisuje.

Serwer autorytatywny odpowiada na zapytanie i dorzuca parametr TTL. Time To Live. To czas, przez jaki resolver może trzymać tę odpowiedź w swojej pamięci podręcznej. I tutaj zaczynają się problemy operacyjne.

Na czym polega propagacja DNS i dlaczego to tyle trwa?

Propagacja to mit w klasycznym rozumieniu tego słowa. To nie jest tak, że informacja „rozchodzi się” po sieci falami. Zmiana na serwerze autorytatywnym jest natychmiastowa. Problem leży w cache’owaniu. Resolvery dostawców internetu i publiczne serwery (jak te od Google czy Cloudflare) przechowują stare zapytania przez czas określony parametrem TTL. Jeśli TTL wynosił 24 godziny, a ty zmienisz adres IP serwera, część świata będzie widzieć nową stronę od razu, a część dopiero jutro.

Dlatego przed planowaną migracją serwera zmniejszamy TTL do 300 sekund. Robimy to na 48 godzin przed akcją. Wtedy, podczas przepięcia ruchu, zastoje trwają maksymalnie 5 minut. Zapominasz o tym kroku i masz weekend z głowy, odbierając telefony od wściekłego zarządu. U nas w oddziale kiedyś ktoś o tym zapomniał. CAŁY ruch poszedł w próżnię na kilkanaście godzin.

Musimy pamiętać, że niektórzy lokalni operatorzy ignorują niskie wartości TTL. Ustawiają sztywne limity na swoich urządzeniach, żeby oszczędzać pasmo. Z tym nie zrobisz nic. Musisz czekać, aż ich wtyczki wygasną. To u nas w sumie chyba hipoteza z wczoraj, bo pewności do tych trendów rynkowych nikt obecnie nie ma o 2025 r. Wiele zależy od regionu i dostawcy. Widzimy zjawisko odrzucania krótkich cykli buforowania w sieciach mobilnych.

Kto zarządza systemem nazw domen i ustala zasady?

Internet Corporation for Assigned Names and Numbers. ICANN. To organizacja non-profit z siedzibą w Kalifornii. Decydują o tym, jakie nowe końcówki TLD wejdą na rynek. Pilnują, by adresacja IP na świecie się nie dublowała. W ramach ICANN działa IANA, która zajmuje się technicznym przydzielaniem numerów i zarządzaniem strefą korzenia. Przez lata ICANN podlegało pod rząd USA. W 2016 roku to się zmieniło. Przekazali kontrolę wielostronnej społeczności globalnej.

Czy ICANN może wyłączyć internet? Nie. System jest zbyt zdecentralizowany. Nawet jeśli wyłączą wpisy w korzeniu, lokalne resolvery będą działać na danych z pamięci podręcznej przez pewien czas. Poza tym, infrastruktura root servers jest zarządzana przez 12 niezależnych instytucji. Są tam uniwersytety, armia amerykańska, NASA i organizacje europejskie. Zmuszenie ich wszystkich do jednoczesnego wyciągnięcia wtyczki jest fizycznie niemożliwe. Zastosowano tu skrajną redundancję.

Rejestratorzy domen podpisują umowy z ICANN. Muszą spełniać rygorystyczne wymogi techniczne i prawne. Jeśli firma hostingowa upada, ICANN ma procedury awaryjne, by przenieść twoją domenę do innego operatora. Nikt nie traci adresu biznesowego z dnia na dzień. Chociaż z tymi transferami bywa różnie. Kody AuthInfo często nie docierają na maila, a support milczy. Prawda jest zresztą absolutnie taka, że procedury to jedno, a życie i praca z panelem klienta to drugie.

Jak skonfigurować własną strefę DNS bez błędów w rekordach?

Zacznij od audytu tego, co masz. Logujesz się do panelu domeny. Patrzysz na obecne nazwy serwerów (NS). Jeśli wskazują na firmę hostingową, to tam musisz szukać opcji edycji strefy. Dobrym pomysłem jest zrobienie zrzutu ekranu lub eksportu strefy do pliku BIND przed jakąkolwiek zmianą. Zawsze miej drogę powrotu. Kopia zapasowa ratuje etat.

Unikaj używania rekordów CNAME dla głównej domeny (tzw. apex domain). Protokół DNS tego nie lubi. Jeśli ustawisz CNAME dla „mojastrona.pl”, nie będziesz mógł dodać tam rekordów MX dla poczty. Zamiast tego stosuj aliasy typu ANAME lub rekordy ALIAS, jeśli twój dostawca je obsługuje. Rozwiązują one ten konflikt, zwracając adres IP w locie.

Wykorzystuj publiczne narzędzia do testowania propagacji. Strony takie jak dnschecker pozwalają sprawdzić, jaki adres IP widzą resolvery w różnych krajach w czasie rzeczywistym. Wbijasz nazwę domeny i od razu wiesz, czy zmiany zapisały się globalnie. Poprawiliśmy w ten sposób dziesiątki wdrożeń. Bez narzędzi zewnętrznych zgadujesz, a na produkcji nie ma miejsca na zgadywanie.

Na koniec po prostu weryfikuj składnię. Kropka na końcu wartości w rekordzie CNAME ma znaczenie. Oznacza bezwzględny adres. Brak kropki powoduje, że serwer dokleja na końcu twoją własną domenę. Powstają wtedy potworki typu „serwer.inna-firma.pl.mojastrona.pl”. Błąd banalny, ale kładzie usługę natychmiast.

Wyjdź teraz ze swojego panelu, zaloguj się na serwer i sprawdź konfigurację swoich rekordów pocztowych. Gwarantuję, że brakuje ci rygorystycznej polityki DMARC. Zmień to, zanim twoje maile zaczną masowo odbijać się od serwerów odbiorczych. DNS nie wybacza zaniedbań. Zostawiam cię z tym zadaniem na dzisiaj.