Wie behebe ich DNS-SERVFAIL-Probleme?
Beim Auflösen meiner Domain in Amazon Route 53 erhalte ich die Antwort „SERVFAIL“.
Lösung
Problem: Ein Nameserver (NS) eines Drittanbieters blockiert die IP-Adresse des öffentlichen AWS-Resolvers
Wenn ein NS eines Drittanbieters die IP-Adresse des öffentlichen Resolvers blockiert, werden beim Lösen von Abfragen für Ihre öffentliche Domain SERVFAIL-Antworten angezeigt. Dies geschieht unabhängig davon, ob Sie die Lösung von einer oder mehreren AWS-Regionen aus durchführen. Wenn dieselbe DNS-Abfrage jedoch für einige der öffentlichen DNS-Resolver wie 8.8.8.8 oder 1.1.1.1 aufgelöst wird, wird die NOERROR-Antwort zurückgegeben.
Um dieses Problem zu lösen, wenden Sie sich an Ihren DNS-Drittanbieter, um eine Zulassungsliste zu erstellen. Fügen Sie der Liste alle IP-Adressbereiche des öffentlichen AWS-Resolvers aus der AWS-Region hinzu, in der Sie SERVFAIL-Antworten beobachten.
Problem: In einer öffentlich gehosteten Zone ist eine falsche Subdomain-Delegierung konfiguriert
Beispiel
In Ihrer öffentlich gehosteten Zone „example.com“ ist die Subdomain-Delegierung für „aws.example.com“ konfiguriert. Die Konfiguration der Subdomain-Delegierung gibt nicht erreichbare oder falsche Nameserver an, die für die Subdomain nicht autoritativ sind.
Übergeordnete öffentlich gehostete Zone für die Domain „example.com“
example.com | NS | ns1.example.com, ns2.example.com, ns3.example.com, ns4.example.com |
aws.example.com | NS | dummy-ns1.com, dummy-ns2.net, dummy-ns3.co.uk, dummy-ns4.org, |
Von der Subdomain gehostete Zone für die Domain „aws.example.com“
aws.example.com | NS | ns1-xxx.awsdns-xx.com, ns2-xxx.awsdns-xx.co.uk, ns3-xxx.awsdns-xx.net, ns4-xxx.awsdns-xx.org |
aws.example.com | A | 1.2.3.4 |
Um den vorherigen Fehler zu beheben, konfigurieren Sie die Nameserver-Datensätze in der übergeordneten gehosteten Zone so, dass sie mit den Nameservern in der gehosteten Zone der Subdomain übereinstimmen. Wenn Sie benutzerdefinierte Nameserver verwenden, stellen Sie sicher, dass die Nameserver erreichbar sind.
Problem: Beim Domain-Registrar sind falsche Nameserver aufgeführt
Wenn beim Domain-Registrar falsche Nameserver aufgeführt sind, gibt es zwei Ursachen für den Erhalt von SERVFAIL-Antworten:
- Die Nameserver, die beim Domain-Registrar konfiguriert sind, stimmen nicht mit den Nameservern überein, die in Ihrer öffentlich gehosteten Zone bereitgestellt werden.
- Die beim Registrar konfigurierten Nameserver sind vorhanden, aber für die angegebene Domäne nicht autoritativ.
Wenn die Nameserver nicht vorhanden sind, laufen die Resolver nach dem Initiieren iterativer Abfragen ab. Diese Zeitüberschreitungen führen zu erheblicher Latenz bei der Abfragezeit. Da die Nameserver keine Antwort bereitstellen können, gibt der Resolver die SERVFAIL-Antwort zurück.
Die öffentlich gehostete Zone der Domain
example.com | NS | ns1.example.com, ns2.example.com, ns3.example.com, ns4.example.com |
Die Nameserver werden beim Domain-Registrar konfiguriert, wie im folgenden Beispiel gezeigt:
whois example.com | grep "Name Server" Name Server: ns1.test.com Name Server: ns2.test.com Name Server: ns3.test.com Name Server: ns4.test.com
Gehen Sie wie folgt vor, um diesen Fehler zu beheben:
- **Der White-Label-Nameserver ist nicht implementiert:**Ersetzen Sie den Nameserver des Registrars durch die Nameserver, die Ihrer öffentlich gehosteten Zone zugewiesen sind.
- **Der White-Label-Nameserver ist implementiert:**Stellen Sie sicher, dass die Nameserver des Registrars mit Ihren Verbindungsdatensätzen und den A-Einträgen für White-Label-Nameserver in der öffentlich gehosteten Zone identisch sind.
Problem: Es gibt eine nicht unterstützte Subdomain-Delegierung, die in der privaten gehosteten Zone konfiguriert ist
Wenn die Subdomain-Delegierung in der privaten gehosteten Zone falsch konfiguriert ist, gibt der DNS-Resolver der Virtual Private Cloud (VPC) SERVFAIL zurück.
Private gehostete Zone
servfail.local | NS | ns-xxx.awsdns-xx.co.uk, ns-x.awsdns-xx.com, ns-xxx.awsdns-xx.org, ns-xxx.awsdns-xx.net. |
sub.servfail.local | NS | ns-xxx.awsdns-xx.net. |
Hinweis: Sie können die AWS-Managementkonsole nicht zum Erstellen von NS-Datensätzen in einer privaten gehosteten Zone verwenden, um die Verantwortung für eine Subdomain zu delegieren. Verwenden Sie stattdessen die AWS Command Line Interface (AWS CLI). Beachten Sie, dass Amazon Route 53 die Subdomain-Delegierung in einer privaten gehosteten Zone nicht unterstützt.
Problem: DNSSEC ist falsch konfiguriert
DNSSEC kann aus einer oder mehreren der folgenden Fehlkonfigurationen bestehen:
- DNSSEC ist auf der Ebene des Domain-Registrars aktiviert, jedoch nicht auf der Seite des DNS-Hosting-Dienstes.
- Die DNSSEC-Signatur wird auf der Ebene des Domain-Registrars und auf der Seite des DNS-Hosting-Dienstes aktiviert. Eine oder mehrere wichtige Informationen (wie Schlüsseltyp, Signaturalgorithmus und öffentlicher Schlüssel) stimmen jedoch nicht überein. Oder der DS-Datensatz ist falsch.
- Die Vertrauenskette zwischen der übergeordneten Zone und der untergeordneten Zone ist nicht aufgebaut. Der DS-Datensatz in der übergeordneten Zone stimmt nicht mit dem Hash des öffentlichen KSK in der untergeordneten Zone überein.
Informationen zur Behebung dieses Problems finden Sie unter Wie kann ich DNSSEC-Konfigurationsprobleme in Route 53 identifizieren und beheben?
Problem: Die eingehende und ausgehende Endpunktverkettung des Route 53 Resolvers ist falsch konfiguriert
Dieses Problem wird durch DNS-Verkehr verursacht, der sich in einer Schleife befindet. Der Verkehrsfluss nach dem folgenden Muster verursacht die Schleife:
EC2-Instance – VPC-DNS-Resolver – (Weiterleitungsregel bei Übereinstimmung) – ausgehender Endpunkt – (Ziel-IP-Adresse des eingehenden Endpunkts) – Eingehender Endpunkt – VPC-DNS-Resolver
Informationen zur Behebung dieses Problems finden Sie unter Vermeiden von Schleifenkonfigurationen mit Resolver-Endpunkten.
Problem: Es gibt Konnektivitätsprobleme auf ausgehenden Route 53 Resolver-Endpunkten
Wenn es Konnektivitätsprobleme zwischen den ausgehenden Route 53 Resolver-Endpunkten und den Ziel-IP-Adressen der Resolver-Regel gibt, gibt AmazonProvidedDNS SERVFAIL zurück.
Gehen Sie wie folgt vor, um dieses Problem zu beheben:
- Überprüfen Sie die Netzwerkkonnektivität von der vom Endpunkt erstellten VPC für ausgehende, elastische Netzwerkschnittstellen zu den Ziel-IP-Adressen:
- Überprüfen Sie die Netzwerk-Zugriffssteuerungslisten (Netzwerk-ACLs).
- Stellen Sie sicher, dass es eine Ausgangsregel für ausgehende Endpunkt-Sicherheitsgruppen gibt, die TCP- und UDP-Verkehr über Port 53 zu den Ziel-IP-Adressen zulässt.
- Überprüfen Sie alle Firewall-Regeln, die auf der Seite der Ziel-IP-Adresse konfiguriert sind.
- Überprüfen Sie das Routing zwischen der elastischen Netzwerkschnittstelle des ausgehenden Endpunkts und den Ziel-IP-Adressen.
- Die ausgehenden elastischen Endpunkt-Netzwerkschnittstellen von Route 53 Resolver verfügen standardmäßig über keine öffentlichen IP-Adressen. Wenn es sich bei dem Ziel-DNS-Server um einen öffentlichen DNS-Server handelt (z. B. 8.8.8.8), stellen Sie sicher, dass der ausgehende Endpunkt in einem privaten Subnetz mit einem Routing-Tabelleneintrag für ein NAT-Gateway erstellt wird.
Problem: In der übergeordneten Zone fehlt ein Verbindungsdatensatz
Beispiel
In der öffentlich gehosteten Zone für die Domain „example.com“ gibt es eine Subdomain-Delegierung für „glue.example.com“, die auf die Nameserver der Subdomain verweist. Der Verbindungsdatensatz existiert jedoch nicht in der öffentlich gehosteten Zone „example.com“, wie im folgenden Beispiel gezeigt:
Übergeordnete öffentlich gehostete Zone für die Domain „example.com“
example.com | NS | ns1.example.com, ns2.example.com, ns3.example.com, ns4.example.com |
glue.example.com | NS | ns1.glue.example.com, ns2.glue.example.com, ns3.glue.example.com, ns4.glue.example.com |
Öffentliche gehostete Zone der Subdomain für die Domain „glue.example.com“
glue.example.com | NS | ns1.glue.example.com, ns2.glue.example.com, ns3.glue.example.com, ns4.glue.example.com |
glue.example.com | A | 1.2.3.4 |
ns1.glue.example.com | A | 3.3.3.3 |
ns2.glue.example.com | A | 4.4.4.4 |
ns3.glue.example.com | A | 5.5.5.5 |
ns4.glue.example.com | A | 6.6.6.6 |
Um dieses Problem zu beheben, erstellen Sie die Verbindungsdatensätze für die Subdomain „glue.example.com.“ in der gehosteten Zone der übergeordneten Domain.
Übergeordnete öffentlich gehostete Zone für die Domain „example.com“
example.com | NS | ns1.example.com, ns2.example.com, ns3.example.com, ns4.example.com |
glue.example.com | NS | ns1.glue.example.com, ns2.glue.example.com, ns3.glue.example.com, ns4.glue.example.com |
glue.example.com | A | 1.2.3.4 |
ns1.glue.example.com | A | 3.3.3.3 |
ns2.glue.example.com | A | 4.4.4.4 |
ns3.glue.example.com | A | 5.5.5.5 |
ns4.glue.example.com | A | 6.6.6.6 |
Problem: Die maximale Rekursionstiefe ist überschritten
Wenn die abfragende Domain mit einer Tiefe von mehr als neun antwortet, ist die maximale Rekursionstiefe überschritten. Die Antwort darf eine Kette von nicht mehr als acht CNAME-Datensätzen und einem abschließenden A/AAAA-Datensatz sein.
Um dieses Problem zu beheben, reduzieren Sie die Anzahl der CNAME-Datensätze in der Antwort. Um Schleifen zu vermeiden, unterstützt Route 53 Resolver eine maximale Tiefe von neun (Kette von acht CNAMEs und einem A/AAAA-Datensatz).
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 3 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 3 Jahren