Wichtige Begriffe

Diese Seite enthält wichtige Begriffe für Cloud DNS. Schauen Sie sich diese Begriffe an, um mehr über die Funktionsweise von Cloud DNS und die grundlegenden Konzepte zu erfahren.

Die Cloud DNS API wurde mit Blick auf Projekte, verwaltete Zonen, Datensätze und Änderungen an Datensätzen konzipiert.

Projekt

Ein Projekt in der Google Cloud Console ist ein Container für Ressourcen und eine Domain für die Zugriffssteuerung. Für ein Projekt wird dort auch die Abrechnung konfiguriert und zusammengefasst. Weitere Informationen finden Sie unter Projekte erstellen und verwalten.

Verwaltete Zone

Die verwaltete Zone enthält DNS-Einträge (Domain Name System) für das gleiche Suffix des DNS-Namens (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 die Tage an, an denen die Zone vorhanden ist. Verwaltete Zonen unterstützen Labels, mit denen Sie Ihre Abrechnung organisieren können.

Öffentliche Zone

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. Zum Veröffentlichen Ihres Dienstes im Internet können Sie DNS-Einträge in einer öffentlichen Zone erstellen. In der öffentlichen Zone example.com können Sie beispielsweise den folgenden Eintrag für Ihre öffentliche Website www.example.com anlegen:

DNS-Name	Typ	TTL (Sekunden)	Daten
www.example.com	A	300	198.51.100.0

Cloud DNS weist beim Erstellen 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.

Hinweis: Öffentliche Cloud DNS-Zonen sind autoritativ. NS-Ressourceneinträge (Nameserver) und SOA-Ressourceneinträge befinden sich an der Zonenspitze. Diese Eintragstypen können Sie nicht löschen. Weitere Informationen finden Sie unter RFC 1034.

Weitere Informationen zum Registrieren und Einrichten Ihrer Domain finden Sie unter Domain mithilfe von Cloud DNS einrichten.

Private Zone

Mit privaten Zonen können Sie benutzerdefinierte Domainnamen für Ihre VM-Instanzen, Load-Balancer und andere Google Cloud-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 (Virtual Private Cloud) abgefragt werden kann.

Sie müssen die Liste der autorisierten VPC-Netzwerke, die Ihre private Zone abfragen können, beim Erstellen oder Aktualisieren der Zone angeben. Es dürfen nur autorisierte Netzwerke Abfragen an die private Zone stellen. Ohne Angabe autorisierter Netzwerke kann die private Zone nicht abgefragt werden.

Sie können private Zonen mit einer freigegebenen VPC verwenden. Wichtige Informationen zur Verwendung privater Zonen mit einer freigegebenen VPC finden Sie unter Überlegungen zu freigegebenen VPC-Netzwerken.

Private Zonen unterstützen keine DNS-Sicherheitserweiterungen (DNSSEC) und keine benutzerdefinierten Ressourcendatensätze vom Typ NS. Anfragen für DNS-Einträge 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 unten aufgeführte Tabelle enthält Beispiele für Einträge 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. Die Clients 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 dient als rekursiver Resolver zum Abfragen der privaten Zonen.

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

Private Zonen ermöglichen Ihnen, Split-Horizon-DNS-Konfigurationen zu erstellen. Dies liegt daran, dass Sie eine private Zone mit einem anderen Datensatz erstellen können. Dadurch wird der gesamte Datensatz in einer öffentlichen Zone überschrieben. Sie können dann steuern, welche VPC-Netzwerke die Einträge in der privaten Zone abfragen. Ein Beispiel finden Sie unter Sich überschneidende Zonen.

Service Directory

Service Directory ist eine verwaltete Dienst-Registry für Google Cloud, mit der Sie zusätzlich zu herkömmlichem DNS mit HTTP oder gRPC (mit der Lookup API) Dienste registrieren und entdecken können. Sie können Service Directory verwenden, um sowohl Google Cloud-Dienste als auch Dienste von Drittanbietern zu registrieren.

Mit Cloud DNS können Sie von Service Directory unterstützte Zonen erstellen. Diese sind eine Art private Zone mit Informationen zu Ihren Diensten und Endpunkten. Sie fügen der Zone keine Datensätze hinzu. Sie werden stattdessen automatisch anhand der Konfiguration des mit der Zone verknüpften Service Directory-Namespace abgeleitet. Weitere Informationen zu Service Directory finden Sie in der Übersicht zu Service Directory.

Wenn Sie eine dienstverzeichnisgestützte Zone erstellen, können Sie Einträge nicht direkt der Zone hinzufügen. Die Daten stammen aus der Service Directory-Dienst-Registry.

Cloud DNS und Reverse Lookup für Adressen außerhalb RFC 1918

Standardmäßig leitet Cloud DNS Anfragen für PTR-Einträge von Adressen außerhalb des RFC 1918-Bereichs über das öffentliche Internet weiter. Cloud DNS unterstützt jedoch die umgekehrte Suche nach Adressen außerhalb RFC 1918 unter Verwendung privater Zonen.

Nachdem Sie ein VPC-Netzwerk für die Verwendung von Adressen außerhalb von RFC 1918 konfiguriert haben, müssen Sie eine private Cloud DNS-Zone als verwaltete Zone für den umgekehrten Lookup konfigurieren. Mit dieser Konfiguration kann Cloud DNS Adressen außerhalb von RFC 1918 lokal auflösen, anstatt sie über das Internet zu senden.

Wenn Sie eine verwaltete Reverse Lookup-DNS-Zone erstellen, können Sie der Zone keine Datensätze direkt hinzufügen. Die Daten stammen von den Compute-Engine-IP-Adressdaten.

Cloud DNS unterstützt außerdem die ausgehende Weiterleitung an Adressen außerhalb von RFC 1918, indem diese Adressen privat in Google Cloud weitergeleitet werden. Wenn Sie diese Art von ausgehender Weiterleitung aktivieren möchten, müssen Sie eine Weiterleitungszone mit bestimmten Argumenten für den Weiterleitungspfad konfigurieren. Weitere Informationen finden Sie unter Weiterleitungsziele und Routingmethoden.

Weiterleitungszone

Eine Weiterleitungszone ist eine von Cloud DNS verwaltete private Zone, die Anfragen für diese Zone an die IP-Adressen der Weiterleitungsziele weiterleitet. Weitere Informationen finden Sie unter DNS-Weiterleitungsmethoden.

Wenn Sie eine Weiterleitungszone erstellen, können Sie der Weiterleitungszone keine Einträge direkt hinzufügen. die Daten von einem oder mehreren konfigurierten Ziel-Nameservern oder Resolvern stammen.

Peering-Zone

Eine Peering-Zone ist eine von Cloud DNS verwaltete private Zone, die der Reihenfolge der Namensauflösung eines anderen VPC-Netzwerks folgt. Sie können damit die Namen auflösen, die im anderen VPC-Netzwerk definiert sind.

Wenn Sie eine DNS-Peering-Zone erstellen, können Sie der Zone keine Datensätze direkt hinzufügen. Die Daten stammen aus dem Produzenten-VPC-Netzwerk gemäß der Reihenfolge der Namensauflösung.

Antwortrichtlinie

Eine Antwortrichtlinie ist ein Konzept der privaten Cloud DNS-Zone, das Regeln anstelle von Datensätzen enthält. Mit diesen Regeln lassen sich ähnliche Effekte erzielen wie mit dem RPZ-Entwurfskonzept (Response Policy Zone) (IETF). Mit der Antwortrichtlinie können Sie benutzerdefinierte Regeln in DNS-Servern innerhalb Ihres Netzwerks einführen, die der DNS-Resolver während der Suche prüft. Wenn eine Regel in der Antwortrichtlinie die eingehende Abfrage beeinflusst, wird sie verarbeitet. Andernfalls wird die Suche normal fortgesetzt. Weitere Informationen finden Sie unter Antwortrichtlinien und Regeln verwalten.

Eine Antwortrichtlinie unterscheidet sich von einer RPZ. Dabei handelt es sich um eine ansonsten normale DNS-Zone mit speziell formatierten Daten, die dafür sorgen, dass kompatible Resolver für spezielle Aktionen zuständig sind. Antwortrichtlinien sind keine DNS-Zonen und werden in der API separat verwaltet.

Zonenvorgänge

Alle Änderungen, die Sie an verwalteten Zonen in Cloud DNS vornehmen, werden in der Sammlung von Vorgängen aufgezeichnet. Hier sind die Aktualisierungen für verwaltete Zonen aufgeführt, zu denen Änderungen von Beschreibungen, DNSSEC-Status oder Konfigurationen gehören. Änderungen an Datensätzen innerhalb einer Zone werden in Ressourcendatensätzen separat gespeichert, wie nachfolgend in diesem Dokument beschrieben.

Internationalisierter Domainname (IDN)

Ein internationalisierter Domainname (IDN) ist ein Internetdomainname, mit dem Nutzer auf der ganzen Welt ein sprachspezifisches Skript oder Alphabet verwenden können. Beispiel: arabische, chinesische, kyrillische, Devanagari-, hebräische oder lateinische Schriftzeichen in Domainnamen. Diese Konversion wird mithilfe von Punycode umgesetzt, einer Darstellung von Unicode-Zeichen mit ASCII. Eine IDN-Darstellung von .ελ ist z. B. .xn--qxam. Einige Browser, E-Mail-Clients und Anwendungen erkennen sie möglicherweise und rendern sie in Ihrem Namen als .ελ. Der IDNA-Standard (Internationalizing Domain Names in Applications) erlaubt nur Unicode-Strings, die so kurz sind, dass sie als gültiges DNS-Label dargestellt werden. Informationen zur Verwendung von IDN mit Cloud DNS finden Sie unter Zonen mit internationalisierten Domainnamen erstellen.

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

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

Delegierte Subzonen

Mit DNS kann der Inhaber einer Zone eine Subdomain mithilfe von NS-Einträgen (Nameserver) 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.

Hinweis: In privaten Zonen wird das Delegieren von Subdomains an verschiedene Nameserver mithilfe von NS-Einträgen nicht unterstützt.

Ressourcendatensätze

Ein Ressourcendatensatz ist eine Sammlung von DNS-Einträgen mit demselben Label, derselben Klasse und demselben Typ, aber mit unterschiedlichen Daten. Ressourcendatensätze enthalten den aktuellen Status der DNS-Einträge, aus denen eine verwaltete Zone besteht. Sie können einen Ressourcendatensatz lesen, aber nicht direkt ändern. Allerdings können Sie die Ressourcendatensätze einer verwalteten Zone bearbeiten, wenn Sie eine Change-Anfrage in der Änderungssammlung erstellen. Sie können die Ressourcendatensätze auch mit der API ResourceRecordSets bearbeiten. Der Ressourcendatensatz enthält alle Ihre Änderungen sofort. 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. Weitere Informationen zum Verwalten von Datensätzen finden Sie unter Einträge hinzufügen, ändern und löschen.

Hinweis: In Übereinstimmung mit der DNS-Branche folgen die Cloud DNS-Nameserver dann in zufälliger Reihenfolge der Reihenfolge der Ressourcendatensätze, wenn mehrere Datensätze in einem Datensatz vorhanden sind. Das ist das übliche DNS-Verhalten, das für öffentliche und auch für private Cloud DNS-Zonen gilt. Caching-Resolver im Pfad können weiterhin Datensätze als ursprünglich im Cache gespeicherte Daten zurückgeben und die Reihenfolge für nachfolgende Antworten nicht neu anordnen.

Änderung des Ressourcendatensatzes

Um eine Änderung an einem Ressourcendatensatz vorzunehmen, senden Sie eine Change- oder ResourceRecordSets-Anfrage, die Hinzufügungen oder Löschungen enthält. Das Hinzufügen und Löschen kann in Bulk-Vorgängen oder in einer einzigen atomaren Transaktion ausgeführt werden. Die Änderungen werden auf jedem autoritativen DNS-Server sofort wirksam.

Angenommen, es ist ein A-Eintrag wie der folgende vorhanden:

www  A  203.0.113.1 203.0.113.2

Sie führen dazu 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 so 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 Datensätzen einer Zone, die mit dem Befehl gcloud dns record-sets transaction vorgenommen wurde. Allerdings können Sie die Seriennummer eines SOA-Eintrags manuell in eine beliebige Zahlenfolge ändern, einschließlich eines Datums im Format ISO 8601, wie in RFC 1912 empfohlen.

Im folgenden SOA-Eintrag können Sie die Seriennummer z. B. direkt in der Google Cloud Console ändern. Dafür geben Sie den gewünschten Wert in das dritte durch Leerzeichen getrennte Feld des Eintrags ein:

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

DNS-Serverrichtlinie

Mit einer DNS-Serverrichtlinie können Sie auf Namensauflösungsdienste zugreifen, die von der Google Cloud in einem VPC-Netzwerk mit eingehender Weiterleitung bereitgestellt werden oder die Reihenfolge der VPC-Namensauflösung mit einer Richtlinie zu ausgehenden Servern ersetzen. Weitere Informationen finden Sie unter DNS-Serverrichtlinien.

Domain, Subdomain 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 öffentliche Zonen für übergeordnete Domains in Cloud DNS, bevor Sie öffentliche 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 deren Erstellung kompliziert werden, wenn Sie sie später zu Cloud DNS migrieren möchten. Weitere Informationen finden Sie unter Nameserver-Limits.

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.