Wpisanie adresu strony do przeglądarki wygląda jak najprostsza czynność w internecie. Człowiek podaje nazwę, na przykład xarox.pl, naciska Enter i po chwili widzi witrynę. Komputer nie posługuje się jednak nazwami w taki sposób jak my. Aby nawiązać połączenie, potrzebuje adresu IP serwera. Tłumaczeniem jednej postaci adresu na drugą zajmuje się DNS, czyli Domain Name System.
DNS bywa nazywany książką telefoniczną internetu, ale to porównanie jest tylko częściowo trafne. Nie istnieje jedna centralna książka ze wszystkimi domenami. Zamiast niej działa rozproszony, hierarchiczny system, w którym różne organizacje odpowiadają za różne fragmenty przestrzeni nazw. Dzięki temu miliardy urządzeń mogą pytać o domeny bez pobierania jednej gigantycznej bazy.
Zanim powstał DNS, wystarczał jeden plik
We wczesnej sieci liczba komputerów była na tyle mała, że mapowanie nazw na adresy można było przechowywać w pliku HOSTS.TXT. Network Information Center utrzymywało jego główną wersję, a pozostałe maszyny regularnie ją pobierały. Rozwiązanie działało, dopóki sieć była niewielka. Każdy nowy host i każda zmiana wymagały jednak aktualizacji centralnego spisu oraz rozesłania kolejnej kopii.
Paul Mockapetris opisał problem w RFC 1034. Wraz ze wzrostem liczby komputerów rosło obciążenie serwera udostępniającego plik, a lokalne organizacje musiały czekać, aż ich zmiany zostaną uwzględnione. Potrzebny był system rozproszony, w którym odpowiedzialność można przekazywać niżej. Pierwsze specyfikacje DNS opublikowano w 1983 roku, a dojrzały opis architektury i protokołu znalazł się w dokumentach RFC 1034 i RFC 1035 z listopada 1987 roku.
Domena jest drzewem czytanym od prawej strony
Nazwa domenowa ma strukturę drzewa. Najwyżej znajduje się niewidoczny na co dzień korzeń oznaczany kropką. Niżej są domeny najwyższego poziomu, takie jak .pl, .com czy .org. Pod nimi znajdują się domeny drugiego poziomu, a następnie subdomeny. W nazwie www.example.pl resolver analizuje elementy od prawej: najpierw korzeń, potem pl, następnie example, a na końcu www.
Każdy fragment oddzielony kropką jest etykietą. Specyfikacja RFC 1035 ogranicza długość pojedynczej etykiety do 63 oktetów, a pełnej nazwy zapisanej w protokole do 255 oktetów. Wielkość liter nie zmienia wyniku: XAROX.PL i xarox.pl są z punktu widzenia DNS tą samą nazwą.
Hierarchia pozwala delegować odpowiedzialność. Operator strefy .pl nie musi znać adresów wszystkich serwerów każdej polskiej witryny. Wystarczy, że wie, które serwery nazw są autorytatywne dla konkretnej domeny. Z kolei właściciel domeny może zarządzać jej rekordami bez proszenia operatora całej końcówki krajowej o każdą zmianę.
Co dzieje się po naciśnięciu Enter
Przeglądarka najpierw sprawdza, czy odpowiedź nie jest już dostępna lokalnie. Informacja mogła zostać zapamiętana przez samą przeglądarkę albo system operacyjny. Jeśli jej nie ma, komputer wysyła pytanie do skonfigurowanego resolvera rekurencyjnego. Zwykle dostarcza go operator internetu, administrator sieci firmowej albo wybrana usługa publiczna.
Resolver wykonuje pracę w imieniu użytkownika. Gdy nie ma odpowiedzi w swojej pamięci podręcznej, rozpoczyna poszukiwanie od serwerów korzenia. Korzeń nie zwraca jeszcze adresu żądanej witryny. Wskazuje serwery odpowiedzialne za odpowiednią domenę najwyższego poziomu. Serwer .pl odsyła następnie do autorytatywnych serwerów konkretnej domeny, a dopiero one udzielają właściwej odpowiedzi.
W dokumentacji IANA widnieje trzynaście identyfikatorów serwerów korzenia, od A do M. Nie oznacza to trzynastu fizycznych maszyn ustawionych w jednym miejscu. Poszczególni operatorzy utrzymują wiele instancji rozproszonych geograficznie. Dla resolvera ważne są jednak stabilne nazwy i adresy punktów startowych, zapisane zwykle w tak zwanym pliku root hints.
Cała ścieżka może wydawać się długa, ale rzadko jest wykonywana od początku dla każdego otwarcia strony. Największe znaczenie ma pamięć podręczna. Resolver zachowuje uzyskane informacje i przez określony czas odpowiada na kolejne pytania bez ponownego przechodzenia przez wszystkie poziomy drzewa.
DNS przechowuje więcej niż adres strony
Najbardziej znany jest rekord A, który wiąże nazwę z adresem IPv4. Jego odpowiednikiem dla IPv6 jest rekord AAAA. DNS przechowuje jednak także inne rodzaje danych. Rekord MX wskazuje serwery obsługujące pocztę dla domeny, NS określa serwery nazw, CNAME tworzy alias prowadzący do innej nazwy, a TXT pozwala publikować dane tekstowe. W praktyce rekordy TXT są dziś używane między innymi do weryfikowania własności domen i konfigurowania zabezpieczeń poczty.
Każdy rekord ma parametr TTL, czyli czas, przez jaki wolno przechowywać go w pamięci podręcznej przed ponownym zapytaniem źródła. Jak opisuje specyfikacja formatu rekordów DNS, po upływie TTL resolver powinien ponownie skonsultować się ze źródłem informacji. Długi TTL zmniejsza liczbę zapytań i obciążenie serwerów, ale sprawia, że zmiana adresu rozchodzi się wolniej. Krótki przyspiesza aktualizacje kosztem większego ruchu.
To właśnie stąd bierze się potoczne stwierdzenie o „propagacji DNS”. Nie ma jednego globalnego przycisku, który jednocześnie odświeża internet. Gdy administrator zmienia rekord, część resolverów zobaczy nową wartość od razu, a część będzie jeszcze korzystać z poprzedniej odpowiedzi do końca jej TTL.
Dlaczego awaria DNS wygląda jak awaria internetu
Jeśli resolver nie otrzyma poprawnej odpowiedzi, przeglądarka nie wie, z jakim adresem IP ma się połączyć. Sama sieć może działać, serwer może być sprawny, a mimo to witryna pozostaje niedostępna pod swoją nazwą. To dlatego problemy z DNS bywają mylone z awarią łącza albo hostingu.
Rozproszona budowa ogranicza ryzyko jednego centralnego punktu awarii. Domena może mieć kilka autorytatywnych serwerów, a dane są kopiowane i buforowane w wielu miejscach. Nie oznacza to pełnej odporności. Błędna delegacja, niepoprawny rekord, wygaśnięcie domeny lub awaria usługodawcy DNS nadal mogą odciąć użytkowników od działającego serwera.
Autentyczność i prywatność to dwa różne problemy
Klasyczny DNS powstał w czasach, gdy priorytetem były skalowalność i dostępność, a nie ochrona przed podszywaniem się pod odpowiedzi. Rozszerzenie DNSSEC dodaje podpisy kryptograficzne, dzięki którym walidujący resolver może sprawdzić pochodzenie danych i wykryć ich zmianę. RFC 4033 podkreśla jednak, że DNSSEC nie zapewnia poufności: zapytania nie stają się przez to niewidoczne dla obserwatora.
Szyfrowanie połączenia między urządzeniem a resolverem realizują inne mechanizmy, między innymi DNS over HTTPS. Zgodnie z RFC 8484 DoH i DNSSEC rozwiązują odrębne problemy i mogą działać razem. DoH chroni transport zapytania do wybranego resolvera, natomiast DNSSEC pozwala zweryfikować autentyczność podpisanych danych. Żaden z tych mechanizmów sam w sobie nie sprawia też, że operator resolvera przestaje widzieć pytania.
Niewidzialna infrastruktura codzienności
ICANN opisuje DNS jako system łączący nazwy domenowe z adresami IP. W praktyce jego rola jest szersza: kieruje pocztę, wspiera weryfikację usług, pomaga rozdzielać ruch i pozwala administratorom zmieniać infrastrukturę bez zmuszania użytkowników do zapamiętywania nowych numerów.
Największym sukcesem DNS jest jego niewidoczność. Podczas zwykłego otwarcia strony współpracują ze sobą pamięć urządzenia, resolver rekurencyjny, serwery korzenia, rejestr domeny najwyższego poziomu i serwery autorytatywne. Użytkownik widzi tylko nazwę. System zaprojektowany dla znacznie mniejszej sieci nadal działa, ponieważ od początku rozdzielał odpowiedzialność, korzystał z hierarchii i zakładał intensywne użycie pamięci podręcznej.