Cloud DNS-Fehler beheben

Auf dieser Seite finden Sie Lösungen für häufige Probleme,die bei der Verwendung von Cloud DNS zum Erstellen von öffentlichen Zonen, privaten Zonen, Weiterleitungszonen und Ressourceneinträgen auftreten können.

Öffentliche Zonen

In diesem Abschnitt werden Probleme mit öffentlichen Zonen behandelt.

Eine öffentliche Zone kann nicht erstellt werden

Wenn der Fehler attempted action failed auftritt, ist die Cloud DNS API in Ihrem Projekt nicht aktiviert.

So aktivieren Sie die Cloud DNS API:

  1. Rufen Sie in der Google Cloud Console die Seite API-Bibliothek auf.

    Zur API-Bibliothek

  2. Wählen Sie unter Letztes Projekt auswählen das Google Cloud-Projekt aus, in dem Sie die API aktivieren möchten.

  3. Suchen Sie auf der Seite API-Bibliothek im Feld Nach APIs und Diensten suchen nach Cloud DNS API. Es wird eine Seite mit der Beschreibung der API angezeigt.

  4. Klicken Sie auf Aktivieren.

Private Zonen

In diesem Abschnitt werden Probleme mit privaten Zonen behandelt.

Probleme mit privaten Zonen in Projekten mit freigegebenen VPC-Diensten

Wichtige Informationen zur Verwendung privater Zonen mit freigegebenen VPC-Netzwerken finden Sie unter Private Zonen und freigegebene VPCs.

Es kann keine private Zone erstellt werden und es lassen sich keine Richtlinien auflisten oder erstellen

Sie müssen die Rolle eines DNS-Administrators haben, um verschiedene Aktionen für private Zonen ausführen zu können, z. B. das Auflisten von DNS-Serverrichtlinien (Domain Name System) oder das Erstellen einer privaten Zone. Diese Rolle kann über das IAM-Tool (Identity and Access Management) zugewiesen werden.

Private Zonen werden nicht im selben VPC-Netzwerk aufgelöst

Der Test muss von einer VM-Instanz ausgeführt werden, deren primäre Schnittstelle sich im selben Netzwerk wie die von Ihnen erstellte private Zone befindet

Eine VM-Instanz sendet den gesamten Traffic von ihrer primären Schnittstelle, es sei denn, der Traffic ist für ein Subnetz bestimmt, das an eine der anderen Schnittstellen angeschlossen ist, oder wenn für die VM Richtlinien-Routing konfiguriert ist. Die primäre Schnittstelle der Test-VM muss sich im selben Netzwerk wie die private Zone befinden, die Sie testen.

Legen Sie fest, dass Ihre VM Folgendes verwendet:

gcloud compute instances describe VM_NAME \
    --zone=GCE_ZONE \
    --format="csv[no-heading](networkInterfaces['network'])"

Das Netzwerk muss sich in der Liste der Netzwerke befinden, die zum Abfragen Ihrer privaten Zone autorisiert sind:

gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
    --format="csv(privateVisibilityConfig['networks'])"

Übereinstimmung des DNS-Namens in der Abfrage mit Ihrer Zone prüfen

Google Cloud löst einen Eintrag gemäß der Reihenfolge der Namensauflösung auf. Dabei wird die Zone mit dem längsten Suffix verwendet, um zu ermitteln, welche Zone nach einem bestimmten DNS-Namen abgefragt wird. Achten Sie darauf, dass das Suffix für den abgefragten Eintrag mindestens einer privaten Zone entspricht, auf die in Ihrem VPC-Netzwerk zugegriffen werden kann. Google Cloud sucht beispielsweise zuerst nach myapp.dev.gcp.example.lan in einer Zone, in der dev.gcp.example.lan bereitgestellt wird (sofern zugänglich). Anschließend wird in einer Zone gesucht, die gcp.example.lan bereitstellt (sofern zugänglich).

Die Ausgabe des folgenden Befehls enthält das DNS-Suffix für die jeweilige private Zone:

gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
    --format="csv[no-heading](dnsName)"

DNS-Namen mithilfe des Metadatenservers abfragen

Verwenden Sie dig, um die DNS-Namensabfrage direkt an den Google Cloud-Metadatenserver 169.254.169.254 zu senden:

dig DNS_NAME @169.254.169.254

Verwenden Sie dig, um den Standard-Nameserver der VM abzufragen:

dig DNS_NAME

Wenn die Ausgabe der beiden dig-Befehle unterschiedliche Antworten liefert, prüfen Sie den Abschnitt ;; SERVER: des zweiten Befehls. Der antwortende Server muss der Metadatenserver 169.254.169.254 sein. Wenn dies nicht der Fall ist, haben Sie das Gastbetriebssystem so konfiguriert, dass anstelle des standardmäßigen Google Cloud-Metadatenservers ein benutzerdefinierter DNS-Nameserver verwendet wird. In privaten Cloud DNS-Zonen müssen Sie zur Namensauflösung den Metadatenserver verwenden. Dies erfolgt sowohl in der Linux-Gastumgebung als auch in der Windows-Gastumgebung automatisch. Wenn Sie das für eine VM verwendete Image importiert haben, prüfen Sie, ob die entsprechende Gastumgebung installiert wurde.

Private Zonen werden nicht über Cloud VPN oder Cloud Interconnect aufgelöst

Sorgen Sie zuerst dafür, dass Sie den DNS-Namen von einem autorisierten VPC-Netzwerk aus abfragen und auflösen können.

Konnektivität über Cloud VPN oder Cloud Interconnect überprüfen

Achten Sie darauf, dass die Verbindung von einem lokalen System zum VPC-Netzwerk funktioniert. Insbesondere müssen TCP- und UDP-Traffic über Port 53 das lokale Netzwerk verlassen und zum VPC-Netzwerk geleitet werden können. Prüfen Sie die Konfiguration der lokalen Firewalls, ob damit ein solcher ausgehender Traffic zulässig ist.

Für den Test der Konnektivität von einem lokalen System zu einer Beispiel-VM im VPC-Netzwerk können Sie ein beliebiges Protokoll wie ping (ICMP) verwenden. Auch wenn Cloud DNS-Anfragen nicht an Google Cloud-VMs gesendet werden, können Sie durch das Testen der Konnektivität zu einer Beispiel-VM die Konnektivität über einen Cloud VPN-Tunnel oder eine Cloud Interconnect-Verbindung prüfen. Für die Google Cloud-Beispiel-VM sollte eine geeignete Firewallregel zum Zulassen von eingehendem Traffic konfiguriert werden, da die implizierte Regel zum Ablehnen von eingehendem Traffic ansonsten den gesamten eingehenden Traffic blockiert.

Dafür sorgen, dass für das autorisierte VPC-Netzwerk die eingehende Weiterleitung aktiviert ist

Die eingehende Weiterleitung muss für jedes VPC-Netzwerk aktiviert sein, das Ihre private Cloud DNS-Zone abfragen darf. Verwenden Sie den folgenden Befehl, um alle Richtlinien aufzulisten:

gcloud dns policies list

Identifizieren Sie in der Ausgabetabelle das Netzwerk und prüfen Sie im Feld Forwarding, ob die Weiterleitung aktiviert ist.

Darauf achten, dass das autorisierte Netzwerk ein VPC-Netzwerk ist

Die DNS-Weiterleitung erfordert Subnetze. Diese sind nur für VPC-Netzwerke und nicht für Legacy-Netzwerke verfügbar.

gcloud compute networks list \
    --format="csv[no-heading](name, SUBNET_MODE)"

Legacy-Netzwerke sind in der Ausgabe durch LEGACY gekennzeichnet.

Darauf achten, dass in diesem Netzwerk eine gültige DNS-Weiterleitungsadresse reserviert ist

Mit dem folgenden Befehl werden alle reservierten DNS-Weiterleitungs-IP-Adressen in Ihrem Projekt angezeigt.

gcloud compute addresses list \
    --filter="purpose=DNS_RESOLVER" \
    --format='csv[no-heading](address, subnetwork)'

Sie können dem Filter eine AND-Klausel hinzufügen, um die Ausgabe auf das für Sie relevante Subnetzwerk zu beschränken.

Beispiel:

--filter="name ~ ^dns-forwarding AND subnetwork ~ SUBNETWORK_NAME"

Wenn Sie im erwarteten Netzwerk bzw. in der erwarteten Region keine IP-Adresse finden, reichen Sie ein Ticket beim Google Cloud-Support ein.

Führen Sie den Befehl dig aus, der auf die Abfrage unter der Adresse verweist, die Sie im vorherigen Befehl gefunden haben. Tun Sie dies von einer VM im selben Netzwerk aus. Durch diesen Test wird überprüft, ob der eingehende Forwarder funktioniert und die Ursache des Problems anderswo liegt.

dig DNS_NAME @10.150.0.1 # address returned by previous command

Wiederholen Sie den Befehl dig, aber von einem lokalen Host im VPN aus.

In privater Zone definierter CNAME-Eintrag funktioniert nicht

Cloud DNS führt nur CNAME-Chasings wie unter CNAME-Chasing beschrieben durch.

Reverse-Lookup-Zonen

In diesem Abschnitt erhalten Sie Tipps zur Fehlerbehebung für Reverse-Lookup-Zonen. Einige Probleme im Zusammenhang mit privaten Zonen können auch bei Reverse-Lookup-Zonen auftreten. Weitere Tipps finden Sie im Abschnitt zur Fehlerbehebung für private Zonen.

VM mit einer Adresse außerhalb des RFC-1918-Bereichs wird nicht aufgelöst

VM mit einer Adresse außerhalb des RFC-1918-Bereichs abgleichen

Wenn Sie eine VM außerhalb RFC 1918 in der Alphaversion erstellt haben, bevor die Cloud DNS-Unterstützung eingeführt wurde, wird eine solche VM möglicherweise nicht korrekt aufgelöst. Starten Sie Ihre VMs neu, um dieses Problem zu beheben.

Weiterleitungszonen

In diesem Abschnitt erhalten Sie Tipps zur Fehlerbehebung für Weiterleitungszonen. Einige der Probleme hinsichtlich privater Zonen können auch im Zusammenhang mit Weiterleitungszonen auftreten. Weitere Tipps finden Sie im Abschnitt zur Fehlerbehebung für private Zonen.

Weiterleitungszonen (ausgehende Weiterleitung) funktionieren nicht

Sorgen Sie zuerst dafür, dass Sie den DNS-Namen von einem autorisierten VPC-Netzwerk aus abfragen und auflösen können.

Das Weiterleiten von Abfragen von VMs in einem Nutzer-VPC-Netzwerk an ein Produzenten-VPC-Netzwerk funktioniert nicht

Wenn Sie DNS-Peering verwenden und Abfragen von VMs in einem Nutzer-VPC-Netzwerk an ein Produzenten-VPC-Netzwerk und dann an einen oder mehrere lokale Nameserver weiterleiten möchten, müssen Sie eine der folgenden Voraussetzungen erfüllen:

  • Der dynamische Routingmodus des VPC-Netzwerk des Erstellers ist auf GLOBAL festgelegt.

  • Die VM im VPC-Netzwerk des Nutzers befindet sich in derselben Region wie der VPN-Tunnel oder Cloud Interconnect im VPC des Erstellers.

  • (Nur klassisches VPN) Das VPC-Netzwerk des Produzenten hat eine statische Route, die den Traffic für die lokalen Nameserver über den klassischen VPN-Tunnel sendet. Das VPC-Netzwerk des Erstellers muss außerdem eine VM oder einen VPN-Tunnel in derselben Region wie das Subnetzwerk haben, das von den Client-VMs verwendet wird.

    • Angenommen, VPC1 verwendet eine Peering-Zone, die Abfragen für example.com. an VPC2 sendet. Weiter angenommen, VPC2 hat eine private Weiterleitungszone für example.com., die die Abfragen mithilfe eines Klassisches VPN-Tunnels an einen lokalen Nameserver weiterleitet.

      Damit eine VM, die sich in us-east1 in VPC1 befindet, example.com. abfragen kann, muss VPC2 eine VM in us-east1 haben. Außerdem muss eine statische Route für die CIDR-Bereiche der lokalen Nameserver konfiguriert werden, wobei der nächste Hop als Klassisches VPN-Tunnel konfiguriert ist.

Konnektivität über Cloud VPN oder Cloud Interconnect überprüfen

Für den Test der Konnektivität von einem lokalen System zu einer Beispiel-VM im VPC-Netzwerk können Sie ein beliebiges Protokoll wie ping (ICMP) verwenden. Sie müssen auch versuchen, den lokalen Nameserver direkt von einer Beispiel-Google Cloud-VM aus mit einem Tool wie dig abzufragen:

dig DNS_NAME @192.168.x.x # address of the onprem DNS server

Firewallregeln im VPC-Netzwerk prüfen

Die implizierte Firewallregel zum Zulassen von ausgehendem Traffic erlaubt ausgehende Verbindungen und etablierte Antworten von VMs im VPC-Netzwerk, es sei denn, Sie haben benutzerdefinierte Regeln zum Ablehnen von ausgehendem Traffic erstellt. Wenn Sie benutzerdefinierte Regeln zum Ablehnen von ausgehendem Traffic erstellt haben, müssen Sie Zulassungsregeln mit höherer Priorität erstellen, durch die zumindest ausgehender Traffic zu Ihren lokalen Nameservern gestattet wird.

Lokale Firewall prüfen

Die lokale Firewall muss so konfiguriert sein, dass sämtlicher eingehender Traffic von 35.199.192.0/19 sowie ausgehender Traffic zugelassen wird.

Prüfen Sie die Logs der lokalen Firewall auf DNS-Anfragen von 35.199.192.0/19. Zum Suchen mit einem regex-Ausdruck verwenden Sie Folgendes:

"35\.199\.(19[2-9]|20[0-9]|21[0-9]|22[0-3]).*"

Lokalen Nameserver prüfen

Im lokalen Nameserver darf keine ACL (Access Control List, Zugriffssteuerungsliste) konfiguriert sein, die Abfragen von 35.199.192.0/19 blockiert.

Prüfen Sie, ob der lokale Nameserver Pakete von 35.199.192.0/19 empfängt. Wenn Sie Shell-Zugriff haben, können Sie mit einem Tool wie tcpdump nach eingehenden Paketen von 35.199.192.0/19 sowie nach ausgehenden Paketen suchen:

sudo tcpdump port 53 and tcp -vv

Rückgaberouten überprüfen

Ihr lokales Netzwerk muss eine Route zum Ziel 35.199.192.0/19 haben, wobei der nächste Hop ein VPN-Tunnel oder eine Interconnect-Verbindung für das VPC-Netzwerk ist, das die DNS-Anfrage gesendet hat. Dieses Verhalten wird unter Weiterleitungszonen erstellen beschrieben.

Wenn Sie mehrere VPN-Tunnel für das Verbinden eines VPC-Netzwerks mit dem lokalen Netzwerk verwenden, muss die Antwort nicht über den Tunnel übertragen werden, der sie gesendet hat. Beim Übertragen der Antwort muss jedoch ein VPN-Tunnel mit einem nächsten Hop verwendet werden, der sich im selben VPC-Netzwerk befindet, von dem die Anfrage stammt.

Wenn Sie mehrere VPC-Netzwerke mit Ihrem lokalen Netzwerk verbunden haben, müssen Sie dafür sorgen, dass DNS-Antworten nicht an das falsche gesendet werden. Google Cloud verwirft DNS-Antworten, die an das falsche VPC-Netzwerk gesendet wurden. Eine empfohlene Lösung finden Sie in unserem Leitfaden Best Practices.

Die ausgehende Weiterleitung an einen Nameserver, der eine IP-Adresse außerhalb RFC 1918 verwendet, schlägt fehl

Standardmäßig verwendet Cloud DNS Standardrouting, mit dem Abfragen über das öffentliche Internet weitergeleitet werden, wenn der Ziel-Nameserver eine IP-Adresse außerhalb des RFC 1918-Bereichs hat. Standardrouting unterstützt keine Weiterleitungsabfragen an Nameserver mit Adressen außerhalb RFC 1918, die nicht über das öffentliche Internet erreichbar sind.

Zur Weiterleitung von Abfragen an einen Nameserver, der eine IP-Adresse außerhalb RFC 1918 über Ihr VPC-Netzwerk verwendet, konfigurieren Sie die Cloud DNS-Weiterleitungszone oder die Serverrichtlinie so, dass privates Routing für den Ziel-Nameserver verwendet wird.

Eine Beschreibung der Unterschiede zwischen Standard- und privatem Routing finden Sie unter Weiterleitungsziele und Routingmethoden.

Diese Einschränkung gilt auch dann, wenn für den Ziel-Nameserver eine VPC-Route vorhanden ist. Routen für Adressen außerhalb RFC 1918 haben keine Auswirkungen auf das Verhalten der ausgehenden Weiterleitung von Cloud DNS, wenn das Standardrouting konfiguriert ist.

Die ausgehende Weiterleitung an eine sekundäre Netzwerkkarte schlägt fehl

Prüfen Sie, ob Sie den sekundären Netzwerkschnittstellen-Controller (NIC) richtig eingerichtet haben.

Eine Anleitung zum Einrichten zusätzlicher NICs finden Sie unter VM-Instanzen mit mehreren Netzwerkschnittstellen erstellen.

Ausgehende weitergeleitete Abfragen erhalten SERVFAIL-Fehler

Wenn Cloud DNS einen Fehler von allen Ziel-Nameservern empfängt oder keine Antwort von einem der Ziel-Nameserver empfängt, wird ein SERVFAIL-Fehler zurückgegeben.

Prüfen Sie zur Behebung dieses Problems, ob Ihre lokalen Nameserver ordnungsgemäß konfiguriert sind. Prüfen Sie dann, ob Ihre lokalen Nameserver innerhalb von 4 Sekunden auf Abfragen aus dem Cloud DNS Adressbereich antworten, der in Google Cloud und lokale Firewalls öffnen, um DNS-Traffic zuzulassen beschrieben ist. Wenn Ihre lokalen Nameserver vorgelagerte Nameserver konsultieren, z. B. weil sie als Caching-Resolver konfiguriert sind, prüfen Sie, ob es Probleme mit den vorgelagerten Nameservern gibt.

Wenn das Weiterleitungsziel ein lokales System ist, sollten Sie beachten, dass die für diesen Pfad konfigurierten Routen benutzerdefinierte dynamische Routen oder benutzerdefinierte statische Routen sein können. Die einzige Ausnahme ist, dass benutzerdefinierte statische Routen mit Netzwerktags nicht zum Weiterleiten von DNS-Abfragen gültig sind. Achten Sie darauf, dass für die zum Aufrufen des lokalen Nameservers verwendete Route kein Netzwerk-Tag angibt.

Ressourceneinträge

Dieser Abschnitt enthält Tipps zur Fehlerbehebung bei Ressourceneinträgen.

Bei der Abfrage von Ressourceneinträgen unerwartete Daten in der Zone

Wenn Sie nach Ressourceneinträgen suchen, die in einer von Cloud DNS verwalteten Zone vorhanden sind, und unerwartete Daten erhalten, kann dies verschiedene Gründe haben:

  1. Ressourceneinträge, die mit der in RFC 1035 angegebenen Syntax @ erstellt werden, werden nicht unterstützt. Cloud DNS interpretiert das Symbol @ in solchen Ressourceneinträgen wortgetreu. Daher wird in der Zone example.com. ein Datensatz für den QNAME @ als @.example.com. anstelle von example.com. interpretiert. Achten Sie darauf, dass Sie Datensätze ohne das Symbol @ erstellen, um dieses Problem zu beheben. Alle Namen beziehen sich auf den Anfang der Zone.

  2. Wie alle Datensätze unterliegen Platzhalter-CNAME-Einträge den Regeln, die in RFC 4592 beschrieben werden. Beispiel: Sie definieren die folgenden Datensätze in der Zone example.com.:

    *.images.example.com. IN CNAME _static.example.com.

    srv1.images.example.com. IN A 192.0.2.91

    _static.example.com. IN A 192.0.2.92

    Bei einer Abfrage für public.srv1.images.example.com. wird NOERROR mit einem leeren Antwortabschnitt zurückgegeben. Wenn ein Eintrag zwischen dem CNAME und dem QNAME vorhanden ist, wird der CNAME-Eintrag nicht zurückgegeben. Es gibt jedoch keinen Eintrag, der genau mit QNAME übereinstimmt. Daher gibt Cloud DNS eine leere Antwort zurück. Dies ist das DNS-Standardverhalten.

Cloud DNS-Ressourceneinträge werden in zufälliger Reihenfolge zurückgegeben

In Übereinstimmung mit den DNS-Branchenpraktiken wenden Cloud DNS-Nameserver jetzt die Reihenfolge der Ressourcendatensätze nach dem Zufallsprinzip an und ignorieren die Reihenfolge, die vom autoritativen Server angegeben wurde. Das ist das übliche DNS-Verhalten, das für öffentliche und auch für private Cloud DNS-Zonen gilt.

Nicht unterstützter zonaler Ressourcentyp

Wenn Sie das Flag --location in einen gcloud-Befehl oder eine API-Anfrage für ein Feature eingeben, das auf eine andere Cloud DNS-Zone verweist, wird die Anfrage abgelehnt. Wenn Sie beispielsweise eine Funktion für ausschließlich zonale Funktionen an einen globalen Server oder eine Funktionsanfrage für einen globalen Server an einen zonalen Server senden, lehnt der Server die Anfrage ab und gibt den Fehler _UNSUPPORTED_ZONAL_RESOURCETYPE zurück

Eine Liste der Ressourcen und Funktionen, die von zonalem Cloud DNS unterstützt werden, finden Sie unter Unterstützung von zonalem Cloud DNS.

Nächste Schritte