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

Lesedauer: 8 Minute
0

Ich erhalte eine NXDOMAIN-Antwort vom DNS-Resolver oder einen DNS_PROBE_FINISHED_NXDOMAIN-Fehler beim Auflösen von Amazon Route 53-Datensätzen.

Behebung

Feststellen, ob sich die Domain im aktiven oder gesperrten Status befindet

1.    Führen Sie eine Whois-Abfrage für die Domain durch.

Hinweis: Stellen Sie sicher, dass Whois installiert ist, bevor Sie die folgenden Befehle ausführen.

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. Geben Sie in der Eingabeaufforderung whois example.com ein.

Hinweis: Wenn die Domain bei Amazon Registrar registriert ist, können Sie das Whois-Suchtool von Amazon Registrar verwenden.

2.    Prüfen Sie den Status der Domain. Wenn der Wert von Domain Status clientHold ist, wird die Domain gesperrt.

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.

Um eine Domain im Internet wieder verfügbar zu machen, entfernen Sie sie aus dem gesperrten Status. Im Folgenden sind die häufigsten Gründe aufgeführt, aus denen eine Domain gesperrt werden könnte:

  • Sie haben eine neue Domain registriert, aber nicht auf den Link in der Bestätigungs-E-Mail geklickt.
  • Sie haben die automatische Verlängerung für die Domain deaktiviert und die Domain ist abgelaufen.
  • Sie haben die E-Mail-Adresse für den Kontakt des Registranten geändert, aber Sie haben nicht überprüft, ob die neue E-Mail-Adresse gültig ist.

Weitere Informationen finden Sie unter Meine Domain ist gesperrt (Status ist ClientHold).

Vergewissern Sie sich, dass die richtigen Nameserver auf dem Domain-Registrar konfiguriert sind

1.    Notieren Sie sich in der Whois-Ausgabe die Nameserver, die für Ihre Domain maßgeblich sind. Ein Beispiel finden Sie in der vorhergehenden Whois-Ausgabe.

Sie können auch das Dig-Hilfsprogramm verwenden, um die konfigurierten Nameserver zu überprüfen.

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

2.    Öffnen Sie die Route 53-Konsole.

3.    Wählen Sie im Navigationsbereich Gehostete Zonen aus.

4.    Wählen Sie auf der Seite Gehostete Zonen das Optionsfeld (nicht den Namen) für die gehostete Zone aus. Wählen Sie dann Details anzeigen aus.

5.    Wählen Sie auf der Detailseite für die gehostete Zone die Option Details der gehosteten Zone aus.

6.    Vergewissern Sie sich, dass die in den Details der gehosteten Zone aufgeführten Nameserver mit den Nameservern in der whois- oder dig+trace-Ausgabe identisch sind.

Wichtig: Wenn die Nameserver nicht identisch sind, aktualisieren Sie sie beim Domain-Registrar. Wenn die Domain bei Route 53 registriert ist, finden Sie weitere Informationen unter Hinzufügen oder Ändern von Nameservern und Glue-Einträgen für eine Domain. Bei Domains, die bei einem Drittanbieter registriert sind, finden Sie in der Dokumentation des Anbieters Anweisungen zur Aktualisierung der Nameserver.

Bestätigen, dass der angeforderte Datensatz existiert

Vergewissern Sie sich, dass die gehostete Zone für die Domain den angeforderten Datensatz enthält. Wenn Sie zum Beispiel eine NXDOMAIN-Antwort erhalten, wenn Sie versuchen, www.example.com aufzulösen, dann überprüfen Sie die von example.com gehostete Zone auf den www.example.com-Eintrag. Eine Anleitung zum Auflisten von Datensätzen in Route 53 finden Sie unter Datensätze auflisten.

Wenn Sie einen CNAME-Eintrag haben, der auf einen anderen Domain-Namen verweist, stellen Sie sicher, dass der kanonische Name existiert und auflösbar ist.

Beispiel

Der CNAME-Eintrag example.com ist mit dem Wert blog.example.com konfiguriert. Stellen Sie in diesem Fall sicher, dass der Datensatz blog.example.com existiert und aufgelöst werden kann.

Suchen nach Problemen bei der Subdomain-Delegierung

1.    Suchen Sie in der übergeordneten gehosteten Zone nach einem Nameserver-Eintrag (NS) für den Domain-Namen, den Sie auflösen möchten. Wenn ein NS-Eintrag für eine Subdomain existiert, wird die Autorität für die Domain und ihre Subdomains an eine andere Zone delegiert. Wenn beispielsweise ein NS-Eintrag für www.example.com existiert, wird die Autorität für www an die Nameserver im NS-Eintrag delegiert. Wenn die Delegierung gültig ist, müssen Sie den Datensatz für die Domain in der delegierten Zone erstellen, nicht in der übergeordneten Zone von example.com.

2.    Wenn die Delegierung nicht gültig ist, löschen Sie den NS-Eintrag für die Domain. Vergewissern Sie sich, dass die übergeordnete gehostete Zone (example.com) einen Datensatz für den Domain-Namen enthält, den Sie beheben möchten.

3. Resolver, die die QNAME-Minimierung implementieren, enthalten in jeder Abfrage die Mindestdetails, die für diesen Schritt des Behebungsprozesses erforderlich sind. Dies kann bei einigen Resolvern zu einem NXDOMAIN-Problem führen. Wenn Sie mehrere Ebenen der Subdomain-Delegierung konfigurieren, folgen Sie auf jeder Ebene der strikten Delegierung. Weitere Informationen finden Sie unter Routing des Datenverkehrs für zusätzliche Ebenen von Subdomains.

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

1.    Überprüfen Sie die Resolver-IP-Adresse, die auf dem Client-Betriebssystem (OS) konfiguriert ist. Für Linux überprüfen Sie die Datei /etc/resolv.conf. Überprüfen Sie für Windows die DNS-Server in der Ausgabe ipconfig /all. Suchen Sie nach dem Standard-DNS-Resolver für eine Virtual Private Cloud (VPC) (VPC CIDR+2). Wenn der VPC-CIDR beispielsweise 10.0.0.0/8 lautet, lautet die IP-Adresse des DNS-Resolvers 10.0.0.2. Wenn Sie den VPC-DNS-Resolver in /etc/resolv.conf nicht sehen, überprüfen Sie den benutzerdefinierten DNS-Resolver.

2.    Wenn Sie den VPC-DNS-Resolver verwenden, überprüfen Sie die Regeln für private gehostete Zonen und Route 53-Resolver.

Bei Verwendung von Resolver-Regeln und privat gehosteten Zonen

Wenn die Resolver-Regel und der Domain-Name der privaten gehosteten Zone übereinstimmen, hat die Resolver-Regel Vorrang. Weitere Informationen finden Sie unter Überlegungen bei der Arbeit mit einer privat gehosteten Zone. In diesem Fall wird die DNS-Abfrage an die Ziel-IP-Adresse gesendet, die in der Resolver-Regel als Ziel konfiguriert ist.

Bei Verwendung einer privat gehosteten Zone und ohne Resolver-Regel

Stellen Sie sicher, dass der VPC eine privat gehostete Zone mit passenden Domain-Namen zugeordnet ist. Beispielsweise könnten Sie eine öffentlich gehostete Zone und eine privat gehostete Zone für die Domain haben, die einer VPC zugeordnet ist. Dies ist ein Split-View- oder Split-Horizon-DNS. In diesem Fall können Clients in der VPC keine Datensätze auflösen, die in der öffentlich gehosteten Zone erstellt wurden. Wenn der Eintrag in der privat gehosteten Zone nicht vorhanden ist, fällt das VPC-DNS nicht auf die öffentlich gehostete Zone zurück.

Wenn nur Resolver-Regeln und keine privat gehostete Zone verwendet werden

Überprüfen Sie die Route 53-Resolver-Regeln. Wenn es eine Regel gibt, die dem Domain-Namen entspricht, wird die Abfrage für die Domain an die konfigurierten Ziel-IP-Adressen weitergeleitet. Das bedeutet, dass die Abfrage nicht an die öffentlichen Standardresolver weitergeleitet wird.

Feststellen, ob Ihr Problem auf negatives Caching zurückzuführen ist

Negatives Caching ist der Vorgang, bei dem eine negative Antwort von einem autoritativen Nameserver im Cache gespeichert wird. Eine NXDOMAIN-Antwort wird als negative Antwort betrachtet. Sehen Sie sich das folgende Beispiel an:

Ein Client stellt eine DNS-Abfrage für neg.example.com und erhält den Antwortcode NXDOMAIN, da der Datensatz neg.example.com nicht existiert.

Diesem Benutzer gehört auch example.com, weshalb er einen neuen Datensatz für neg.example.com erstellt. Der Benutzer erhält weiterhin eine NXDOMAIN-Antwort, wenn Benutzer in anderen Netzwerken den Datensatz erfolgreich auflösen können.

Wenn der Benutzer vor dem Erstellen des neuen Datensatzes eine Anfrage an neg.example.com stellt, erhält er eine NXDOMAIN-Antwort. Wenn der Benutzer das negative Caching in seinen Resolver-Einstellungen aktiviert hat, speichert der Resolver diese Antwort im Cache. Nachdem der Benutzer den neuen Datensatz erstellt hat, führt er die Abfrage erneut durch. Der Resolver hat diese Abfrage zuvor empfangen und zwischengespeichert, sodass er die Antwort aus dem Cache zurückgegeben hat.

In der Antwort auf eine negative Antwort wird kein Datensatz zurückgegeben, daher gibt es keinen TTL-Wert (Time to Live) im Vergleich zu einer positiven Antwort. In diesem Fall verwendet der Resolver den niedrigsten Wert aus den folgenden:

  • Der TTL-Mindestwert des SOA-Eintrags (Start of Authority).
  • Der TTL-Wert des SOA-Eintrags zum Zwischenspeichern der NXDOMAIN-Antwort.

Um dieses Problem zu bestätigen, senden Sie eine Anfrage direkt an den Nameserver, um zu sehen, ob Sie eine Antwort erhalten. Zum Beispiel:

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