Jak naprawić wolne zapytanie DNS

Co właściwie mierzy wolne zapytanie

Wczytywanie strony zaczyna się od zapytania o nazwę, potem połączenia TCP, potem uzgadniania TLS, a na końcu czasu myślenia samego serwera. Tylko pierwszy z tych etapów to DNS i to jedyny, który często da się poprawić bez dotykania samej witryny.

W tym miejscu mylą się dwie liczby. Zapytanie z pamięci podręcznej kosztuje niemal nic, bo odpowiedź jest już na Twoim komputerze albo o jeden skok dalej. Zimne zapytanie może obejmować zapytanie do serwera root, kolejne do domeny najwyższego poziomu i jeszcze jedno do własnych serwerów nazw domeny, a każde to osobny cykl w obie strony na dystansie dzielącym Cię od tych serwerów. Poniżej 20 ms na ciepło i poniżej 100 ms na zimno to nic niezwykłego. Cokolwiek zbliżonego do sekundy oznacza, że jeden z etapów jest daleko, przeciążony albo przekracza limit czasu i jest ponawiany.

Nowoczesne strony pogarszają sytuację, mając wiele nazw hostów. Czcionki, analityka, obrazy i widżety płatności potrzebują każde własnego zapytania, a przeglądarka rozwiązująca dziesięć nazw hostów po 300 ms każda spędza trzy sekundy na DNS, zanim wyrenderuje cokolwiek użytecznego.

Potwierdź, że to DNS jest wolne

Zmierz, zanim cokolwiek zmienisz. Najczystsze pojedyncze polecenie dzieli żądanie na fazy:

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com

Jeśli time_namelookup to niewielki ułamek całości, DNS nie jest Twoim problemem i powinieneś raczej czytać o czasie odpowiedzi serwera. Jeśli to jedna trzecia albo więcej, czytaj dalej. Dla samego zapytania dig wypisuje czas, jaki upłynął:

dig example.com | grep "Query time"
dig @1.1.1.1 example.com | grep "Query time"
dig @8.8.8.8 example.com | grep "Query time"

W Windows PowerShell daje ten sam odczyt:

Measure-Command { Resolve-DnsName www.example.com }
Measure-Command { Resolve-DnsName www.example.com -Server 1.1.1.1 }

Porównaj swój domyślny resolver z publicznymi. Duża różnica mówi, że naprawa leży po Twojej stronie. Podobne czasy wszędzie wskazują na własne serwery nazw domeny.

Jeden wynik całkowicie wyklucza ten poradnik. Jeśli resolver odpowiada natychmiast NXDOMAIN, nazwa nie jest opublikowana i masz do czynienia z innym problemem, opisanym w DNS_PROBE_FINISHED_NXDOMAIN.

Dlaczego tak się dzieje

• Odległy resolver. Usługi publiczne działają w trybie anycast, więc ten sam adres odpowiada z pobliskiej lokalizacji. Resolver dostawcy internetu albo pojedynczy serwer biurowy tego nie robi, więc każde zapytanie płaci pełny cykl w obie strony.
• Pierwszy serwer na liście nie działa. Klient czeka na przekroczenie limitu czasu, a potem pyta drugi. W systemach opartych na glibc domyślnie jest to 5 sekund przed pierwszą ponowną próbą, co dokładnie odpowiada przerwie, którą ludzie opisują jako "zawiesza się, a potem się wczytuje".
• Bardzo niskie TTL. TTL wynoszące 30 albo 60 sekund oznacza, że niemal każdy odwiedzający płaci za świeże zapytanie, bo kopia w pamięci podręcznej już wygasła.
• Długie łańcuchy CNAME. Każde ogniwo to kolejne zapytanie. Łańcuchy złożone z trzech lub czterech ogniw są typowe za CDN-ami i narzędziami marketingowymi.
• Wolne autorytatywne serwery nazw. Dostawca DNS z niewieloma lokalizacjami odpowiada szybko dla części świata, a wolno dla reszty.
• Walidacja DNSSEC. Walidowanie łańcucha dodaje zapytania. Zwykle jest to tanie, ale częściowo zepsuty łańcuch powoduje ponowne próby, które wyglądają jak spowolnienie.
• Domeny wyszukiwania. Resolver skonfigurowany z sufiksami próbuje najpierw example.com.corp.local, zanim spróbuje example.com, tracąc jedno nieudane zapytanie na każdy sufiks.
• Zapytania AAAA bez IPv6. System pyta o oba typy rekordów i czeka na odpowiedź, której i tak nie może użyć.
• VPN albo proxy filtrujące, wysyłające każde zapytanie przez tunel do resolvera na innym kontynencie.
• Router działający jako forwarder, z maleńką pamięcią podręczną i słabym procesorem.

Jak to naprawić

Na Twoim urządzeniu

1. Wyczyść pamięci podręczne, żeby pomiary były uczciwe: ipconfig /flushdns w Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder w macOS, sudo resolvectl flush-caches w Linuksie.
2. Sprawdź, jakie serwery są skonfigurowane i w jakiej kolejności: Get-DnsClientServerAddress, scutil --dns albo resolvectl status. Usuń każdy wpis, który już nie odpowiada, bo martwy pierwszy wpis kosztuje Cię limit czasu przy każdym zimnym zapytaniu.
3. W Linuksie skróć czekanie na czas badania, dodając options timeout:2 attempts:2 do /etc/resolv.conf, i przytnij nieużywane sufiksy search.
4. Rozłącz VPN i zmierz ponownie. Jeśli wartość spada o połowę, przyczyną jest tunel i to jego ustawienie resolvera trzeba zmienić.

W Twojej sieci

1. Ustaw resolver w DHCP na routerze, zamiast robić to na każdym urządzeniu osobno, tak żeby każdy klient dostawał tę samą, szybką parę.
2. Daj własnemu forwarderowi routera publiczny resolver jako źródło nadrzędne zamiast domyślnego od dostawcy internetu, albo pomiń forwarder całkowicie, przekazując klientom publiczne adresy bezpośrednio.
3. W sieci firmowej z własnym serwerem DNS sprawdź, czy przekazuje on zapytania dalej, zamiast wykonywać pełną rekurencję z jednej lokalizacji, i czy jego pamięć podręczna jest wystarczająco duża, by przetrwać dzień roboczy.

Na Twojej własnej domenie

1. Podnieś TTL na rekordach, które rzadko się zmieniają. Pięć minut to rozsądne minimum dla rekordu, który może trzeba będzie szybko przenieść; godzina albo dzień pasują do wszystkiego stabilnego.
2. Spłaszcz łańcuchy CNAME tam, gdzie się da. Wskaż rekordem bezpośrednio na cel końcowy zamiast na łańcuch aliasów: dig www.example.com CNAME +short pokazuje, jak głęboki jest Twój.
3. Użyj dostawcy DNS z serwerami nazw w trybie anycast i trzymaj co najmniej dwa serwery nazw w oddzielnych sieciach.
4. Sprawdź, czy DNSSEC się waliduje. Porównaj zwykłe zapytanie z takim, które pomija walidację: dig example.com @1.1.1.1 względem dig +cd example.com @1.1.1.1. Duża różnica albo SERVFAIL tylko w pierwszym przypadku oznaczają, że łańcuch jest zepsuty.

Sprawdź to z zewnątrz

Twoje własne pomiary opisują jedną sieć w jednej chwili, co jest najmniej przydatną próbką, jaką możesz wziąć. Resolver oddalony od Ciebie o 8 ms może być oddalony o 400 ms od klienta w innym regionie, a to właśnie ten klient się skarży.

Zacznij od zmierzenia bezpośrednio serwerów autorytatywnych, co usuwa każdą pamięć podręczną między Tobą a źródłem:

dig NS example.com +short
dig @ns1.example-dns.net example.com | grep "Query time"
dig example.com +trace

Wynik +trace pokazuje delegację krok po kroku, więc etap, który się zawiesza, jest widoczny, zamiast zostać uśredniony. Następnie uruchom sprawdzenie zapytania DNS, które rozwiązuje nazwę z punktów kontrolnych w różnych krajach i raportuje każdy z osobna. To pomiar, którego nie zrobisz z laptopa: pokazuje, czy Twoje serwery nazw są wolne wszędzie, co wskazuje na dostawcę, czy wolne z jednego kontynentu, co wskazuje na zasięg jego sieci. Jeśli niektóre lokalizacje zwracają inną odpowiedź, a nie po prostu wolniejszą, pytanie dotyczy raczej propagacji, co opisuje jak sprawdzić propagację DNS.

Opóźnienie, które dryfuje, zamiast się psuć

Opóźnienie DNS rzadko psuje się w oczywisty sposób. Dryfuje: serwer nazw traci lokalizację, TTL zostaje obniżony podczas migracji i nigdy nie podniesiony z powrotem, a sześć tygodni później witryna wydaje się ociężała z powodów, których nikt nie potrafi wskazać. Pojedynczy pomiar nie pokaże trendu, dlatego warto rejestrować czas zapytania według harmonogramu, z regionów, w których są Twoi odwiedzający. HostTracker monitoruje witryny od 2004 roku, a teraz obserwuje ponad 500 000 witryn z punktów kontrolnych w 158 miastach, zachowując historię, która sprawia, że powolny dryf staje się widoczny. Pozostałe poradniki znajdziesz w grupie poradników "napraw to", a przypadek awarii, gdy nic w ogóle nie wraca, opisuje DNS server not responding.