DNS-Zonen – Übersicht

Cloud DNS unterstützt verschiedene Arten vonöffentlichen und privaten Zonen. In diesem Dokument finden Sie Details zu verschiedenen Zonentypen und dazu, wann Sie die eine oder die andere verwenden können.

Weiterleitungszonen

Mit 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 in Ihrem VPC-Netzwerk oder in einem lokalen Netzwerk, das über Cloud VPN oder Cloud Interconnect mit Ihrem VPC-Netzwerk verbunden ist.

Weiterleitungsziele und Routingmethoden

Cloud DNS unterstützt drei Arten von Zielen und bietet standardmäßige oder private Routingmethoden für die Konnektivität.

Weiterleitungsziel Beschreibung Standardrouting wird unterstützt Privates Routing unterstützt Quelle der Anfragen
Typ 1 Eine interne IP-Adresse einer Google Cloud-VM oder ein interner Passthrough-Netzwerk-Load Balancer in demselben VPC-Netzwerk, das zur Verwendung der Weiterleitungszone autorisiert ist. Nur RFC 1918-IP-Adressen – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet. Jede interne IP-Adresse, z. B. eine private RFC 1918-Adresse, eine private IP-Adresse außerhalb RFC 1918 oder eine privat wiederverwendete externe IP-Adresse, mit Ausnahme einer IP-Adresse für ein verbotenes Weiterleitungsziel – 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. Nur RFC 1918-IP-Adressen – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet. Jede interne IP-Adresse, z. B. eine private RFC 1918-Adresse, eine private IP-Adresse außerhalb RFC 1918 oder eine privat wiederverwendete externe IP-Adresse, mit Ausnahme einer IP-Adresse für ein verbotenes Weiterleitungsziel – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet. 35.199.192.0/19
Typ 3 Eine externe IP-Adresse eines DNS-Nameservers, auf die über das Internet zugegriffen werden kann oder die externe IP-Adresse einer Google Cloud-Ressource, z. B. die externe IP-Adresse einer VM in einem anderen VPC-Netzwerk. Nur externe, routingfähige IP-Adressen: Der Traffic wird immer an das Internet oder an die externe IP-Adresse einer Google Cloud-Ressource weitergeleitet. Privates Routing wird nicht unterstützt. Achten Sie darauf, dass kein privates Routing ausgewählt ist. Google Public DNS-Quellbereiche

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 oder nicht. 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.

Verbotene Ziel-IP-Adressen für die Weiterleitung

Die folgenden IP-Adressen können nicht für Cloud DNS-Weiterleitungsziele verwendet werden:

  • 169.254.0.0/16
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 224.0.0.0/4
  • 240.0.0.0/4
  • ::1/128
  • ::/128
  • 2001:db8::/32
  • fe80::/10
  • fec0::/10
  • ff00::/8

Reihenfolge für Weiterleitungsziel auswählen

Mit Cloud DNS können Sie eine Liste von Weiterleitungszielen für eine Weiterleitungszone konfigurieren.

Wenn Sie zwei oder mehr Weiterleitungsziele konfigurieren, verwendet Cloud DNS einen internen Algorithmus, um ein Weiterleitungsziel auszuwählen. Dieser Algorithmus sortiert jedes Weiterleitungsziel.

Zur Verarbeitung einer Anfrage versucht Cloud DNS zuerst eine DNS-Abfrage, indem das Weiterleitungsziel mit dem höchsten Rang kontaktiert wird. Wenn dieser Server nicht antwortet, wiederholt Cloud DNS die Anfrage an das nächsthöhere Rang der Weiterleitung. Wenn keine Weiterleitungsziele eine Antwort zurückgeben, synthetisiert Cloud DNS die Antwort SERVFAIL.

Der Algorithmus für die Rangfolge ist automatisch und die folgenden Faktoren erhöhen das Ranking eines Weiterleitungsziels:

  • Je höher die Anzahl der erfolgreichen DNS-Antworten ist, die vom Weiterleitungsziel verarbeitet wurden. Erfolgreiche DNS-Antworten enthalten NXDOMAIN-Antworten.
  • Die geringere Latenz (Umlaufzeit) für die Kommunikation mit dem Weiterleitungsziel.

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 oder in verschiedenen Projekten autorisieren, sofern sich die VPC-Netzwerke in derselben Organisation befinden.

  • 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 zuvor beschrieben konfiguriert sind, lösen einen Eintrag gemäß der Reihenfolge der 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 kein transitives Routing für die Verbindung mit einem Weiterleitungsziel verwenden. Das folgende Szenario veranschaulicht eine ungültige Konfiguration:

  • Sie haben Cloud VPN oder Cloud Interconnect verwendet, um ein lokales Netzwerk mit einem VPC-Netzwerk namens vpc-net-a zu verbinden.

  • Sie haben VPC-Netzwerk-Peering über VPC-Netzwerk vpc-net-a 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. Damit eine Weiterleitungszone verwendet werden kann, muss eine VM für die Verwendung ihres Metadatenservers konfiguriert sein.

  • Fragen Sie das Weiterleitungsziel direkt nach diesem Eintrag ab. Obwohl Cloud DNS diesen Pfad nicht verwendet, geht die Abfrage davon aus, dass transitive Verbindung erfolgreich ist.

Sie können dieses ungültige Szenario mit einer Peering-Zone für Cloud DNS beheben:

  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.

Informationen zum Erstellen von Weiterleitungszonen finden Sie unter Weiterleitungszone erstellen.

Peering-Zonen

Eine Peering-Zone ist eine private Cloud DNS-Zone, mit der Sie DNS-Anfragen zwischen Cloud DNS-Zonen in verschiedenen VPC-Netzwerken senden können. Beispielsweise kann ein SaaS-Anbieter (Software as a Service) Kunden Zugriff auf seine verwalteten DNS-Einträge in Cloud DNS gewähren.

Zum Bereitstellen von DNS-Peering müssen Sie eine private 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 durchführt, wird als DNS-Produzentennetzwerk bezeichnet.

Die Peering-Zone ist nur für VPC-Netzwerke sichtbar, die während der Zonenkonfiguration ausgewählt werden. Das VPC-Netzwerk, das zur Verwendung der Peering-Zone berechtigt ist, wird als DNS-Nutzernetzwerk bezeichnet.

Wenn Google Cloud-Ressourcen im DNS-Nutzernetzwerk autorisiert wurden, können sie nach Einträgen im Namespace der Peering-Zone suchen, 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.

Daher 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 Server-Richtlinie konfiguriert wurde.

Mit DNS-Peering können Sie ein Netzwerk (DNS-Nutzernetzwerk) DNS-Anfragen an ein anderes Netzwerk (DNS-Produzentennetzwerk) weiterleiten lassen, das dann DNS-Suchanfragen durchführt.

DNS-Peering-Einschränkungen und wichtige Punkte

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.
  • Während DNS-Produzenten- und -Nutzernetzwerke normalerweise Teil derselben Organisation sind, wird organisationsübergreifendes DNS-Peering unterstützt.
  • DNS-Peering und VPC-Netzwerk-Peering sind unterschiedliche Dienste. Beim VPC-Netzwerk-Peering werden DNS-Informationen nicht automatisch freigegeben. DNS-Peering kann für 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. Sie können beispielsweise eine Peering-Zone in vpc-net-a erstellen, die auf vpc-net-b ausgerichtet ist, und dann eine Peering-Zone in vpc-net-b erstellen, die auf vpc-net-c ausgerichtet ist.
  • Wenn Sie DNS-Peering für eine Weiterleitungszone verwenden, muss das Ziel-VPC-Netzwerk mit der Weiterleitungszone eine VM, einen VLAN-Anhang oder einen Cloud VPN-Tunnel enthalten, der sich in derselben Region befindet wie das Quell-VM, die die DNS-Peering-Zone verwendet. Weitere Informationen zu dieser Einschränkung finden Sie unter Abfragen von VMs in einem Nutzer-VPC-Netzwerk an ein Produzenten-VPC-Netzwerk weiterleiten, das nicht funktioniert.

Eine Anleitung zum Erstellen einer Peering-Zone finden Sie unter Peering-Zone erstellen.

Verwaltete Zonen für den umgekehrten Lookup

Eine verwaltete Zone für den umgekehrten Lookup ist eine private Zone mit einem speziellen Attribut, das Cloud DNS anweist, eine PTR-Suche anhand der Compute Engine-DNS-Daten auszuführen.

PTR-Einträge für RFC 1918-Adressen in privaten Zonen

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 Namensauflösung beschrieben.

Beispielzonen:

  • 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.

Beim Erstellen einer privaten Cloud DNS-Zone für RFC 1918-Adressen werden benutzerdefinierte PTR-Einträge, die Sie für VMs in dieser Zone erstellen, von den PTR-Einträgen überschrieben, die das interne DNS automatisch erstellt. Das liegt daran, dass PTR-Einträge des internen 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 DNS-Zone 10.in-addr.arpa. beantwortet. Der PTR-Eintrag in Ihrer privaten Cloud DNS-Zone für test.example.domain wird ignoriert.

Zum Überschreiben der automatisch erstellten internen DNS-PTR-Einträge für VMs müssen Sie Ihre benutzerdefinierten PTR-Einträge in einer privaten Zone erstellen, die mindestens so spezifisch ist wie eine der in diesem Abschnitt dargestellten Zonen. 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

Wenn Sie nur einen Teil eines Netzwerkblocks überschreiben müssen, können Sie spezifischere private Cloud DNS-Reverse-Zonen erstellen. So können Sie z. B. eine private Zone für 5.10.in-addr.arpa. verwenden, um dort PTR-Einträge bereitzuhalten, mit denen alle internen DNS-PTR-Einträge überschrieben werden, die automatisch für VMs mit IP-Adressen im Adressbereich 10.5.0.0/16 erstellt werden.

Eine Anleitung zum Erstellen einer verwalteten Zone für den umgekehrten Lookup finden Sie unter Verwaltete Zone für den umgekehrten Lookup erstellen.

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. Beispiel:

  • 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.

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 verwendet den längsten Suffixabgleich, um festzustellen, 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 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 verwendet öffentliche Nameserver, um einen Datensatz für myapp.example.com. aufzulösen (beachten Sie den abschließenden Punkt), da es keine private Zone für example.com gibt, die für das VPC-Netzwerk autorisiert wurde. Verwenden Sie dig von einer Compute Engine-VM, um den Standard-Nameserver der VM abzufragen:

    dig myapp.example.com.

    Weitere Informationen finden Sie unter DNS-Name über den Metadatenserver abfragen.

  • 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, wie in der folgenden Tabelle dargestellt.

Datensatz Typ TTL (Sekunden) Daten
myrecord1.gcp.example.com A 5 10.128.1.35

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

Datensatz Typ TTL (Sekunden) Daten
myrecord1.gcp.example.com A 5 104.198.6.142
myrecord2.gcp.example.com A 50 104.198.7.145

Die folgenden Abfragen werden wie beschrieben aufgelöst:

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

Projektübergreifende Bindung

Mit einer projektübergreifenden Bindung können Sie die Inhaberschaft des DNS-Namespace des Dienstprojekts unabhängig von der Inhaberschaft des DNS-Namespace des gesamten VPC-Netzwerks beibehalten.

Eine typische Einrichtung für ein freigegebenes VPC besteht aus Service-Projekten, die eine Anwendung oder einen Service einer virtuellen Maschine (VM) übernehmen, während das Host-Projekt für das VPC-Netzwerk und die Netzwerkinfrastruktur zuständig ist. Häufig wird ein DNS-Namespace aus dem Namespace des VPC-Netzwerks erstellt, um den Ressourcen des Dienstprojekts zu entsprechen. Bei einer solchen Einrichtung kann es einfacher sein, die Verwaltung des DNS-Namespace jedes Serviceprojekts an die Administratoren der einzelnen Serviceprojekte zu delegieren (bei denen es sich häufig um verschiedene Abteilungen oder Unternehmen handelt). Mit der projektübergreifenden Bindung können Sie die Inhaberschaft des DNS-Namespace des Serviceprojekts vom Besitz des DNS-Namespace des gesamten VPC-Netzwerks trennen.

Die folgende Abbildung zeigt eine typische Einrichtung einer freigegebenen VPC mit DNS-Peering.

Eine freigegebene VPC-Einrichtung mit DNS-Peering.
Freigegebene VPC mit DNS-Peering (zum Vergrößern klicken)

Die folgende Abbildung zeigt eine Einrichtung mit projektübergreifender Bindung. Mit Cloud DNS kann jedes Dienstprojekt seine DNS-Zonen erstellen und Inhaber sein. Gleichzeitig ist es jedoch an das freigegebene Netzwerk gebunden, das dem Hostprojekt gehört. Dies ermöglicht eine bessere Autonomie und eine präzisere Berechtigungsgrenze für die DNS-Zonenverwaltung.

Eine Einrichtung mit projektübergreifender Bindung.
Eine Einrichtung mit projektübergreifender Bindung (zum Vergrößern klicken)

Eine projektübergreifende Bindung bietet Folgendes:

  • Dienstprojektadministratoren und Nutzer können ihre eigenen DNS-Zonen erstellen und verwalten.
  • Sie müssen kein Platzhalter-VPC-Netzwerk erstellen.
  • Hostprojektadministratoren müssen das Dienstprojekt nicht verwalten.
  • IAM-Rollen gelten weiterhin auf Projektebene.
  • Alle DNS-Zonen sind direkt dem freigegebenen VPC-Netzwerk zugeordnet.
  • Es ist jede beliebige DNS-Auflösung verfügbar. Jede VM im freigegebenen VPC-Netzwerk kann die zugehörigen Zonen auflösen.
  • Es gibt kein transitives Hop-Limit. Sie können es in einem Hub- und Spoke-Design verwalten.

Eine Anleitung zum Erstellen einer Zone mit aktivierter projektübergreifender Bindung finden Sie unter Projektübergreifende Bindungszone erstellen.

Zonale Cloud DNS-Zonen

Mit zonalem Cloud DNS können Sie private DNS-Zonen erstellen, die nur einer Google Cloud-Zone zugeordnet sind. Zonale Cloud DNS-Zonen werden für GKE erstellt, wenn Sie einen Clusterbereich auswählen.

Der Cloud DNS-Standarddienst ist global und DNS-Namen sind global in Ihrem VPC-Netzwerk sichtbar. Bei dieser Konfiguration ist Ihr Dienst globalen Ausfällen ausgesetzt. Zonales Cloud DNS ist ein neuer privater Cloud DNS-Dienst, der in jeder Google Cloud-Zone vorhanden ist. Die Fehlerdomain ist in dieser Google Cloud-Zone enthalten. Private zonale Cloud DNS-Zonen sind bei globalen Ausfällen nicht betroffen. Alle zonalen Ausfälle der Google Cloud wirken sich nur auf diese bestimmte Google Cloud-Zone und Cloud DNS-Zonen innerhalb dieser Google Cloud-Zone aus. Beachten Sie, dass alle in einem zonalen Dienst erstellten Ressourcen nur für diese Google Cloud-Zone sichtbar sind.

Informationen zum Konfigurieren einer zonalen Cloud DNS-Clusterzone finden Sie unter Zonale Zone für GKE-Cluster konfigurieren.

Unterstützung für zonale Cloud DNS

In der folgenden Tabelle sind die Cloud DNS-Ressourcen und -Funktionen aufgeführt, die von zonalen Cloud DNS-Diensten unterstützt werden.

Ressource oder Feature Verfügbar in globalem Cloud DNS Verfügbar in zonalem Cloud DNS
Verwaltete öffentliche Zonen
Verwaltete private Zonen (Netzwerk- oder VPC-bezogen)
Verwaltete private Zonen (GKE-bezogen)
Weiterleitungszonen1
Peering-Zonen
Verwaltete Zonen für den umgekehrten Lookup
Änderungen erstellen oder Einträge verwalten2
Service Directory-Zonen
Richtlinien
Antwortrichtlinien (netzwerkbezogen)
Antwortrichtlinien (auf GKE-Cluster beschränkt)
Antwortrichtlinienregeln

1Zonales Cloud DNS unterstützt nur Weiterleitungszonen, die einem GKE-Cluster zugeordnet sind.

2Der GKE-Controller überschreibt alle Änderungen an den Einträgen beim Neustart.

Abrechnung für zonale Cloud DNS-Zonen

Die Abrechnung für zonale Cloud DNS-Zonen und -Antwortrichtlinien funktioniert genauso wie bei ihren globalen Gegenstücken.

Nächste Schritte