Cloud DNS – Übersicht

Diese Seite bietet eine Übersicht über die Features und Leistungsmerkmale von Cloud DNS. Cloud DNS ist ein stabiler globaler DNS-Hochleistungsdienst (Domain Name System), der Ihre Domainnamen kostengünstig im globalen DNS veröffentlicht.

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 haben Sie die Möglichkeit, Ihre Zonen und Einträge im DNS zu 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 Virtual Private Cloud-Netzwerken (VPC).

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.

Eine Einführung in Cloud DNS finden Sie in der Kurzanleitung.

Jetzt testen

Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit von Cloud DNS in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

Cloud DNS kostenlos testen

Überlegungen zu freigegebenen VPC-Netzwerken

Zur Verwendung einer von Cloud DNS verwalteten privaten Zone, einer Cloud DNS-Weiterleitungszone oder einer Cloud DNS-Peering-Zone mit freigegebener VPC müssen Sie die Zone im Hostprojekt erstellen. Fügen Sie dann der Liste der autorisierten Netzwerke für diese Zone ein oder mehrere freigegebene VPC-Netzwerke hinzu.

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

DNS-Weiterleitungsmethoden

Google Cloud bietet eingehende und ausgehende DNS-Weiterleitung für private Zonen. Sie können die DNS-Weiterleitung konfigurieren, indem Sie eine Weiterleitungszone oder eine Cloud DNS-Serverrichtlinie erstellen. Die beiden Methoden werden in der folgenden Tabelle zusammengefasst:

DNS-Weiterleitung Cloud DNS-Methoden
Eingehend

Erstellen Sie eine Richtlinie für eingehenden Server, damit 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.

Lokale Clients können Datensätze in privaten Zonen, Weiterleitungszonen und Peering-Zonen auflösen, für die das VPC-Netzwerk autorisiert wurde. Lokale Clients verwenden Cloud VPN oder Cloud Interconnect, um eine Verbindung zum VPC-Netzwerk herzustellen.

Ausgehend

Sie können VMs in einem VPC-Netzwerk so konfigurieren:

  • Senden Sie DNS-Anfragen an DNS-Nameserver Ihrer Wahl. Die Nameserver können sich im selben VPC-Netzwerk, in einem lokalen Netzwerk oder im Internet befinden.
  • 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. Informationen dazu, wie Google Cloud Traffic an die IP-Adresse eines Weiterleitungsziels weiterleitet, finden Sie unter Weiterleitungsziele und Routingmethoden.
  • Erstellen Sie eine Richtlinie für ausgehenden Server für das VPC-Netzwerk, um alle DNS-Anfragen an einen alternativen Nameserver zu senden. 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 Namensauflösung.

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 verwendet einen Algorithmus, um die Reaktionsfähigkeit eines Weiterleitungsziels zu bestimmen. Ihre weitergeleiteten ausgehenden Abfragen können manchmal zu SERVFAIL-Fehlern führen. Informationen darüber, wie Sie dieses Problem umgehen können, finden Sie unter Ausgehend weitergeleitete Anfragen erhalten SERVFAIL-Fehler.

Informationen zum Anwenden von Serverrichtlinien finden Sie unter DNS-Serverrichtlinien erstellen. Informationen zum Erstellen einer Weiterleitungszone finden Sie unter Weiterleitungszone erstellen.

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.

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 CNAME-Einträge, die in einer privaten Zone definiert sind, die nicht funktioniert.

DNSKEY

Der DNSSEC-Schlüssel von einem anderen Operator für die sichere Übertragung. Dieser Eintragstyp kann einer Zone, für die DNSSEC aktiviert ist, nur im Übertragungsstatus hinzugefügt werden.

DS

Fingerabdruck für DNSSEC-Schlüssel für eine sichere delegierte Zone. Bei diesem Datensatztyp wird DNSSEC für eine delegierte Zone nur dann aktiviert, wenn Sie DNSSEC für diese Zone freischalten und aktivieren.

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 (VoIP), 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 willkürlichen Text enthalten und außerdem für die Definition von maschinenlesbaren Daten verwendet werden kann, wie zum Beispiel 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.

Informationen zum Arbeiten mit DNS-Einträgen finden Sie unter Einträge verwalten.

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

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 Typen von Zielen und bietet standardmäßige oder private Methoden für das Routing von Traffic an diese Ziele.

Weiterleitungsziel Beschreibung Standardrouting wird unterstützt Privates Routing unterstützt Quelle der Anfragen
Typ 1 Eine interne IP-Adresse einer Google Cloud-VM 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, einschließlich privater IP-Adressen außerhalb RFC 1918 und privat wiederverwendete öffentliche IP-Adressen – 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, einschließlich privater IP-Adressen außerhalb RFC 1918 und privat wiederverwendete öffentliche IP-Adressen – 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.

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

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

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

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. 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
foo.gcp.example.com A 5 10.128.1.35

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

Datensatz 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 DNS-Weiterleitung, die ausgehende DNS-Weiterleitung oder beides angeben. In diesem Abschnitt bezieht sich Richtlinie für Eingangsserver auf eine Richtlinie, die die eingehende DNS-Weiterleitung zulässt. Die Richtlinie für ausgehende Server bezieht sich 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 Cloud DNS-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 in Ihrem VPC-Netzwerk eine eingehende Serverrichtlinie erstellen, um diese Namensauflösungsdienste für ein lokales Netzwerk zur Verfügung zu stellen, das über Cloud VPN oder Cloud Interconnect verbunden ist.

Wenn Sie eine Richtlinie für eingehenden Server erstellen, verwendet Cloud DNS eine interne IP-Adresse aus dem primären IP-Adressbereich jedes Subnetzes, das Ihr VPC-Netzwerk verwendet. Wenn Sie zum Beispiel ein VPC-Netzwerk haben, das zwei Subnetze in derselben Region und ein drittes Subnetz in einer anderen Region enthält, sind insgesamt drei IP-Adressen für die eingehende Weiterleitung reserviert. Cloud DNS verwendet diese internen IP-Adressen als Einstiegspunkt für eingehende DNS-Anfragen.

Einstiegspunkte für Richtlinien für eingehende Server

Die regionalen internen IP-Adressen, die von Cloud DNS für die Server-Richtlinie für eingehenden Traffic verwendet werden, dienen als Einstiegspunkte in die Namensauflösungsdienste des VPC-Netzwerks. Um die eingehende Server-Richtlinie zu verwenden, 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 befinden wie der Cloud VPN-Tunnel oder VLAN-Anhang, die Ihr lokales Netzwerk mit Ihrem VPC-Netzwerk verbinden.

Informationen zum Erstellen von Richtlinien für eingehende Server finden Sie unter Richtlinie für eingehende Server erstellen.

Serverrichtlinie für ausgehenden Traffic

Sie können die Reihenfolge der VPC-Namensauflösung ändern. Dazu erstellen Sie eine Richtlinie für ausgehenden Server, die eine Liste alternativer Nameserver 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 Richtlinien für ausgehende Server finden Sie unter Richtlinien für ausgehende Server erstellen.

Alternative Nameserver und Routingmethoden

Cloud DNS unterstützt drei 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 wird unterstützt Privates Routing unterstützt Quelle der Anfragen
Typ 1 Eine interne IP-Adresse einer Google Cloud-VM in demselben VPC-Netzwerk, in dem die Serverrichtlinie für ausgehenden Traffic definiert ist. Nur RFC 1918-IP-Adressen – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet. Jede interne IP-Adresse, einschließlich privater IP-Adressen außerhalb RFC 1918 und privat wiederverwendete öffentliche IP-Adressen – 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 Nur RFC 1918-IP-Adressen – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet. Jede interne IP-Adresse, einschließlich privater IP-Adressen außerhalb RFC 1918 und privat wiederverwendete öffentliche IP-Adressen – 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 Google Public DNS-Quellbereiche

Sie können eine der folgenden Routingmethoden auswählen, wenn Sie den alternativen Nameserver einer Richtlinie für ausgehende Server angeben:

  • Standardrouting: Leitet Traffic über ein autorisiertes VPC-Netzwerk oder das Internet weiter, je nachdem, ob der alternative Nameserver eine RFC-1918-Adresse ist. 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.

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 vornehmen dürfen, muss die Bearbeiterrolle (roles/editor) oder Inhaberrolle (roles/owner) im Abschnitt „Berechtigungen“ der Cloud Console vorhanden sein. Die Betrachterrolle (roles/viewer) gewährt Lesezugriff 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“ (roles/dns.admin oder roles/dns.reader) 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 für Ihre verwalteten Zonen an verschiedenen Standorten weltweit eine hohe Verfügbarkeit zu bieten. 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 Wert für die Gültigkeitsdauer (Time to Live, TTL), den Sie für Ihre Einträge festlegen (in Sekunden festgelegt), bestimmt den Cache des DNS-Resolvers. 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 kürzeren Wert zu ändern. 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.

Nächste Schritte

  • Eine Einführung in Cloud DNS finden Sie im Schnellstart.
  • Weitere Informationen zum Registrieren und Einrichten Ihrer Domain finden Sie in der Anleitung Domain mit Cloud DNS einrichten.
  • Weitere Informationen zu API-Clientbibliotheken finden Sie unter Beispiele und Bibliotheken.
  • Informationen zu Lösungen für häufige Probleme, die bei der Verwendung von Cloud DNS auftreten können finden Sie unter Fehlerbehebung.