So beheben Sie eine langsame DNS-Abfrage

Was eine langsame Abfrage misst

Das Laden einer Seite beginnt mit einer Namensabfrage, dann einer TCP-Verbindung, dann einem TLS-Handshake, dann der eigenen Denkzeit des Servers. Nur der erste dieser Schritte ist DNS, und es ist der einzige, den Sie oft verbessern können, ohne die Website überhaupt anzufassen.

Zwei Zahlen werden hier häufig verwechselt. Eine zwischengespeicherte Abfrage kostet fast nichts, weil die Antwort schon auf Ihrem Rechner liegt oder nur einen Hop entfernt ist. Eine kalte Abfrage kann eine Anfrage an die Root beinhalten, eine weitere an die Top-Level-Domain und eine weitere an die eigenen Nameserver der Domain, jede ein Umlauf über welche Distanz auch immer Sie von diesen Servern trennt. Unter 20 ms warm und unter 100 ms kalt sind unauffällig. Alles, was sich einer Sekunde nähert, bedeutet, dass einer der Hops weit entfernt, überlastet oder in ein Timeout gelaufen ist und erneut versucht wird.

Moderne Seiten verschlimmern das, weil sie viele Hostnamen haben. Schriftarten, Analytics, Bilder und Zahlungs-Widgets brauchen jeweils ihre eigene Abfrage, und ein Browser, der zehn Hostnamen zu je 300 ms auflöst, hat drei Sekunden für DNS aufgewendet, bevor überhaupt etwas Nützliches gerendert wird.

Bestätigen, dass DNS der langsame Teil ist

Messen Sie, bevor Sie irgendetwas ändern. Der sauberste einzelne Befehl teilt eine Anfrage in ihre Phasen auf:

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

Ist time_namelookup nur ein kleiner Bruchteil des Gesamtwerts, ist DNS nicht Ihr Problem, und Sie sollten stattdessen über die Server-Antwortzeit lesen. Ist es ein Drittel oder mehr, machen Sie weiter. Für die Abfrage allein gibt dig Ihnen die verstrichene Zeit aus:

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"

Unter Windows liefert PowerShell dieselbe Messung:

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

Vergleichen Sie Ihre Vorgabe mit den öffentlichen Resolvern. Ein großer Abstand zeigt, dass die Lösung bei Ihnen liegt. Ähnliche Zeiten überall deuten auf die eigenen Nameserver der Domain.

Ein Ergebnis schließt diese Anleitung vollständig aus. Antwortet ein Resolver sofort mit NXDOMAIN, ist der Name nicht veröffentlicht, und Sie haben ein anderes Problem vor sich, beschrieben unter DNS_PROBE_FINISHED_NXDOMAIN.

Warum es passiert

• Ein entfernter Resolver. Öffentliche Dienste nutzen Anycast, sodass dieselbe Adresse von einem nahegelegenen Standort antwortet. Ein Resolver des Internetanbieters oder ein einzelner Büroserver tut das nicht, und jede Abfrage zahlt den vollen Umlauf.
• Der erste Server in der Liste ist tot. Der Client wartet sein Timeout ab und fragt dann den zweiten. Bei glibc-Systemen liegt die Vorgabe bei 5 Sekunden bis zum ersten erneuten Versuch, genau die Pause, die Menschen als "es hängt und lädt dann" beschreiben.
• Sehr niedrige TTLs. Eine TTL von 30 oder 60 Sekunden bedeutet, dass fast jeder Besucher für eine frische Abfrage bezahlt, weil die zwischengespeicherte Kopie bereits abgelaufen ist.
• Lange CNAME-Ketten. Jedes Glied ist eine weitere Abfrage. Ketten aus drei oder vier sind hinter CDNs und Marketing-Tools üblich.
• Langsame autoritative Nameserver. Ein DNS-Anbieter mit wenigen Standorten antwortet für einen Teil der Welt schnell und für den Rest langsam.
• DNSSEC-Validierung. Das Validieren einer Kette fügt Abfragen hinzu. Normalerweise ist das günstig, aber eine teilweise defekte Kette verursacht erneute Versuche, die wie Langsamkeit aussehen.
• Suchdomains. Ein mit Suffixen konfigurierter Resolver probiert example.com.corp.local vor example.com und verbraucht für jedes Suffix zuerst eine fehlgeschlagene Abfrage.
• AAAA-Abfragen ohne IPv6. Das System fragt beide Eintragstypen ab und wartet auf die Antwort, die es nicht nutzen kann.
• Ein VPN oder Filter-Proxy, der jede Abfrage durch einen Tunnel zu einem Resolver auf einem anderen Kontinent schickt.
• Ein Router als Forwarder mit einem winzigen Cache und einer zu schwachen CPU.

So beheben Sie es

Auf Ihrem Gerät

1. Leeren Sie die Caches, damit Ihre Messungen ehrlich sind: ipconfig /flushdns unter Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder unter macOS, sudo resolvectl flush-caches unter Linux.
2. Schauen Sie, welche Server konfiguriert sind und in welcher Reihenfolge: Get-DnsClientServerAddress, scutil --dns oder resolvectl status. Entfernen Sie jeden Eintrag, der nicht mehr antwortet, denn ein toter erster Eintrag kostet Sie bei jeder kalten Abfrage das Timeout.
3. Verkürzen Sie unter Linux die Wartezeit während Ihrer Untersuchung, indem Sie options timeout:2 attempts:2 zu /etc/resolv.conf hinzufügen, und entfernen Sie ungenutzte search-Suffixe.
4. Trennen Sie das VPN und messen Sie erneut. Halbiert sich die Zahl, ist der Tunnel die Ursache, und seine Resolver-Einstellung ist es, was Sie ändern müssen.

In Ihrem Netzwerk

1. Setzen Sie den Resolver per DHCP am Router statt Gerät für Gerät, damit jeder Client dasselbe schnelle Paar erhält.
2. Geben Sie dem eigenen Forwarder des Routers einen öffentlichen Resolver vorgeschaltet statt der Vorgabe des Internetanbieters, oder umgehen Sie den Forwarder ganz, indem Sie Clients die öffentlichen Adressen direkt geben.
3. Prüfen Sie bei einem Firmennetzwerk mit eigenem DNS-Server, dass er weiterleitet statt von einem einzelnen Standort aus vollständig rekursiv aufzulösen, und dass sein Cache groß genug ist, um den Arbeitstag zu überstehen.

Auf Ihrer eigenen Domain

1. Erhöhen Sie die TTLs bei Einträgen, die sich selten ändern. Fünf Minuten sind eine vernünftige Untergrenze für einen Eintrag, den Sie eventuell schnell verschieben müssen; eine Stunde oder ein Tag passt für alles Stabile.
2. Verflachen Sie CNAME-Ketten, wo Sie können. Zeigen Sie den Eintrag auf das endgültige Ziel statt auf eine Kette von Aliassen: dig www.example.com CNAME +short zeigt, wie tief Ihre geht.
3. Nutzen Sie einen DNS-Anbieter mit Anycast-Nameservern, und behalten Sie mindestens zwei Nameserver in getrennten Netzwerken.
4. Prüfen Sie, dass DNSSEC validiert. Vergleichen Sie eine normale Abfrage mit einer, die die Validierung überspringt: dig example.com @1.1.1.1 gegen dig +cd example.com @1.1.1.1. Ein großer Unterschied, oder ein SERVFAIL nur bei der ersten, bedeutet, dass die Kette defekt ist.

Prüfen Sie es von außen

Ihre eigenen Messungen beschreiben ein Netzwerk in einem Moment, was die am wenigsten aussagekräftige Stichprobe ist, die Sie nehmen können. Ein Resolver, der 8 ms von Ihnen entfernt ist, kann 400 ms von einem Kunden in einer anderen Region entfernt sein, und dieser Kunde ist es, der sich beschwert.

Beginnen Sie damit, die autoritativen Server direkt zu messen, was jeden Cache zwischen Ihnen und der Quelle entfernt:

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

Die Ausgabe von +trace geht die Delegation Schritt für Schritt durch, sodass ein stockender Hop sichtbar wird, statt weggemittelt zu werden. Führen Sie dann die DNS-Abfrageprüfung aus, die den Namen von Prüfpunkten in verschiedenen Ländern auflöst und jeden einzeln meldet. Das ist die Messung, die Sie von einem Laptop aus nicht vornehmen können: Sie zeigt, ob Ihre Nameserver überall langsam sind, was auf den Anbieter hindeutet, oder von einem Kontinent aus langsam, was auf dessen Netzwerkabdeckung hindeutet. Liefern manche Standorte eine andere Antwort statt einer langsameren, ist die Frage stattdessen die Verbreitung, behandelt unter so prüfen Sie die DNS-Verbreitung.

Latenz, die driftet statt zu brechen

DNS-Latenz bricht selten auf offensichtliche Weise. Sie driftet, ein Nameserver verliert einen Standort, eine TTL wird während einer Migration abgesenkt und nie wieder angehoben, und sechs Wochen später fühlt sich die Website träge an, aus Gründen, auf die niemand zeigen kann. Eine einzelne Messung kann keinen Trend zeigen, weshalb es sich lohnt, die Abfragezeit nach Zeitplan aus den Regionen aufzuzeichnen, in denen Ihre Besucher sind. HostTracker überwacht Websites seit 2004 und beobachtet inzwischen über 500.000 Websites von Prüfpunkten in 158 Städten und hält die Historie fest, die eine langsame Drift sichtbar macht. Die anderen Anleitungen hier finden Sie im Beheben-Bereich, und der Fehlerfall, in dem überhaupt nichts zurückkommt, ist DNS-Server antwortet nicht.