Rozpoznawanie DNS, od początku do końca

Za każdym razem, gdy wpiszesz domenę w przeglądarkę, zanim do żądanej strony dotrze choćby jeden pakiet, uruchamia się łańcuch wyszukiwań. Większość tego łańcucha jest niewidoczna, a większość wyjaśnień kończy się na "to jakby książka telefoniczna". Oto co naprawdę się dzieje, krok po kroku, wraz z częściami, które ludzie zwykle pomijają.

Resolver niezależny nie jest inteligentny

Twój system operacyjny nie wykonuje rzeczywistego rozpoznawania DNS samodzielnie. Uruchamia resolver niezależny, cienką warstwę kodu, która po prostu przekazuje zapytanie do serwera DNS skonfigurowanego w /etc/resolv.conf na Linuksie lub w ustawieniach karty sieciowej na Windows. Sprawdź swój za pomocą:

cat /etc/resolv.conf

Ten plik zwykle wskazuje na router (jak 192.168.1.1), resolver dostawcy internetu lub publiczny taki jak 1.1.1.1 lub 8.8.8.8. Resolver niezależny nie posiada własnej logiki buforowania poza tą, którą zapewnia system operacyjny lub lokalny demon jak systemd-resolved.

Resolver rekurencyjny wykonuje prawdziwą pracę

Kiedy zapytanie trafia na resolver rekurencyjny, ten serwer przejmuje zadanie znalezienia odpowiedzi, nawet jeśli musi zapytać kilka innych serwerów. Jeśli odpowiedź jest już buforowana z poprzedniego wyszukiwania, otrzymasz ją natychmiast. Sprawdź TTL za pomocą:

dig example.com

Spójrz na ANSWER SECTION — liczba przed typem rekordu (jak 300 przed A) to TTL w sekundach. To czas, przez który resolvery mogą buforować rekord przed ponownym zapytaniem.

Jeśli nic nie jest buforowane, resolver rekurencyjny rozpoczyna przechodzenie przez hierarchię DNS od głównego serwera.

Serwery główne, TLD i serwery autorytatywne

Istnieje 13 adresów serwerów głównych (a.root-servers.net do m.root-servers.net), z których każdy wspierany jest wieloma maszynami fizycznymi za pośrednictwem routingu anycast. Serwer główny nie wie, gdzie znajduje się example.com, ale wie, które serwery obsługują .com, więc zwraca odsyłacz.

Resolver następnie pyta serwer TLD .com, który znowu nie zna ostatecznej odpowiedzi, ale wie, które nameservery są autorytatywne dla example.com. Możesz zobaczyć to delegowanie sam:

dig +trace example.com

To polecenie pokazuje każdy przeskok: główny, następnie TLD, następnie autorytatywne nameservery dla domeny, kończąc na rzeczywistym rekordie A lub AAAA. To najlepsze polecenie do wizualnego zrozumienia DNS zamiast teoretycznego.

Serwer autorytatywny to ostatnia stacja. To serwer, który właściciel domeny faktycznie skonfigurował, często za pośrednictwem panelu DNS u rejestratora lub usługi takiej jak Route 53 lub Cloudflare DNS. To jedyny serwer w całym łańcuchu, który ma rzeczywistą, kanoniczną odpowiedź zamiast buforowanej kopii lub odsyłacza.

Typy rekordów, które rzeczywiście napotkasz

Rekord A mapuje nazwę na adres IPv4, AAAA robi to samo dla IPv6. CNAME wskazuje jedną nazwę na inną nazwę zamiast adresu IP, w ten sposób sieci CDN takie jak Cloudflare lub Fastly kierują ruch bez ujawniania czystych adresów IP. Rekordy MX obsługują routing poczty, a rekordy TXT zawierają dowolny tekst, najczęściej teraz używane do SPF, DKIM i łańcuchów weryfikacji domeny. Rekordy NS mówią światu, które serwery są autorytatywne dla strefy, i to typ rekordu, który umożliwia delegowanie.

Gdzie naprawdę znajduje się buforowanie

Buffering odbywa się na wielu warstwach jednocześnie: sama przeglądarka (Chrome ma własną pamięć podręczną DNS widoczną w chrome://net-internals/#dns), pamięć podręczna resolvera systemu operacyjnego, lokalny router i upstream resolver rekurencyjny. Dlatego zmiana DNS może wydawać się działać natychmiast na jednym urządzeniu i pojawiać się godzinami na innym — nie trafiasz do tej samej pamięci podręcznej.

Kiedy obniżasz TTL rekordu przed planowaną migracją, nie przyspieszasz czegoś natychmiast. Po prostu zmniejszasz okno, podczas którego nieświeże dane mogą utrzymywać się, gdy zmiana faktycznie się ma stać. Zrób to co najmniej jeden cykl TTL wcześniej, nie pięć minut przed przełączeniem.

Dlaczego to ma znaczenie dla rozwiązywania problemów

Kiedy strona jest niedostępna, dig +trace mówi dokładnie, która warstwa jest uszkodzona: problem główny/TLD wygląda zupełnie inaczej niż nieprawidłowo skonfigurowany serwer autorytatywny lub nieświeża pamięć podręczna na własnej maszynie. Porównanie dig example.com z sprawdzonym resolverem, takim jak dig example.com @1.1.1.1, określa, czy problem jest w lokalnym resolverze czy w rzeczywistej konfiguracji DNS domeny.

DNS wygląda prosto z zewnątrz, ponieważ zwykle rozwiązuje się w poniżej 100ms i nikt o tym nie myśli. Poniżej to rozproszczony, buforowany, hierarchiczny system zapytań, który w dużej mierze niezmieniony w strukturze działa od lat osiemdziesiątych, co jest całkiem dobrym argumentem za tym, jak dobrze oryginalny projekt się sprawdził.

Jeśli chcesz pójść dalej, Korra Studio ma powiązane segmenty w DEFENSE_GRID omawiające rozszerzenia bezpieczeństwa DNS, DNS tunneling jako technikę eksfiltracji i budowanie własnego resolvera od zera w Python.