Hoe u een trage DNS-opzoeking oplost

Wat een trage opzoeking meet

Het laden van een pagina begint met een naamopzoeking, dan een TCP-verbinding, dan een TLS-handshake, dan de eigen denktijd van de server. Alleen de eerste daarvan is DNS, en dat is de enige die u vaak kunt verbeteren zonder de site zelf aan te raken.

Twee cijfers worden hier vaak door elkaar gehaald. Een opzoeking uit de cache kost bijna niets, want het antwoord staat al op uw machine of een sprong verderop. Een koude opzoeking kan een query naar de root inhouden, nog een naar het topleveldomein, en nog een naar de eigen nameservers van het domein, elk een retourtje over welke afstand er ook tussen u en die servers ligt. Onder 20 ms warm en onder 100 ms koud is niets bijzonders. Alles wat richting een seconde gaat, betekent dat een van de sprongen ver weg is, overbelast is, of vastloopt en opnieuw wordt geprobeerd.

Moderne pagina's maken dit erger doordat ze veel hostnamen hebben. Lettertypen, analytics, afbeeldingen en betaalwidgets hebben elk hun eigen opzoeking nodig, en een browser die tien hostnamen oplost tegen 300 ms per stuk, heeft al drie seconden aan DNS besteed voordat er ook maar iets nuttigs wordt weergegeven.

Bevestig dat DNS het trage onderdeel is

Meet voordat u iets verandert. Het duidelijkste enkele commando splitst een verzoek in zijn fasen:

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

Is time_namelookup een klein deel van het totaal, dan is DNS niet uw probleem en kunt u beter lezen over responstijd van de server. Is het een derde of meer, ga dan verder. Voor de opzoeking op zich toont dig de verstreken tijd:

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"

Op Windows geeft PowerShell dezelfde meting:

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

Vergelijk uw standaardresolver met de openbare resolvers. Een groot verschil vertelt u dat de oplossing bij u zit. Vergelijkbare tijden overal wijzen naar de eigen nameservers van het domein.

Eén resultaat sluit deze handleiding volledig uit. Antwoordt een resolver meteen met NXDOMAIN, dan is de naam niet gepubliceerd en kijkt u naar een ander probleem, beschreven in DNS_PROBE_FINISHED_NXDOMAIN.

Waarom het gebeurt

• Een verre resolver. Openbare diensten draaien anycast, zodat hetzelfde adres antwoordt vanaf een locatie dichtbij. Een resolver van een provider of een enkele kantoorserver doet dat niet, en elke query betaalt het volledige retourtje.
• De eerste server in de lijst is dood. De client wacht zijn time-out uit en vraagt dan de tweede. Op glibc-systemen is de standaard 5 seconden voor de eerste herhaling, precies de pauze die mensen omschrijven als "het hangt, en laadt dan".
• Zeer lage TTL's. Een TTL van 30 of 60 seconden betekent dat vrijwel elke bezoeker betaalt voor een verse opzoeking, omdat de gecachte versie al is verlopen.
• Lange CNAME-ketens. Elke schakel is nog een opzoeking. Ketens van drie of vier zijn gebruikelijk achter CDN's en marketingtools.
• Trage autoritatieve nameservers. Een DNS-provider met weinig locaties antwoordt snel voor een deel van de wereld en traag voor de rest.
• DNSSEC-validatie. Het valideren van een keten voegt queries toe. Dat is normaal goedkoop, maar een gedeeltelijk kapotte keten veroorzaakt herhalingen die op traagheid lijken.
• Zoekdomeinen. Een resolver die met achtervoegsels is ingesteld, probeert example.com.corp.local voordat hij example.com probeert, en besteedt eerst een mislukte query aan elk achtervoegsel.
• AAAA-opzoekingen zonder IPv6. Het systeem vraagt om beide recordtypes en wacht op het antwoord dat het niet kan gebruiken.
• Een VPN of filterende proxy die elke query door een tunnel stuurt naar een resolver op een ander continent.
• Een router die als forwarder optreedt met een piepkleine cache en een te zwakke processor.

Hoe u het oplost

Op uw apparaat

1. Wis de caches, zodat uw metingen eerlijk zijn: ipconfig /flushdns op Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder op macOS, sudo resolvectl flush-caches op Linux.
2. Bekijk welke servers zijn ingesteld en in welke volgorde: Get-DnsClientServerAddress, scutil --dns, of resolvectl status. Verwijder elke vermelding die niet meer antwoordt, want een dode eerste vermelding kost u de time-out bij elke koude opzoeking.
3. Verkort op Linux de wachttijd tijdens uw onderzoek door options timeout:2 attempts:2 toe te voegen aan /etc/resolv.conf, en snoei ongebruikte search-achtervoegsels.
4. Koppel de VPN los en meet opnieuw. Halveert het cijfer, dan is de tunnel de oorzaak en is de resolverinstelling ervan wat u moet veranderen.

Op uw netwerk

1. Stel de resolver in via DHCP op de router in plaats van apparaat voor apparaat, zodat elke client hetzelfde snelle paar krijgt.
2. Geef de eigen forwarder van de router een openbare resolver stroomopwaarts in plaats van de standaard van de provider, of omzeil de forwarder helemaal door clients de openbare adressen rechtstreeks te geven.
3. Controleer op een bedrijfsnetwerk met een eigen DNS-server of die doorstuurt in plaats van volledige recursie te doen vanaf één locatie, en of de cache groot genoeg is om de werkdag te overleven.

Op uw eigen domein

1. Verhoog de TTL's op records die zelden veranderen. Vijf minuten is een redelijke ondergrens voor een record dat u snel zou moeten kunnen verplaatsen; een uur of een dag past bij alles wat stabiel is.
2. Maak CNAME-ketens plat waar het kan. Laat het record naar het uiteindelijke doel wijzen in plaats van naar een keten van aliassen: dig www.example.com CNAME +short toont hoe diep de uwe gaat.
3. Gebruik een DNS-provider met anycast-nameservers, en houd minstens twee nameservers op gescheiden netwerken.
4. Controleer of DNSSEC valideert. Vergelijk een gewone query met een die validatie overslaat: dig example.com @1.1.1.1 tegenover dig +cd example.com @1.1.1.1. Een groot verschil, of een SERVFAIL alleen bij de eerste, betekent dat de keten kapot is.

Controleer het van buitenaf

Uw eigen metingen beschrijven één netwerk op één moment, wat het minst nuttige monster is dat u kunt nemen. Een resolver die 8 ms bij u vandaan is, kan 400 ms bij een klant in een andere regio vandaan zijn, en die klant is degene die klaagt.

Begin met het rechtstreeks meten van de autoritatieve servers, wat elke cache tussen u en de bron wegneemt:

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

De uitvoer van +trace loopt de delegatie stap voor stap na, zodat een sprong die vastloopt zichtbaar is in plaats van weggemiddeld. Voer vervolgens de DNS-querycontrole uit, die de naam oplost vanaf controlepunten in verschillende landen en elk apart rapporteert. Dat is de meting die u niet vanaf een laptop kunt nemen: die toont of uw nameservers overal traag zijn, wat wijst naar de provider, of traag vanaf één continent, wat wijst naar het netwerkbereik daarvan. Geven sommige locaties een ander antwoord in plaats van een tragere, dan is de vraag propagatie in plaats van snelheid, behandeld in hoe u DNS-propagatie controleert.

Latency die verschuift in plaats van kapotgaat

DNS-latency gaat zelden op een duidelijke manier kapot. Ze verschuift, een nameserver verliest een locatie, een TTL wordt tijdens een migratie verlaagd en nooit meer verhoogd, en zes weken later voelt de site traag zonder dat iemand kan zeggen waarom. Eén meting kan geen trend tonen, en daarom is het de moeite waard om de opzoektijd volgens een schema te registreren vanuit de regio's waar uw bezoekers zitten. HostTracker monitort al sinds 2004 websites en houdt inmiddels meer dan 500.000 websites in de gaten vanaf controlepunten in 158 steden, en bewaart de geschiedenis die een trage verschuiving zichtbaar maakt. De overige handleidingen hier staan in het onderdeel over oplossingen, en het geval waarin er helemaal niets terugkomt, is DNS-server reageert niet.