Jak opravit pomalé vyhledávání DNS

Co pomalé vyhledávání vlastně měří

Načítání stránky začíná vyhledáním názvu, pak přijde spojení TCP, pak handshake TLS a pak vlastní čas přemýšlení serveru. Jen to první je DNS, a je to jediné, co často jde zlepšit, aniž byste se dotkli samotného webu.

Zde se pletou dvě čísla. Vyhledání z cache stojí téměř nic, protože odpověď je už na vašem počítači nebo jeden krok daleko. Studené vyhledání může zahrnovat dotaz na kořen, další na doménu nejvyšší úrovně a další na vlastní jmenné servery domény, každý jako zpáteční cesta přes jakoukoli vzdálenost, která vás od těch serverů dělí. Pod 20 ms za tepla a pod 100 ms za studena je bezpříznakové. Cokoli blížící se sekundě znamená, že jeden z kroků je daleko, přetížený, nebo vyprší a opakuje se.

Moderní stránky to zhoršují tím, že mají mnoho názvů hostitelů. Fonty, analytika, obrázky a platební widgety potřebují každý vlastní vyhledání, a prohlížeč, který přeloží deset názvů hostitelů po 300 ms, stráví na DNS tři sekundy dřív, než vykreslí cokoli užitečného.

Potvrďte, že DNS je pomalá část

Než cokoli změníte, změřte to. Nejčistší jediný příkaz rozdělí požadavek na jeho fáze:

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

Pokud je time_namelookup jen malý zlomek celkového času, DNS není váš problém a měli byste místo toho číst o době odezvy serveru. Pokud je to třetina nebo víc, pokračujte. Pro samotné vyhledání vám dig vypíše uplynulý čas:

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"

Na Windows dá stejný výsledek PowerShell:

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

Porovnejte svůj výchozí resolver s veřejnými. Velký rozdíl vám řekne, že oprava je na vaší straně. Podobné časy všude ukazují na vlastní jmenné servery domény.

Jeden výsledek tento návod úplně vylučuje. Pokud resolver okamžitě odpoví NXDOMAIN, název není publikovaný a díváte se na jiný problém, popsaný v DNS_PROBE_FINISHED_NXDOMAIN.

Proč k tomu dochází

• Vzdálený resolver. Veřejné služby provozují anycast, takže stejná adresa odpovídá z nejbližší lokality. Resolver poskytovatele internetu nebo jediný firemní server to neumí, a každý dotaz platí celou zpáteční cestu.
• První server v seznamu je mrtvý. Klient vyčká svůj časový limit, pak se zeptá druhého. Na systémech s glibc je výchozí hodnota 5 sekund před prvním opakováním, což je přesně ta pauza, kterou lidé popisují jako "zasekne se, pak se to načte".
• Velmi nízké TTL. TTL 30 nebo 60 sekund znamená, že téměř každý návštěvník platí za čerstvé vyhledání, protože kopie z cache už vypršela.
• Dlouhé řetězce CNAME. Každý článek je další vyhledání. Řetězce o třech nebo čtyřech článcích jsou běžné za CDN a marketingovými nástroji.
• Pomalé autoritativní jmenné servery. Poskytovatel DNS s málo lokalitami odpovídá rychle pro část světa a pomalu pro zbytek.
• Validace DNSSEC. Ověření řetězce přidává dotazy. Obvykle je to levné, ale částečně rozbitý řetězec způsobuje opakování, která vypadají jako pomalost.
• Vyhledávací domény. Resolver nastavený s příponami zkusí example.com.corp.local dřív než example.com, přičemž utratí neúspěšný dotaz na každou příponu jako první.
• Dotazy AAAA bez IPv6. Systém se ptá na oba typy záznamů a čeká na odpověď, kterou nemůže použít.
• VPN nebo filtrující proxy, která posílá každý dotaz tunelem na resolver na jiném kontinentu.
• Router fungující jako forwarder s malou cache a slabým procesorem.

Jak to opravit

Na vašem zařízení

1. Vyprázdněte cache, aby vaše měření byla poctivá: ipconfig /flushdns na Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder na macOS, sudo resolvectl flush-caches na Linuxu.
2. Podívejte se, které servery jsou nastavené a v jakém pořadí: Get-DnsClientServerAddress, scutil --dns, nebo resolvectl status. Odstraňte každou položku, která už neodpovídá, protože mrtvá první položka vás stojí časový limit u každého studeného vyhledání.
3. Na Linuxu si zkraťte čekání během vyšetřování přidáním options timeout:2 attempts:2 do /etc/resolv.conf a odstraňte nepoužívané přípony search.
4. Odpojte VPN a změřte znovu. Pokud se číslo sníží na polovinu, příčinou je tunel a je potřeba změnit nastavení jeho resolveru.

Ve vaší síti

1. Nastavte resolver v DHCP na routeru místo zařízení po zařízení, aby každý klient dostal stejnou rychlou dvojici.
2. Dejte vlastnímu forwarderu routeru veřejný resolver výše v hierarchii místo výchozího poskytovatele internetu, nebo forwarder úplně obejděte tím, že klientům předáte veřejné adresy přímo.
3. Na firemní síti s vlastním serverem DNS zkontrolujte, že přeposílá, místo aby dělal plnou rekurzi z jednoho místa, a že jeho cache je dost velká, aby přežila celý pracovní den.

Na vlastní doméně

1. Zvyšte TTL u záznamů, které se mění zřídka. Pět minut je rozumné minimum pro záznam, který byste možná potřebovali rychle přesunout; hodina nebo den se hodí pro vše stabilní.
2. Kde to jde, zplošťte řetězce CNAME. Namiřte záznam přímo na konečný cíl místo řetězce aliasů: dig www.example.com CNAME +short ukáže, jak hluboký je ten váš.
3. Použijte poskytovatele DNS s anycast jmennými servery a udržujte alespoň dva jmenné servery na oddělených sítích.
4. Zkontrolujte, že DNSSEC validuje. Porovnejte běžný dotaz s tím, který validaci přeskočí: dig example.com @1.1.1.1 proti dig +cd example.com @1.1.1.1. Velký rozdíl, nebo SERVFAIL jen u prvního, znamená, že je řetězec rozbitý.

Zkontrolujte to zvenčí

Vaše vlastní časy popisují jednu síť v jednom okamžiku, což je nejméně užitečný vzorek, jaký můžete získat. Resolver, který je od vás 8 ms daleko, může být od zákazníka v jiném regionu 400 ms daleko, a stěžuje si právě ten zákazník.

Začněte měřením přímo autoritativních serverů, čímž odstraníte každou cache mezi vámi a zdrojem:

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

Výstup +trace prochází delegování krok po kroku, takže krok, který se zasekne, je vidět místo toho, aby se rozpustil v průměru. Pak spusťte kontrolu DNS dotazu, která přeloží název z kontrolních bodů v různých zemích a nahlásí každý zvlášť. To je měření, které z notebooku nezískáte: ukáže, zda jsou vaše jmenné servery pomalé všude, což ukazuje na poskytovatele, nebo pomalé z jednoho kontinentu, což ukazuje na jeho síťové pokrytí. Pokud některé lokality vrátí jinou odpověď místo pomalejší, otázkou je místo toho šíření, popsané v jak zkontrolovat šíření DNS.

Latence, která se spíš rozjíždí, než že by se rozbila

Latence DNS se málokdy rozbije zjevným způsobem. Spíš se pomalu rozjíždí, jmenný server ztratí lokalitu, TTL se sníží během migrace a už nikdy se nezvýší zpátky, a o šest týdnů později je web pro všechny nepříjemně pomalý z důvodů, na které nikdo nedokáže ukázat. Jediné měření nemůže ukázat trend, a proto se vyplatí zaznamenávat dobu vyhledání pravidelně z regionů, kde jsou vaši návštěvníci. HostTracker monitoruje weby od roku 2004 a nyní sleduje přes 500 000 webů z kontrolních bodů ve 158 městech, čímž udržuje historii, která pomalý posun zviditelní. Ostatní návody zde jsou v sekci oprav, a případ selhání, kdy se nevrátí vůbec nic, je DNS server not responding.