Übersicht

Auf dieser Seite erhalten Sie eine Übersicht über die Funktionen und Leistungsmerkmale von Cloud DNS. Eine Einführung in Cloud DNS finden Sie im Schnellstart.

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

Allgemeine DNS-Konzepte

Eine Liste der allgemeinen DNS-Terminologie finden Sie unter RFC 7719.

Cloud DNS bietet sowohl öffentliche 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).

Mit privaten Zonen können Sie Konfigurationen für Split-Horizon-DNS erstellen, da Sie eine private Zone mit einem anderen Satz von DNS-Einträgen erstellen können, der für Ihr VPC-Netzwerk spezifisch ist.

Cloud DNS-Konzepte

Die Cloud DNS API wurde mit Blick auf Projekte, verwaltete Zonen, Einträge und Änderungen an Einträgen konzipiert.

Projekt
Ein Projekt der Google Cloud Platform Console ist ein Container für Ressourcen und eine Domain für die Zugriffssteuerung. Dort wird auch die Abrechnung konfiguriert und zusammengefasst. Jede Cloud DNS-Ressource befindet sich also in einem Projekt und jeder Cloud DNS-Vorgang muss das jeweils verwendete Projekt angeben.
Verwaltete Zonen
Die verwaltete Zone enthält die DNS-Einträge für denselben DNS-Namenssuffix (z. B. example.com). Ein Projekt kann mehrere verwaltete Zonen enthalten, die aber jeweils einen eindeutigen Namen haben müssen. In Cloud DNS ist die verwaltete Zone die Ressource, mit der eine DNS-Zone modelliert wird. Alle Einträge in einer verwalteten Zone werden auf denselben von Google betriebenen Nameservern gehostet. Diese Nameserver beantworten in Übereinstimmung mit Ihrer Konfiguration der Zone DNS-Abfragen für Ihre verwaltete Zone. Ein Projekt kann mehrere verwaltete Zonen enthalten. Gebühren fallen für jede Zone für jeden Tag an, an dem die Zone existiert. Verwaltete Zonen unterstützen Labels, mit denen Sie Ihre Abrechnung organisieren können. Unter Zonen verwalten wird beschrieben, wie Einträge in den Zonen verwaltet werden.
Öffentliche Zonen

Eine öffentliche Zone ist im Internet sichtbar. Cloud DNS hat öffentliche autoritative Nameserver, die auf Abfragen zu öffentlichen Zonen unabhängig vom Herkunftsort der Abfragen antworten. Sie können DNS-Einträge in einer öffentlichen Zone erstellen, um Ihren Dienst im Internet zu veröffentlichen. Beispiel: In der öffentlichen Zone example.com können Sie den folgenden Eintrag für Ihre öffentliche Website www.example.com erstellen.

DNS-Name Typ TTL (Sekunden) Daten
www.example.com A 300 [public_ip_address]

Cloud DNS weist bei der Erstellung einer öffentlichen Zone eine Reihe von Nameservern zu. Damit die DNS-Einträge in einer öffentlichen Zone über das Internet aufgelöst werden können, müssen Sie bei Ihrem Registrator in der Domainregistrierung die Nameserver-Einstellung aktualisieren.

Private Zonen

Mit privaten Zonen können Sie benutzerdefinierte Domainnamen für Ihre VMs, Load-Balancer und andere GCP-Ressourcen verwalten, ohne die zugrunde liegenden DNS-Daten im öffentlichen Internet zugänglich zu machen. Eine private Zone ist ein Container mit DNS-Einträgen, der nur von einem oder mehreren von Ihnen autorisierten VPC-Netzwerken abgefragt werden kann.

Eine private Zone kann nur von Ressourcen in dem Projekt abgefragt werden, in dem sie definiert ist. Die von Ihnen autorisierten VPC-Netzwerke müssen sich in demselben Projekt wie die private Zone befinden. Sie können diese Einschränkung außer Kraft setzen, wenn Sie das DNS-Peering mit einem anderen Netzwerk einrichten.

Bei der Erstellung oder Aktualisierung der privaten Zone geben Sie die Liste der autorisierten VPC-Netzwerke an, die die private Zone abfragen können. Nur autorisierte Netzwerke dürfen Abfragen an die private Zone stellen. Wenn Sie keine autorisierten Netzwerke angeben, kann die private Zone nicht abgefragt werden.

Sie können private Zonen mit freigegebener VPC verwenden. Wichtige Informationen zur Verwendung von privaten Zonen mit freigegebenen VPC-Netzwerken finden Sie auf dieser Seite unter Private Zonen und freigegebene VPCs.

Private Zonen unterstützen keine DNS-Sicherheitserweiterungen (DNSSEC).

Anfragen zu DNS-Einträgen in privaten Zonen müssen über den Metadatenserver 169.254.169.254 gesendet werden. Dies ist der standardmäßige interne Nameserver für VMs, die aus von Google bereitgestellten Images erstellt werden. Sie können von jeder VM, die ein autorisiertes VPC-Netzwerk verwendet, Abfragen an diesen Nameserver senden.

So ist es etwa möglich, eine private Zone für dev.gcp.example.com zu erstellen, um interne DNS-Einträge für experimentelle Anwendungen zu hosten. Die folgende Tabelle zeigt Beispiele von Einträgen in dieser Zone. Datenbankclients können dabei mit ihrem internen DNS-Namen anstelle der IP-Adresse eine Verbindung zum Datenbankserver db-01.dev.gcp.example.com herstellen. Sie lösen diesen internen DNS-Namen mit dem Host-Resolver auf der VM auf, der die DNS-Abfrage an den Metadatenserver 169.254.169.254 sendet. Der Metadatenserver fungiert als rekursiver Resolver, um die private Zone abzufragen.

DNS-Name Typ TTL (Sekunden) Daten
db-01.dev.gcp.example.com A 5 10.128.1.35
instance-01.dev.gcp.example.com A 50 10.128.1.10
Weiterleitungszonen

Eine Weiterleitungszone ist eine von Cloud DNS verwaltete private Zone, die Anfragen zu dieser Zone an die IP-Adressen der Weiterleitungsziele sendet. Weitere Informationen finden Sie unter DNS-Weiterleitung.

Peering-Zonen

Eine Peering-Zone ist eine von Cloud DNS verwaltete private Zone, die der Reihenfolge der Namensauflösung eines anderen VPC-Netzwerks folgt und zum Auflösen der im anderen VPC-Netzwerk definierten Namen verwendet werden kann.

Zonenvorgänge

Alle Änderungen, die Sie in Cloud DNS an verwalteten Zonen vornehmen, werden in der Sammlung von Vorgängen aufgezeichnet, in der Aktualisierungen von verwalteten Zonen aufgelistet werden (Änderungen von Beschreibungen, DNSSEC-Status oder Konfiguration).

Registrator

Ein Domainnamenregistrator ist eine Organisation, die die Reservierung von Internet-Domainnamen verwaltet. Ein Registrator muss von einer Registry für generische Top-Level-Domains (gTLD) oder einer Registry für länderspezifische Top-Level-Domains (ccTLD) akkreditiert sein.

Internes DNS

Die GCP erstellt automatisch interne DNS-Namen für VMs, auch wenn Sie nicht Cloud DNS verwenden. Weitere Informationen zum internen DNS finden Sie in der zugehörigen Dokumentation.

Delegierte untergeordnete Zonen

Mit DNS können Inhaber einer Zone eine Subdomain mithilfe von NS-Einträgen an einen anderen Nameserver delegieren. Resolver folgen dann diesen Einträgen und senden Abfragen für die Subdomain an den in der Delegierung angegebenen Ziel-Nameserver.

Sammlung von Ressourceneinträgen

Die Sammlung von Ressourceneinträgen enthält den aktuellen Status der DNS-Einträge, aus denen eine verwaltete Zone besteht. Sie können diese Sammlung lesen, aber nicht direkt ändern. Sie können die Ressourceneinträge in einer verwalteten Zone bearbeiten, wenn Sie in der Änderungssammlung eine Change-Anfrage erstellen. All Ihre Änderungen werden in der Sammlung von Ressourceneinträgen sofort wirksam. Es kommt jedoch zu einer Verzögerung zwischen dem Zeitpunkt, zu dem Änderungen an der API vorgenommen werden, und dem Zeitpunkt, zu dem sie in Ihren autoritativen DNS-Servern wirksam werden. Unter Einträge verwalten wird erläutert, wie Sie Einträge verwalten.

Änderungen an Ressourceneinträgen

Wenn Sie eine Änderung an einer Sammlung von Ressourceneinträgen vornehmen möchten, senden Sie eine Change-Anfrage mit dem Inhalt, der hinzugefügt oder gelöscht werden soll. Das Hinzufügen und Löschen kann in Bulk-Vorgängen in einer einzigen atomaren Transaktion durchgeführt werden und die Änderungen werden auf jedem autoritativen DNS-Server gleichzeitig wirksam.

Beispiel: Sie haben einen A-Eintrag wie den folgenden:

www  A  203.0.113.1 203.0.113.2

Sie führen einen Befehl wie den folgenden aus:

DEL  www  A  203.0.113.2
ADD  www  A  203.0.113.3

Ihr Eintrag sieht nach der Bulk-Änderung dann folgendermaßen aus:

www  A  203.0.113.1 203.0.113.3

ADD und DEL werden gleichzeitig ausgeführt.

Format von SOA-Seriennummern

Die Seriennummern von SOA-Einträgen, die in von Cloud DNS verwalteten Zonen erstellt wurden, erhöhen sich monoton mit jeder transaktionalen Änderung an den Einträgen einer Zone, die mit dem Befehl gcloud dns record-sets transaction vorgenommen wurde. Sie können die Seriennummer eines SOA-Eintrags jedoch manuell in eine beliebige Zahlenfolge ändern, einschließlich eines gemäß ISO 8601 formatierten Datums, wie in RFC 1912 empfohlen. Dies wäre zum Beispiel bei folgendem SOA-Eintrag möglich:

ns-gcp-private.googledomains.com. cloud-dns-hostmaster.google.com. [serial number] 21600 3600 259200 300

Sie können die Seriennummer direkt über die Google Cloud Platform Console ändern. Dazu geben Sie den gewünschten Wert in das dritte durch Leerzeichen getrennte Feld des Eintrags ein.

DNS-Serverrichtlinie

Mit einer DNS-Serverrichtlinie können Sie auf Namensauflösungsdienste zugreifen, die von der GCP in einem VPC-Netzwerk mit eingehender Weiterleitung bereitgestellt werden. Sie können auch die Reihenfolge der VPC-Namensauflösung mit ausgehender Weiterleitung ändern.

Domains, Subdomains und Delegierung

Die meisten Subdomains sind nur Einträge in der verwalteten Zone der übergeordneten Domain. Subdomains, die durch das Erstellen von Nameserver-Einträgen in der Zone der jeweils übergeordneten Domain delegiert werden, müssen auch einer eigenen Zone zugeordnet werden. Erstellen Sie verwaltete Zonen für übergeordnete Domains in Cloud DNS, bevor Sie Zonen für ihre delegierten Subdomains einrichten. Dies gilt auch dann, wenn die übergeordnete Domain über einen anderen DNS-Dienst gehostet wird. Wenn Sie mehrere Subdomainzonen einrichten, ohne die übergeordnete Zone zu erstellen, kann ihre Erstellung kompliziert werden, wenn Sie sie später zu Cloud DNS migrieren möchten.

DNSSEC

DNSSEC (Domain Name System Security Extensions) ist eine Sammlung von DNS-Erweiterungen der Internet Engineering Task Force (IETF), mit denen Antworten auf Domainnamenabfragen authentifiziert werden. DNSSEC bietet keinen Datenschutz für diese Suchvorgänge, verhindert jedoch, dass Angreifer die Antworten auf DNS-Anfragen verfälschen oder manipulieren.

DNSKEYs-Sammlung

Die DNSKEYs-Sammlung enthält den aktuellen Status der DNSKEY-Einträge, die zum Signieren einer DNSSEC-aktivierten Zone verwendet werden. Sie können diese Sammlung nur lesen. Alle Änderungen an den DNSKEYs werden von Cloud DNS vorgenommen. Die DNSKEYs-Sammlung enthält alle Informationen, die Domainregistratoren benötigen, um DNSSEC zu aktivieren.

Reihenfolge der VPC-Namensauflösung

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

  1. Wenn für das VPC-Netzwerk eine DNS-Richtlinie konfiguriert wurde, die einen alternativen Nameserver für die ausgehende Weiterleitung angibt, leitet die GCP alle DNS-Abfragen nur an diesen Server weiter. Weitere Informationen finden Sie unter Ausgehende DNS-Weiterleitung über einen alternativen Nameserver.
  2. Die GCP fragt die folgenden GCP-Namensauflösungsdienste in der angegebenen Reihenfolge und abhängig vom längsten übereinstimmenden Suffix ab:
    • Die GCP fragt alle von Cloud DNS verwalteten privaten Weiterleitungszonen ab, die für das VPC-Netzwerk autorisiert wurden, und sendet Anfragen an die IP-Adressen der Weiterleitungsziele.
    • Die GCP fragt alle von Cloud DNS verwalteten privaten Zonen, die für das VPC-Netzwerk autorisiert wurden, nach Einträgen in diesen Zonen ab.
    • Die GCP durchsucht die automatisch erstellten Einträge des internen Compute Engine-DNS für das Projekt.
  3. Die GCP fragt öffentlich verfügbare Zonen gemäß dem entsprechend konfigurierten SOA-Eintrag ab. Dies schließt öffentliche Cloud DNS-Zonen ein.

PTR-Einträge in privaten Zonen verwenden

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

Da der Abgleich mit dem längsten Präfix wie unter Reihenfolge der VPC-Namensauflösung beschrieben erfolgt, sollten Sie zum Durchführen von Reverse-Lookups mit benutzerdefinierten PTR-Einträgen für RFC 1918-Adressen eine private Cloud DNS-Zone erstellen, die mindestens so spezifisch wie folgende Beispiele aufgebaut ist:

  • 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 VM-Instanzen in dieser Zone erstellen, von den PTR-Einträgen überschrieben, die das interne DNS von Compute Engine 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-Instanz 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, achten Sie darauf, dass 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 z. B. den folgenden PTR-Eintrag in einer privaten Zone für 10.in-addr.arpa. erstellen, überschreibt Ihr Eintrag den automatisch generierten:

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. verwendet werden, um PTR-Einträge bereitzuhalten, die alle automatisch erstellten PTR-Einträge des internen Compute Engine-DNS für VMs mit IP-Adressen im Bereich 10.5.0.0/16 überschreiben.

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

PTR-Einträge für Adressen, bei denen es sich nicht um RFC 1918-Adressen handelt, stehen nicht in Konflikt mit den automatisch erstellten PTR-Einträgen des internen DNS von Compute Engine.

Aufgrund der Reihenfolge der VPC-Namensauflösung werden private Zonen vor öffentlich verfügbaren Zonen im Internet abgefragt.

Beispiel: Im öffentlichen Internet gibt die Anfrage PTR IN 2.2.0.192.in-addr.arpa den Wert example.com zurück. Sie möchten diesen Wert jedoch für VM-Instanzen in einem oder mehreren Ihrer VPC-Netzwerke überschreiben. Sie können dies erreichen, indem Sie eine private Zone mit dem DNS-Namen in-addr.arpa erstellen und den folgenden PTR-Eintrag hinzufügen:

2.2.0.192.in-addr.arpa -> test.com

Wenn VMs in VPC-Netzwerken zur Abfrage dieser privaten Zone autorisiert sind und PTR IN 2.2.0.192.in-addr.arpa abfragen, erhalten sie die Antwort test.com anstelle von example.com.

PTR-Einträge in öffentlichen Zonen verwenden

Für Anfragen an eine öffentliche Cloud DNS-Zone zu anderen Adressen als RFC 1918 müssen Sie den Teil des Root-delegierten in-addr.arpa-Bereichs für Ihren IP-Block an die Cloud DNS-Nameserver delegieren.

Weitere allgemeine Informationen zum Konfigurieren von Reverse DNS finden Sie hier. Beachten Sie jedoch, dass die genauen Schritte zum Konfigurieren von Reverse DNS je nach Registrator variieren.

Unterstützte DNS-Eintragstypen

Cloud DNS unterstützt die folgenden Eintragstypen:

Eintragstyp Beschreibung
A

Adresseintrag für die Verknüpfung von Hostnamen mit ihrer IPv4-Adresse.

AAAA

IPv6-Adresseintrag für die Verknüpfung von Hostnamen mit ihrer IPv6-Adresse.

CAA

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

CNAME

Canonical-Name-Eintrag zur Angabe von Aliasnamen.
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 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 den Eintrag nach Bedarf anpassen. Zum Beispiel können Sie die Seriennummer in eine beliebige Zahl ändern, um eine datumsbasierte Versionsverwaltung zu unterstützen.

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-IP- und Instant-Messaging-Protokollen sowie anderen Anwendungen verwendet wird.

SSHFP

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

TLSA

TLS-Authentifizierungseintrag zur Überprü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 Abfragestrings 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.

Mit diesem Befehl können Sie DNSSEC für eine verwaltete Zone aktivieren:

gcloud dns managed-zones update my-zone --dnssec-state on

Auch bei neu erstellten Zonen kann DNSSEC aktiviert sein:

gcloud dns managed-zones create my-zone \
    --description "Signed Zone" --dns-name myzone.example --dnssec-state=on

Außerdem gibt es eine Reihe von DNSSEC-Parametern, die Sie festlegen können, wenn die Standardeinstellungen für Ihre Bereitstellung nicht geeignet sind.

DNS-Weiterleitung

Sie können die DNS-Weiterleitung zwischen Ihren externen Nameservern und den internen Nameservern der GCP einrichten. Durch die Konfiguration einer bidirektionalen Weiterleitung können Instanzen in Ihrem VPC-Netzwerk die Adressen von Hosts in lokalen oder Multi-Cloud-Netzwerken nachschlagen und Hosts in verknüpften Netzwerken können nach Adressen für Ressourcen in Ihrem VPC-Netzwerk suchen.

So unterstützt die GCP die DNS-Weiterleitung:

  • VPC-Netzwerke unterstützen sowohl die eingehende als auch die ausgehende DNS-Weiterleitung mithilfe von DNS-Serverrichtlinien. Eingehende Anfragen müssen von Systemen in Netzwerken stammen, die über einen Cloud VPN-Tunnel oder Cloud Interconnect mit der VPC verbunden sind, beispielsweise von einem lokalen Rechenzentrum.

  • Private verwaltete Cloud DNS-Zonen unterstützen die ausgehende DNS-Weiterleitung mithilfe von Weiterleitungszonen.

Im folgenden Beispiel werden zwei VPC-Netzwerke prod und dev gezeigt, für die die DNS-Weiterleitung konfiguriert ist:

DNS-Weiterleitung mit lokalen DNS-Servern (zum Vergrößern klicken)
DNS-Weiterleitung mit lokalen DNS-Servern (zum Vergrößern klicken)
  • Das Netzwerk dev ist mithilfe von dynamischem Routing über einen Cloud VPN-Tunnel mit einem lokalen Rechenzentrum in Europa verbunden.
  • Das Netzwerk prod ist mithilfe von dynamischem Routing über Cloud VPN-Tunnel mit lokalen Rechenzentren in Asien, Europa und den USA verbunden.
  • Alle Netzwerke wurden so konfiguriert, dass sie globales dynamisches Routing verwenden.
  • Alle drei Rechenzentren sind miteinander verbunden. IP-Adressen, die von den einzelnen lokalen und VPC-Netzwerken verwendet werden, sind RFC 1918-IP-Adressen und überschneiden sich nicht.
  • In jedem lokalen Rechenzentrum befinden sich lokale BIND-Server. Diese Nameserver sind redundant konfiguriert, um die Zone corp.example.com zu bedienen.
  • Sie haben DNS-Richtlinien für die Cloud VPN-Netzwerke dev und prod erstellt, um die Weiterleitung zu den lokalen Nameservern zu ermöglichen.
  • VMs in der GCP verwenden ihren Metadatenserver 169.254.169.254 zum Auflösen des GCP-internen DNS, von autorisierten privaten Cloud DNS-Zonen für die jeweiligen Netzwerke dev oder prod, von öffentlichen DNS-Zonen und von Ihrer lokalen Zone corp.example.com.

DNS-Serverrichtlinie

Eine DNS-Serverrichtlinie ermöglicht Ihnen die Konfiguration der ein- und ausgehenden DNS-Weiterleitung für ein VPC-Netzwerk. Sie können auf das jeweilige VPC-Netzwerk genau eine DNS-Serverrichtlinie anwenden.

Eine schrittweise Anleitung finden Sie unter DNS-Serverrichtlinien verwenden.

Eingehende DNS-Weiterleitung

Jedes VPC-Netzwerk stellt für die VM-Instanzen, die es verwenden, Dienste zur DNS-Namensauflösung bereit. Wenn VMs ihren Metadatenserver 169.254.169.254 als Nameserver verwenden, sucht die GCP entsprechend der Reihenfolge der VPC-Namensauflösung nach DNS-Einträgen.

Standardmäßig sind die Namensauflösungsdienste des VPC-Netzwerks außerhalb dieses Netzwerks nicht verfügbar. Sie können sie für Systeme in lokalen Netzwerken zur Verfügung stellen, die über Cloud VPN oder Cloud Interconnect verbunden sind. Dazu erstellen Sie eine DNS-Richtlinie, um die eingehende DNS-Weiterleitung zum VPC-Netzwerk zu aktivieren. Wenn sie aktiviert ist, können Systeme in den verbundenen Netzwerken eine interne IP-Adresse in Ihrem VPC-Netzwerk abfragen, um deren Namensauflösungsdienste zu nutzen.

Unter DNS-Richtlinie erstellen, die die eingehende DNS-Weiterleitung aktiviert erfahren Sie, wie Sie eine DNS-Richtlinie konfigurieren, die für Ihr VPC-Netzwerk eine eingehende Weiterleitung ermöglicht. Bei entsprechender Konfiguration weist die GCP eine interne IP-Adresse in einem Subnetz (in einer Region) Ihres VPC-Netzwerks zu. Diese dient als Proxy für eingehende DNS-Anfragen. Sie können eine Region angeben oder die GCP automatisch eine auswählen lassen. Jede DNS-Richtlinie für eingehende DNS-Weiterleitung weist genau eine Proxy-IP-Adresse für eingehende Anfragen zu. Diese IP-Adresse dient jedoch lediglich als Einstiegspunkt in die Namensauflösungsdienste des VPC-Netzwerks. Sie können dann Ihre lokalen Nameserver so konfigurieren, dass sie bei Bedarf zur Proxy-Adresse weiterleiten.

Ausgehende DNS-Weiterleitung über einen alternativen Nameserver

Sie können die Reihenfolge der VPC-Namensauflösung ändern. Dazu erstellen Sie eine DNS-Richtlinie, die eine Liste alternativer Nameserver angibt. In diesem Fall werden die alternativen Nameserver zur einzigen von der GCP abgefragten Quelle für alle DNS-Anfragen, die von VMs in der VPC über den Metadatenserver 169.254.169.254 gesendet werden.

Informationen zum Konfigurieren einer DNS-Richtlinie für die ausgehende Weiterleitung finden Sie unter DNS-Richtlinie erstellen, die einen alternativen Nameserver aktiviert. Wenn Sie alternative Nameserver mithilfe von RFC 1918-IP-Adressen angeben, müssen diese entweder interne IP-Adressen anderer GCP-VMs in Ihrem VPC-Netzwerk oder Systeme in Ihrem lokalen Netzwerk sein, die über Cloud VPN oder Cloud Interconnect mit Ihrem VPC-Netzwerk verbunden sind. Wenn Sie alternative Nameserver mithilfe von öffentlichen IP-Adressen angeben, müssen diese im Internet erreichbar sein.

DNS-Weiterleitungszonen

Neben einem alternativen Nameserver steht über die Definition einer Weiterleitungszone eine andere Art der ausgehenden DNS-Weiterleitung zur Verfügung. Diese ähnelt hinsichtlich der Einrichtung einer privaten Zone, da sie mit einem DNS-Namen verknüpft ist und an mehrere Netzwerke gebunden sein kann. Die Weiterleitungszone enthält jedoch keine Einträge. Alle übereinstimmenden Abfragen für eine Weiterleitungszone werden stattdessen an eine Reihe von DNS-Zielservern weitergeleitet. Wie beim alternativen Nameserver ist das Ziel eine Liste von IP-Adressen.

Das System versucht, den Namen über alle Ziel-Nameserver aufzulösen. Im obigen Beispiel werden übereinstimmende Abfragen an 172.16.1.28, 172.16.4.34 und 172.16.8.50 oder an eine Teilmenge davon weitergeleitet. Beachten Sie, dass das System die Auflösungsstrategie je nach der Antwortbereitschaft der Server und den aktuellen Netzwerkbedingungen ändern kann.

Wenn die Weiterleitungsbedingungen mehrerer Weiterleitungszonen sich miteinander überschneiden, hat die Zone mit der längsten Übereinstimmung für eine Abfrage Vorrang vor den anderen. Angenommen, ein DNS-Server enthält drei Weiterleitungszonen:

  • Weiterleitungszone 1: onprem.example.com, Ziel: 172.16.8.40
  • Weiterleitungszone 2: dev.onprem.example.com, Ziel: 172.16.8.50
  • Weiterleitungszone 3: prod.onprem.example.com, Ziel: 172.16.8.60

Eine Abfrage bezüglich mysvc.onprem.example.com wird gemäß Zone 1 an 172.16.8.40 weitergeleitet, eine Abfrage bezüglich mysvc.dev.onprem.example.com gemäß Zone 2 an 172.16.8.50 und eine Abfrage bezüglich mysvc.prod.onprem.example.com gemäß Zone 3 an 172.16.8.60.

Eine Anleitung finden Sie unter Weiterleitungszonen erstellen.

DNS-Peering

Mit DNS-Peering können Sie Anfragen zu Einträgen aus dem Namespace einer bestimmten Zone an ein anderes VPC-Netzwerk senden.

Zur Bereitstellung von DNS-Peering müssen Sie eine Cloud DNS-Peering-Zone 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.

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.

Sobald die Autorisierung abgeschlossen ist, können GCP-Ressourcen im DNS-Nutzernetzwerk nach Einträgen im Namespace der Peering-Zone suchen, als ob sie sich im DNS-Produzentennetzwerk befänden. Die Suche nach Einträgen im Namespace der Peering-Zone erfolgt in der Reihenfolge der Namensauflösung des DNS-Produzentennetzwerks. Auf diese Weise können GCP-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

Beachten Sie beim Konfigurieren von DNS-Peering Folgendes:

  • DNS-Peering ist eine einseitige Beziehung. Mit DNS-Peering können GCP-Ressourcen im DNS-Nutzernetzwerk nach Einträgen im Namespace der Peering-Zone suchen, als ob sich die GCP-Ressourcen im DNS-Produzentennetzwerk befänden.
  • Die DNS-Produzenten- und -Nutzernetzwerke müssen VPC-Netzwerke der GCP sein.
  • DNS-Peering und VPC-Netzwerk-Peering sind unterschiedliche Dienste. DNS-Peering kann in Verbindung mit VPC-Netzwerk-Peering verwendet werden, DNS-Peering ist für VPC-Netzwerk-Peering jedoch nicht erforderlich.

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

Anwendungsfälle

SaaS-Beispiel

Ein SaaS-Anbieter (Produzent) möchte seinen SaaS-Kunden (Nutzern) Zugriff auf einen Dienst gewähren, der in einem Peering-Netzwerk gehostet wird. Der Produzent erstellt ein Netzwerk, in dem der Dienst gehostet wird, und führt ein Peering mit dem Nutzernetzwerk durch. Der Produzent möchte auch die DNS-Namen angeben, mit denen die Nutzer auf den Dienst zugreifen.

Der Nutzer kann dem Produzenten die Nutzung eines Dienstkontos gewähren, mit dem der Produzent eine Peering-Zone im Nutzernetzwerk einrichten kann. Der Produzent gewährt diesem Dienst außerdem die Rolle dns.peer in seinem eigenen Netzwerk, sodass Anforderungen aus der Peering-Zone die Resolver-Zone erreichen können. Oder der Produzent kann den Nutzer anweisen, wie er die Einrichtung richtig vornimmt.

Einrichtung innerhalb von Organisationen

Durch Cloud DNS verwaltete Zonen können zur Verwendung mehrerer VPC-Netzwerke im gleichen Projekt autorisiert werden. Möglicherweise müssen Sie jedoch eine DNS-Zone für mehrere Projekte in Ihrer Organisation freigeben.

Mit DNS-Peering können Sie diese Anforderung erfüllen: Erstellen Sie eine einzelne verwaltete private Zone, die für ein Herstellernetzwerk autorisiert ist. Erstellen Sie dann eine ausreichende Anzahl von Peering-Zonen für den gleichen Namespace, der für jedes Nutzernetzwerk in den verschiedenen Projekten autorisiert ist. Konfigurieren Sie jede Peering-Zone so, dass sie dasselbe Produzentennetzwerk verwendet, damit die GCP-Ressourcen in den Nutzernetzwerken die Reihenfolge der Namensauflösung des Produzentennetzwerks befolgen können. Somit haben sie die Möglichkeit, Einträge im Namespace einer verwalteten privaten Zone aufzulösen, die für das Produzentennetzwerk autorisiert ist.

Weitere Informationen zu Peering-Zonen

Informationen finden Sie unter Konfigurieren von Peering-Zonen.

Private Zonen und freigegebene VPCs

Damit Sie private Zonen mit einer freigegebenen VPC verwenden können, müssen Sie Ihre private Zone im Hostprojekt erstellen und das entsprechende freigegebene VPC-Netzwerk der Liste autorisierter Netzwerke für diese Zone hinzufügen.

Sich überschneidende Zonen

Ein Projekt kann mehrere verwaltete Zonen haben. 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. Die beiden Zonen "dev.gcp.example.com" und "gcp.example.com" überschneiden sich zum Beispiel.

Sich überschneidende ö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. Falls dies nicht möglich ist, kann keine sich überschneidende Zone erstellt werden.

Überschneidungen zwischen öffentlichen und privaten Zonen sind zulässig.

Private Zonen für verschiedene VPC-Netzwerke können sich überschneiden. So können z. B. zwei VPC-Netzwerke jeweils eine Datenbank mit dem Namen database.gcp.example.com in einer Zone gcp.example.com haben. Abfragen bezüglich database.gcp.example.com erhalten entsprechend den für die jeweiligen VPC-Netzwerke definierten Zoneneinträgen unterschiedliche Antworten. Weitere Informationen finden Sie unter Split-Horizon-DNS.

Abfragen mit sich überschneidenden Zonen auflösen

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.

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 zugegriffen werden darf. Die GCP verarbeitet dann die DNS-Abfragen von VMs im VPC-Netzwerk:

  • Der Metadatenserver verwendet öffentliche Nameserver, um myapp.example.com aufzulösen, da für example.com keine private Zone vorhanden ist.
  • Der Metadatenserver löst myapp.gcp.example.com mithilfe der privaten Zone gcp.example.com auf, da gcp.example.com das längste gemeinsame Suffix für den angeforderten DNS-Eintrag und die verfügbaren 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 einem öffentlichen Nameserver ein Eintrag für myapp.gcp.example.com definiert ist.
  • Abfragen bezüglich myapp.dev.gcp.example.com werden auf ähnliche Weise entsprechend den Einträgen in der 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 existiert.
  • 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.

Split-Horizon-DNS

Sie können eine Kombination aus öffentlichen und privaten Zonen in einer Split-Horizon-DNS-Konfiguration verwenden. Bei privaten Zonen können Sie unterschiedliche Antworten auf eine Abfrage nach demselben Eintrag definieren, wenn die Abfrage von einer VM innerhalb einer autorisierten VPC stammt. Split-Horizon-DNS ist nützlich, wenn Sie separate Entwicklungs-, Unternehmens- und Produktions-VPC-Netzwerke haben:

  • Sie können eine private Zone definieren und den Zugriff von einem Entwicklungs-VPC-Netzwerk aus gestatten, sodass Abfragen von VMs in diesem Netzwerk nach DNS-Einträgen in dieser Zone an andere VMs im selben Netzwerk gerichtet werden.
  • Es lässt sich eine zweite private Zone definieren, die dieselben DNS-Einträge (Namen) mit unterschiedlichen Antworten bereitstellt und den Zugriff von einem Unternehmensnetzwerk aus erlaubt.
  • Sie können eine dritte, öffentliche Zone definieren, die dieselben DNS-Einträge mit geeigneten öffentlichen Antworten für die Produktion bereitstellt.

Angenommen, Sie haben sowohl eine öffentliche Zone als auch eine private Zone für gcp.example.com erstellt. Sie haben den Registrator für gcp.example.com für die Verwendung von Cloud DNS-Nameservern konfiguriert, sodass Ihre öffentliche Zone im Internet erreichbar ist. Außerdem haben Sie den Zugriff auf die private Zone von Ihrem VPC-Netzwerk aus gestattet.

In der privaten Zone erstellen Sie einen einzelnen Eintrag:

DNS-Name Typ TTL (Sekunden) Daten
foo.gcp.example.com A 5 10.128.1.35

In der öffentlichen Zone erstellen Sie zwei Einträge:

DNS-Name 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 Beispiele zeigen, wie Abfragen in Bezug auf DNS-Einträge aufgelöst werden:

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

Zugriffssteuerung

Allgemeine Zugriffssteuerung

Sie können die Nutzer, die Änderungen an Ihren DNS-Einträgen vornehmen dürfen, auf der Seite "IAM & Verwaltung" der Google Cloud Platform Console verwalten. Damit Nutzer Änderungen vornehmen dürfen, müssen sie im Abschnitt "Berechtigungen" der GCP Console als editor oder owner aufgelistet sein. Die Anzeige-Berechtigungsstufe "viewer" 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 ansehen.

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

Eine Einführung in Cloud DNS finden Sie im Schnellstart.

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Cloud DNS-Dokumentation