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 Trusted Cloudadressiert werden können.

Allgemeine Grundsätze

Informationen zu DNS-Konzepten in Trusted Cloud

Wenn Sie DNS in Trusted Cloudverwenden, müssen Sie die verschiedenen Systeme und Dienste kennen, die in Trusted 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 der 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 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 inTrusted Cloudzuzuordnen. Informationen zu Methoden für den Zugriff aufTrusted 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.

Best Practices für private Cloud DNS-Zonen

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

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

Verwenden Sie das Sicherheitsprinzip der geringsten Berechtigung, um das Recht zum Ändern von DNS-Einträgen nur solchen Nutzern 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 Rollen und Berechtigungen, 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 Trusted 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.

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

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.

Öffnen Sie Trusted Cloud Ihre lokalen Firewalls, um DNS-Traffic zuzulassen.

So achten Sie darauf, dass DNS-Traffic an keiner Stelle Ihres VPC-Netzwerk 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.

• Der Trafficfluss muss 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. Je nachdem, welche DNS-Serversoftware Sie verwenden, haben Sie jedoch unter Umständen mehrere Möglichkeiten, lokal auf die DNS-Einträge in Trusted 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 Trusted Cloudweiter. 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 Trusted Cloud eine Subdomain der lokal verwendeten Zone ist, können Sie diese Subdomain auch an denTrusted 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 inTrusted 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. Trusted 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 177.222.82.0/25 als Quelle. Daher können Antworten nur dann ordnungsgemäß weitergeleitet werden, wenn Ihre lokalen Umgebungen vollständig 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 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 Trusted 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 automatisch generierte 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

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 Trusted Cloud Ressourceneinträge und -Zonen innerhalb der Umgebung verwaltet. Alle Einträge sind für Abfragen sowohl von lokalen als auch von Trusted 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 VPC-Netzwerken von Trusted Cloudverbunden. 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 freigegebene 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 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 177.222.82.0/25 der 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 IhrerTrusted 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.

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 inTrusted Cloud -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 freigegebene 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 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 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 inTrusted Cloud -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 unter Fehlerbehebung.
• Informationen zur Vorgehensweise und Implementierung einer Hybridkonfiguration mit Trusted Cloudfinden Sie im Leitfaden für Hybrid- und Multi-Cloud-Muster und -Praktiken.
• Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.