Best Practices für Cloud DNS

In diesem Dokument werden Best Practices für private Zonen, die DNS-Weiterleitung und Referenzarchitekturen für das Hybrid-DNS vorgestellt.

Es ist sowohl für Menschen als auch für Anwendungen einfacher, das Domain Name System (DNS) zu verwenden, um Anwendungen und Dienste zu adressieren. Die Namen lassen sich leichter merken und bieten mehr Flexibilität als IP-Adressen. In einer Hybridumgebung, die aus lokalen Plattformen und einer oder mehreren Cloud-Plattformen besteht, muss häufig umgebungsübergreifend auf DNS-Einträge für interne Ressourcen zugegriffen werden. Traditionell werden lokale DNS-Einträge manuell über einen autoritativen DNS-Server verwaltet, z. B. BIND in UNIX- oder Linux-Umgebungen oder Active Directory in Microsoft Windows-Umgebungen.

In diesem Artikel werden Best Practices für die Weiterleitung privater DNS-Anfragen zwischen Umgebungen beschrieben, damit Dienste sowohl von lokalen Umgebungen als auch innerhalb von Google Cloud adressiert werden können.

Allgemeine Grundsätze

Informationen zu DNS-Konzepten in Google Cloud

Wenn Sie DNS in Google Cloud verwenden, müssen Sie die verschiedenen Systeme und Dienste kennen, die in Google Cloud für die DNS-Auflösung und die Domainnamen verfügbar sind:

• Das interne DNS ist ein Dienst, der automatisch DNS-Namen für virtuelle Maschinen und interne Load-Balancer in Compute Engine erstellt.
• Cloud DNS ist ein Dienst, der DNS-Zonenbereitstellung mit niedriger Latenz und Hochverfügbarkeit bietet. Dieser Dienst kann als autoritativer DNS-Server für öffentliche Zonen verwendet werden, die im Internet sichtbar sind, oder für private Zonen, die nur innerhalb Ihres Netzwerks sichtbar sind.
• Managed Service for Microsoft Active Directory ist ein hochverfügbarer, gehärteter Dienst, der Microsoft Active Directory einschließlich eines Domaincontrollers ausführt.
• Das öffentliche DNS ist ein Google-Dienst, der nicht Teil von Google Cloud ist und als offener, rekursiver DNS-Resolver dient.
• Cloud Domains ist ein Domain-Registrator für den Kauf, die Übertragung und die Verwaltung von Domains in Google Cloud. Über Cloud Domains können Sie über eine API mit dem Domainregistrierungssystem interagieren.

Stakeholder, Tools und Prozesse bestimmen

Für eine DNS-Strategie in einer Hybridumgebung ist es wichtig, dass Sie sich mit Ihrer aktuellen Architektur vertraut machen und mit allen Stakeholdern Kontakt aufnehmen. Gehen Sie so vor:

• Ermitteln und kontaktieren Sie den Administrator der Unternehmens-DNS-Server Ihrer Organisation. Bitten Sie ihn um die Angaben zu den Konfigurationen, die Sie brauchen, um Ihre lokale Konfiguration einer geeigneten Architektur in Google Cloud zuzuordnen. Informationen zu Methoden für den Zugriff auf Google Cloud-DNS-Einträge finden Sie unter Bedingte Weiterleitung für den lokalen Zugriff auf DNS-Einträge verwenden.
• Machen Sie sich mit der aktuellen DNS-Software vertraut und ermitteln Sie die Domainnamen, die in Ihrer Organisation privat verwendet werden.
• Ermitteln Sie Kontaktpersonen im Netzwerkteam, die dafür sorgen können, dass Traffic korrekt an Cloud DNS-Server weitergeleitet wird.
• Machen Sie sich mit Ihrer hybriden Konnektivitätsstrategie sowie mit Hybrid- und Multi-Cloud-Mustern und -Verfahrensweisen vertraut.

Einfache und einheitliche Namenskonvention erstellen

Legen Sie eine Namenskonvention fest, die in Ihrer gesamten Organisation einheitlich und leicht zu merken ist. Angenommen, Ihre Organisation verwendet example.com als Domainnamen der zweiten Ebene sowie als Domain für öffentliche Ressourcen (z. B. www.example.com). Der Ort, an dem die öffentlichen Zonen gehostet werden, ist für dieses Dokument nicht von Bedeutung, da es hier um die Migration privater Zonen geht.

Für die lokale Benennung von Unternehmensressourcen stehen folgende Muster zur Auswahl:

• Sie können getrennte Domainnamen für lokale Server und für Google Cloud haben. Bei diesem Muster wird für Ihre verschiedenen Umgebungen eine separate Domain verwendet, z. B. corp.example.com für Ihre lokalen Server und gcp.example.com für alle Ressourcen in Google Cloud. Wenn Sie andere öffentliche Cloud-Umgebungen verwenden, können diese jeweils eine eigene Subdomain haben. Dies ist das bevorzugte Muster, da damit Anfragen zwischen verschiedenen Umgebungen problemlos weitergeleitet werden können.

  Sie können auch getrennte Domainnamen wie example.com und example.cloud verwenden.

• Sie können die Google Cloud-Domain als Subdomain der Domain haben, die lokale Server enthält. Bei Verwendung der Domain example.com kann die lokale Umgebung corp.example.com und Google Cloud gcp.corp.example.com nutzen. Dies ist ein gängiges Muster, wenn die meisten Ressourcen vor Ort verbleiben.

• Sie können die lokale Domain als Subdomain der Domain haben, die Google Cloud-Einträge enthält. Bei Verwendung der Domain example.com kann Google Cloud corp.example.com und die lokale Umgebung dc.corp.example.com nutzen. Dies ist ein eher ungewöhnliches Muster, kann aber für Digital-Organisationen sinnvoll sein, die lokal nur wenige Ressourcen haben.

• Sie können dieselbe Domain für Google Cloud und lokale Umgebungen verwenden. In diesem Fall verwenden sowohl Google Cloud als auch die lokale Umgebung Ressourcen, die die Domain corp.example.com verwenden. Vermeiden Sie dieses Muster, da es die Verwaltung von Einträgen in einer Hybridumgebung erheblich erschwert. Das Muster ist nur sinnvoll, wenn Sie ein einziges autoritatives DNS-System verwenden.

Im Folgenden werden diesen Domainnamen verwendet:

• example.com als Domainname für Ihre öffentlichen Einträge (unabhängig davon, wo sie gehostet werden).
• corp.example.com als Zone, die von Ihrem lokalen DNS-Server gehostet wird. Diese Zone hostet Einträge Ihrer lokalen Ressourcen.
• gcp.example.com als private verwaltete Cloud DNS-Zone, die Einträge für Ihre Google Cloud-Ressourcen hostet.

Abbildung 1 zeigt eine Domainnameneinrichtung, die sowohl für Ihr lokales Netzwerk als auch für Google Cloud konsistent ist.

Abbildung 1. Der Domainname wird in der gesamten Organisation einheitlich eingerichtet.

Zum Benennen von Ressourcen in Ihrem VPC-Netzwerk (Virtual Private Cloud) können Sie an Richtlinien wie im Leitfaden Best Practices und Referenzarchitekturen für das VPC-Design orientieren.

Ort der DNS-Auflösung auswählen

In einer Hybridumgebung kann die DNS-Auflösung an verschiedenen Orten ausgeführt werden. In diesem Fall können Sie folgende Aktionen ausführen:

• Sie verwenden einen hybriden Ansatz mit zwei autoritativen DNS-Systemen.
• Sie führen die DNS-Auflösung weiterhin lokal aus.
• Sie verschieben die gesamte DNS-Auflösung nach Cloud DNS.

Da wir den hybriden Ansatz empfehlen, steht dieser im Mittelpunkt dieses Dokuments. Der Vollständigkeit halber werden auch die alternativen Ansätze kurz beschrieben.

Hybriden Ansatz mit zwei autoritativen DNS-Systemen verwenden

Wir empfehlen einen Hybridansatz mit zwei autoritativen DNS-Systemen. Bei diesem Ansatz gilt Folgendes:

• Die autoritative DNS-Auflösung für Ihre private Google Cloud-Umgebung wird von Cloud DNS übernommen.
• Die autoritative DNS-Auflösung für lokale Ressourcen wird von vorhandenen DNS-Servern lokal gehostet.

Abbildung 2 zeigt diese Anordnung.

Abbildung 2. Eine hybride DNS-Architektur, die sowohl Cloud DNS als auch lokale DNS-Server verwendet, bietet eine autoritative DNS-Auflösung.

Das in Abbildung 2 dargestellte Szenario ist der bevorzugte Anwendungsfall. Die folgenden Angaben werden weiter unten auf dieser Seite behandelt:

• Weiterleitung zwischen Umgebungen mithilfe von privaten Zonen und der DNS-Weiterleitung einrichten
• Firewalls und Routing konfigurieren
• Referenzarchitekturen, die zeigen, wie eine oder mehrere VPC-Netzwerke verwendet werden

DNS-Auflösung weiterhin lokal ausführen

Ein alternativer Ansatz besteht darin, für das autoritative Hosting aller internen Domainnamen weiterhin Ihren vorhandenen lokalen DNS-Server zu verwenden. In diesem Fall können Sie einen alternativen Nameserver verwenden, um alle Anfragen von Google Cloud über die ausgehende DNS-Weiterleitung weiterzuleiten.

Dieser Ansatz bietet folgende Vorteile:

• Sie müssen weniger Änderungen an Geschäftsprozessen vornehmen.
• Sie können weiterhin Ihre vorhandenen Tools verwenden.
• Sie können Sperrlisten dazu verwenden, einzelne DNS-Anfragen lokal zu filtern.

Der Ansatz hat jedoch die folgenden Nachteile:

• DNS-Anfragen von Google Cloud haben eine höhere Latenz.
• Ihr System benötigt eine Verbindung zu lokalen Umgebungen für DNS-Vorgänge.
• Es ist möglicherweise schwierig, hochflexible Umgebungen wie automatisch skalierte Instanzgruppen einzubinden.
• Das System ist eventuell nicht mit Produkten wie Dataproc kompatibel, da für diese Produkte die umgekehrte Auflösung der Google Cloud-Instanznamen erforderlich ist.

Gesamte DNS-Auflösung nach Cloud DNS verschieben

Eine andere Möglichkeit ist die Migration zu Cloud DNS als autoritativem Dienst für die gesamte Domainauflösung. Anschließend können Sie private Zonen und die eingehende DNS-Weiterleitung verwenden, um Ihre vorhandene lokale Namensauflösung zu Cloud DNS zu migrieren.

Dieser Ansatz bietet folgende Vorteile:

• Sie müssen keinen hochverfügbaren DNS-Dienst lokal verwalten.
• Ihr System kann mit Cloud DNS zentralisiertes Logging und Monitoring nutzen.

Der Ansatz hat jedoch die folgenden Nachteile:

• Lokale DNS-Anfragen haben eine höhere Latenz.
• Ihr System benötigt zur Namensauflösung eine zuverlässige Verbindung zu Ihrem VPC-Netzwerk.

Best Practices für private Cloud DNS-Zonen

Private Zonen hosten DNS-Einträge, die nur innerhalb Ihrer Organisation sichtbar sind. Öffentliche Zonen in Cloud DNS werden in diesem Dokument nicht behandelt. Solche Zonen decken die öffentlichen Einträge der Organisation ab, z. B. DNS-Einträge für die öffentliche Website, und sind bei einer Hybridkonfiguration nicht so bedeutsam.

Mithilfe von Automatisierung private Zonen im Hostprojekt der freigegebenen VPC verwalten

Wenn Sie in Ihrer Organisation freigegebene VPC-Netzwerke verwenden, müssen Sie alle privaten Zonen in Cloud DNS innerhalb des Hostprojekts hosten. Alle Dienstprojekte können automatisch auf die Einträge in privaten Zonen zugreifen, die mit dem freigegebenen VPC-Netzwerk verbunden sind. Alternativ können Sie die Zone in einem Dienstprojekt mit projektübergreifender Bindung einrichten.

Abbildung 3 zeigt, wie private Zonen in einem freigegebenen VPC-Netzwerk gehostet werden.

Abbildung 3. Diese Konfiguration zeigt, wie private Zonen mit einer freigegebenen VPC verknüpft sind.

Wenn Sie möchten, dass Teams ihre eigenen DNS-Einträge festlegen, empfehlen wir die automatisierte Erstellung von DNS-Einträgen. Sie können z. B. eine Webanwendung oder eine interne API erstellen, mit der Nutzer ihre eigenen DNS-Einträge unter bestimmten Subdomains festlegen. Die Anwendung prüft, ob die Einträge Ihren Organisationsregeln entsprechen.

Alternativ können Sie Ihre DNS-Konfiguration in einem Code-Repository wie Cloud Source Repositories in Form von Terraform- oder Cloud Deployment Manager-Deskriptoren ablegen und Pull-Anfragen von Teams akzeptieren.

In beiden Fällen bietet ein Dienstkonto mit der IAM-Rolle DNS-Administrator im Hostprojekt die Möglichkeit, die Änderungen nach der Genehmigung automatisch bereitzustellen.

IAM-Rollen nach dem Prinzip der geringsten Berechtigung festlegen

Sicherheitsprinzip der geringsten Zielgruppe anwenden berechtigen, DNS-Einträge nur in die diese Aufgabe ausführen müssen. Vermeiden Sie die Verwendung einfacher Rollen, da diese möglicherweise Zugriff auf Ressourcen gewähren, die über die vom Nutzer benötigten Ressourcen hinausgehen. Cloud DNS bietet Rollen und Berechtigungen, mit denen Sie Lese- und Schreibzugriff gewähren können, der für DNS gilt.

Wenn die Möglichkeit zum Erstellen privater Zonen von der Möglichkeit zum Erstellen öffentlicher Zonen getrennt werden muss, verwenden Sie die Berechtigung dns.networks.bindPrivateDNSZone.

Best Practices für DNS-Weiterleitungszonen und Serverrichtlinien

Cloud DNS bietet DNS-Weiterleitungszonen und DNS-Serverrichtlinien, um DNS-Namen zwischen Ihrer lokalen Umgebung und der Google Cloud-Umgebung nachschlagen zu können. Sie haben mehrere Möglichkeiten, die DNS-Weiterleitung zu konfigurieren. Der folgende Abschnitt führt Best Practices für die Hybrid-DNS-Konfiguration auf. Diese Best Practices finden Sie unter Referenzarchitekturen für das Hybrid-DNS.

Hinweis: Die DNS-Weiterleitung kann nicht für die Weiterleitung zwischen verschiedenen Google Cloud-Umgebungen verwendet werden, unabhängig davon, auf welche Weise sie miteinander verbunden sind. Verwenden Sie für diesen Anwendungsfall DNS-Peering.

Weiterleitungszonen zum Abfragen lokaler Server verwenden

Zum Abfragen von DNS-Einträgen in Ihrer lokalen Umgebung müssen Sie eine Weiterleitungszone für die Domain einrichten, die Sie lokal für Ihre Unternehmensressourcen verwenden, z. B. corp.example.com. Dieser Ansatz wird gegenüber einer DNS-Richtlinie, die einen alternativen Nameserver aktiviert, bevorzugt. Der Zugriff auf interne DNS-Namen von Compute Engine bleibt erhalten. Öffentliche IP-Adressen werden weiterhin ohne einen zusätzlichen Hop über einen lokalen Nameserver aufgelöst.

Den Trafficfluss dieser Konfiguration finden Sie unter Referenzarchitekturen für das Hybrid-DNS.

Verwenden Sie nur dann alternative Nameserver, wenn der gesamte DNS-Traffic lokal überwacht oder gefiltert werden muss und wenn privates DNS-Logging für Ihre Anforderungen nicht ausreicht.

Hinweis: Cloud DNS wird nicht automatisch mit lokalen Nameservern synchronisiert. Lokale Nameserver müssen verfügbar sein, damit auf ausgehende weitergeleitete Abfragen geantwortet werden kann. Wie unter DNS-Weiterleitungszonen beschrieben, speichert Cloud DNS Ergebnisse von ausgehenden weitergeleiteten Abfragen bis zu 60 Sekunden lang oder während ihrer Gültigkeitsdauer (TTL). Lokale Einträge werden von Google Cloud weder synchronisiert noch im Cache gespeichert. Anfragen werden weitergeleitet, sobald sie eingehen. Daher ist es von zentraler Bedeutung, dass lokale DNS-Server verfügbar und erreichbar sind. Nur dann können lokale Domains aufgelöst werden.

Mithilfe von DNS-Serverrichtlinien lokale Abfragen zulassen

Damit lokale Hosts DNS-Einträge abfragen können, die in privaten Cloud DNS-Zonen wie gcp.example.com gehostet werden, erstellen Sie eine DNS-Serverrichtlinie mit der eingehenden DNS-Weiterleitung. Mit der eingehenden DNS-Weiterleitung kann Ihr System alle privaten Zonen im Projekt sowie interne DNS-IP-Adressen und Peering-Zonen abfragen.

Den Trafficfluss dieser Konfiguration finden Sie unter Referenzarchitekturen für das Hybrid-DNS.

Google Cloud und lokale Firewalls öffnen, um DNS-Traffic zuzulassen

So achten Sie darauf, dass DNS-Traffic an keiner Stelle Ihres VPC-Netzwerks oder Ihrer lokalen Umgebung gefiltert wird:

• Ihre lokale Firewall muss Abfragen von Cloud DNS. Cloud DNS sendet Abfragen aus dem IP-Adressbereich 35.199.192.0/19. Das DNS verwendet UDP-Port 53 oder TCP-Port 53, je nach Größe der Anfrage oder Antwort.

• Ihr DNS-Server darf keine Anfragen blockieren. Wenn Ihre lokale Der DNS-Server akzeptiert nur Anfragen von bestimmten IP-Adressen. Achten Sie darauf, dass der IP-Adressbereich 35.199.192.0/19 ist enthalten.

• Sicherstellen, dass Traffic von der lokalen Umgebung zur Weiterleitungs-IP-Adresse fließen kann Adressen. Fügen Sie in Cloud Router-Instanzen einen benutzerdefinierten Route für den IP-Adressbereich 35.199.192.0/19 in Ihrer VPC Netzwerk mit der lokalen Umgebung.

Bedingte Weiterleitung für den lokalen Zugriff auf DNS-Einträge verwenden

Mit Cloud DNS können Sie für den Zugriff auf private Einträge, die lokal auf Unternehmens-DNS-Servern gehostet werden, nur Weiterleitungszonen verwenden. Je nachdem, welche DNS-Serversoftware Sie verwenden, haben Sie jedoch unter Umständen mehrere Möglichkeiten, lokal auf die DNS-Einträge in Google Cloud zuzugreifen. In allen Fällen erfolgt der Zugriff auf die Einträge über die eingehende DNS-Weiterleitung:

• Bedingte Weiterleitung. Bei Verwendung der bedingten Weiterleitung leitet Ihr Unternehmens-DNS-Server Anfragen für bestimmte Zonen oder Subdomains an die Weiterleitungs-IP-Adressen in Google Cloud weiter. Wir empfehlen diesen Ansatz, da er am wenigsten komplex ist und Sie damit alle DNS-Anfragen auf den Unternehmens-DNS-Servern zentral kontrollieren können.

• Delegation. Wenn Ihre private Zone in Google Cloud eine Subdomain der lokal verwendeten Zone ist, können Sie diese Subdomain auch an den Google Cloud-Nameserver delegieren. Legen Sie dazu NS-Einträge in Ihrer Zone fest. Mit dieser Konfiguration können Clients direkt mit den Weiterleitungs-IP-Adressen in Google Cloud kommunizieren. Achten Sie also darauf, dass die Firewall diese Anfragen weiterleitet.

• Zonenübertragungen. Da Cloud DNS keine Zonenübertragungen unterstützt, können Sie DNS-Einträge nicht mit lokalen DNS-Servern mithilfe von Zonenübertragungen synchronisieren.

DNS-Peering verwenden, um die ausgehende Weiterleitung von mehreren VPC-Netzwerken zu vermeiden

Verwenden Sie keine ausgehende Weiterleitung von mehreren VPC-Netzwerken zu Ihren lokalen DNS-Servern, da dies zu Problemen mit dem Rücktraffic führt. Google Cloud akzeptiert Antworten von Ihren DNS-Servern nur, wenn sie an das VPC-Netzwerk weitergeleitet werden, von dem die Abfrage stammt. Abfragen von einem VPC-Netzwerk haben aber den gleichen IP-Adressbereich 35.199.192.0/19 als Quelle. Daher können Antworten nur dann ordnungsgemäß weitergeleitet werden, wenn Ihre lokalen Umgebungen vollständig getrennt sind.

Abbildung 4. Problem, das sich ergibt, wenn mehrere VPC-Netzwerke die ausgehende Weiterleitung verwenden.

Wir empfehlen, ein einzelnes VPC-Netzwerk für das Abfragen lokaler Nameserver über die ausgehende Weiterleitung festzulegen. Anschließend können zusätzliche VPC-Netzwerke die lokalen Nameserver abfragen und dafür das festgelegte VPC-Netzwerk mit einer DNS-Peering-Zone ansteuern. Ihre Abfragen werden dann an lokale Nameserver gemäß der Reihenfolge der Namensauflösung des festgelegten VPC-Netzwerks weitergeleitet. Diese Konfiguration wird unter Referenzarchitekturen für das Hybrid-DNS dargestellt.

Unterschied zwischen DNS-Peering und VPC-Netzwerk-Peering

VPC-Netzwerk-Peering ist nicht mit DNS-Peering identisch. Mit dem VPC-Netzwerk-Peering können VM-Instanzen in mehreren Projekten sich gegenseitig erreichen, die Namensauflösung wird dabei jedoch nicht geändert. Die Ressourcen in den einzelnen VPC-Netzwerken folgen weiterhin ihrer eigenen Auflösungsreihenfolge.

Im Gegensatz dazu können Sie über DNS-Peering erlauben, dass Anfragen für bestimmte Zonen an ein anderes VPC-Netzwerk weitergeleitet werden. Damit lassen sich Anfragen an verschiedene Google Cloud-Umgebungen weiterleiten, unabhängig davon, ob die VPC-Netzwerke miteinander verbunden sind.

VPC-Netzwerk-Peering und DNS-Peering werden auch unterschiedlich eingerichtet. Beim VPC-Netzwerk-Peering müssen beide VPC-Netzwerke eine Peering-Beziehung zum anderen VPC-Netzwerk einrichten. Das Peering erfolgt dann automatisch in beide Richtungen.

DNS-Peering leitet DNS-Anfragen in eine Richtung weiter und erfordert keine bidirektionale Beziehung zwischen VPC-Netzwerken. Ein VPC-Netzwerk, das als DNS-Nutzernetzwerk bezeichnet wird, sucht nach einer Cloud DNS-Peering-Zone in einem anderen VPC-Netzwerk. Dieses Netzwerk wird als DNS-Produzentennetzwerk bezeichnet. Nutzer mit der IAM-Berechtigung dns.networks.targetWithPeeringZone für das Projekt des Produzentennetzwerks können DNS-Peering zwischen Nutzer- und Produzentennetzwerken einrichten. Zum Einrichten des DNS-Peerings von einem VPC-Nutzernetzwerk aus benötigen Sie die DNS-Peer-Rolle für das Hostprojekt des VPC-Produzentennetzwerks.

Wenn Sie automatisch generierte Namen verwenden, sollten Sie DNS-Peering für interne Zonen verwenden

Wenn Sie die automatisch generierten Namen für VMs verwenden, Dienst erstellt wird, können Sie die projectname.internal mit DNS-Peering weiterleiten. mit anderen Projekten verknüpfen. Wie in Abbildung 5 gezeigt, können Sie alle .internal in einem Hub-Projekt, um sie über Ihr lokales Netzwerk zugänglich zu machen.

Abbildung 5: Mit DNS-Peering werden alle .internal-Zonen in einem Hub organisiert.

Bei Problemen der Anleitung zur Fehlerbehebung folgen

Die Anleitung zur Cloud DNS-Fehlerbehebung führt Sie durch die Behebung von häufig beim Einrichten von Cloud DNS auftretenden Fehlern.

Referenzarchitekturen für das Hybrid-DNS

Dieser Abschnitt stellt einige Referenzarchitekturen für gängige Szenarien mit privaten Cloud DNS-Zonen in einer Hybridumgebung dar. In allen Fällen werden sowohl lokale Ressourcen als auch Google Cloud-Ressourceneinträge und -Zonen innerhalb der Umgebung verwaltet. Alle Einträge sind für Abfragen sowohl von lokalen als auch von Google Cloud-Hosts verfügbar.

Verwenden Sie die Referenzarchitektur, die Ihrem VPC-Netzwerkdesign entspricht:

• Hybridarchitektur mit nur einem freigegebenen VPC-Netzwerk: Verwendet ein einzelnes VPC-Netzwerk, das mit lokalen Umgebungen verbunden ist.

• Hybridarchitektur mit mehreren separaten VPC-Netzwerken: Verbindet mehrere VPC-Netzwerke mit lokalen Umgebungen über verschiedene VPN-Tunnel oder VLAN-Anhänge und verwendet dieselbe lokale DNS-Infrastruktur.

• Hybridarchitektur mit einem Hub-VPC-Netzwerk, das mit Spoke-VPC-Netzwerken verbunden ist: Verbindet mit VPC-Netzwerk-Peering ein Hub-VPC-Netzwerk mit mehreren unabhängigen Spoke-VPC-Netzwerken.

In allen Fällen ist die lokale Umgebung über einen oder mehrere Cloud VPN-Tunnel oder Dedicated Interconnect- oder Partner Interconnect-Verbindungen mit den Google Cloud-VPC-Netzwerken verbunden. Es spielt dabei keine Rolle, welche Verbindungsmethode für jedes einzelne VPC-Netzwerk verwendet wird.

Hybridarchitektur mit nur einem freigegebenen VPC-Netzwerk

Der häufigste Anwendungsfall ist ein einzelnes freigegebenes VPC-Netzwerk, das mit der lokalen Umgebung verbunden ist, wie in Abbildung 6 dargestellt.

Abbildung 6. Eine Hybridarchitektur verwendet ein einzelnes freigegebene VPC-Netzwerk, um eine Verbindung zu einem lokalen Netzwerk herzustellen.

So richten Sie diese Architektur ein:

1. Richten Sie Ihre lokalen DNS-Server als autoritative Server für corp.example.com ein.
2. Konfigurieren Sie in Cloud DNS eine autoritative private Zone wie z. B. gcp.example.com im Hostprojekt des freigegebenen VPC-Netzwerks und richten Sie alle Einträge für Ressourcen in dieser Zone ein.
3. Legen Sie im Hostprojekt für das freigegebene VPC-Netzwerk eine DNS-Serverrichtlinie fest, um die eingehende DNS-Weiterleitung zuzulassen.
4. Geben Sie eine DNS-Weiterleitungszone an, die corp.example.com an die lokalen DNS-Server weiterleitet. Das freigegebene VPC-Netzwerk muss berechtigt sein, die Weiterleitungszone abzufragen.
5. Richten Sie die Weiterleitung zu gcp.example.com auf Ihren lokalen DNS-Servern so ein, dass sie auf eine IP-Adresse für eingehende Weiterleitungen im freigegebenen VPC-Netzwerk verweist.
6. Achten Sie dafür, dass DNS-Traffic in Ihrer lokalen Firewall zulässig ist.
7. Fügen Sie in Cloud Router-Instanzen eine benutzerdefinierte beworbene Route für den Bereich hinzu. 35.199.192.0/19 für die lokale Umgebung

Hybridarchitektur mit mehreren separaten VPC-Netzwerken

Eine weitere Option für Hybridarchitekturen ist die Verwendung mehrerer separater VPC-Netzwerke. Diese VPC-Netzwerke sind in Ihrer Google Cloud-Umgebung nicht über VPC-Netzwerk-Peering miteinander verbunden. Alle VPC-Netzwerke verwenden separate Cloud VPN-Tunnel oder VLAN-Anhänge, um eine Verbindung zu Ihren lokalen Umgebungen herzustellen.

Wie in Abbildung 7 dargestellt, ist ein typischer Anwendungsfall für diese Architektur, wenn Sie separate Produktions- und Entwicklungsumgebungen haben, die nicht miteinander kommunizieren, aber die DNS-Server gemeinsam nutzen.

Abbildung 7: Eine Hybridarchitektur kann mehrere separate VPC-Netzwerke.

So richten Sie diese Architektur ein:

1. Richten Sie Ihre lokalen DNS-Server als autoritative Server für corp.example.com ein.
2. Konfigurieren Sie in Cloud DNS eine private Zone wie z. B. prod.gcp.example.com im Hostprojekt des freigegebenen VPC-Produktionsnetzwerks und richten Sie alle Einträge für Ressourcen in dieser Zone ein.
3. Konfigurieren Sie in Cloud DNS eine private Zone wie z. B. dev.gcp.example.com im Hostprojekt des freigegebenen VPC-Entwicklungsnetzwerks und richten Sie alle Einträge für Ressourcen in dieser Zone ein.
4. Legen Sie im Hostprojekt für das freigegebene VPC-Produktionsnetzwerk eine DNS-Serverrichtlinie fest, um die eingehende DNS-Weiterleitung zuzulassen.
5. Legen Sie im freigegebenen VPC-Produktionsnetzwerk eine DNS-Zone fest, um corp.example.com an die lokalen DNS-Server weiterzuleiten.
6. Richten Sie für prod.gcp.example.com eine DNS-Peering-Zone vom freigegebenen VPC-Entwicklungsnetzwerk zum freigegebenen VPC-Produktionsnetzwerk ein.
7. Legen Sie für dev.gcp.example.com eine DNS-Peering-Zone vom freigegebenen VPC-Produktionsnetzwerk zum freigegebenen VPC-Entwicklungsnetzwerk fest.
8. Richten Sie die eingehende Weiterleitung ein, indem Sie die Auflösung von gcp.example.com. an die virtuellen IP-Adressen der eingehenden Weiterleitung von Cloud DNS auf Ihren lokalen Nameservern delegieren.
9. Achten Sie darauf, dass die Firewall DNS-Traffic sowohl lokal als auch in Google Cloud-Firewalls zulässt.
10. Fügen Sie in Cloud Router-Instanzen eine benutzerdefinierte beworbene Route für den IP-Adressbereich 35.199.192.0/19 im freigegebenen VPC-Produktionsnetzwerk der lokalen Umgebung hinzu.

Hybridarchitektur mit einem Hub-VPC-Netzwerk, das mit Spoke-VPC-Netzwerken verbunden ist

Eine weitere Möglichkeit ist Cloud Interconnect oder Cloud VPN, von der lokalen Infrastruktur zu einem Hub-VPC-Netzwerk. Wie in Abbildung 8 dargestellt, können Sie mit VPC-Netzwerk-Peering ein VPC-Netzwerk mit mehreren Spoke-VPC-Netzwerken verbinden. Jedes Spoke-VPC-Netzwerk hostet seine eigenen privaten Zonen Cloud DNS Benutzerdefinierte Routen beim VPC-Netzwerk-Peering sowie benutzerdefinierte Route Advertising auf Cloud Router, ermöglicht den vollständigen Routenaustausch und Verbindungen zwischen lokalen und allen Spoke-VPC-Netzwerken. DNS-Peering wird parallel zu VPC-Netzwerk-Peering-Verbindungen ausgeführt, um die Namensauflösung zwischen Umgebungen zu ermöglichen.

Das folgende Diagramm zeigt diese Architektur.

Abbildung 8: In einer Hybridarchitektur kann ein Hub verwendet werden VPC-Netzwerk, das mit Spoke-VPC-Netzwerken verbunden ist.

So richten Sie diese Architektur ein:

1. Richten Sie Ihre lokalen DNS-Server als autoritative Server für corp.example.com ein.
2. Konfigurieren Sie in Cloud DNS eine private Zone wie z. B. projectX.gcp.example.com für jedes Spoke-VPC-Netzwerk und richten Sie alle Einträge für Ressourcen in dieser Zone ein.
3. Legen Sie im Hub-Projekt für das freigegebene VPC-Produktionsnetzwerk eine DNS-Serverrichtlinie fest, um die eingehende DNS-Weiterleitung zuzulassen.
4. Erstellen Sie im Hub-VPC-Netzwerk eine private DNS-Zone für corp.example.com und konfigurieren Sie die ausgehende Weiterleitung zu den lokalen DNS-Servern.
5. Legen Sie für projectX.gcp.example.com eine DNS-Peering-Zone vom Hub-VPC-Netzwerk zu jedem Spoke-VPC-Netzwerk fest.
6. Legen Sie für example.com eine DNS-Peering-Zone von jedem Spoke-VPC-Netzwerk zum Hub-VPC-Netzwerk fest.
7. Richten Sie die Weiterleitung zu gcp.example.com auf Ihren lokalen DNS-Servern so ein, dass sie auf eine IP-Adresse für eingehende Weiterleitungen in dem Hub-VPC-Netzwerk verweist.
8. Achten Sie darauf, dass die Firewall DNS-Traffic sowohl lokal als auch in Google Cloud-Firewalls zulässt.
9. Fügen Sie in Cloud Router-Instanzen eine benutzerdefinierte beworbene Route für den IP-Adressbereich 35.199.192.0/19 im Hub-VPC-Netzwerk zur lokalen Umgebung hinzu.
10. (Optional) Wenn Sie auch die automatisch erstellten internen DNS-Namen verwenden, führen Sie ein Peering für jede Spoke-Projektzone wie spoke-project-x.internal mit dem Hub-Projekt aus und leiten Sie alle lokalen Abfragen für .internal weiter.

Hinweis: Wenn Sie mit dieser Architektur Cloud VPN anstelle von VPC-Netzwerk-Peering zwischen Google Cloud-Umgebungen verwenden, müssen Sie darauf achten, dass sich im Hub-Projekt ein VM- oder VPN-Tunnel in jeder Region befindet, die in den Spoke-Projekten verwendet wird. Damit ist gewährleistet, dass alle VMs Einträge über DNS-Peering abfragen können.

Mehrfachanbieter-öffentliches DNS mit Cloud DNS

Als grundlegende Komponente des Anwendungsnetzwerks ist DNS der Schlüssel um sicherzustellen, dass Ihre Anwendungen oder Dienste für Ihre Nutzer verfügbar sind. Sie können die Verfügbarkeit und Ausfallsicherheit Ihrer Anwendungen und Dienste verbessern, indem Sie mehrere DNS-Anbieter konfigurieren. Wenn mehrere DNS-Anbieter konfiguriert sind, kann Ihre Anwendung oder Ihr Dienst für Ihre Nutzer verfügbar sein, auch wenn bei einem der DNS-Anbieter eine Störung auftritt. Sie können auch die Bereitstellung und Migration von Hybridanwendungen mit Abhängigkeiten zwischen lokalen und Cloud-Umgebungen mit einer DNS-Konfiguration mit mehreren Anbietern.

Google Cloud bietet eine Open-Source-Lösung auf der Grundlage von octoDNS, mit der Sie eine Umgebung mit mehreren DNS-Anbietern einrichten und betreiben können. Das Multi-Anbieter-DNS nutzt Cloud DNS als einen Ihrer DNS-Anbieter in einer Aktiv-Aktiv-Konfiguration (empfohlen) oder Aktiv-Passiv-Konfiguration, um eine hohe der verfügbaren DNS-Architektur. Nachdem Sie die Lösung bereitgestellt haben, octoDNS eine einmalige sowie fortlaufende Synchronisierung zwischen Ihren aktuellen DNS-Zonen und verwalteten DNS-Zonen, die in Cloud DNS gehostet werden. Wenn einzelne DNS-Einträge aktualisiert werden, werden die Änderungen an die entsprechenden DNS-Zonen übertragen, die in Cloud DNS gehostet werden, ohne dass Änderungen an Ihren CI/CD-Pipelines erforderlich sind.

Wichtig: Um eine Aktiv-Aktiv-Konfiguration und Zuverlässigkeit zu erreichen, müssen Sie die NS-Einträge bei Ihrem Registrar so aktualisieren, dass sie Cloud DNS enthalten Nameservern.

• Informationen zum Konfigurieren von Cloud DNS in einer öffentlichen DNS-Konfiguration mit mehreren Anbietern finden Sie unter multi-provider-dns-with-clouddns.

Nächste Schritte

• Informationen zu Lösungen für häufige Probleme, die bei der Verwendung von Cloud DNS auftreten können finden Sie unter Fehlerbehebung.
• Informationen zur Vorgehensweise und Implementierung einer Hybridkonfiguration mit Google Cloud finden Sie im Leitfaden für Hybrid- und Multi-Cloud-Muster und -Praktiken.
• Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.