Wie behebe ich NXDOMAIN-Antworten, wenn ich Route 53 als DNS-Dienst verwende?

Lesedauer: 6 Minute
0

Ich erhalte eine NXDOMAIN-Antwort (Domain nicht vorhanden) vom DNS-Resolver oder einen Fehler DNS_PROBE_FINISHED_NXDOMAIN, wenn ich versuche, Datensätze in Amazon Route 53 aufzulösen.

Kurzbeschreibung

Möglicherweise erhältst du eine NXDOMAIN-Antwort oder einen Fehler DNS_PROBE_FINISHED_NXDOMAIN, wenn ein DNS-Resolver den angeforderten Domainnamen nicht finden kann. Dies kann durch eine Sperrung der Domain, falsch konfigurierte Nameserver oder fehlende DNS-Einträge verursacht werden.

Lösung

Prüfen, ob die Domain aktiv oder gesperrt ist

Gehe wie folgt vor, um zu überprüfen, ob die Domain aktiv oder gesperrt ist.

  1. Führe eine WHOIS-Abfrage für die Domain durch.
    Stelle sicher, dass WHOIS installiert ist, bevor du die folgenden Befehle ausführst.
    Für Windows: Öffnen Sie eine Windows-Eingabeaufforderung und geben Sie dann whois -v example.com ein.
    Für Linux: Öffnen Sie Ihren SSH-Client. Gib in der Eingabeaufforderung whois example.com ein.
    Wenn die Domain bei Amazon Registrar registriert ist, kannst du das WHOIS-Suchtool von Amazon Registrar verwenden.
  2. Prüfe den Status der Domain. Wenn der Wert von „Domain Status“ „clientHold“ ist, wird die Domain gesperrt.

Häufige Gründe für die Sperrung einer Domain:

  • Die Bestätigungs-E-Mail wurde nach der Domainregistrierung nicht verifiziert.
  • Die automatische Verlängerung wurde deaktiviert und die Domain ist abgelaufen.
  • Die E-Mail-Adresse des Registranten wurde geändert, aber nie verifiziert.

Weitere Informationen findest du unter Meine Domain ist gesperrt (Status ist ClientHold).

Beispiel für eine WHOIS-Ausgabe:

whois example.com
   Domain Name: EXAMPLE.COM
   Registry Domain ID: 87023946_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.godaddy.com
   Registrar URL: http://www.godaddy.com
   Updated Date: 2020-05-08T10:05:49Z
   Creation Date: 2002-05-28T18:22:16Z
   Registry Expiry Date: 2021-05-28T18:22:16Z
   Registrar: GoDaddy.com, LLC
   Registrar IANA ID: 146
   Registrar Abuse Contact Email: abuse@godaddy.com
   Registrar Abuse Contact Phone: 480-624-2505
   Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
   Domain Status: clientHold https://icann.org/epp#clientHold  
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
   Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
   Name Server: ns-1470.awsdns-55.org.
   Name Server: ns-1969.awsdns-54.co.uk.
   Name Server: ns-736.awsdns-28.net.
   Name Server: ns-316.awsdns-39.com.

Vergewissere dich, dass die richtigen Nameserver konfiguriert sind

Du kannst autoritative Nameserver anzeigen, indem du die WHOIS-Ausgabe oder den Befehl dig +trace verwenden.

Gehe wie folgt vor, um die Einstellungen für gehostete Zonen in Route 53 zu überprüfen:

  1. Öffne die Amazon Route 53-Konsole.
  2. Wähle im Navigationsbereich Gehostete Zonen.
  3. Wähle die gewünschte gehostete Zone und klicke dann auf Details anzeigen.
  4. Wähle Details zur gehosteten Zone.
  5. Vergleiche die aufgelisteten Nameserver mit denen im WHOIS oder in der dig +traceAusgabe.

Wichtig: Wenn sich die Nameserver unterscheiden, aktualisiere sie beim Domain-Registrar.

Beispiel für eine dig +trace-Ausgabe:

dig +trace example.com  
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.2 <<>> +trace example.com
;; global options: +cmd
.                       518400  IN      NS      H.ROOT-SERVERS.NET.
.                       518400  IN      NS      I.ROOT-SERVERS.NET.
.                       518400  IN      NS      J.ROOT-SERVERS.NET.
.                       518400  IN      NS      K.ROOT-SERVERS.NET.
;; Received 239 bytes from 10.0.0.2#53(10.0.0.2) in 0 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
C41A5766
com.                    86400   IN      RRSIG   DS 8 1 86400 20210329220000 20210316210000 42351 .
;; Received 1174 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 104 ms

example.com.         172800  IN      NS      ns-1470.awsdns-55.org.  	------>Name servers of interest.
example.com.         172800  IN      NS      ns-1969.awsdns-54.co.uk.
example.com.         172800  IN      NS      ns-736.awsdns-28.net.
example.com.         172800  IN      NS      ns-316.awsdns-39.com.

;; Received 732 bytes from 192.33.14.30#53(b.gtld-servers.net) in 91 ms

example.com.         3600    IN      A       104.200.22.130
example.com.         3600    IN      A       104.200.23.95
example.com.         3600    IN      NS      ns-1470.awsdns-55.org.
example.com.         3600    IN      NS      ns-1969.awsdns-54.co.uk.
example.com.         3600    IN      NS      ns-736.awsdns-28.net.
example.com.         3600    IN      NS      ns-316.awsdns-39.com.

;; Received 127 bytes from 173.201.72.25#53(ns-1470.awsdns-55.org) in 90 ms

Bestätigen, dass der angeforderte Datensatz existiert

Prüfe in der gehosteten Zone, ob der angeforderte Datensatz existiert.

Wenn du einen CNAME verwendest, stelle sicher, dass die Zieldomain (Canonical Name) ebenfalls existiert und auflösbar ist.

Wenn beispielsweise der CNAME-Datensatz „example.com“ mit dem Wert „blog.example.com“ konfiguriert ist, überprüfe, ob der Datensatz blog.example.com existiert und aufgelöst werden kann.

Suchen nach Problemen bei der Subdomain-Delegierung

Um nach Problemen mit der Subdomain-Delegierung zu suchen, ziehe die folgenden Maßnahmen in Betracht:

  • Suche in der übergeordneten gehosteten Zone nach NS-Einträgen für die Domain. Wenn beispielsweise „www.example.com“ einen NS-Eintrag hat, wird dieser delegiert.
  • Wenn die Delegierung gültig ist, füge den Datensatz der delegierten Zone hinzu.
  • Wenn die Delegierung nicht gültig ist, lösche den NS-Eintrag und füge den Datensatz der übergeordneten Zone hinzu.

Hinweis: Die QNAME-Minimierung in DNS-Resolvern kann zu NXDOMAIN-Fehlern mit tiefgreifenden Subdomain-Delegierung führen. Weitere Informationen findest du unter Schutz vor hängenden Datensätzen der Delegierung in Route 53.

Feststellen, ob das Problem mit der DNS-Auflösung nur in der VPC besteht

Prüfe, ob der DNS-Resolver auf dem Betriebssystem konfiguriert ist.

  • Für Linux: Öffne die Datei /etc/resolv.conf.
  • Für Windows: Führe in der Eingabeaufforderung Folgendes aus: ipconfig /all

Suche nach der DNS-Resolver-Adresse. Wenn der Virtual Private Cloud (VPC)-CIDR 10.0.0.0/8 ist, sollte der Resolver 10.0.0.2 betragen.

Wenn du den Amazon Virtual Private Cloud (Amazon VPC)-Resolver verwendest, überprüfe die folgenden Szenarien:

Szenario A: Du hast sowohl eine Resolver-Regel als auch eine privat gehostete Zone

  • Die Resolver-Regel hat Vorrang.
  • Die DNS-Abfrage wird an die IP-Adresse in der Resolver-Regel weitergeleitet.

Weitere Informationen findest du unter Arbeiten mit privat gehosteten Zonen.

Szenario B: Du hast nur eine privat gehostete Zone

  • Clients innerhalb der VPC können keine Datensätze in der öffentlichen Zone auflösen.
  • Diese Konfiguration wird split-horizon DNS genannt.

Szenario C: Du hast nur eine Resolver-Regel

  • Die DNS-Anfrage wird an die konfigurierte IP-Adresse weitergeleitet.
  • Die standardmäßigen öffentlichen Resolver werden in diesem Fall nicht verwendet.

Prüfen, ob das Problem auf negatives Caching zurückzuführen ist

Eine NXDOMAIN-Antwort kann vom Resolver zwischengespeichert werden, wenn negatives Caching aktiv ist.
Beispielszenario:

  • Du frast „neg.example.com“ ab und es existiert nicht.
  • Der Resolver speichert das NXDOMAIN-Ergebnis im Cache.
  • Später erstellst du den Datensatz, aber der Resolver gibt immer noch NXDOMAIN zurück.

Resolver verwenden Folgendes, um zu bestimmen, wie lange negative Antworten zwischengespeichert werden sollen:

  • Die minimale TTL aus dem SOA-Datensatz
  • Die TTL des SOA-Datensatz (je nachdem, welcher Wert niedriger ist)

Um zu bestätigen, ob negatives Caching aktiv ist, sende eine Anfrage direkt an den Nameserver, um eine Antwort zu erhalten, wie im folgenden Beispiel:

dig www.example.com @ns-1470.awsdns-55.org
AWS OFFICIALAktualisiert vor einem Monat