Cloud DNS – Übersicht

Diese Seite bietet eine Übersicht über die Features und Leistungsmerkmale von Cloud DNS. Eine Einführung in Cloud DNS finden Sie in der Kurzanleitung.

Einführung

Cloud DNS ist ein stabiler globaler DNS-Hochleistungsdienst (Domain Name System), der Ihre Domainnamen kostengünstig im globalen DNS veröffentlicht.

Konzepte

DNS ist eine hierarchische verteilte Datenbank, mit der Sie IP-Adressen und andere Daten speichern und in der Sie Namen suchen können. Mit Cloud DNS können Sie Ihre Zonen und Einträge im DNS veröffentlichen, ohne eigene DNS-Server und Software verwalten zu müssen.

Cloud DNS bietet sowohl öffentliche Zonen als auch private verwaltete DNS-Zonen. Eine öffentliche Zone ist im öffentlichen Internet sichtbar, eine private Zone hingegen nur in einem oder mehreren von Ihnen festgelegten VPC-Netzwerken.

Eine Liste der allgemeinen DNS-Terminologie finden Sie unter Allgemeine DNS-Übersicht.

Eine Liste der wichtigsten Begriffe für Cloud DNS finden Sie unter Wichtige Begriffe.

Überlegungen zu freigegebenen VPC-Netzwerken

Wenn Sie eine von Cloud DNS verwaltete private Zone, eine Cloud DNS-Weiterleitungszone oder eine Cloud DNS-Peering-Zone mit einer freigegebenen VPC verwenden möchten, müssen Sie die Zone im Hostprojekt erstellen und dann die entsprechenden freigegebenen VPC-Netzwerke in die Liste der autorisierten Netzwerke für diese Zone aufnehmen.

Weitere Informationen finden Sie unter Best Practices für private Cloud DNS-Zonen.

Reihenfolge der VPC-Namensauflösung

Jedes VPC-Netzwerk stellt für die VM-Instanzen, die es verwenden, DNS-Namensauflösungsdienste bereit. Wenn VMs ihren Metadatenserver 169.254.169.254 als Nameserver verwenden, sucht Google Cloud in der folgenden Reihenfolge nach DNS-Einträgen:

  • Wenn für das VPC-Netzwerk eine Serverrichtlinie für ausgehenden Traffic konfiguriert ist, leitet Google Cloud alle DNS-Abfragen an diese alternativen Server weiter. Die Reihenfolge der VPC-Namensauflösung besteht nur aus diesem Schritt.

  • Wenn das VPC-Netzwerk keine Serverrichtlinie für ausgehenden Traffic hat, geschieht Folgendes:

    1. Google Cloud sucht nach einer privaten Zone, die mit dem angeforderten Eintrag so weit wie möglich übereinstimmt (längstes übereinstimmendes Suffix). Dies umfasst folgende Schritte:
      • Die in privaten Zonen erstellten Einträge werden durchsucht.
      • Die Weiterleitungsziele für Weiterleitungszonen werden abgefragt.
      • Die Reihenfolge der Namensauflösung eines anderen VPC-Netzwerks, das Peering-Zonen verwendet, wird abgefragt.
    2. Google Cloud durchsucht die automatisch erstellten Einträge des internen Compute Engine-DNS für das Projekt.
    3. Google Cloud fragt öffentlich verfügbare Zonen anhand des entsprechend konfigurierten SOA-Eintrags ab. Dies schließt öffentliche Cloud DNS-Zonen ein.

DNS-Weiterleitungsmethoden

Google Cloud bietet eingehende und ausgehende DNS-Weiterleitung für private Zonen.

  • Eingehende Weiterleitung bedeutet, dass ein lokaler DNS-Client oder -Server DNS-Anfragen an Cloud DNS senden kann. Der DNS-Client oder -Server kann dann Einträge gemäß der Reihenfolge der Namensauflösung eines VPC-Netzwerks auflösen. Bei der eingehenden Weiterleitung können lokale Clients Einträge in privaten Zonen, Weiterleitungszonen und Peering-Zonen auflösen, für die das VPC-Netzwerk autorisiert wurde. Lokale Clients stellen über Cloud VPN oder Cloud Interconnect eine Verbindung zum VPC-Netzwerk her.

  • Ausgehende Weiterleitung bedeutet, dass VMs in Google Cloud DNS-Anfragen an DNS-Nameserver Ihrer Wahl senden können. Die Nameserver können sich im selben VPC-Netzwerk, in einem lokalen Netzwerk oder im Internet befinden.

Zum Konfigurieren der DNS-Weiterleitung erstellen Sie eine Weiterleitungszone oder eine Cloud DNS-Serverrichtlinie. Die beiden Methoden werden in der folgenden Tabelle zusammengefasst:

Weiterleitung Cloud DNS-Methoden
Eingehend Lokale Systeme können Anfragen an ein VPC-Netzwerk senden, um die Reihenfolge der VPC-Namensauflösung dieses Netzwerks zu verwenden, wenn Sie eine Serverrichtlinie für eingehenden Traffic für dieses VPC-Netzwerk erstellen.
Ausgehend Sie können VMs in einem VPC-Netzwerk für Folgendes konfigurieren:
  • Auflösen von Einträgen, die auf Nameservern gehostet werden, die als Weiterleitungsziele einer Weiterleitungszone konfiguriert sind. Das VPC-Netzwerk ist zur Verwendung dieser Zone autorisiert. Wichtige Informationen dazu, wie Google Cloud Traffic an die IP-Adresse eines Weiterleitungsziels weiterleitet, finden Sie unter Weiterleitungsziele und Routingmethoden.
  • Senden aller DNS-Anfragen an einen alternativen Nameserver durch Erstellen einer Serverrichtlinie für ausgehenden Traffic für das VPC-Netzwerk. Wenn Sie einen alternativen Nameserver verwenden, können VMs im VPC-Netzwerk keine Einträge mehr in privaten Cloud DNS-Zonen, Weiterleitungszonen oder Peering-Zonen auflösen. Weitere Informationen finden Sie unter Reihenfolge der VPC-Namensauflösung. Lesen Sie sich diese aufmerksam durch.

Sie können gleichzeitig die eingehende und die ausgehende Weiterleitung für ein VPC-Netzwerk konfigurieren. Durch die bidirektionale Weiterleitung können VMs im VPC-Netzwerk Einträge in einem lokalen Netzwerk oder in einem Netzwerk auflösen, das von einem anderen Cloud-Anbieter gehostet wird. Hosts im lokalen Netzwerk haben mit dieser Art der Weiterleitung außerdem die Möglichkeit, Einträge für Ihre Google Cloud-Ressourcen aufzulösen.

Die Cloud DNS-Steuerungsebene bestimmt mithilfe eines Algorithmus die Reaktionsfähigkeit eines Weiterleitungsziels. Ihre weitergeleiteten ausgehenden Abfragen können manchmal zu SERVFAIL-Fehlern führen. Informationen zur Umgehung dieses Problems finden Sie im entsprechenden Abschnitt der Dokumentation zur Fehlerbehebung.

PTR-Einträge in privaten Zonen

PTR-Einträge für RFC-1918-Adressen

Zum Ausführen von Reverse-Lookups mit benutzerdefinierten PTR-Einträgen für RFC-1918-Adressen müssen Sie eine private Cloud DNS-Zone erstellen, die mindestens so spezifisch wie eine der folgenden Beispielzonen aufgebaut ist. Der Grund hierfür ist der Abgleich mit dem längsten Suffix wie unter Reihenfolge der VPC-Namensauflösung beschrieben.

  • 10.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 16.172.in-addr.arpa., 17.172.in-addr.arpa., ... bis 31.172.in-addr.arpa.

Wenn Sie eine private Cloud DNS-Zone für RFC-1918-Adressen einrichten, werden benutzerdefinierte PTR-Einträge, die Sie für VMs in dieser Zone erstellen, durch die PTR-Einträge überschrieben, die das interne Compute Engine-DNS automatisch erstellt. Das liegt daran, dass PTR-Einträge des internen Compute Engine-DNS in der vorherigen Liste spezifischerer Zonen erstellt werden.

Angenommen, Sie erstellen eine verwaltete private Zone für in-addr.arpa. mit dem folgenden PTR-Eintrag für eine VM mit der IP-Adresse 10.1.1.1:

1.1.1.10.in-addr.arpa. -> test.example.domain

PTR-Abfragen für 1.1.1.10.in-addr.arpa. werden von der spezifischeren internen Compute Engine-DNS-Zone 10.in-addr.arpa. beantwortet. Der PTR-Eintrag in Ihrer privaten Cloud DNS-Zone für test.example.domain wird ignoriert.

Wenn Sie die automatisch erstellten PTR-Einträge des internen Compute Engine-DNS für VMs überschreiben möchten, müssen Sie darauf achten, dass Ihre benutzerdefinierten PTR-Einträge in einer privaten Zone erstellt werden, die mindestens so spezifisch wie eine der in diesem Abschnitt dargestellten Zonen ist. Wenn Sie beispielsweise den folgenden PTR-Eintrag in einer privaten Zone für 10.in-addr.arpa. erstellen, wird der automatisch generierte Eintrag von Ihrem Eintrag überschrieben:

1.1.1.10.in-addr.arpa. -> test.example.domain

Sie können auch spezifischere private Cloud DNS-Reverse-Zonen erstellen, wenn Sie nur einen Teil eines Netzwerkblocks überschreiben müssen. Beispielsweise kann eine private Zone für 5.10.in-addr.arpa. zum Speichern von PTR-Einträgen verwendet werden, die alle internen DNS-PTR-Einträge von Compute Engine überschreiben, die automatisch für VMs mit IP-Adressen im Adressbereich 10.5.0.0/16 erstellt werden.

Unterstützte DNS-Eintragstypen

Cloud DNS unterstützt die folgenden Eintragstypen:

Eintragstyp Beschreibung
A

Adresseintrag, der die Hostnamen den jeweiligen IPv4-Adressen zuordnet.

AAAA

IPv6-Adresseintrag, der die Hostnamen den jeweiligen IPv6-Adressen zuordnet.

CAA

CAA-Eintrag (Certificate Authority Authorization), mit dem angegeben wird, welche Zertifizierungsstellen zum Erstellen von Zertifikaten für eine Domain berechtigt sind.

CNAME

Canonical-Name-Eintrag, der Aliasnamen angibt.
Cloud DNS unterstützt das rekursive Auflösen von CNAMEs nicht zonenübergreifend für verschiedene verwaltete private Zonen (CNAME-Chasing). Weitere Informationen finden Sie unter Fehlerbehebung.

IPSECKEY

IPSEC-Tunnel-Gateway-Daten und öffentliche Schlüssel für IPSEC-fähige Clients, die eine opportunistische Verschlüsselung ermöglichen.

MX

Mail-Exchange-Eintrag für die Weiterleitung von Anfragen an Mailserver.

NAPTR

Naming-Authority-Pointer-Eintrag, definiert durch RFC 3403.

NS

Nameserver-Eintrag, mit dem eine DNS-Zone an einen autoritativen Server delegiert wird.

PTR

Pointer-Eintrag, der häufig für Reverse DNS-Lookups verwendet wird.

SOA

Start-of-Authority-Eintrag, mit dem autoritative Informationen über eine DNS-Zone angegeben werden. Ein SOA-Ressourceneintrag wird für Sie erstellt, wenn Sie Ihre verwaltete Zone erstellen. Sie können diesen Eintrag nach Bedarf anpassen. Zum Beispiel haben Sie die Möglichkeit, die Seriennummer in eine beliebige Zahl zu ändern, mit der eine datumsbasierte Versionsverwaltung unterstützt wird.

SPF

Sender-Policy-Framework-Eintrag, ein verworfener Eintragstyp, der früher für E-Mail-Validierungssysteme verwendet wurde (verwenden Sie stattdessen einen TXT-Eintrag).

SRV

Service-Locator-Eintrag, der von einigen Voice-Over-IPs, Instant-Messaging-Protokollen und anderen Anwendungen verwendet wird.

SSHFP

SSH-Fingerabdruck für SSH-Clients zur Prüfung der öffentlichen Schlüssel von SSH-Servern.

TLSA

TLS-Authentifizierungseintrag zur Prüfung von X.509-Serverzertifikaten durch TLS-Clients.

TXT

Texteintrag, der beliebigen Text enthalten und außerdem für die Definition von maschinenlesbaren Daten verwendet werden kann, z. B. von Sicherheitsdaten oder Informationen zur Verhinderung von Datenmissbrauch. Ein TXT-Eintrag kann einen oder mehrere Textstrings enthalten. Die maximale Länge eines einzelnen Strings beträgt 255 Zeichen. Mehrere Strings werden durch Mail-Agents und andere Software-Agents verkettet. Setzen Sie jeden String in Anführungszeichen. Beispiel:


"Hello world" "Bye world"

Unter Einträge verwalten wird gezeigt, wie Sie mit DNS-Einträgen arbeiten.

Platzhalter-DNS-Einträge

Platzhaltereinträge werden für alle Eintragstypen, ausgenommen NS-Einträge, unterstützt.

DNSSEC

Cloud DNS unterstützt verwaltetes DNSSEC und schützt Ihre Domains vor Spoofing- und Cache-Poisoning-Angriffen. Wenn Sie einen Überprüfungs-Resolver wie Google Public DNS verwenden, bietet DNSSEC eine starke Authentifizierung (jedoch keine Verschlüsselung) für die Domainsuche. Weitere Informationen zu DNSSEC finden Sie unter DNSSEC-Konfiguration verwalten.

Weiterleitungszonen

Mithilfe von Cloud DNS-Weiterleitungszonen können Sie Ziel-Nameserver für bestimmte private Zonen konfigurieren. Die Verwendung einer Weiterleitungszone ist eine Möglichkeit, die von Ihrem VPC-Netzwerk ausgehende DNS-Weiterleitung zu implementieren.

Eine Cloud DNS-Weiterleitungszone ist ein spezieller Typ von privater Cloud DNS-Zone. Anstatt Einträge innerhalb der Zone zu erstellen, geben Sie einen Satz von Weiterleitungszielen an. Jedes Weiterleitungsziel ist eine IP-Adresse eines DNS-Servers, der sich in Ihrem VPC-Netzwerk oder in einem lokalen Netzwerk befindet, das über Cloud VPN oder Cloud Interconnect mit Ihrem VPC-Netzwerk verbunden ist.

Weiterleitungsziele und Routingmethoden

Cloud DNS unterstützt drei Typen von Zielen und bietet standardmäßige oder private Methoden für das Routing von Traffic an diese Ziele.

Weiterleitungsziel Beschreibung Standardrouting Privates Routing Anfragen kommen von
Typ 1 Eine interne IP-Adresse einer Google Cloud-VM im selben VPC-Netzwerk, das zur Verwendung der Weiterleitungszone autorisiert ist Müssen RFC-1918-IP-Adressen sein – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet Beliebige interne IP-Adresse – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet 35.199.192.0/19
Typ 2 Eine IP-Adresse eines lokalen Systems, das über Cloud VPN oder Cloud Interconnect mit dem VPC-Netzwerk verbunden ist, das zum Abfragen der Weiterleitungszone autorisiert ist Müssen RFC-1918-IP-Adressen sein – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet Beliebige interne IP-Adresse – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet 35.199.192.0/19
Typ 3 Eine externe IP-Adresse eines DNS-Nameservers im Internet.
Enthält eine externe IP-Adresse einer Google Cloud-Ressource.
Muss eine im Internet routingfähige Adresse sein – Traffic wird immer an das Internet weitergeleitet Privates Routing wird nicht unterstützt Quellbereiche von Google Public DNS

Sie können eine der beiden folgenden Routingmethoden auswählen, wenn Sie das Weiterleitungsziel in die Weiterleitungszone aufnehmen:

  • Standardrouting:: Leitet Traffic über ein autorisiertes VPC-Netzwerk oder über Internet weiter, je nachdem, ob das Weiterleitungsziel eine RFC-1918-IP-Adresse ist. Wenn das Weiterleitungsziel eine RFC-1918-IP-Adresse ist, klassifiziert Cloud DNS das Ziel entweder als Typ 1- oder Typ 2-Ziel und leitet Anfragen über ein autorisiertes VPC-Netzwerk weiter. Wenn das Ziel keine RFC 1918-IP-Adresse ist, klassifiziert Cloud DNS das Ziel als Typ 3 und erwartet, dass das Ziel über das Internet zugänglich ist.

  • Privates Routing: Leitet Traffic immer über ein autorisiertes VPC-Netzwerk weiter, unabhängig von der IP-Adresse des Ziels (RFC 1918 oder nicht). Daher werden nur Ziele vom Typ 1 und Typ 2 unterstützt.

Für den Zugriff auf das Weiterleitungsziel Typ 1 oder Typ 2 verwendet Cloud DNS Routen im autorisierten VPC-Netzwerk, in dem sich der DNS-Client befindet. Diese Routen definieren einen sicheren Pfad zum Weiterleitungsziel:

Weitere Anleitungen zu den Netzwerkanforderungen für Ziele vom Typ 1 und Typ 2 finden Sie unter Anforderungen an das Netzwerk weiterleiten.

Weiterleitungszonen verwenden

VMs in einem VPC-Netzwerk können in folgenden Fällen eine Cloud DNS-Weiterleitungszone verwenden:

  • Das VPC-Netzwerk wurde zur Verwendung der Cloud DNS-Weiterleitungszone autorisiert. Sie können mehrere VPC-Netzwerke im selben Projekt zur Verwendung der Weiterleitungszone autorisieren.
  • Das Gastbetriebssystem jeder VM im VPC-Netzwerk verwendet den Metadatenserver 169.254.169.254 der VM als Nameserver.

Sich überschneidende Weiterleitungszonen

Da Cloud DNS-Weiterleitungszonen eine Art von privaten Zonen sind, die von Cloud DNS verwaltet werden, können Sie mehrere sich überschneidende Zonen erstellen. VMs, die wie oben beschrieben konfiguriert sind, lösen einen Eintrag gemäß der Reihenfolge der VPC-Namensauflösung auf. Dabei wird die Zone mit dem längsten Suffix verwendet. Weitere Informationen finden Sie unter Sich überschneidende Zonen.

Caching und Weiterleitungszonen

Cloud DNS speichert Antworten auf Abfragen, die an Cloud DNS-Weiterleitungszonen gesendet wurden, im Cache. Dabei wird ein Cache mit Antworten von erreichbaren Weiterleitungszielen über die kürzere der folgenden Zeitspannen beibehalten:

  • 60 Sekunden
  • Die Gültigkeitsdauer (TTL) des Eintrags

Wenn alle Weiterleitungsziele für eine Weiterleitungszone nicht mehr erreichbar sind, behält Cloud DNS den Cache der zuvor in dieser Zone angeforderten Einträge während der Gültigkeitsdauer (TTL) jedes Eintrags bei.

Wann sollte stattdessen Peering verwendet werden?

Cloud DNS kann keine Verbindung zu einem Weiterleitungsziel über transitives Routing herstellen. Das folgende Szenario veranschaulicht eine ungültige Konfiguration:

  • Sie haben ein lokales Netzwerk über Cloud VPN oder Cloud Interconnect mit einem VPC-Netzwerk namens vpc-net-a verbunden.

  • Sie haben das VPC-Netzwerk vpc-net-a über VPC-Netzwerk-Peering mit vpc-net-b verbunden. Sie haben vpc-net-a für den Export benutzerdefinierter Routen und vpc-net-b für deren Import konfiguriert.

  • Sie haben eine Weiterleitungszone erstellt, deren Weiterleitungsziele sich im lokalen Netzwerk befinden, mit dem vpc-net-a verbunden ist. Sie haben vpc-net-b zur Verwendung dieser Weiterleitungszone autorisiert.

Das Auflösen eines Eintrags in einer Zone, die von den Weiterleitungszielen bedient wird, schlägt in diesem Szenario fehl, obwohl eine Verbindung von vpc-net-b zu Ihrem lokalen Netzwerk besteht. Führen Sie die folgenden Tests über eine VM in vpc-net-b aus, um diesen Fehler nachzuvollziehen:

  • Fragen Sie den Metadatenserver 169.254.169.254 der VM nach einem Eintrag ab, der in der Weiterleitungszone definiert ist. Diese Abfrage schlägt erwartungsgemäß fehl, da Cloud DNS kein transaktives Routing an Weiterleitungsziele unterstützt. Eine VM muss zur Verwendung ihres Metadatenservers konfiguriert sein, um eine Weiterleitungszone verwenden zu können.
  • Fragen Sie das Weiterleitungsziel direkt nach diesem Eintrag ab. Diese Abfrage zeigt, dass transitive Verbindungen erfolgreich sind, obwohl Cloud DNS diesen Pfad nicht verwendet.

Sie können dieses ungültige Szenario mithilfe einer Cloud DNS-Peering-Zone korrigieren:

  1. Erstellen Sie eine Cloud DNS-Peering-Zone, die für vpc-net-b autorisiert ist und auf vpc-net-a verweist.
  2. Erstellen Sie eine Weiterleitungszone, die für vpc-net-a autorisiert ist und deren Weiterleitungsziele lokale Nameserver sind.

Sie können diese Schritte in beliebiger Reihenfolge ausführen. Nach Abschluss dieser Schritte können Compute Engine-Instanzen in vpc-net-a und vpc-net-b die lokalen Weiterleitungsziele abfragen.

DNS-Peering

Mit DNS-Peering können Sie Anfragen für Einträge aus dem Namespace einer bestimmten Zone an ein anderes VPC-Netzwerk senden. Beispielsweise kann ein SaaS-Anbieter einem SaaS-Kunden Zugriff auf von ihm verwaltete DNS-Einträge gewähren.

Zum Bereitstellen von DNS-Peering müssen Sie eine Cloud DNS-Peering-Zone erstellen und für die Ausführung von DNS-Lookups in einem VPC-Netzwerk konfigurieren, in dem die Einträge für den Namespace dieser Zone verfügbar sind. Das VPC-Netzwerk, in dem die DNS-Peering-Zone Lookups ausführt, wird als DNS-Produzentennetzwerk bezeichnet.

Zur Verwendung von DNS-Peering müssen Sie ein Netzwerk für die Verwendung einer Peering-Zone autorisieren. Das zur Verwendung der Peering-Zone berechtigte VPC-Netzwerk wird als DNS-Nutzernetzwerk bezeichnet.

Wenn die Autorisierung abgeschlossen ist, können Google Cloud-Ressourcen im DNS-Nutzernetzwerk so nach Einträgen im Namespace der Peering-Zone nachschlagen, als ob sie sich im DNS-Produzentennetzwerk befinden. Lookups für Einträge im Namespace der Peering-Zone erfolgen in der Reihenfolge der Namensauflösung des DNS-Produzentennetzwerks. Auf diese Weise können Google Cloud-Ressourcen im DNS-Nutzernetzwerk Einträge im Namespace der Zone aus den folgenden Quellen abrufen, die im DNS-Produzentennetzwerk verfügbar sind:

  • Von Cloud DNS verwaltete private Zonen, die zur Verwendung durch das DNS-Produzentennetzwerk autorisiert sind
  • Von Cloud DNS verwaltete Weiterleitungszonen, die zur Verwendung durch das DNS-Produzentennetzwerk autorisiert sind
  • Interne DNS-Namen von Compute Engine im DNS-Produzentennetzwerk
  • Ein alternativer Nameserver, sofern im DNS-Produzentennetzwerk eine ausgehende DNS-Richtlinie konfiguriert wurde

Einschränkungen für DNS-Peering

Beachten Sie beim Konfigurieren von DNS-Peering Folgendes:

  • DNS-Peering ist eine einseitige Beziehung. Es erlaubt Google Cloud-Ressourcen im DNS-Nutzernetzwerk, so nach Einträgen im Namespace der Peering-Zone zu suchen, als ob sich die Ressourcen im DNS-Produzentennetzwerk befinden.
  • Die DNS-Produzenten- und -Nutzernetzwerke müssen VPC-Netzwerke sein.
  • DNS-Peering und VPC-Netzwerk-Peering sind unterschiedliche Dienste. DNS-Peering kann in Verbindung mit VPC-Netzwerk-Peering verwendet werden, VPC-Netzwerk-Peering ist für DNS-Peering jedoch nicht erforderlich.
  • Transitives DNS-Peering wird unterstützt, jedoch nur über einen einzigen transitiven Hop. Es können also maximal drei VPC-Netzwerke beteiligt sein, wobei das Netzwerk in der Mitte der transitive Hop ist. So lässt sich beispielsweise eine Peering-Zone in vpc-net-a erstellen, die auf vpc-net-b verweist, und dann eine Peering-Zone in vpc-net-b, die auf vpc-net-c verweist.
  • Wenn Sie DNS-Peering für das Verweisen auf eine Weiterleitungszone verwenden, muss das Ziel-VPC-Netzwerk mit der Weiterleitungszone eine VM, einen Interconnect-Anhang (VLAN) oder einen Cloud VPN-Tunnel in derselben Region wie die Quell-VM enthalten, die die DNS-Peering-Zone verwendet. Weitere Informationen zu dieser Einschränkung finden Sie unter Fehlerbehebung.

Zum Erstellen einer Peering-Zone benötigen Sie die IAM-Rolle DNS-Peer für das Projekt, in dem das DNS-Produzentennetzwerk enthalten ist.

Sich überschneidende Zonen

Wenn der ursprüngliche Domainname einer Zone mit dem der anderen Zone identisch oder eine Subdomain einer Domain desselben Namens ist, überschneiden sich zwei Zonen. Beispiele:

  • Eine Zone für gcp.example.com und eine weitere Zone für gcp.example.com überschneiden sich, da die Domainnamen identisch sind.
  • Eine Zone für dev.gcp.example.com und eine Zone für gcp.example.com überschneiden sich, da dev.gcp.example.com eine Subdomain von gcp.example.com ist. Im nächsten Abschnitt werden Regeln für sich überschneidende Zonen erläutert.

Regeln für sich überschneidende Zonen

Cloud DNS erzwingt die folgenden Regeln für sich überschneidende Zonen:

  • Sich überschneidende öffentliche Zonen sind auf denselben Cloud DNS-Nameservern nicht zulässig. Wenn Sie überschneidende Zonen erstellen, versucht Cloud DNS, sie auf verschiedenen Nameservern abzulegen. Falls dies nicht möglich ist, kann Cloud DNS die sich überschneidende Zone nicht erstellen.

  • Eine private Zone kann sich mit einer beliebigen öffentlichen Zone überschneiden.

  • Private Zonen für verschiedene VPC-Netzwerke können sich überschneiden. So können z. B. zwei VPC-Netzwerke jeweils eine Datenbank-VM mit dem Namen database.gcp.example.com in einer Zone gcp.example.com haben. An database.gcp.example.com gerichtete Abfragen erhalten unterschiedliche Antworten, je nachdem, welche Zoneneinträge in der Zone definiert sind, die für die einzelnen VPC-Netzwerke autorisiert ist.

  • Zwei private Zonen, auf die über dasselbe VPC-Netzwerk zugegriffen werden darf, können keine identischen Ursprünge haben, es sei denn, eine Zone ist eine Subdomain der anderen. Der Metadatenserver entscheidet abhängig vom längsten übereinstimmenden Suffix, welcher Ursprung in der jeweiligen Zone nach Einträgen abgefragt werden soll.

Beispiele für die Abfrageauflösung

Google Cloud löst Cloud DNS-Zonen wie unter Reihenfolge der VPC-Namensauflösung beschrieben auf. Beim Ermitteln der Zone, die für einen bestimmten Eintrag abzufragen ist, sucht Cloud DNS nach einer Zone, die mit dem angeforderten Eintrag so weit wie möglich übereinstimmt (längstes übereinstimmendes Suffix).

Sofern Sie keinen alternativen Nameserver in einer Serverrichtlinie für ausgehenden Traffic angegeben haben, sucht Google Cloud den Eintrag zuerst in einer privaten Zone (oder Weiterleitungszone bzw. Peering-Zone), die für Ihr VPC-Netzwerk autorisiert ist, und erst dann in einer öffentlichen Zone.

Die folgenden Beispiele veranschaulichen die Reihenfolge, die der Metadatenserver beim Abfragen von DNS-Einträgen einhält. Angenommen, Sie haben für jedes dieser Beispiele die zwei privaten Zonen gcp.example.com und dev.gcp.example.com erstellt und außerdem die Berechtigung vergeben, vom selben VPC-Netzwerk aus darauf zuzugreifen. In diesem Fall werden DNS-Abfragen von VMs in einem VPC-Netzwerk so von Google Cloud verarbeitet:

  • Der Metadatenserver löst Einträge für myapp.example.com mithilfe von öffentlichen Nameservern auf, da es keine private Zone für example.com gibt, die für das VPC-Netzwerk autorisiert wurde.
  • Der Metadatenserver löst den Eintrag myapp.gcp.example.com mithilfe der autorisierten privaten Zone gcp.example.com auf, da gcp.example.com das längste gemeinsame Suffix zwischen dem angeforderten Eintragsnamen und den verfügbaren autorisierten privaten Zonen ist. NXDOMAIN wird zurückgegeben, wenn in der privaten Zone gcp.example.com kein Eintrag für myapp.gcp.example.com definiert ist, selbst wenn in einer öffentlichen Zone ein Eintrag für myapp.gcp.example.com definiert ist.
  • Entsprechend werden Abfragen für myapp.dev.gcp.example.com gemäß den Einträgen in der autorisierten privaten Zone dev.gcp.example.com aufgelöst. NXDOMAIN wird zurückgegeben, wenn in der Zone dev.gcp.example.com kein Eintrag für myapp.dev.gcp.example.com vorhanden ist, selbst wenn in einer anderen privaten oder öffentlichen Zone ein Eintrag für myapp.dev.gcp.example.com definiert ist.
  • Abfragen bezüglich myapp.prod.gcp.example.com werden gemäß Einträgen in der privaten Zone gcp.example.com aufgelöst, da gcp.example.com das längste gemeinsame Suffix für den angeforderten DNS-Eintrag und die verfügbaren privaten Zonen ist.

Beispiel für ein Split-Horizon-DNS

Sie können in einer Split-Horizon-DNS-Konfiguration eine Kombination aus öffentlichen und privaten Zonen verwenden. Bei privaten Zonen haben Sie die Möglichkeit, abweichende Antworten auf eine Abfrage nach demselben Eintrag für den Fall zu definieren, dass die Abfrage von einer VM innerhalb eines autorisierten VPC-Netzwerks kommt. Das Split-Horizon-DNS ist nützlich, wenn Sie je nach VPC-Ursprungsnetzwerk unterschiedliche Einträge für dieselben DNS-Abfragen bereitstellen müssen.

Im Folgenden finden Sie ein Split-Horizon-Beispiel:

  • Sie haben die öffentliche Zone gcp.example.com erstellt und ihren Registrator zur Verwendung von Cloud DNS-Nameservern konfiguriert.
  • Sie haben die private Zone gcp.example.com erstellt und Ihr VPC-Netzwerk für den Zugriff auf diese Zone autorisiert.

In der privaten Zone haben Sie einen einzelnen Eintrag erstellt:

Eintrag Typ TTL (Sekunden) Daten
foo.gcp.example.com A 5 10.128.1.35

In der öffentlichen Zone haben Sie zwei Einträge erstellt:

Eintrag Typ TTL (Sekunden) Daten
foo.gcp.example.com A 5 104.198.6.142
bar.gcp.example.com A 50 104.198.7.145

Die folgenden Abfragen werden wie beschrieben aufgelöst:

  • Eine Abfrage bezüglich foo.gcp.example.com von einer VM in Ihrem VPC-Netzwerk gibt 10.128.1.35 zurück.
  • Eine Abfrage bezüglich foo.gcp.example.com aus dem Internet gibt 104.198.6.142 zurück.
  • Eine Abfrage bezüglich bar.gcp.example.com von einer VM in Ihrem VPC-Netzwerk gibt einen NXDOMAIN-Fehler zurück, da für bar.gcp.example.com kein Eintrag in der privaten Zone gcp.example.com vorhanden ist.
  • Eine Abfrage bezüglich bar.gcp.example.com aus dem Internet gibt 104.198.7.145 zurück.

DNS-Serverrichtlinien

Sie können genau eine DNS-Serverrichtlinie für jedes VPC-Netzwerk konfigurieren. Die Richtlinie kann die eingehende oder die ausgehende Weiterleitung oder beides festlegen. In diesem Abschnitt bezieht sich Serverrichtlinie für eingehenden Traffic auf eine Richtlinie, die die eingehende DNS-Weiterleitung zulässt, und Serverrichtlinie für ausgehenden Traffic auf eine mögliche Methode zur Implementierung der ausgehenden DNS-Weiterleitung. Eine Richtlinie kann sowohl eine Serverrichtlinie für eingehenden Traffic als auch eine Serverrichtlinie für ausgehenden Traffic sein, wenn sie die Features beider Richtlinien implementiert.

Weitere Informationen finden Sie unter Serverrichtlinien anwenden.

Serverrichtlinie für eingehenden Traffic

Jedes VPC-Netzwerk stellt für die VMs, die das Netzwerk verwenden, DNS-Namensauflösungsdienste bereit. Wenn eine VM ihren Metadatenserver 169.254.169.254 als Nameserver verwendet, sucht Google Cloud gemäß der Reihenfolge der VPC-Namensauflösung nach DNS-Einträgen.

Standardmäßig sind die Namensauflösungsdienste eines VPC-Netzwerks über seine Reihenfolge der Namensauflösung nur für dieses VPC-Netzwerk selbst verfügbar. Sie können diese Namensauflösungsdienste für ein lokales Netzwerk verfügbar machen, das über Cloud VPN oder Cloud Interconnect verbunden ist. Dazu erstellen Sie eine DNS-Richtlinie für eingehenden Traffic in Ihrem VPC-Netzwerk.

Wenn Sie eine Richtlinie für eingehenden Traffic erstellen, verwendet Cloud DNS eine interne IP-Adresse aus dem primären IP-Adressbereich eines Subnetzes in jeder Region, die Ihr VPC-Netzwerk verwendet. Diese internen IP-Adressen werden als Einstiegspunkte für eingehende DNS-Anfragen verwendet.

Richtlinie für eingehenden Traffic – Einstiegspunkte

Die regionalen internen IP-Adressen, die von Cloud DNS für die DNS-Richtlinie für eingehenden Traffic verwendet werden, dienen als Einstiegspunkte in die Namensauflösungsdienste des VPC-Netzwerks. Zur Verwendung der DNS-Richtlinie für eingehenden Traffic müssen Sie Ihre lokalen Systeme oder Nameserver so konfigurieren, dass DNS-Abfragen an die Proxy-IP-Adresse weitergeleitet werden, die sich in derselben Region wie der Cloud VPN-Tunnel oder der Cloud Interconnect-Anhang (VLAN) befindet, der Ihr lokales Netzwerk mit Ihrem VPC-Netzwerk verbindet.

Informationen zum Erstellen von Serverrichtlinien für eingehenden Traffic finden Sie unter Serverrichtlinie für eingehenden Traffic erstellen.

Serverrichtlinie für ausgehenden Traffic

Wenn Sie die Reihenfolge der VPC-Namensauflösung ändern möchten, können Sie eine DNS-Richtlinie für ausgehenden Traffic erstellen, die eine Liste von alternativen Nameservern angibt. Bei Angabe von alternativen Nameservern für ein VPC-Netzwerk fragt Google Cloud nur diese Nameserver ab, um DNS-Anfragen von VMs in Ihrem VPC-Netzwerk zu verarbeiten, die zur Verwendung ihrer Metadatenserver konfiguriert sind (169.254.169.254).

Informationen zum Erstellen von Serverrichtlinien für ausgehenden Traffic finden Sie unter Serverrichtlinie für ausgehenden Traffic erstellen.

Alternative Nameserver und Routingmethoden

Cloud DNS unterstützt vier Typen von alternativen Nameservern und bietet Standard- und private Routingmethoden für das Routing von Traffic an diese Server.

Alternative Nameserver werden in der folgenden Tabelle definiert:

Alternativer Nameserver Beschreibung Standardrouting Privates Routing Anfragen kommen von
Typ 1 Eine interne IP-Adresse einer Google Cloud-VM in demselben VPC-Netzwerk, in dem die Serverrichtlinie für ausgehenden Traffic definiert ist Müssen RFC-1918-IP-Adressen sein – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet Beliebige interne IP-Adresse – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet 35.199.192.0/19
Typ 2 Eine IP-Adresse eines lokalen Systems, das mit dem VPC-Netzwerk mit der Serverrichtlinie für ausgehenden Traffic über Cloud VPN oder Cloud Interconnect verbunden ist Müssen RFC-1918-IP-Adressen sein – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet Beliebige interne IP-Adresse – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet 35.199.192.0/19
Typ 3 Eine externe IP-Adresse eines DNS-Nameservers im Internet.
Enthält eine externe IP-Adresse einer Google Cloud-Ressource.
Muss eine im Internet routingfähige Adresse sein – Traffic wird immer an das Internet weitergeleitet Privates Routing wird nicht unterstützt Quellbereiche von Google Public DNS
Typ 4 Eine externe IP-Adresse einer Compute Engine-VM in einem anderen VPC-Netzwerk.
Muss eine IP-Adresse außerhalb des RFC 1918-Bereichs sein. Privates Routing wird nicht unterstützt. Achten Sie darauf, dass das private Routing deaktiviert ist. Quellbereiche von Google Public DNS

Sie können eine der zwei folgenden Routingmethoden auswählen, wenn Sie den alternativen Nameserver einer Richtlinie für die ausgehende Weiterleitung angeben.

  • Standardrouting: Leitet Traffic über ein autorisiertes VPC-Netzwerk oder das Internet weiter, je nachdem, ob der alternative Nameserver eine RFC-1918-Adresse ist oder nicht. Wenn der alternative Nameserver eine RFC-1918-IP-Adresse ist, klassifiziert Cloud DNS den Nameserver entweder als Nameserver vom Typ 1 oder Typ 2 und leitet Anfragen über ein autorisiertes VPC-Netzwerk. Wenn der alternative Nameserver keine RFC-1918-IP-Adresse ist, klassifiziert Cloud DNS den Nameserver als Typ 3 und erwartet, dass der Nameserver über das Internet zugänglich ist.

  • Privates Routing: Leitet den Traffic immer über ein autorisiertes VPC-Netzwerk weiter, unabhängig von der IP-Adresse des alternativen Nameservers (RFC 1918 oder nicht). Daher werden nur Nameserver vom Typ 1 und Typ 2 unterstützt.

Für den Zugriff auf einen alternativen Nameserver vom Typ 1 oder Typ 2 verwendet Cloud DNS Routen im autorisierten VPC-Netzwerk, in dem sich der DNS-Client befindet. Diese Routen definieren einen sicheren Pfad zum Nameserver:

Weitere Anleitungen zu den Netzwerkanforderungen für Nameserver vom Typ 1 und Typ 2 finden Sie unter Netzwerkanforderungen für alternative Nameserver.

Zugriffsteuerung

Allgemeine Zugriffssteuerung

Sie können die Nutzer, die Änderungen an Ihren DNS-Einträgen vornehmen dürfen, auf der Seite "IAM & Verwaltung" in der Google Cloud Console verwalten. Damit Nutzer Änderungen ausführen können, müssen sie im Bereich "Berechtigungen" der Cloud Console entweder als editor oder owner aufgeführt sein. Die-Berechtigungsstufe zum Betrachten gewährt einen schreibgeschützten Zugriff auf die Cloud DNS-Einträge.

Diese Berechtigungen gelten außerdem für Dienstkonten, die Sie möglicherweise für die Verwaltung Ihrer DNS-Dienste verwenden.

Zugriffssteuerung für verwaltete Zonen

Nutzer mit der Rolle "Projektbesitzer" oder "Projektbearbeiter" können die verwalteten Zonen in dem von ihnen verwalteten Projekt verwalten oder aufrufen.

Nutzer mit der Rolle "DNS-Administrator" oder "DNS-Leser" können die verwalteten Zonen in allen Projekten, auf die sie Zugriff haben, verwalten oder ansehen.

Projektinhaber, Bearbeiter, DNS-Administratoren und Leser können die Liste der privaten Zonen ansehen, die auf ein VPC-Netzwerk im aktuellen Projekt angewendet werden.

Leistung und Timing

Cloud DNS verwendet Anycast, um Ihren verwalteten Zonen an verschiedenen Standorten weltweit eine Hochverfügbarkeit zu ermöglichen. Anfragen werden automatisch an den nächsten Standort weitergeleitet, wodurch sich die Latenz verkürzt und die Leistung bei der Suche des autoritativen Namens für Ihre Nutzer verbessert wird.

Übernahme von Änderungen

Änderungen werden in zwei Schritten übernommen. Im ersten Schritt muss die Änderung, die Sie durch die API oder das Befehlszeilentool senden, an die autoritativen DNS-Server des Cloud DNS weitergeleitet werden. Im zweiten Schritt müssen die DNS-Resolver diese Änderung anwenden, wenn die Einträge in deren Cache abgelaufen sind.

Der Cache der DNS-Resolver wird von der Gültigkeitsdauer (Time to Live, TTL) gesteuert, die Sie für Ihre Einträge festlegen und die in Sekunden angegeben wird. Beispiel: Wenn Sie einen TTL-Wert von 86400 (die Anzahl der Sekunden in 24 Stunden) angeben, werden die DNS-Resolver angewiesen, die Einträge 24 Stunden lang im Cache zu speichern. Einige DNS-Resolver ignorieren den TTL-Wert oder nutzen ihre eigenen Werte, die die vollständige Übernahme der Einträge verzögern können.

Wenn Sie eine Änderung an Diensten planen, die ein enges Zeitfenster erfordert, ist es möglicherweise ratsam, den TTL-Wert vor Ihrer Änderung auf einen kleineren Wert festzulegen. Dadurch verkleinert sich das Zeitfenster für das Caching und die Übernahme Ihrer neuen Eintragseinstellungen wird beschleunigt. Nach der Änderung können Sie den Wert auf den vorherigen TTL-Wert zurücksetzen, um die DNS-Resolver zu entlasten.

Weitere Informationen