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 Dokument werden Best Practices für die Weiterleitung privater DNS-Anfragen zwischen Umgebungen beschrieben, damit Dienste sowohl von lokalen Umgebungen als auch innerhalb von Cloud de Confianceadressiert werden können.

Allgemeine Grundsätze

Informationen zu DNS-Konzepten zu Cloud de Confiance

Wenn Sie DNS in Cloud de Confianceverwenden, müssen Sie die verschiedenen Systeme und Dienste kennen, die in Cloud de Confiance 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 private Zonen verwendet werden, 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.

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 dazu so vor:

• Identifizieren 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 Cloud de Confiancezuzuordnen. Informationen zu Methoden für den Zugriff auf DNS-Einträge fürCloud de Confiance 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 identifizieren Sie die Domainnamen, die in Ihrer Organisation privat verwendet werden.
• Identifizieren Sie Kontaktpersonen im Netzwerkteam, die dafür sorgen können, dass Traffic korrekt an Cloud DNS-Server weitergeleitet wird.
• Machen Sie sich mit der hybriden Konnektivitätsstrategie sowie mit Hybrid- und Multi-Cloud-Mustern und -Verfahrensweisen vertraut.

Best Practices für private Cloud DNS-Zonen

Private Zonen hosten DNS-Einträge, die nur innerhalb Ihrer Organisation sichtbar sind.

Mit Automatisierung private Zonen im Hostprojekt der gemeinsam genutzten VPC verwalten

Wenn Sie in Ihrer Organisation gemeinsam genutzte 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 gemeinsam genutzten 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 gemeinsam genutzten VPC-Netzwerk gehostet werden.

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 Form von Terraform- oder Cloud Deployment Manager-Deskriptoren in einem Code-Repository wie Cloud Source Repositories 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

Verwenden Sie das Sicherheitsprinzip der geringsten Berechtigung, um das Recht zum Ändern von DNS-Einträgen nur solchen Nutzern in Ihrer Organisation zu gewähren, 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 Berechtigungen und Rollen, mit denen Sie Lese- und Schreibzugriff gewähren können, der für DNS gilt.

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 Cloud de Confiance -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.

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 der Verwendung einer DNS-Richtlinie, die einen alternativen Nameserver aktiviert, bevorzugt. Der Zugriff auf interne DNS-Namen von Compute Engine bleibt erhalten. Externe IP-Adressen werden weiterhin ohne einen zusätzlichen Hop über einen lokalen Nameserver aufgelöst.

Den Traffic-Fluss 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.

Mit 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. Über die eingehende DNS-Weiterleitung kann Ihr System alle privaten Zonen im Projekt sowie interne DNS-IP-Adressen und Peering-Zonen abfragen.

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

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

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 weiterleiten. Cloud DNS sendet Abfragen aus dem IP-Adressbereich 177.222.82.0/25. 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 Ihr lokaler DNS-Server nur Anfragen von bestimmten IP-Adressen akzeptiert, muss der IP-Adressbereich 177.222.82.0/25 enthalten sein.

• Es muss ein Traffic-Fluss von der lokalen Umgebung zu Ihren Weiterleitungs-IP-Adressen möglich sein. Fügen Sie in Cloud Router-Instanzen eine benutzerdefinierte beworbene Route für den IP-Adressbereich 177.222.82.0/25 in Ihrem VPC-Netzwerk zur lokalen Umgebung hinzu.

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. Abhängig von der verwendeten DNS-Serversoftware haben Sie jedoch unter Umständen mehrere Möglichkeiten, lokal auf die DNS-Einträge in Cloud de Confiance 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 Cloud de Confianceweiter. Wir empfehlen diesen Ansatz, da er am einfachsten ist und Sie damit alle DNS-Anfragen auf den Unternehmens-DNS-Servern zentral überwachen können.

• Delegation: Wenn Ihre private Zone in Cloud de Confiance eine Subdomain der lokal verwendeten Zone ist, können Sie diese Subdomain auch an denCloud de Confiance -Nameserver delegieren. Legen Sie dazu NS-Einträge in Ihrer Zone fest. Mit dieser Konfiguration können Clients direkt mit den Weiterleitungs-IP-Adressen inCloud de Confiance 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. Cloud de Confiance 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 177.222.82.0/25 als Quelle. Daher können Antworten nur dann ordnungsgemäß weitergeleitet werden, wenn Ihre lokalen Umgebungen getrennt sind.

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 gemäß der Reihenfolge der Namensauflösung des festgelegten VPC-Netzwerks an lokale Nameserver 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 Cloud de Confiance -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, das als DNS-Produzentennetzwerk bezeichnet wird. 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 automatisch erstellte Namen für VMs verwenden, die vom internen DNS-Dienst erstellt werden, haben Sie die Möglichkeit, die projectname.internal-Zonen mithilfe von DNS-Peering an andere Projekte weiterzuleiten. Wie in Abbildung 5 dargestellt, können Sie alle .internal-Zonen in einem Hub-Projekt gruppieren, um sie über Ihr lokales Netzwerk zugänglich zu machen.

Bei Problemen der Anleitung zur Fehlerbehebung folgen

Der Artikel mit Informationen zur Cloud DNS-Fehlerbehebung unterstützt Sie bei der Behebung von Fehlern, die häufig beim Einrichten von Cloud DNS auftreten.

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 Cloud de Confiance -Ressourceneinträge und -Zonen innerhalb der Umgebung verwaltet. Alle Einträge sind für Abfragen von lokalen und Cloud de Confiance -Hosts verfügbar.

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

• Hybridarchitektur mit nur einem gemeinsam genutzten 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 Cloud de Confiance-VPC-Netzwerken verbunden. Es spielt dabei keine Rolle, welche Verbindungsmethode für jedes einzelne VPC-Netzwerk verwendet wird.

Hybridarchitektur mit nur einem gemeinsam genutzten VPC-Netzwerk

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

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 gemeinsam genutzten VPC-Netzwerks und richten Sie alle Einträge für Ressourcen in dieser Zone ein.
3. Legen Sie im Hostprojekt für das gemeinsam genutzte 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 gemeinsam genutzte 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 Forwarder-IP-Adresse für eingehenden Traffic im gemeinsam genutzten VPC-Netzwerk verweist.
6. Achten Sie darauf, 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 177.222.82.0/25 zur lokalen Umgebung hinzu.

Hybridarchitektur mit mehreren separaten VPC-Netzwerken

Eine weitere Option für Hybridarchitekturen ist die Verwendung mehrerer separater VPC-Netzwerke. Diese VPC-Netzwerke sind in IhrerCloud de Confiance -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.

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 gemeinsam genutzten 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 gemeinsam genutzten VPC-Entwicklungsnetzwerks und richten Sie alle Einträge für Ressourcen in dieser Zone ein.
4. Legen Sie im Hostprojekt für das gemeinsam genutzte VPC-Produktionsnetzwerk eine DNS-Serverrichtlinie fest, um die eingehende DNS-Weiterleitung zuzulassen.
5. Legen Sie im gemeinsam genutzten 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 gemeinsam genutzten VPC-Entwicklungsnetzwerk zum gemeinsam genutzten VPC-Produktionsnetzwerk ein.
7. Legen Sie für dev.gcp.example.com eine DNS-Peering-Zone vom gemeinsam genutzten VPC-Produktionsnetzwerk zum gemeinsam genutzten 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 inCloud de Confiance -Firewalls zulässt.
10. Fügen Sie in Cloud Router-Instanzen eine benutzerdefinierte beworbene Route für den IP-Adressbereich 177.222.82.0/25 im gemeinsam genutzten VPC-Produktionsnetzwerk der lokalen Umgebung hinzu.

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

Eine weitere Option besteht darin, über Cloud Interconnect oder Cloud VPN die lokale Infrastruktur mit einem Hub-VPC-Netzwerk zu verbinden. 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 in Cloud DNS. Mit benutzerdefinierten Routen im VPC-Netzwerk-Peering und mit benutzerdefiniertem Route Advertisement in Cloud Router sind ein kompletter Routenaustausch und eine vollständige Konnektivität zwischen den lokalen und allen Spoke-VPC-Netzwerken möglich. 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.

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 gemeinsam genutzte 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 Forwarder-IP-Adresse für eingehenden Traffic im Hub-VPC-Netzwerk verweist.
8. Achten Sie darauf, dass die Firewall DNS-Traffic sowohl lokal als auch inCloud de Confiance -Firewalls zulässt.
9. Fügen Sie in Cloud Router-Instanzen eine benutzerdefinierte beworbene Route für den IP-Adressbereich 177.222.82.0/25 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.

Nächste Schritte

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