Fehlerbehebung für Domains

Wenn Google Public DNS eine Domain nicht auflösen kann, liegt das häufig an einem Problem mit dieser Domain oder ihren autoritativen Nameservern. Mit den folgenden Schritten können Sie die Ursache des Problems ermitteln, damit Domainadministratoren es selbst beheben können.

Bevor Sie mit diesen Schritten beginnen, prüfen Sie die Domain unter dns.google wie auf der allgemeinen Seite zur Fehlerbehebung beschrieben. Möglicherweise verweist sie auf einen bestimmten Diagnoseschritt unten. Andernfalls führen Sie alle folgenden Schritte aus, bis Sie die Ursache finden.

Schritt 1: Auf DNSSEC-Validierungsprobleme prüfen

Wenn bei der Suche nach dns.google für die Domain "Status": 2 (SERVFAIL) angezeigt wird und Abfragen ohne DNSSEC erfolgreich sind, liegt möglicherweise ein DNSSSEC-Problem mit den Nameservern der Domain oder der zugehörigen Top-Level-Domain-Registry (TLD) vor, die DS-Einträge für die DNSSEC-Validierung registrierter Domains veröffentlicht.

Änderungen beim Registrator oder DNS-Dienst

DNSSEC-Probleme können auftreten, nachdem eine Domain von einem Registrator oder einem DNS-Dienst, der DNSSEC unterstützt, zu einem Dienst gewechselt ist, der DNSSEC nicht unterstützt. Wenn der vorherige Dienst veraltete DS-Einträge in der TLD-Registry verlässt und der neue Dienst keine neuen DNSKEY-Einträge mit übereinstimmenden DS-Einträgen in der TLD-Registry erstellt, können Validierungsauflösungen wie Google Public DNS die Domain nicht auflösen.

Bitten Sie in diesem Fall Ihren Domain-Registrator, veraltete DS-Einträge aus der TLD-Registry zu entfernen.

DNSSEC-Antworten sind zu groß

Eine weitere Ursache für DNSSEC-Probleme können DNSSEC-Antworten sein, die zu groß für ein IP-Paket sind. Dadurch werden fragmentierte Antworten erzeugt, die möglicherweise verworfen werden. Wenn DNSViz keine Antwort anzeigt, bis die Größe der UDP-Nutzlast verringert wurde, können DNSSEC-Fehler durch sehr große Antworten verursacht werden. Die Antwortgrößen können durch eine oder mehrere der folgenden Aktionen reduziert werden:

  • Minimale Antworten für autoritative Nameserver konfigurieren
  • Anzahl der aktiven DNSKEY-Einträge auf zwei oder drei reduzieren
  • Verwenden Sie DNSKEY-Einträge mit 1.280 oder 2.048 Bit (RFC 6781, StackExchange).
  • Von RSA-Signaturen zu kleineren ECDSA-Signaturen wechseln (RFC 8624)

Prüfen Sie auch, ob andere DNSSEC-Probleme von den Tools in Schritt 2 gemeldet wurden. Beispiele hierfür sind fehlerhafte NSEC- oder NSEC3-Denial-of-Presence-Einträge, die beweisen, dass keine Subdomains vorhanden sind (PowerDNS mit in externen Datenbanken gespeicherten Zonen).

Schritt 2: Die autoritativen Nameserver prüfen

Archivierte DNSViz-Seite

Wenn bei Google Public DNS (oder einem offenen Resolver) ein Problem beim Auflösen einer Domain auftritt, zeigt DNSViz Probleme mit der Domain und dem Nameserver an, die sie verursachen. Rufen Sie die DNSViz-Webseite auf und geben Sie den problematischen Domainnamen ein. Falls DNSViz keine Verlaufsdaten hat oder nur Daten enthält, die älter als einen Tag sind (wie auf der Seite dargestellt), klicken Sie auf die große Schaltfläche Analysieren, um unten eine kleinere Schaltfläche zum Analysieren einzublenden (falls sie noch nicht sichtbar ist) und klicken Sie darauf. Wenn die Analyse abgeschlossen ist, klicken Sie auf „Weiter“, um die Ergebnisse zu sehen. Klicken Sie auf die roten Fehler- und gelben Warnungen in der linken Seitenleiste, um Details aufzurufen, oder halten Sie den Mauszeiger über Objekte im Diagramm, um diese Informationen im Kontext anzuzeigen.

Wenn bei der Diagnose früher mögliche DNSSEC-Probleme mit der Domain festgestellt wurden, rufen Sie die Webseite DNSSEC Analyzer auf und geben Sie den Domainnamen ein. Wenn dieses Analysetool DNSSEC-Fehler oder -Warnungen meldet, halten Sie den Mauszeiger über die roten ⊗- oder gelben ⚠💙-Symbole, um Vorschläge zur Behebung zu erhalten.

Auf der Webseite intoDNS werden Berichte zu Nicht-DNSSEC-Problemen mit der auf der Hauptseite eingegebenen Domain sowie Vorschläge zu deren Behebung angezeigt.

Domainadministratoren sollten die meisten Fehler dieser Tools beheben, da sie nicht nur Probleme mit Google Public DNS, sondern auch mit anderen Resolvern verursachen können.

Schritt 3: Auf Delegierungsprobleme prüfen

Google Public DNS ist ein „übergeordneter“ Resolver, der nur die Nameserver verwendet, die in Verweisen von der übergeordneten Domain zurückgegeben werden. Wenn die Nameserver-Namen und Glue-Adressen in der TLD veraltet oder falsch sind, kann dies zu Delegierungsproblemen führen.

Wenn DNSViz oder in DNS DNS Warnungen zu Inkonsistenzen zwischen den in der TLD delegierten Nameservern und denen in der untergeordneten Domain meldet, müssen diese möglicherweise behoben werden, bevor das öffentliche DNS von Google die Domain auflösen kann. Wenn in diesen Tools gemeldet wird, dass die registrierte Domain nicht vorhanden ist (NXDOMAIN), überprüfen Sie, ob die Domain aus irgendeinem Grund abgelaufen oder auf „Hold“ gesetzt ist.

Probleme bei der Delegierung können auch auftreten, wenn die Namen der Nameserver einer Domain nicht aufgelöst werden. Prüfen Sie die Einträge A und AAAA für die Nameserver in dns.google, um zu sehen, ob es Probleme mit den Nameserver-Domains gibt.

Schritt 4: Große Antworten prüfen

Der Großteil des Traffics wird über UDP abgerufen. Große UDP-Datagrams unterliegen einer Fragmentierung und fragmentiertes UDP leidet an einer unzuverlässigen Übermittlung. Dies war der Hauptzweck des DNS Flag Day 2020, mit dem wir die Zuverlässigkeit von DNS weltweit verbessern wollten. Google Public DNS hat sich daran beteiligt und begrenzt die Größe der UDP-Antworten, die es über UDP akzeptiert. Führen Sie eine Abfrage wie die folgende mit einer eigenen Eingabeaufforderung oder einer Google Cloud Shell aus:

$ dig +short example.com NS
ns1.example.com
ns2.example.com
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY
...

Diese Abfragen für verschiedene Eintragstypen geben Folgendes an:

+dnssec
Aktivieren Sie DNSSEC und geben Sie insbesondere die erforderlichen Einträge für die DNSSEC-Validierung zurück, wenn sie verfügbar sind. Dadurch kann das Ergebnis erheblich erweitert werden. Damit wird das Verhalten von Google Public DNS emuliert.
+bufsize=1400
Beschränken Sie die zulässige UDP-Puffergröße. Dies emuliert das Verhalten von Google Public DNS ab Stand des DNS Flag Day 2020.
+timeout=1
Legen Sie das Zeitlimit auf eine Sekunde fest. Damit wird das Verhalten von Google Public DNS emuliert.
@ns1.example.com
Welcher autoritative Server abgefragt werden soll: Behalten Sie das @-Zeichen bei, ersetzen Sie ansonsten den autoritativen Server Ihrer Domain, wie im ersten Befehl gezeigt.

Beobachten Sie die Ausgabe. Sehen Sie eine Zeile wie diese:

;; Truncated, retrying in TCP mode.
Das zeigt an, dass die Antwort größer war als die angeforderte UDP-Puffergröße. Sie wurde daher gekürzt und als Antwort darauf der Client auf TCP umgestellt. Ihre autoritativen Server sollten DNS-Traffic über TCP-Port 53 verarbeiten können. (Siehe RFC 7766, wofür Implementierungen UDP und TCP-Transport unterstützen MÜSSEN müssen.)
;; MSG SIZE rcvd: 2198
Für eine Zahl über 1.400? Das ist wieder eine große Antwort.
;; Query time: 727 msec
Für eine Zahl über 500? Langsame Antworten (insbesondere diejenigen, die kürzer als 1 Sekunde sind) werden vom Google Public DNS möglicherweise verworfen. Dies ist besonders wahrscheinlich, wenn ein gewisser Zeitaufwand für einen UDP-Versuch aufgewendet wurde, auf den dann ein TCP-Versuch folgte. Der geografische Standort von Server und Client kann die Latenz erheblich beeinträchtigen.
;; connection timed out; no servers could be reached
Besonders wenn das nur für einige Abfragen der Fall ist, weist das auf ein Problem hin, bei dem Ihr Server keine DNS-Abfragen zeitnah beantworten kann.

Sie können folgende Abfragevarianten ausprobieren:

Parameter +tcp hinzufügen.
Dadurch wird dig gezwungen, TCP sofort zu verwenden. Sie können prüfen, ob Ihr autoritativer Server TCP-Abfragen direkt auf diese Weise verarbeitet.
Der Parameter +bufsize=1400 wird entfernt.
Dadurch wird das Standardverhalten von dig wiederhergestellt (Fehlercode 4096). Wenn Ihre Abfragen mit dieser Einstellung fehlschlagen, aber ohne sie funktionieren, ist das ein Hinweis darauf, dass Ihr Server ein TCP-Failover nicht gut verarbeitet. Die Verwendung von UDP zur Übertragung großer Antworten funktioniert nur manchmal. Am besten unterstützen Sie den TCP-Transport für DNS.
Wird auf jedem Nameserver wiederholt.
Das Beispiel oben hat zwei autoritative Nameserver (ns1 und ns2). Einige Probleme werden durch unterschiedliche Server verursacht, die unterschiedliche Antworten zurückgeben. Achten Sie darauf, dass alle Fragen einheitlich beantwortet werden, indem Sie auf allen autoritativen Servern dieselben Abfragen wiederholen.

Wenn alle Abfragen klein (1.400 Byte oder weniger), schnell (vorzugsweise 500 Millisekunden oder schneller) und zuverlässig waren (funktioniert konsistent über TCP und UDP), ist die Antwortgröße kein Problem. Lesen Sie dazu die anderen Abschnitte zur Fehlerbehebung. Selbst wenn Ihre Antworten schnell beantwortet werden, können Abfragen aus weit entfernten Regionen länger dauern.

Wenn eine dieser Prüfungen fehlschlägt (groß? langsam? unzuverlässig?), besteht der primäre Schritt darin, A) darauf zu achten, dass Ihr Server mit UDP-Abkürzung antwortet, wenn seine Antwort die angeforderte UDP-Puffergröße und B überschreitet, dass er den TCP-Abfragewiederholungsbefehl verarbeiten kann, der folgt. Verschiedene Tools können Ihnen dabei helfen, Probleme mit der DNS-Zuverlässigkeit zu diagnostizieren:

Falls in diesen Tools Fehler oder Warnungen angezeigt werden, beheben Sie diese. Bitte lesen Sie auch alle anderen Schritte zur Fehlerbehebung auf dieser Website.

Schritt 5: Prüfen, ob andere öffentliche Resolver die Domain auflösen

Wenn Sie nach der Ausführung der Schritte oben keine Ursache für das Problem gefunden haben, führen Sie die folgenden Befehle in einer Eingabeaufforderung aus. Ersetzen Sie dabei example.test. durch die betreffende Domain und behalten Sie die nachstehenden Punkte bei:

Windows

nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.

macOS oder Linux

dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'

Diese Befehle verwenden die DNS-Resolver von OpenDNS, Quad9 und Cloudflare 1.1.1.1. Wenn sowohl bei dieser als auch bei Google Public DNS Fehler bei der Auflösung auftreten, liegt das Problem wahrscheinlich bei der Domain oder den Nameservern.

Wenn Sie von mehr als einem anderen öffentlichen Resolver ein erfolgreiches Ergebnis erhalten, liegt möglicherweise ein Problem mit Google Public DNS vor. Wenn in der Problemverfolgung keine ähnlichen Probleme für die Domain (oder deren TLD) gemeldet wurden, sollten Sie uns das Problem melden, einschließlich der Befehlsausgabe und des Diagnosetexts oder der Screenshots im Bericht.