Knowledge Center Monthly Newsletter - June 2025
Stay up to date with the latest from the Knowledge Center. See all new Knowledge Center articles published in the last month, and re:Post's top contributors.
Wie behebe ich NXDOMAIN-Antworten, wenn ich Route 53 als DNS-Dienst verwende?
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.
- 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. - 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:
- Öffne die Amazon Route 53-Konsole.
- Wähle im Navigationsbereich Gehostete Zonen.
- Wähle die gewünschte gehostete Zone und klicke dann auf Details anzeigen.
- Wähle Details zur gehosteten Zone.
- Vergleiche die aufgelisteten Nameserver mit denen im WHOIS oder in der
dig +trace
Ausgabe.
Wichtig: Wenn sich die Nameserver unterscheiden, aktualisiere sie beim Domain-Registrar.
- Wenn die Domain bei Route 53 registriert ist, findest du weitere Informationen unter Hinzufügen oder Ändern von Nameservern und Verbindungsdatensatz für eine Domain.
- Informationen zu Domains, die an anderer Stelle registriert sind, findest du in der Dokumentation des Anbieters.
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

Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 2 Jahren