Co to Jest DNS i Jak Działa Rozwiązywanie Nazw

Co DNS naprawdę robi przy każdym żądaniu

Każde żądanie do example.com zaczyna się od wyszukania, które nie ma nic wspólnego z twoją aplikacją: coś musi zamienić tę nazwę na adres IP, zanim jakikolwiek pakiet TCP opuści maszynę. Tym tłumaczeniem jest DNS, Domain Name System, i działa przy każdym żądaniu, niezależnie od tego, czy klientem jest przeglądarka, curl, czy usługa backendowa łącząca się z inną po hostname.

Nie ma za tym jednej tabeli. DNS to hierarchia serwerów, z których każdy odpowiada za wycinek przestrzeni nazw, odpytywanych po kolei, aż przyjdzie odpowiedź. Znajomość tego łańcucha zamienia “strona nie działa” w “certyfikat wygasł” albo “rekord wciąż wskazuje na stary adres IP”: dwa zupełnie różne problemy, które z poziomu karty przeglądarki wyglądają identycznie.

Jak resolver rekurencyjny przechodzi przez hierarchię DNS

Tę pracę wykonują dwa typy serwerów, z różnymi zadaniami. Resolver rekurencyjny to ten, z którym rozmawia twoja maszyna: resolver twojego dostawcy internetu albo publiczny, jak 1.1.1.1 czy 8.8.8.8. On przechodzi całą drogę za ciebie i oddaje jedną ostateczną odpowiedź. Serwery autorytatywne przechowują właściwe rekordy domeny, rozłożone w hierarchii odzwierciedlającej kropki w nazwie.

1
2
3
4
5
6
7
8

klient   ->  resolver                             jedno zapytanie, jedna odpowiedź
             resolver -> serwer root              "kto obsługuje .com?"
                      <- nameservery dla .com
             resolver -> serwer TLD .com          "kto obsługuje example.com?"
                      <- nameservery dla example.com
             resolver -> nameserver example.com   "rekord A dla example.com?"
                      <- 93.184.216.34
klient   <-  resolver                             93.184.216.34

Serwery root nic nie wiedzą o example.com. Wiedzą tylko, które serwery obsługują .com. Serwer TLD (top-level domain) dla .com też nie przechowuje rekordu; wie tylko, które nameservery są autorytatywne dla example.com - te, na które wskazuje twój rejestrator przy konfiguracji domeny. Dopiero ten ostatni serwer przechowuje rekord A i zwraca adres IP. Trzy rundy, żeby twoja maszyna nigdy nie musiała wiedzieć, że ta hierarchia w ogóle istnieje.

Większość tej drogi nigdy nie ma miejsca przy prawdziwym zapytaniu. Resolvery cache’ują odpowiedzi z serwerów root i TLD godzinami albo dniami, bo prawie się nie zmieniają, więc realne zapytanie zwykle zaczyna się już od serwera autorytatywnego dla konkretnego rekordu. Często nawet tam nie dociera: odpowiedź jest już w cache’u.

Typy rekordów DNS, których naprawdę używasz

Serwer autorytatywny domeny przechowuje zestaw rekordów, z których każdy odpowiada na inne pytanie:

CNAME to ten, który wszystkich łapie. Nie wskazuje na adres IP; wskazuje na inną nazwę, a resolver musi ją także wyszukać, idąc łańcuchem, aż trafi na rekord A albo AAAA. CDN albo platforma SaaS daje ci hostname typu abcd123.cloudfront.net właśnie z tego powodu: może zmieniać adresy IP za tą nazwą kiedy chce i zwracać inny w zależności od tego, skąd przyszło zapytanie, bez dotykania twojego rekordu DNS.

Jedno ograniczenie zaskakuje każdego, kto konfiguruje gołą domenę: CNAME nie może współistnieć z innymi rekordami przy tej samej nazwie, a wierzchołek strefy (example.com bez subdomeny) zawsze potrzebuje rekordów NS i SOA. Nie możesz więc zrobić CNAME z wierzchołka na hostname CDN, tylko z subdomeny takiej jak www. Dostawcy obchodzą to czymś, co nazywają ALIAS, ANAME albo CNAME flattening: serwer autorytatywny sam rozwiązuje cel i zwraca rekord A, więc wierzchołek wygląda dla każdego klienta jak zwykły rekord adresowy, mimo że wciąż śledzi zmieniające się adresy IP CDN za sobą.

Jak odpytywać DNS za pomocą dig

dig zadaje te pytania bezpośrednio, bez cache’u przeglądarki po drodze.

1

dig example.com

Liczy się ANSWER SECTION:

1
2

;; ANSWER SECTION:
example.com.        300    IN    A    93.184.216.34

Pięć pól, w kolejności: zapytana nazwa, TTL w sekundach (jak długo ta odpowiedź może być cache’owana), klasa (IN dla internetu, w praktyce zawsze ta), typ rekordu i wartość. TTL równy 300 oznacza, że każdy resolver z tą odpowiedzią odpyta ponownie w ciągu pięciu minut.

Zapytaj o konkretny typ zamiast domyślnego A:

1
2
3

dig example.com MX
dig example.com TXT
dig example.com NS

Dodaj +short, kiedy chcesz samą wartość - to przydaje się w skrypcie:

1
2

dig +short example.com
93.184.216.34

Zapytaj konkretny resolver za pomocą @. Tak sprawdzasz, czy zmiana dotarła już do jednego dostawcy, zanim dotrze do ciebie:

1
2

dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

+trace odtwarza całą drogę, od serwera root aż do odpowiedzi autorytatywnej, zamiast ufać wynikowi z cache’u:

1

dig +trace example.com

nslookup robi tę samą podstawową robotę ze starszym, bardziej rozwlekłym interfejsem. Warto go znać, bo jest domyślnie dostępny w Windows, gdzie często brakuje dig.

Dlaczego zmiana DNS zajmuje czas: TTL i cache

Zmieniasz rekord i nie pojawia się wszędzie od razu. To opóźnienie nazywa się “propagacją” - słowo sugerujące, że coś rozchodzi się po internecie kopia po kopii. Nic się nie rozchodzi. Nowa wartość jest aktywna na serwerze autorytatywnym w momencie, gdy ją zapisujesz. Czasu wymaga to, że każdy resolver, który już wcześniej zcache’ował starą odpowiedź, dalej ją zwraca, aż ta kopia wygaśnie.

To zmienia pytanie, które warto zadać. Nie “jak długo trwa propagacja”, tylko “jaki TTL miał stary rekord i ile resolverów go zcache’owało”. TTL równy 300 sekund oznacza, że resolver, który odpytał minutę temu, zwraca starą odpowiedź maksymalnie przez kolejne cztery minuty. TTL równy 86400 oznacza, że jakiś resolver gdzieś na świecie odpowiada starym adresem IP jeszcze przez dobę po twojej zmianie. Niektórzy dostawcy ignorują też ustawiony przez ciebie TTL i trzymają cache dłużej, niż prosiłeś, co jest drugim powodem, dla którego dwie osoby w różnych sieciach mogą naprawdę widzieć różne odpowiedzi w trakcie zmiany.

Zaplanuj więc zmianę, zamiast czekać, aż sama przejdzie. Dzień przed planowaną migracją na nowy serwer albo nowy CDN obniż TTL rekordu, który zamierzasz zmienić, do 60 albo 300 sekund. Ten niski TTL musi najpierw dotrzeć do cache’ów i wygasić długo żyjące kopie. Potem wprowadź właściwą zmianę: każdy resolver odświeża się teraz w nowym krótkim oknie zamiast starego długiego. Podnieś TTL z powrotem, gdy nowa wartość zostanie potwierdzona.

Częste błędy DNS i sytuacje, gdy problem to nie DNS

Wiszący CNAME to najczęstszy błąd w praktyce. Subdomena nadal wskazuje na wyłączoną usługę, stary bucket S3 albo usuniętą dystrybucję CDN, a ktokolwiek przejmie tę nazwę po drugiej stronie, może serwować własną treść pod twoją domeną. Usuń rekord DNS tego samego dnia, w którym wyłączasz to, na co wskazywał, nie tygodnie później.

Brakujące albo błędne rekordy MX wyglądają jak problem serwera pocztowego. Jeśli wychodzące e-maile działają, ale nic nigdy nie dochodzi, sprawdź rekord MX domeny, zanim zaczniesz grzebać w konfiguracji serwera pocztowego; może wciąż wskazywać na usługę, z której odszedłeś miesiące temu.

Wiele zgłoszeń “DNS jest zepsuty” nie ma nic wspólnego z DNS. Jeśli dig example.com zwraca poprawny, aktualny adres IP, a strona wciąż się nie ładuje, rozwiązywanie nazwy już się udało, a problem jest dalej: reguła zapory sieciowej, niepasujący certyfikat przy handshake TLS, albo reverse proxy routujący na podstawie nagłówka Host, którego nie rozpoznaje. Sprawdź odpowiedź poleceniem dig, zanim wyciągniesz wnioski z tego, co pokazuje przeglądarka.

Gdzie sprawdzić najpierw, gdy domena się nie rozwiązuje

Uruchom dig +short <domena> na swoim resolverze systemowym i na publicznym (dig @1.1.1.1 +short <domena>). Jeśli się różnią, jesteś w trakcie zmiany, a stary TTL mówi, ile jeszcze poczekać. Jeśli się zgadzają i adres IP jest poprawny, DNS zrobił swoje: przejdź do TLS, routingu albo aplikacji. Jeśli adres IP jest błędny albo nic nie wraca, popraw to na serwerze autorytatywnym. Czyszczenie lokalnego cache’a nie zmienia niczego, co widzi ktokolwiek inny.

Powiązane artykuły

• Co to Jest CDN i Jak Działa
• Co to Jest TLS i Jak Działa Szyfrowanie HTTPS
• Co to Jest Reverse Proxy i Jak Działa