Coś się zepsuło. Strona się nie ładuje, maile się odbijają, albo godzinę temu zmieniłeś rekord i nic się nie dzieje. W dziewięciu przypadkach na dziesięć odpowiedź siedzi w DNS — trzeba tylko wiedzieć, jak spojrzeć.
DNS to książka adresowa internetu: zamienia example.com na IP, z którym przeglądarka faktycznie może się połączyć. Gdy szwankuje, wszystko dalej w łańcuchu wygląda na zepsute, choć serwer jest cały. Przejdźmy przez to, jak czytać go jak należy.
Rekordy, które warto znać
Nie trzeba ich znać wszystkich na pamięć. Oto te, które się przewijają:
| Rekord | Co robi | Kiedy gryzie |
|---|---|---|
| A | Mapuje nazwę na adres IPv4 | Strona wskazuje na zły/stary serwer |
| AAAA | To samo, ale IPv6 | Użytkownicy IPv6 cię nie dosięgają |
| MX | Dokąd trafia poczta domeny | Maile się odbijają albo znikają |
| TXT | Dowolny tekst — SPF, DKIM, weryfikacja | Poczta ląduje w spamie; weryfikacja pada |
| NS | Które serwery nazw są autorytatywne | Cała domena rozwiązuje się źle |
| CNAME | Alias wskazujący jedną nazwę na drugą | Subdomena się nie rozwiązuje |
| SOA | Metadane administracyjne strefy | Rzadko — ale wskazuje główny NS |
| CAA | Które CA mogą wystawiać ci certyfikaty | Wydanie certyfikatu zostaje odrzucone |
Nasze narzędzie DNS lookup odpytuje wszystkie dziesięć obsługiwanych typów — A, AAAA, MX, TXT, NS, CNAME, SOA, CAA, SRV i PTR — wobec wybranego resolvera: Google (8.8.8.8), Cloudflare (1.1.1.1) lub Quad9 (9.9.9.9), i pokazuje surowy wynik w stylu dig z zachowanymi TTL. Czytasz to samo, co sysadmin widzi w terminalu.
Widzisz rekord A wskazujący na nieznane IP? IP WHOIS w sekundy powie, do kogo należy.
TTL: liczba, którą wszyscy ignorują, dopóki nie zaczyna mieć znaczenia
Każdy rekord niesie TTL — time to live, w sekundach. To jak długo resolverom wolno cache'ować odpowiedź, zanim zapytają ponownie. TTL 3600 znaczy „ufaj temu przez godzinę".
Ta jedna liczba tłumaczy większość paniki „moja zmiana DNS nie działa". Prosty przykład: poprawiasz rekord A o 12:00, ale jego TTL to 86400 (całą dobę). Resolwery, które odpytały twoją domenę o 11:30, przez prawie 24 kolejne godziny wciąż zwracają stare IP — więc dla części użytkowników strona „przenosi się" dopiero następnego dnia. Nic się nie zepsuło; po prostu powiedziałeś im, że mogą cache'ować tę odpowiedź przez dobę.
Praktyczna zasada, której się trzymamy: obniż TTL dzień wcześniej, zanim zaplanujesz zmianę rekordu. Zejdź do 300 sekund, poczekaj, aż wygaśnie stary wysoki TTL, i dopiero wtedy wprowadź zmianę. Teraz przełączenie propaguje się w minuty zamiast w dobę. Potem podnieś TTL z powrotem, żeby resolwery nie odpytywały bez przerwy twoich serwerów nazw.
„Zmieniłem — czemu nie jest na żywo?"
Bo DNS nie ma przycisku „odśwież". Nie ma centralnego serwera, do którego się pushuje. Twój autorytatywny serwer nazw ma nową wartość natychmiast — ale każdy resolver, który już zcache'ował starą, będzie ją podawał, dopóki nie wygaśnie jego TTL. A różne resolwery, w różnych krajach, wygasają w różnych momentach.
Dokładnie dlatego zbudowaliśmy sprawdzarkę propagacji DNS tak, jak ją zbudowaliśmy. Zamiast zapytać jeden resolver i na tym poprzestać, wystrzeliwuje to samo zapytanie równolegle do 15 publicznych resolverów rozsianych po świecie — Google i Cloudflare w USA, Quad9 w Szwajcarii, Mullvad w Szwecji, CZ.NIC w Czechach, Alibaba i DNSPod w Chinach i inne. Widzisz, jak nowy rekord zapala się region po regionie, gdy wygasają cache. Gdy wszystkie 15 się zgadza, naprawdę się spropagowałeś.
Reguła kciuka: „propagacja" to nie wolny internet. To cache honorujące TTL, który ustawiłeś.
Gdy problemem jest sam resolver
Czasem rekordy są poprawne wszędzie, a strona i tak rozwiązuje się ślamazarnie. To wskazuje na opóźnienie resolvera, nie na wartości rekordów.
Nasze narzędzie czasu odpowiedzi DNS mierzy właśnie to: uruchamia dig wobec tych samych 15 resolverów, po kilka razy każdy, i raportuje minimum, maksimum oraz średni czas zapytania na resolver. Jeśli twoi użytkownicy są w Niemczech, a twoje serwery nazw odpowiadają Frankfurtowi w 8 ms, ale Sydney w 280 ms, to realny, mierzalny sygnał — może czas na dostawcę DNS anycast.
Kto rządzi strefą: WHOIS i serwery nazw
Jeśli rekordy NS wyglądają źle, pytanie brzmi kto je ustawił. Domain WHOIS daje ci rejestratora, daty rejestracji i wygaśnięcia, kody statusu domeny, czy DNSSEC jest włączony i — co kluczowe — serwery nazw, które rejestr ma w aktach.
Jedna rzecz warta wiedzy, bo tańsze narzędzia robią to źle: wiele nowszych rozszerzeń jak .tools, .app i .dev w ogóle nie prowadzi tradycyjnego serwera WHOIS. Zapytasz je po staremu — nic nie dostaniesz. Nasz lookup automatycznie przechodzi na RDAP — nowoczesny zamiennik oparty na JSON — gdy tylko wykryje chudą lub brakującą odpowiedź WHOIS, więc domena .tools zwraca ten sam uporządkowany wynik co .com. Natknęliśmy się na to zresztą na własnej domenie. Poprawka stała się funkcją.
Jeśli serwery nazw w rejestrze nie zgadzają się z tym, co ustawiłeś u swojego hosta DNS, znalazłeś swój błąd: domena wskazuje zupełnie gdzie indziej i żadna edycja rekordów nie pomoże, dopóki nie naprawi się delegacji NS.
Szybka lista kontrolna, gdy DNS „nie działa"
- Sprawdź rekord, który zmieniłeś, narzędziem lookup. Czy nowa wartość w ogóle tam jest?
- Sprawdź TTL. Wysoki? Po prostu czekasz na wygaśnięcie cache'a.
- Zrób sprawdzenie propagacji. Mieszane wyniki po regionach = cache jeszcze wygasają; spójne wszędzie = jest na żywo.
- Zweryfikuj rekordy NS wobec swojego hosta DNS przez WHOIS. Rozbieżność delegacji jest prawdziwym winowajcą częściej, niż myślisz.
- Wciąż wolno? Zmierz czas odpowiedzi resolvera, zanim obwinisz swoją aplikację.
Podsumowując
Większość „awarii" DNS to nie awarie. To TTL robiące dokładnie to, co im kazałeś, albo delegacja wskazująca gdzieś, o czym zapomniałeś. Czytaj rekordy, szanuj TTL i sprawdzaj propagację na więcej niż jednym resolverze, zanim cokolwiek stwierdzisz. Zacznij od lookupu — odpowiedź zwykle jest tuż tam, w wyniku.
— zespół checkbox.tools