Google PCNE: Cloud DNS, Service Discovery und hybride Namensauflösung — Lernleitfaden

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Teil des Google Professional Cloud Network Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Cloud DNS ist der skalierbare, hochverfügbare DNS-Dienst von Google Cloud, der sowohl öffentliche autoritative Zonen als auch privates DNS für VPCs unterstützt. Er bietet auch Primitive für die hybride Namensauflösung – Weiterleitung, Peering, eingehende Server, Antwortrichtlinien und DNS-Richtlinien – zur Integration mit On-Premises-DNS und Multi-Cloud. Dieser Abschnitt behandelt den Lebenszyklus von autoritativem DNS, die Sichtbarkeit und Freigabe privater Zonen, hybride Auflösung, Muster zur Service-Discovery, Sicherheit und Integrität (einschließlich DNSSEC und Zonentransfers), erweiterte Verkehrsverwaltung mit Routing-Richtlinien, DNS für private Service-Endpunkte und Day-2-Betriebsthemen wie Fehlerbehebung, Caching, Protokollierung sowie Migrations- und Koexistenzstrategien.

Autoritative DNS und der DNS-Lebenszyklus

Verwaltete Zonen und Einträge
- Eine verwaltete Zone ist ein Container für Resource Record Sets (RRsets) für einen einzelnen DNS-Namen (Zone Apex).
- Eintragstypen: A, AAAA, CNAME, MX, TXT, SRV, PTR, NS, SOA (und weitere). Cloud DNS unterstützt keinen CNAME am Zone Apex; verwenden Sie A/AAAA mit der IP eines Load Balancers für das Apex-Mapping.
- Lebenszyklus: Zone erstellen, Einträge hinzufügen/ändern (transaktionale Änderungen), propagieren und betreiben (überwachen/protokollieren/sichern).
- Import aus bestehenden BIND-Dateien zur Beschleunigung der Migration:
  - Beispiel: gcloud dns record-sets import ZONE_FILE –zone-file-format –zone MANAGED_ZONE
Öffentliche vs. private Zonen
- Öffentliche Zonen sind über die öffentlichen autoritativen Nameserver von Google weltweit zugänglich. Die Delegierung erfolgt beim Registrar durch Aktualisierung der NS-Einträge bei der übergeordneten Zone (Parent).
- Private Zonen antworten nur für angehängte VPC-Netzwerke. Sie werden von den VPC-bezogenen Resolvern von Google für Instanzen in diesen VPCs und optional für hybride Clients über eingehende Weiterleitung (Inbound Forwarding) aufgelöst.
Propagierung und TTLs
- Innerhalb von Google Cloud werden Änderungen an Einträgen in Sekunden aktiv; die Invalidierung externer Caches hängt von der TTL ab.
- TTL-Abwägungen: Kurze TTLs ermöglichen Agilität und sicherere Umstellungen, erhöhen aber die Abfragelast und können die Cache-Effizienz verringern; lange TTLs reduzieren die Last, verlängern aber die Bereitstellung veralteter Antworten. Gängige Praxis: 60–300s für dynamische Dienste; 600–3600s für stabile Einträge. Vor Umstellungen sollte die TTL 24–48 Stunden im Voraus reduziert werden.

Sichtbarkeit privater Zonen, VPC-Verknüpfung und projektübergreifendes Design

Anhängen privater Zonen an VPCs
- Eine private Zone wird explizit mit einem oder mehreren VPC-Netzwerken verknüpft. Die Verknüpfung kann projektübergreifend sein (mit entsprechenden IAM-Berechtigungen wie dns.admin für die Zone und der Berechtigung, Netzwerke zu binden).
- Priorität: Die längste Suffix-Übereinstimmung über alle an eine VPC angehängten privaten Zonen gewinnt; seien Sie vorsichtig bei überlappenden privaten Zonen (z. B. svc.corp.internal. und corp.internal.).
Muster für die VPC-übergreifende Freigabe
- Direktes Anhängen: Hängen Sie dieselbe private Zone an mehrere VPCs an. Betrieblich einfach; vermeiden Sie das Anhängen, wo es nicht benötigt wird, um den Blast Radius zu reduzieren.
- Shared VPC: Zentralisieren Sie die DNS-Verwaltung im Host-Projekt und stellen Sie DNS für Service-Projekte bereit, indem Sie das VPC der Subnetze an Zonen anhängen.
- DNS-Peering-Zonen: Wenn VPC-Peering zwischen Netzwerken verwendet wird, kann eine Peering-Zone im Consumer-VPC private Einträge aus dem Producer-VPC auflösen, ohne Zonen duplizieren zu müssen.
Fehlermodi und Schutzmaßnahmen
- Shadowing: Eine private Zone mit demselben Namen wie eine öffentliche Zone führt dazu, dass Clients in angehängten VPCs private Antworten bevorzugen, was potenziell den Zugriff auf öffentliche Endpunkte unterbricht. Verwenden Sie Split-Horizon gezielt, dokumentieren und testen Sie es.
- Übermäßiges Anhängen (Over-attachment): Das zu breite Anhängen einer privaten Zone kann interne Namen preisgeben. Befolgen Sie das Prinzip der geringsten Rechte (Least Privilege) und verwenden Sie separate Subdomains (regions-/dienstbezogen), um den Geltungsbereich einzuschränken.
- IAM-Trennung: Delegieren Sie die Rechte zur DNS-Änderung (dns.admin) getrennt von den Rechten zum Anhängen von Netzwerken (Berechtigung, Netzwerke zu binden), um getrennte Verwaltungsdomänen zu schaffen.

Kurzes Beispiel: Erstellen und Anhängen einer privaten Zone

gcloud dns managed-zones create corp-internal \
  --dns-name=corp.internal. \
  --visibility=private \
  --description="Private corp zone" \
  --networks=prod-vpc,stg-vpc

Hybride Namensauflösung: Weiterleitung, Peering und Richtlinien

Weiterleitungszonen
- Leiten Sie Abfragen für ein Suffix (z. B. onprem.corp.) autoritativ an bestimmte Nameserver (On-Premises oder in anderen Clouds) weiter. Verwenden Sie dies, wenn Sie die Zone nicht in Cloud DNS hosten, aber eine nahtlose Auflösung von GCP aus benötigen.
- Vermeiden Sie Schleifen: Stellen Sie sicher, dass On-Premises-Weiterleiter für dasselbe Suffix nicht zurück auf Cloud DNS verweisen.
Peering-Zonen
- Lösen private Zonen auf, die in einer per Peering verbundenen VPC gehostet werden. Erfordert VPC-Peering-Konnektivität; nicht transitiv. Verwenden Sie dies für Hub-and-Spoke-Designs, um privates DNS in einer Hub-VPC zu zentralisieren.
DNS-Richtlinien
- Ausgehende Weiterleitung: Instanzen in einer VPC senden rekursive Abfragen an On-Premises-Resolver für Domains, die nicht in privaten Zonen von Cloud DNS aufgelöst werden. Konfigurieren Sie dies über eine DNS-Richtlinie mit den IP-Adressen der Ziel-Nameserver, die über Cloud VPN/Interconnect erreichbar sind.
- Eingehende Server: On-Premises-Resolver leiten Abfragen an von Google bereitgestellte eingehende Weiterleitungs-IPs (automatisch zugewiesen aus 35.199.192.0/20) weiter, um private Zonen von Cloud DNS aufzulösen. Verwenden Sie dies, um privates DNS von GCP auf On-Premises und andere Clouds auszuweiten.
- Abfrageprotokollierung: Auf Richtlinienebene aktivieren, um Resolver-Abfrageprotokolle zur Analyse und Fehlerbehebung an Cloud Logging zu senden. Für öffentliche Zonen aktivieren Sie die Abfrageprotokollierung pro Zone für autoritative Abfragen.
Antwortrichtlinien
- Definieren Sie Regeln, um Antworten zu ändern (z. B. NXDOMAIN für bekannte bösartige Domains zurückgeben oder interne A-Records synthetisieren, um öffentliche Antworten zu überschreiben). Wenden Sie diese sorgfältig an; überprüfen Sie, dass kritische Domains von Drittanbietern nicht versehentlich blockiert werden.
Konnektivitätsvoraussetzungen
- Damit die ausgehende/eingehende Weiterleitung funktioniert, stellen Sie hybride Konnektivität (Cloud VPN oder Interconnect) sicher und dass Firewall-Regeln bei Bedarf UDP/TCP 53 in beide Richtungen zulassen. Das Verhalten von EDNS0 und UDP-Fragmentierung variiert je nach Netzwerk – bei MTU-Problemen sollten Sie einen TCP-Fallback zulassen und ein Tuning des EDNS(0)-Puffers auf den On-Premises-Resolvern in Betracht ziehen.
Häufige Fallstricke
- Asymmetrische Erreichbarkeit: Wenn die ausgehende Weiterleitung auf On-Premises-Resolver verweist, der Rückverkehr aber durch eine Firewall oder Routing-Asymmetrie blockiert wird, kommt es zu Zeitüberschreitungen bei den Abfragen. Überprüfen Sie die vom Cloud Router gelernten Routen und erlauben Sie die DNS-Antwortflüsse.
- Geteilte Suffixe: Überlappende Unternehmenssuffixe (corp.local vs. corp.internal) können zu unerwarteten Übereinstimmungen im Suchpfad des Resolvers führen. Standardisieren Sie Suchpfade und die Zuständigkeit für Suffixe.

Kurze Beispiele:

# Outbound forwarding policy to on-prem resolvers
gcloud dns policies create corp-outbound \
  --networks=prod-vpc \
  --forwarding-targets=10.1.0.10,10.1.0.11 \
  --enable-logging

# Forwarding zone for partner domain
gcloud dns managed-zones create partner-fwd \
  --dns-name=partner.example. \
  --visibility=private \
  --forwarding-targets=172.16.10.53,172.16.11.53 \
  --networks=prod-vpc

Service Discovery, Split-Horizon und private Endpunkte

Split-Horizon-DNS
- Liefern Sie intern und extern unterschiedliche Antworten für denselben Namen. Typisches Muster: public foo.example.com wird zu einer öffentlichen Anycast-IP aufgelöst; internal foo.example.com wird zur RFC1918-Adresse eines ILB aufgelöst. Implementieren Sie dies mit einer öffentlichen und einer privaten Zone desselben Namens und beschränken Sie den Geltungsbereich der privaten Zone sorgfältig auf die entsprechenden VPCs.
Interne Service-Benennung
- Verwenden Sie konsistente interne Suffixe (z. B. svc.corp.internal) und serviceorientierte Records (A/AAAA, SRV oder für die Discovery spezifische TXT). Halten Sie die TTLs für dynamisch skalierte Dienste niedrig.
- GKE Service Discovery: Cluster-interne Namen verbleiben innerhalb von CoreDNS (svc.cluster.local). Um sie über Namespaces/VPCs hinweg verfügbar zu machen, veröffentlichen Sie ILB-VIPs in privaten Zonen von Cloud DNS oder nutzen Sie die Service Directory-Integration.
Service Directory-Integration
- Veröffentlichen Sie Service-Endpunkte automatisch über Service Directory und Cloud DNS im DNS, wobei SRV- und A-Records pro Namespace/Service ausgegeben werden. Nützlich zur Entkopplung von Produzenten und Konsumenten und zur Unterstützung einer zustandsbewussten Erkennung von Service-Instanzen.
Private Service-Endpunkte
- Private Service Connect (PSC) zu Google APIs: Leiten Sie googleapis.com privat über PSC-Endpunkte oder verwenden Sie die Restricted Google APIs VIPs (199.36.153.8/30) mit einer privaten Zone für googleapis.com. PSC bietet regional lokale, private IP-Konnektivität mit Kontrolle pro Endpunkt; Restricted VIP ist einfacher, verwendet aber weiterhin öffentliche IP-Bereiche, die über Standardrouten erreichbar sind.
- PSC zu Producer-Diensten: Erstellen Sie A/AAAA-Records in einer privaten Zone, die auf den PSC-Endpunkt oder die ILB-VIP verweisen. Für benutzerdefinierte interne Domains verwalten Sie die private Zone in Cloud DNS und hängen sie an die Consumer-VPCs an.
Abwägungen
- PSC vs. Restricted VIP: PSC bietet granulare Kontrolle und vermeidet Pfade für die Egress-Inspektion; es erfordert ein Endpunkt-/DNS-Setup pro Region. Restricted VIP ist schnell bereitzustellen, verwendet aber gemeinsam genutzte VIPs und kann mit Egress-Routing-Richtlinien interagieren.
- Split-Horizon-Risiko: Falsch definierte Geltungsbereiche privater Zonen können den Zugriff auf öffentliche SaaS-Dienste unterbinden (Black-Holing). Validieren Sie dies vor einem breiten Rollout über Canary-VMs und Abfrageprotokollierung.

Kurzes Beispiel: internes ILB-Mapping

; Private zone: corp.internal.
web.svc.corp.internal.  60  IN  A 10.20.0.15

Sicherheit, Traffic-Management, Betrieb und Migration

DNSSEC und Integrität
- Öffentliche Zonen: Aktivieren Sie die DNSSEC-Signierung in Cloud DNS und veröffentlichen Sie den DS-Record beim Registrar, um vor Spoofing und Cache Poisoning zu schützen. Planen Sie Zeitfenster für den Key-Rollover und überwachen Sie auf Validierungsfehler.
- Private Zonen: DNSSEC-Validierung/-Signierung ist in der Regel unnötig, da die Auflösung über vertrauenswürdige Netzwerke erfolgt. Konzentrieren Sie sich auf die Transportsicherheit (hybride Verbindungen) und die Härtung des Resolvers.
Verwaltete Zonentransfers
- Cloud DNS kann als primärer oder sekundärer Server für AXFR/IXFR fungieren. Verwenden Sie TSIG zur Authentifizierung/Autorisierung von Transfers und NOTIFY für eine zeitnahe Weitergabe. Zonentransfer-Muster vereinfachen die Koexistenz während Migrationen und unterstützen lokale sekundäre Server für regulatorische oder Resilienzanforderungen.
- Fehlermodi: Transfer durch Firewalls blockiert, Nichtübereinstimmung des TSIG-Schlüssels, SOA-Seriennummer nicht inkrementiert oder IXFR auf dem primären Server deaktiviert, was zu vollständigen AXFRs führt.
Routing-Richtlinien und Health Checks
- Cloud DNS unterstützt Traffic-Steuerungsrichtlinien (gewichtsbasiert, geografisch, latenzbasiert und Failover). Fügen Sie Health Checks zu Endpunkten hinzu, um fehlerhafte Antworten automatisch zurückzuziehen.
- Design-Tipps: Halten Sie die Record-Sets pro Richtlinienziel klein; bevorzugen Sie ein regionales Scoping, das auf den User-Footprint abgestimmt ist; kombinieren Sie niedrige TTLs mit Fehlererkennungsintervallen, um die Failover-Zeit zu begrenzen.
- Fallstricke: Zu granulare Geo-Maps können die Betriebskomplexität erhöhen; ein inkonsistentes Health-Signal führt zu „Flapping“ – verwenden Sie Stabilisierungsschwellenwerte und Health-Check-Timeouts, die auf das Anwendungsverhalten abgestimmt sind.
Fehlerbehebung
- Tools: dig/nslookup mit +trace, +short und +dnssec zur Validierung von Ketten; Überprüfung von Cloud Logging auf Resolver-Abfrageprotokolle (DNS-Richtlinien) und autoritative Abfrageprotokolle (verwaltete Zonen).
- Caching: Überprüfen Sie, welchen Resolver Sie testen (die /etc/resolv.conf einer VM verweist normalerweise auf den VPC-Resolver von Google). Leeren Sie lokale Resolver-Caches, wenn Sie TTL-Änderungen testen. Berücksichtigen Sie negatives Caching (RFC 2308): NXDOMAIN-Antworten werden gemäß der SOA MINIMUM/negativen TTL zwischengespeichert.
- Häufige Probleme: Schleifen zwischen ausgehender Weiterleitung und lokalen bedingten Weiterleitern; blockiertes UDP 53 oder MTU-Probleme, die zu abgeschnittenen Antworten führen; Überschattung öffentlicher Zonen durch private Zonen.
Betriebsmuster
- Change Control: Bündeln Sie Änderungen mit Transaktionen, reduzieren Sie die TTLs vor Umstellungen und verwenden Sie eine Canary-VPC-Anbindung zur Validierung der Sichtbarkeit.
- Protokollierung und Überwachung: Aktivieren Sie die Abfrageprotokollierung selektiv; exportieren Sie Protokolle nach BigQuery für Trendanalysen und erstellen Sie Benachrichtigungen bei Spitzen von SERVFAIL/NXDOMAIN.
- Zugriffskontrolle: Trennen Sie Rollen für Record-Änderungen von Rollen für Netzwerk-Anbindungen; setzen Sie das Prinzip der geringsten Rechte (Least Privilege) für Editoren von Antwortrichtlinien durch, um unbeabsichtigte Domain-Sperren zu vermeiden.
Migration und Koexistenz
- Koexistenz: Richten Sie Cloud DNS als sekundären Server über AXFR/IXFR ein, während das lokale DNS primär bleibt; oder umgekehrt (Cloud DNS primär, lokale sekundäre Server). Verwenden Sie TSIG und Allow-Listing.
- Bedingte Weiterleitung: Erstellen Sie für Domains, die lokal bleiben, Weiterleitungszonen oder Richtlinien für die ausgehende Weiterleitung. Stellen Sie sicher, dass hybride Verbindungen hochverfügbar sind (duale VPNs mit unterschiedlichen Peers und Cloud Router).
- Verbindung mehrerer Organisationen: Verbinden Sie VPCs über Cloud VPN/Cloud Router, richten Sie je nach Bedarf gegenseitige bedingte Weiterleitung oder Peering ein und verwenden Sie Zonentransfers für Zonen, die umziehen. Senken Sie die TTLs deutlich vor Änderungen der NS- oder DS-Records beim Registrar.

Kurze Beispiele:

# Enable authoritative query logging for a public zone
gcloud dns managed-zones update prod-public --enable-logging

# Create inbound servers policy (IP allocation is automatic)
gcloud dns policies create corp-inbound --networks=prod-vpc

Praktisches Problemszenario

Contoso Retail und Fabrikam Payments sind separate Google Cloud-Organisationen, die ein Jahr lang interoperieren müssen, während sie Netzwerke und DNS mit minimaler Ausfallzeit integrieren. Jede Organisation verwendet nicht überlappenden 10.0.0.0/8-Adressraum. Contoso wird interne Dienste unter svc.contoso.internal hosten; Fabrikam wird weiterhin pay.fabrikam.internal lokal (on-prem) hosten. Beide Seiten müssen die privaten Namen der jeweils anderen auflösen und schrittweise einige Zonen zu Cloud DNS migrieren.

Vorgehensweise:

Resiliente hybride Konnektivität herstellen
- Erstellen Sie zwei Cloud VPN-Tunnel zwischen der Hub-VPC von Contoso und den lokalen Routern von Fabrikam, jeweils zu einer eigenen öffentlichen IP von Fabrikam, mit Cloud Router BGP auf beiden Tunneln.
- Begründung: Zwei Tunnel plus dynamisches Routing bieten Pfadredundanz und propagieren Routen für DNS-Ziele automatisch, was das Risiko von asymmetrischem Routing für UDP/TCP 53 reduziert.
Bedingte Namensauflösung in beide Richtungen implementieren
- Erstellen Sie bei Contoso eine Weiterleitungszone fabrikam.internal, die an die lokalen DNS-Server von Fabrikam (z. B. 172.20.10.53 und 172.20.11.53) weiterleitet, und binden Sie sie an die App-VPCs an.
- Konfigurieren Sie bei Fabrikam bedingte Weiterleiter auf dem lokalen DNS, um svc.contoso.internal an die eingehenden Weiterleitungs-IPs von Contosos Cloud DNS weiterzuleiten, die durch eine Cloud DNS-Richtlinie für eingehenden Traffic bereitgestellt werden.
- Begründung: Weiterleitungszonen vermeiden doppelte Autorität und ermöglichen es jeder Seite, ihr DNS am aktuellen Ort zu belassen. Eingehende Server erweitern die private Auflösung von Cloud DNS auf Fabrikam, ohne dessen Resolver umfassend ändern zu müssen.
Vor Weiterleitungsschleifen schützen und Sichtbarkeitsgrenzen durchsetzen
- Stellen Sie sicher, dass die bedingten Weiterleiter von Fabrikam contoso.internal nicht für Namen, die Fabrikam noch besitzt, an Contoso zurückleiten; ebenso sollte Contoso nur fabrikam.internal weiterleiten.
- Binden Sie die privaten Zonen von Contoso nur an die VPCs an, die sie benötigen; vermeiden Sie eine globale Anbindung, um den potenziellen Schaden (Blast Radius) zu reduzieren.
- Begründung: Eliminiert DNS-Rekursionsschleifen und verhindert die Überschattung öffentlicher Domains durch private Zonen.
Eine gemeinsam genutzte Zone mittels verwalteter Zonentransfers migrieren
- Konfigurieren Sie für eine gemeinsam genutzte Legacy-Zone legacy.shared.internal, die derzeit auf dem primären BIND-Server von Fabrikam gehostet wird, Cloud DNS als sekundären Server mit TSIG und fügen Sie den primären Server von Fabrikam zur Allow-List für AXFR/IXFR hinzu. Behalten Sie Fabrikam während der Koexistenzphase als primären Server bei.
- Begründung: Der sekundäre Modus ermöglicht eine Live-Synchronisation, ohne Clients ändern zu müssen. Er ermöglicht eine sichere Validierung in Contoso, während eine einzige Quelle der Wahrheit (Single Source of Truth) beibehalten wird.
Split-Horizon für extern zugängliche Dienste einführen
- Erstellen Sie eine öffentliche Zone contoso.example mit Records, die auf die IP eines globalen HTTPS Load Balancers für Kunden verweisen. Erstellen Sie eine identisch benannte private Zone, die an interne VPCs angebunden ist und dieselben Namen auf interne ILB-Adressen abbildet.
- Begründung: Externe Benutzer erreichen weiterhin die Edge Load Balancer; interne Dienste erreichen private ILBs über RFC1918, was Latenz und Kosten optimiert und gleichzeitig konsistente Hostnamen beibehält.
Privaten Zugriff auf Google APIs ohne Egress durch Firewalls ermöglichen
- Aktivieren Sie für Contoso-VMs ohne externe IPs Private Service Connect für Google APIs und erstellen Sie die verwaltete private DNS-Zone für googleapis.com, die auf PSC-Endpunkte verweist.
- Begründung: Stellt sicher, dass der Zugriff auf BigQuery und Pub/Sub privat und lokal zur VPC bleibt, wodurch Egress-Appliances von Drittanbietern vermieden und die Sicherheitslage aufrechterhalten wird.
Beobachtbarkeit und Kontrolle ermöglichen
- Aktivieren Sie die Cloud DNS-Abfrageprotokollierung in der DNS-Richtlinie von Contoso für die beteiligten VPCs und die autoritative Abfrageprotokollierung für öffentliche Zonen. Erstellen Sie Regeln für Antwortrichtlinien, um bekannte bösartige Domains organisationsweit zu blockieren.
- Begründung: Abfragetelemetrie unterstützt die Fehlerbehebung und Kapazitätsplanung; Antwortrichtlinien bieten zentrale Kontrolle für die Sicherheit, ohne jeden Resolver anfassen zu müssen.
Change Management mit sicheren TTLs durchführen
- Reduzieren Sie die TTLs für Records, die migriert werden, eine Woche vor den Änderungen auf 60s. Erhöhen Sie die TTLs nach der Validierung und Umstellung (z. B. Wechsel eines Dienstes von on-prem zu einem GCP ILB) schrittweise auf 300–600s.
- Begründung: Kurze TTLs begrenzen das Risiko während der Übergangsphasen; die Wiederherstellung höherer TTLs verbessert die Cache-Effizienz nach der Stabilisierung.
Testen, validieren und härten
- Führen Sie von Canary-VMs auf beiden Seiten dig mit +trace aus und überprüfen Sie die autoritativen Pfade, bestätigen Sie, dass es keine Spitzen von SERVFAIL/NXDOMAIN in den Protokollen gibt, und simulieren Sie Verbindungsausfälle, um das DNS-Verhalten mit VPN-Redundanz zu beobachten.
- Begründung: Proaktive Validierung erkennt Schleifen-/Sichtbarkeitsprobleme frühzeitig; Ausfallsimulationen überprüfen, ob die hybride Auflösung Transportvorfälle ohne Auswirkungen auf die Benutzer übersteht.