Direkt zum Inhalt

Wie behebe ich Probleme mit der DNS-Auflösung in meiner privaten gehosteten Route 53-Zone?

Lesedauer: 8 Minute
0

Ich möchte Probleme mit der DNS-Auflösung bei meiner privaten gehosteten Amazon Route 53-Zone beheben.

Kurzbeschreibung

Um DNS-Probleme mit privaten gehosteten Zonen zu beheben, überprüfe die Amazon Virtual Private Cloud (Amazon VPC)-Einstellungen, Zonenzuordnungen und die DNS-Servereinrichtung.

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Bestätigen der DNS-Unterstützung in der VPC

Gehe wie folgt vor, um die Auflösung von Datensätzen für private gehostete Zonen zuzulassen:

  1. Aktiviere die DNS-Unterstützung in der Amazon VPC.
  2. Stelle sicher, dass DNSSupport und DNSHostnames in der VPC auf Wahr gesetzt sind. Weitere Informationen findest du unter Anzeigen und Aktualisieren von DNS-Attributen für deine VPC.

Bestätigen der richtigen VPC-ID-Zuordnung

Vergewissere dich, dass die richtige VPC-ID mit der privaten gehosteten Zone verknüpft ist. Stelle außerdem sicher, dass du die Ressourcendatensätze der Domain von derselben VPC aus abfragst.

Wenn du der VPC eine private gehostete Zone zuordnest:

  • Der Route 53-Resolver erstellt eine automatisch definierte Regel und ordnet sie der VPC zu.
  • Ressourcen in der VPC können den Resolver abfragen, um DNS-Datensätze in der privaten gehosteten Zone aufzulösen.

Um VPCs aufzulisten, die einer gehosteten Zone zugeordnet sind, führe den folgenden Befehl in der AWS CLI aus:

aws route53 get-hosted-zone --id VPC_ID

Hinweis: Ersetze VPC_ID durch die entsprechenden Werte.

Um private gehostete Zonen aufzulisten, die bestimmten VPCs zugeordnet sind, führe den folgenden Befehl in der AWS CLI aus:

aws route53 list-hosted-zones-by-vpc --vpc-id VPC_ID --vpc-region REGION_ID

Hinweis: Ersetze HOSTED_ZONE_ID, VPC_ID und REGION_ID durch die relevanten Werte.

Überprüfen der benutzerdefinierten DNS-Serverkonfigurationen

Wenn du in den DHCP-Optionen für DNS in der VPC benutzerdefinierte DNS-Server oder Active Directory-Server konfiguriert hast, überprüfe die folgenden Punkte:

  1. Regel für die Weiterleitung: Die Server leiten DNS-Abfragen für private Domains an die DNS-Server-IP-Adresse der VPC weiter.
  2. Konfiguration der Domain: Die Domain auf benutzerdefinierten Servern unterscheidet sich von der privaten gehosteten Zone.

Wenn der primäre CIDR-Bereich für die VPC beispielsweise 172.31.0.0/16 ist, dann lautet die IP-Adresse des VPC-DNS-Servers 172.31.0.2. Die IP-Adresse ist der VPC-Netzwerkbereich plus zwei.

Überprüfen der Resolver-Konfigurationseinstellungen

Wenn du eine intermittierende DNS-Auflösung oder DNS-Antworten feststellst, überprüfe die Resolver-Konfigurationseinstellungen der Quell-Instance:

  • Verwende für Linux-Instances die Dateien cat /etc/resolv.conf und cat/etc/hosts.
  • Für macOS, siehe DNS-Einstellungen auf dem Mac ändern im macOS-Benutzerhandbuch.
  • Führe für Windows die folgenden Schritte aus:
    Wähle Settings (Einstellungen) und dann Network & internet (Netzwerk und Internet) aus.
    Wähle unter Advanced network settings (Erweiterte Netzwerkeinstellungen) die Option Change adapter settings (Adaptereinstellungen ändern) aus.
    Klicke mit der rechten Maustaste auf die Netzwerkverbindung und wähle dann Eigenschaften.
    Wähle IPv4 properties (IPv4-Eigenschaften) und gib anschließend die bevorzugte DNS-IP-Adresse in das Feld DNS server addresses (DNS-Serveradressen) ein.

Wenn du beispielsweise resolv.conf konfiguriert hast, kannst du die Option rotate (rotieren) verwenden, um bei Abfragen zwischen Amazon DNS und Google DNS (8.8.8.8) einen Lastausgleich vorzunehmen. Die Datei resolv.conf würde etwa wie folgt aussehen:

options rotate; generated by /usr/sbin/dhclient-script
nameserver 8.8.8.8
nameserver 172.31.0.2

Bei der ersten Abfrage beim öffentlichen Google-DNS (8.8.8.8) erhältst du die erwartete NxDomain-Antwort. Der Resolver versucht, die Antwort in der öffentlichen gehosteten Zone statt in der privaten gehosteten Zone zu finden:

Private hosted Zone Record - resolvconf.local
[ec2-user@ip-172-31-253-89 etc]$ curl -vks http://resolvconf.local* Rebuilt URL to: http://resolvconf.local/
* Could not resolve host: resolvconf.local

15:24:58.553320 IP ip-172-31-253-89.ap-southeast-2.compute.internal.40043 > dns.google.domain: 65053+ A? resolvconf.local. (34)
15:24:58.554814 IP dns.google.domain > ip-172-31-253-89.ap-southeast-2.compute.internal.40043: 65053 NXDomain 0/1/0 (109)

Die zweite Abfrage wurde jedoch erfolgreich gelöst. Die zweite Abfrage erreicht den VPC-DNS-Resolver, der der privaten gehosteten Zone zugeordnet ist:

[ec2-user@ip-172-31-253-89 etc]$ curl -vks http://resolvconf.local* Rebuilt URL to: http://resolvconf.local/*   Trying 1.1.1.1...
* TCP_NODELAY set
* Connected to resolvconf.local (1.1.1.1) port 80 (#0)

15:25:00.224761 IP ip-172-31-253-89.ap-southeast-2.compute.internal.51578 > 172.31.0.2.domain: 7806+ A? resolvconf.local. (34)
15:25:00.226527 IP 172.31.0.2.domain > ip-172-31-253-89.ap-southeast-2.compute.internal.51578: 7806 1/0/0 A 1.1.1.1 (50)

Sicherstellen, dass private gehostete Zonen keine überlappenden Namespaces aufweisen

Wenn mehrere Zonen überlappende Namespaces haben:

  • Resolver leitet den Datenverkehr auf der Grundlage der spezifischsten Übereinstimmung weiter
  • Wenn eine passende Zone existiert, aber kein passender Datensatz, dann gibt Resolver NXDOMAIN zurück

Stelle sicher, dass der richtige Datensatz in der spezifischsten privaten gehosteten Zone konfiguriert ist, um eine erfolgreiche DNS-Auflösung zu gewährleisten.

Wenn du beispielsweise zwei private gehostete Zonen mit den folgenden Datensätzen hast:

Private gehostete ZoneDatensatznameWert
lokaloverlap.privatevpc.local60.1.1.1
privatevpc.localoverlap.privatevpc.local50.1.1.1

Anschließend erhältst du das folgende Abfrageergebnis aus der am spezifischsten übereinstimmenden privaten gehosteten Zone:

[ec2-user@IAD-BAS-INSTANCE ~]$ dig overlap.privatevpc.local +short
50.1.1.1

In privaten gehosteten Zonen nach Zonen-/Subdomain-Delegierung suchen

Private gehostete Zonen unterstützen keine Zonen-/Subdomain-Delegierung. Vergewissere dich, dass du keinen Nameserver (NS)-Datensatz für die Subdomain in der privaten gehosteten Zone der übergeordneten Domain konfiguriert hast. Wenn die Delegierung konfiguriert ist, erhält der Client den Antwortcode „SERVFAIL“ vom VPC-Resolver.

Nachfolgend findest du ein Beispiel für eine Delegierungskonfiguration, die SERVFAIL verursacht:

  • Private gehostete Zone: abc.com
  • NS-Datensatz der Delegierung: kc.abc.com
  • Ressourcendatensatz: test.kc.abc.com
[ec2-user@ip-172-31-0-8 ~]$ dig test.kc.abc.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63414
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;test.kc.abc.com        IN      A
;; Query time: 15 msec
;; SERVER: 172.31.0.2#53(172.31.0.2)
;; WHEN: Fri Apr 16 15:57:37 2021
;; MSG SIZE  rcvd: 48

Bestätigen der Unterstützung von Routing-Richtlinien

Stelle sicher, dass du im Ressourcendatensatz eine Routing-Richtlinie konfiguriert hast, die von einer privaten gehosteten Zone unterstützt wird. Weitere Informationen findest du unter Unterstützte Routing-Richtlinien für Datensätze in einer privaten gehosteten Zone.

Überprüfen der Resolver-Regel und der Verwendung des ausgehenden Resolver-Endpunkts

Stelle sicher, dass du Resolver mit einem ausgehenden Endpunkt verwendest. Die Resolver-Regel hat Vorrang, wenn Folgendes zutrifft:

  1. Du verfügst über eine Resolver-Regel, um den Datenverkehr für die Domain der privaten gehosteten Zone an das Netzwerk weiterzuleiten.
  2. Du hast eine Resolver-Regel, die derselben VPC zugeordnet ist, die auch der privaten gehosteten Zone zugeordnet ist.

Weitere Informationen findest du unter Auflösung von DNS-Abfragen zwischen VPCs und dem Netzwerk.

Abfrageschleifen verhindern

Gehe wie folgt vor, um zu vermeiden, dass eine Schleife entsteht:

  1. Erstelle in einer Resolver-Weiterleitungsregel keine Ziel-IP-Adressen, die auf eingehende Endpunkte der VPC verweisen.
  2. Ordne die Endpunkte nicht der privaten gehosteten Zone zu.
  3. Ordne der VPC nicht dieselbe Resolver-Regel zu.

Beispiel für eine Abfrageschleife:

ubuntu@ip-172-32-254-37:~$ dig overlap.privatevpc.local
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9007
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;overlap.privatevpc.local. IN A
;; Query time: 2941 msec
;; SERVER: 172.32.0.2#53(172.32.0.2)

Um dieses Problem zu lösen und die Schleife zu unterbrechen, entferne die Hub-VPC-Verknüpfung mit der Regel. Beispiel für eine erfolgreiche Antwort:

ubuntu@ip-172-32-254-37:~$ dig overlap.privatevpc.local
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58606
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;overlap.privatevpc.local. IN A
;; ANSWER SECTION:
overlap.privatevpc.local. 0 IN A 50.1.1.1
;; Query time: 5 msec
;; SERVER: 172.32.0.2#53(172.32.0.2)

Sich vergewissern, dass der On-Premises-Resolver rekursive Anforderungen sendet

Bei Abfragen von On-Premises- an Route 53-Resolver:

  • Verwende den eingehenden Resolver-Endpunkt, um DNS-Abfragen weiterzuleiten.
  • Stelle sicher, dass der On-Premises-Resolver rekursive (nicht iterative) Abfragen sendet.

Gehe wie folgt vor, um den Auflösungstyp zu überprüfen:

  1. Verwende die Paketerfassung auf dem On-Premises-DNS-Resolver.
  2. Überprüfe die DNS-Flags (Rekursion gewünscht = 0).
  3. Führe mit dem dig-Befehl +norecurse einen Test durch oder setze norecurse mit nslookup.

Beispiel für eine fehlgeschlagene iterative Abfrage:

[ec2-user@IAD-BAS-INSTANCE ~]$ dig @172.31.253.150 overlap.privatevpc.local +norecurse
;; <<>> DiG 9.11.0rc1 <<>> @172.31.253.150 overlap.privatevpc.local +norecurse; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Beispiel für eine erfolgreiche rekursive Abfrage:

[ec2-user@IAD-BAS-INSTANCE ~]$ dig @172.31.253.150 overlap.privatevpc.local
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19051
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;overlap.privatevpc.local.      IN      A
;; ANSWER SECTION:
overlap.privatevpc.local. 0     IN      A       50.1.1.1
;; Query time: 200 msec
;; SERVER: 172.31.253.150#53(172.31.253.150)

Überprüfen der richtigen Regelprioritäten für das von Amazon bereitgestellte DNS

Wenn die Client-Instance eine Abfrage an den Resolver sendet, überprüft der Resolver die Regeln der Instance, wohin die Anforderung weitergeleitet werden soll.

Die spezifischste Regel hat Vorrang. Wenn es beispielsweise eine Resolver-Regel test.example.com und eine private gehostete Zone test.example.com gibt, hat die Resolver-Regel Vorrang. Die Abfrage wird an die Server oder Ziel-IP-Adressen weitergeleitet, die in der Regel konfiguriert sind.

Wenn sich die Regeln auf derselben Domain-Ebene befinden, haben sie folgende Priorität:

  1. Resolver-Regel
  2. Regel der privaten gehosteten Zone
  3. Interne Regel

Ähnliche Informationen

Arbeiten mit privaten gehosteten Zonen

Welche Amazon VPC-Optionen muss ich aktivieren, um meine private gehostete Zone nutzen zu können?

Vermeiden von Schleifenkonfigurationen mit Resolver-Endpunkten