DNS-Zonen – Übersicht

Cloud DNS unterstützt verschiedene Arten vonöffentlichen und privaten Zonen. Dieses Dokument enthält Details zu verschiedenen Zonentypen und dazu, wann Sie einen der Zonentypen 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 ein voll qualifizierter Domainname (FQDN) oder die 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 vier Arten von Zielen und bietet standardmäßige oder private Routingmethoden für die Verbindung.

Weiterleitungsziel Beschreibung Standardrouting wird unterstützt Privates Routing unterstützt Quelle der Anfragen
Typ 1 Eine interne IP-Adresse einer Google Cloud VM oder eines internen Passthrough-Network Load Balancers im selben 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 von RFC 1918 oder eine privat wiederverwendete externe IP-Adresse, mit Ausnahme einer verbotenen Ziel-IP-Adresse für die Weiterleitung. 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 von RFC 1918 oder eine privat wiederverwendete externe IP-Adresse, mit Ausnahme einer verbotenen Ziel-IP-Adresse für die Weiterleitung. 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
Typ 4 Ein voll qualifizierter Domainname eines Ziel-Nameservers, der gemäß der Reihenfolge der VPC-Netzwerkauflösung in IPv4- oder IPv6-Adressen aufgelöst wird. Abhängig vom Netzwerk des aufgelösten Weiterleitungsziels wird Traffic auf zwei Arten weitergeleitet:
  • RFC 1918-IP-Adressen: Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet.
  • Über das Internet routbare externe IP-Adressen: Traffic wird immer an das Internet oder die externe IP-Adresse einer Google Cloud -Ressource weitergeleitet.

Abhängig vom Netzwerk des aufgelösten Weiterleitungsziels wird der Traffic über eine beliebige interne IP-Adresse weitergeleitet, z. B. eine private RFC 1918-Adresse, eine private IP-Adresse außerhalb von RFC 1918 oder eine privat wiederverwendete externe IP-Adresse, mit Ausnahme einer verbotenen Ziel-IP-Adresse für die Weiterleitung. Traffic wird immer über ein autorisiertes VPC-Netzwerk geleitet.

Wenn der DNS-Nameserver in eine externe IP-Adresse aufgelöst wurde, die über das Internet oder die externe IP-Adresse zugänglich ist, wird privates Routing nicht unterstützt.

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 als Ziel vom Typ 1 oder Typ 2 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 2 unterstützt.

Wenn Sie einen FQDN für Ihr Weiterleitungsziel verwenden, muss die Routingmethode Ihrem Netzwerktyp entsprechen. Wenn Ihr Domain-Nameserver in eine öffentliche IP-Adresse aufgelöst wird, müssen Sie Standardrouting verwenden.

Für den Zugriff auf ein Weiterleitungsziel 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 Weiterleitungsziel:

Weitere Informationen zu den Netzwerkanforderungen für Ziele vom Typ 1 und Typ 2 finden Sie unter Anforderungen an Weiterleitungsziele für Netzwerke.

Für den Zugriff auf ein Weiterleitungsziel vom Typ 4 löst Cloud DNS zuerst den Domainnamen auf und verwendet dann die Routingmethode des Quellnetzwerks. Wenn subdomain.example.com beispielsweise in die IP-Adresse eines lokalen Systems aufgelöst wird, das mit dem VPC-Netzwerk verbunden ist, das zum Abfragen der Weiterleitungszone über Cloud VPN autorisiert ist, verwendet es dieselben Routingregeln wie ein Weiterleitungsziel vom Typ 2.

Wenn Sie einen FQDN als Weiterleitungsziel verwenden, können Sie nur einen verwenden. Das Weiterleitungsziel kann in bis zu 50 IP-Adressen aufgelöst werden.

Unzulässige Weiterleitungsziel-IP-Adressen

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

  • 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. Mit diesem Algorithmus wird jedes Weiterleitungsziel in eine bestimmte Reihenfolge gebracht.

Wenn Sie einen FQDN als Weiterleitungsziel verwenden, löst Cloud DNS den Domainnamen in eine Gruppe von bis zu 50 IP-Adressen auf und wendet dann denselben Algorithmus auf diese IP-Adressen an.

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 projektübergreifend autorisieren, um die Weiterleitungszone zu verwenden. Voraussetzung ist, dass sich die VPC-Netzwerke innerhalb derselben Organisation befinden.

  • Das Gastbetriebssystem jeder VM im VPC-Netzwerk verwendet den Metadatenserver 169.254.169.254 der VM als Nameserver.

Wenn Sie einen FQDN als Ziel-Nameserver verwenden, prüfen Sie Folgendes:

  • Sie können nur ein Weiterleitungsziel angeben.
  • Die FQDN-Zielauflösung über eine andere Weiterleitungszone wird nicht unterstützt.
  • Sie können einen FQDN nicht als alternativen Nameserver in Serverrichtlinien verwenden.
  • Ein FQDN-Ziel kann bis zu 50 verknüpfte IP-Adressen auflösen. Alle aufgelösten Adressen über 50 werden abgeschnitten.

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 ihre verwalteten DNS-Einträge in Cloud DNS gewähren.

Für DNS-Peering müssen Sie eine private Peering-Zone von Cloud DNS erstellen und für die Durchfü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.

Nachdem die Google Cloud -Ressourcen im DNS-Nutzernetzwerk autorisiert wurden, können sie so nach Einträgen im Namespace der Peering-Zone suchen, als befänden sie sich im DNS-Produzentennetzwerk. 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 dafür sorgen, dass ein Netzwerk (DNS-Nutzernetzwerk) DNS-Anfragen an ein anderes Netzwerk (DNS-Produzentennetzwerk) weiterleitet, das dann DNS-Lookups durchführt.

DNS-Peering-Einschränkungen und wichtige Punkte

Beachten Sie beim Konfigurieren von DNS-Peering Folgendes:

  • DNS-Peering ist eine einseitige Beziehung. Damit können Google Cloud Ressourcen im DNS-Nutzernetzwerk so nach Einträgen im Namespace der Peering-Zone suchen, als ob sich die Google Cloud Ressourcen im DNS-Produzentennetzwerk befinden würden.
  • 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 geteilt. 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

In diesem Beispiel wird der PTR-Eintrag in Ihrer privaten Cloud DNS-Zone für in-addr.arpa. ignoriert. Alle PTR-Abfragen für 1.1.1.10.in-addr.arpa. werden von der spezifischeren internen DNS-Zone 10.in-addr.arpa. beantwortet.

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 Reverse-Lookup-Zone finden Sie unter Verwaltete Reverse-Lookup-Zone 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: * Überlappende öffentliche Zonen sind auf denselben Cloud DNS-Nameservern nicht zulässig. Wenn Sie sich überschneidende Zonen erstellen, versucht Cloud DNS, sie auf verschiedenen Nameservern abzulegen. Wenn 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 in einer Serverrichtlinie für ausgehenden Traffic keinen alternativen Nameserver angegeben haben, versucht Google Cloud zuerst, einen Eintrag in einer privaten Zone (oder Weiterleitungszone oder Peering-Zone) zu finden, die für Ihr VPC-Netzwerk autorisiert ist, bevor Sie den Eintrag in einer öffentlichen Zone suchen. Die folgenden Beispiele veranschaulichen die Reihenfolge, die der Metadatenserver beim Abfragen von DNS-Einträgen verwendet. Angenommen, Sie haben für jedes dieser Beispiele zwei private Zonen, gcp.example.com und dev.gcp.example.com, erstellt, auf die vom selben VPC-Netzwerk aus autorisierter Zugriff gewährt wird. Google Cloudverarbeitet die DNS-Abfragen von VMs in einem VPC-Netzwerk so:

  • 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äß den Einträgen in der privaten Zone gcp.example.com aufgelöst, da gcp.example.com das längste gemeinsame Suffix zwischen dem angeforderten DNS-Eintrag und den 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 auf eine Google Cloud -Zone beschränkt 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. Durch diese Konfiguration wird 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. Ein Google Cloud zonaler Ausfall betrifft nur diese Google Cloud Zone und die Cloud DNS-Zonen innerhalb dieser Google Cloud Zone. Jede in einem zonalen Dienst erstellte Ressource ist nur für diese Zone Google Cloudsichtbar.

Informationen zum Konfigurieren einer zonalen, clusterbezogenen Cloud DNS-Zone finden Sie unter Zonale GKE-Clusterzone konfigurieren.

Unterstützung für zonale Cloud DNS

In der folgenden Tabelle sind die Cloud DNS-Ressourcen und -Features 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