Google PCNE: Cloud DNS, Service Discovery en Hybride Naamresolutie — Studiegids

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

Onderdeel van de Google Professional Cloud Network Engineer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Cloud DNS is de schaalbare, hoog beschikbare DNS-dienst van Google Cloud die zowel publieke ‘authoritative’ zones als private DNS voor VPC’s ondersteunt. Het biedt ook primitieven voor hybride naamresolutie—forwarding, peering, inbound servers, response policies en DNS policies—om te integreren met on-premises DNS en multi-cloud. Dit gedeelte behandelt de levenscyclus van ‘authoritative’ DNS, de zichtbaarheid en het delen van private zones, hybride resolutie, patronen voor ‘service discovery’, beveiliging en integriteit (inclusief DNSSEC en zone transfers), geavanceerd verkeersbeheer met ‘routing policies’, DNS voor private service-eindpunten, en ‘day-2 operations’ zoals troubleshooting, caching, logging en strategieën voor migratie/co-existentie.

Authoritative DNS en de DNS-levenscyclus

Managed zones en records
- Een ‘managed zone’ is een container voor ‘resource record sets’ (RRsets) voor één enkele DNS-naam (‘zone apex’).
- Record types: A, AAAA, CNAME, MX, TXT, SRV, PTR, NS, SOA (en meer). Cloud DNS ondersteunt geen CNAME op de ‘zone apex’; gebruik A/AAAA met het IP-adres van een load balancer voor ‘apex mapping’.
- Levenscyclus: zone aanmaken, records toevoegen/wijzigen (transactionele wijzigingen), propageren en beheren (monitoren/loggen/beveiligen).
- Importeer vanuit bestaande BIND-bestanden om de migratie te versnellen:
  - Voorbeeld: gcloud dns record-sets import ZONE_FILE –zone-file-format –zone MANAGED_ZONE
Publieke vs. private zones
- Publieke zones zijn wereldwijd toegankelijk via de publieke ‘authoritative’ nameservers van Google. Delegeer bij de registrar door de NS-records bij de ‘parent’ bij te werken.
- Private zones geven alleen antwoord voor gekoppelde VPC-netwerken. Ze worden geresolved door de VPC-scoped resolvers van Google voor instances in die VPC’s en, optioneel, voor hybride clients via ‘inbound forwarding’.
Propagatie en TTL’s
- Binnen Google Cloud worden recordwijzigingen binnen seconden actief; de invalidatie van externe caches is afhankelijk van de TTL.
- Afwegingen bij TTL: korte TTL’s maken flexibiliteit en veiligere ‘cutovers’ mogelijk, maar verhogen de query-last en kunnen de cache-efficiëntie verminderen; lange TTL’s verlagen de last, maar verlengen de tijd dat verouderde antwoorden worden gegeven. Gebruikelijke praktijk: 60–300s voor dynamische services; 600–3600s voor stabiele records. Verlaag de TTL 24–48 uur van tevoren vóór een ‘cutover’.

Zichtbaarheid van private zones, VPC-associatie en cross-project ontwerp

Private zones koppelen aan VPC’s
- Een private zone wordt expliciet geassocieerd met een of meer VPC-netwerken. De associatie kan projecten overspannen (met de juiste IAM-rechten, zoals dns.admin op de zone en de permissie om netwerken te binden).
- Voorrang: de ’longest-suffix match’ over de private zones die aan een VPC zijn gekoppeld, wint; wees voorzichtig bij het overlappen van private zones (bijvoorbeeld svc.corp.internal. en corp.internal.).
- Patronen voor delen tussen VPC’s
  - Directe koppeling: koppel dezelfde private zone aan meerdere VPC’s. Operationeel eenvoudig; vermijd koppelen waar het niet nodig is om de ‘blast radius’ te verkleinen.
  - Shared VPC: centraliseer het DNS-beheer in het ‘host project’ en stel DNS beschikbaar voor ‘service projects’ door de VPC van de subnets aan zones te koppelen.
  - DNS peering zones: wanneer VPC-peering wordt gebruikt tussen netwerken, kan een ‘peering zone’ in de ‘consumer VPC’ private records van de ‘producer VPC’ resolven zonder zones te dupliceren.
Faalmodi en veiligheidsmaatregelen
- Shadowing: een private zone met dezelfde naam als een publieke zone zorgt ervoor dat clients in gekoppelde VPC’s de voorkeur geven aan private antwoorden, wat de toegang tot publieke eindpunten kan verbreken. Gebruik ‘split-horizon’ opzettelijk, documenteer en test dit.
- Over-attachment: het te breed koppelen van een private zone kan interne namen lekken. Volg het ’least privilege’-principe en gebruik aparte subdomeinen (met een regio/service-scope) om de reikwijdte te beperken.
- IAM-scheiding: delegeer rechten voor DNS-wijzigingen (dns.admin) los van de rechten voor netwerkkoppeling (permissie om netwerken te binden) om gescheiden beheerdomeinen te realiseren.

Kort voorbeeld: een private zone aanmaken en koppelen

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

Hybride naamresolutie: doorsturen, peering en beleid

Forwarding zones (doorstuurzones)
- Stuur query’s voor een suffix (bijvoorbeeld onprem.corp.) autoritatief door naar specifieke naamservers (on-prem of in andere clouds). Gebruik dit wanneer je de zone niet host in Cloud DNS, maar wel naadloze resolutie vanuit GCP nodig hebt.
- Vermijd lussen: zorg ervoor dat on-prem forwarders niet terugverwijzen naar Cloud DNS voor hetzelfde suffix.
Peering zones
- Resolveer privézones die in een gepeerde VPC worden gehost. Vereist VPC-peering-connectiviteit; niet transitief. Gebruik dit voor hub-and-spoke-ontwerpen om privé-DNS te centraliseren in een hub-VPC.
DNS-beleid
- Uitgaand doorsturen (outbound forwarding): instances in een VPC sturen recursieve query’s naar on-prem resolvers voor domeinen die niet worden opgelost in privézones van Cloud DNS. Configureer via een DNS-beleid met doel-naamserver-IP’s die bereikbaar zijn via Cloud VPN/Interconnect.
- Inkomende servers (inbound servers): on-prem resolvers sturen query’s door naar door Google geleverde inbound forwarding-IP’s (automatisch toegewezen 35.199.192.0/20) om privézones van Cloud DNS op te lossen. Gebruik dit om privé-DNS van GCP uit te breiden naar on-prem en andere clouds.
- Query-logging: schakel dit in op beleidsniveau om resolver-querylogs naar Cloud Logging te sturen voor analyse en probleemoplossing. Voor publieke zones, schakel per-zone query-logging in voor autoritatieve query’s.
Response policies
- Definieer regels om antwoorden aan te passen (bijvoorbeeld, retourneer NXDOMAIN voor bekende kwaadaardige domeinen, of synthetiseer interne A-records om publieke antwoorden te overschrijven). Pas dit zorgvuldig toe; valideer dat kritieke domeinen van derden niet per ongeluk worden geblokkeerd.
Connectiviteitsvereisten
- Om uitgaand/inkomend te laten werken, zorg voor hybride connectiviteit (Cloud VPN of Interconnect) en firewallregels die UDP/TCP 53 in beide richtingen toestaan. Het gedrag van EDNS0 en UDP-fragmentatie varieert per netwerk. Als er MTU-problemen optreden, sta dan TCP-fallback toe en overweeg EDNS(0) buffer-tuning op on-prem resolvers.
Veelvoorkomende valkuilen
- Asymmetrische bereikbaarheid: als uitgaand doorsturen verwijst naar on-prem resolvers, maar het terugkerende verkeer wordt geblokkeerd door een firewall of routeringsasymmetrie, zullen query’s een time-out krijgen. Verifieer de routes die Cloud Router heeft geleerd en sta de DNS-antwoordstromen toe.
- Gedeelde suffixes: overlappende bedrijfssuffixen (corp.local vs. corp.internal) kunnen onverwachte matches in het zoekpad van de resolver veroorzaken. Standaardiseer zoekpaden en het eigendom van suffixes.

Korte voorbeelden:

# 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 en Private Endpoints

Split-horizon DNS
- Geef verschillende antwoorden voor dezelfde naam, intern en extern. Typisch patroon: publiek foo.example.com resolvet naar een publiek Anycast IP; intern foo.example.com resolvet naar een RFC1918-adres van een ILB. Implementeer dit met een publieke zone en een privézone met dezelfde naam, en koppel de privézone zorgvuldig aan de juiste VPC’s.
Interne servicenamen
- Gebruik consistente interne suffixes (bijvoorbeeld svc.corp.internal) en servicegerichte records (A/AAAA, SRV of discovery-specifieke TXT). Houd TTL’s laag voor dynamisch geschaalde services.
- GKE service discovery: cluster-interne namen blijven binnen CoreDNS (svc.cluster.local). Voor blootstelling over namespaces/VPC’s heen, publiceer ILB VIP’s in privézones van Cloud DNS of gebruik de integratie met Service Directory.
Integratie met Service Directory
- Publiceer service-eindpunten automatisch naar DNS via Service Directory en Cloud DNS, waarbij SRV- en A-records per namespace/service worden aangemaakt. Nuttig voor het ontkoppelen van producers en consumers en het ondersteunen van health-aware discovery van service-instances.
Private service endpoints
- Private Service Connect (PSC) naar Google API’s: stuur googleapis.com privé via PSC-eindpunten, of gebruik de Restricted Google APIs VIP’s (199.36.153.8/30) met een privézone voor googleapis.com. PSC biedt regionaal lokale, privé IP-connectiviteit met controle per eindpunt; Restricted VIP is eenvoudiger maar gebruikt nog steeds publieke IP-ranges die bereikbaar zijn via default routes.
- PSC naar producer services: maak A/AAAA-records aan in een privézone die verwijzen naar het PSC-eindpunt of de ILB VIP. Voor aangepaste interne domeinen, beheer de privézone in Cloud DNS en koppel deze aan de consumer-VPC’s.
Afwegingen
- PSC vs. Restricted VIP: PSC biedt granulaire controle en vermijdt egress-inspectiepaden; het vereist een endpoint/DNS-setup per regio. Restricted VIP is snel te implementeren, maar gebruikt gedeelde VIP’s en kan conflicteren met egress-routeringsbeleid.
- Risico van split-horizon: verkeerd geconfigureerde privézones kunnen de toegang tot publieke SaaS blokkeren (‘black-hole’). Valideer dit via canary-VM’s en query-logging vóór een brede uitrol.

Kort voorbeeld: interne ILB-mapping

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

Beveiliging, Verkeersbeheer, Operations en Migratie

DNSSEC en integriteit
- Publieke zones: schakel DNSSEC-ondertekening in Cloud DNS in en publiceer DS-records bij de registrar om te beschermen tegen spoofing en cache poisoning. Plan periodes voor key rollover en monitor op validatiefouten.
- Privézones: DNSSEC-validatie/-ondertekening is doorgaans onnodig omdat de resolutie plaatsvindt via vertrouwde netwerken; focus op transportbeveiliging (hybride koppelingen) en het versterken van de resolver.
Beheerde zone-overdrachten
- Cloud DNS kan fungeren als primair of secundair voor AXFR/IXFR. Gebruik TSIG om overdrachten te authenticeren/autoriseren en NOTIFY voor tijdige propagatie. Patronen voor zone-overdracht vereenvoudigen co-existentie tijdens migraties en ondersteunen on-premise secundaire servers voor regelgevings- of veerkrachtbehoeften.
- Foutscenario’s: overdracht geblokkeerd door firewalls, mismatch van TSIG-sleutel, SOA-serienummer niet verhoogd, of IXFR uitgeschakeld op de primaire server, wat volledige AXFRs veroorzaakt.
Routeringsbeleid en health checks
- Cloud DNS ondersteunt beleid voor traffic steering (weighted, geo, latency en failover). Koppel health checks aan endpoints om ongezonde antwoorden automatisch in te trekken.
- Ontwerptips: houd recordsets per beleidsdoel klein; geef de voorkeur aan regionale scoping die is afgestemd op de gebruikerslocatie; combineer lage TTL’s met intervallen voor foutdetectie om de failover-tijd te beperken.
- Valkuilen: te gedetailleerde geo-maps kunnen operationele complexiteit veroorzaken; een gebrek aan een consistent health-signaal leidt tot ‘flapping’—gebruik stabilisatiedrempels en time-outs voor health checks die zijn afgestemd op het applicatiegedrag.
Probleemoplossing
- Tools: dig/nslookup met +trace, +short en +dnssec om ketens te valideren; bekijk Cloud Logging voor resolver query logs (DNS-beleid) en authoritative query logs (beheerde zones).
- Caching: controleer welke resolver u test (het /etc/resolv.conf-bestand van een VM verwijst meestal naar de VPC-resolver van Google). Leeg lokale resolver-caches bij het testen van TTL-wijzigingen. Overweeg negative caching (RFC 2308): NXDOMAIN-antwoorden worden gecachet volgens de SOA MINIMUM/negatieve TTL.
- Veelvoorkomende problemen: loops tussen outbound forwarding en on-premise conditional forwarders; geblokkeerde UDP 53 of MTU-problemen die afgeknotte antwoorden veroorzaken; overschaduwde publieke zones door privézones.
Operationele patronen
- Wijzigingsbeheer: bundel wijzigingen met transacties, verlaag TTL’s vóór cutovers en gebruik canary VPC-koppeling om de zichtbaarheid te valideren.
- Logging en monitoring: schakel query logging selectief in; exporteer logs naar BigQuery voor trendanalyse en maak alerts voor pieken in SERVFAIL/NXDOMAIN.
- Toegangsbeheer: scheid rollen voor het wijzigen van records van rollen voor netwerkkoppeling; pas het ’least privilege’-principe toe op editors van responsbeleid om onbedoelde domeinblokkades te voorkomen.
Migratie en co-existentie
- Co-existentie: configureer Cloud DNS als secundair via AXFR/IXFR terwijl de on-premise DNS primair blijft; of omgekeerd (Cloud DNS primair, on-premise secundair). Gebruik TSIG en allow-listing.
- Conditional forwarding: voor domeinen die on-premise blijven, maak forwarding zones of outbound forwarding-beleid aan. Zorg ervoor dat hybride koppelingen hoog beschikbaar zijn (dubbele VPN’s met afzonderlijke peers en Cloud Router).
- Overbrugging van meerdere organisaties: verbind VPC’s via Cloud VPN/Cloud Router, stel wederzijdse conditional forwarding of peering in waar nodig, en gebruik zone-overdrachten voor zones die worden verplaatst. Verlaag TTL’s ruim vóór wijzigingen in de NS- of DS-records bij de registrar.

Korte voorbeelden:

# 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

Praktijkscenario

Contoso Retail en Fabrikam Payments zijn afzonderlijke Google Cloud-organisaties die een jaar lang moeten samenwerken terwijl ze netwerken en DNS integreren met minimale downtime. Elke organisatie gebruikt niet-overlappende 10.0.0.0/8-adresruimte. Contoso zal interne services hosten onder svc.contoso.internal; Fabrikam blijft pay.fabrikam.internal on-premise hosten. Beide partijen moeten elkaars privé-namen kunnen resolven en geleidelijk enkele zones migreren naar Cloud DNS.

Aanpak:

Breng veerkrachtige hybride connectiviteit tot stand
- Maak twee Cloud VPN-tunnels tussen de hub-VPC van Contoso en de on-premise routers van Fabrikam, elk naar een afzonderlijk publiek IP-adres van Fabrikam, met Cloud Router BGP op beide tunnels.
- Rationale: Dubbele tunnels plus dynamische routering bieden padredundantie en propageren routes voor DNS-doelen automatisch, wat de risico’s van asymmetrische routering voor UDP/TCP 53 vermindert.
Implementeer conditional name resolution in beide richtingen
- Maak bij Contoso een forwarding zone fabrikam.internal die doorstuurt naar de on-premise DNS-servers van Fabrikam (bijvoorbeeld 172.20.10.53 en 172.20.11.53) en koppel deze aan de app-VPC’s.
- Configureer bij Fabrikam conditional forwarders op de on-premise DNS om svc.contoso.internal door te sturen naar de inbound forwarding IP’s van Contoso’s Cloud DNS, die worden verstrekt door een Cloud DNS inbound-beleid.
- Rationale: Forwarding zones voorkomen dubbele autoriteit en stellen elke partij in staat om haar DNS te behouden waar deze zich nu bevindt. Inbound servers breiden de privé-resolutie van Cloud DNS uit naar Fabrikam zonder de resolvers daar grootschalig te hoeven wijzigen.
Bescherm tegen forwarding loops en handhaaf zichtbaarheidsgrenzen
- Zorg ervoor dat de conditional forwarders van Fabrikam contoso.internal niet terugsturen naar Contoso voor namen die Fabrikam nog steeds beheert; op dezelfde manier moet Contoso alleen fabrikam.internal doorsturen.
- Koppel de privézones van Contoso alleen aan de VPC’s die ze nodig hebben; koppel ze niet globaal om de ‘blast radius’ te verkleinen.
- Rationale: Elimineert DNS-recursieloops en voorkomt dat privézones publieke domeinen ‘overschaduwen’.
Migreer een gedeelde zone met behulp van beheerde zone-overdrachten
- Voor een legacy gedeelde zone legacy.shared.internal die momenteel wordt gehost op de primaire BIND-server van Fabrikam, configureer Cloud DNS als een secundaire server met TSIG en voeg de primaire server van Fabrikam toe aan de allow-list voor AXFR/IXFR. Houd Fabrikam als primair tijdens de co-existentieperiode.
- Rationale: De secundaire modus zorgt voor live synchronisatie zonder clients te hoeven wijzigen. Het maakt veilige validatie in Contoso mogelijk terwijl één ‘source of truth’ behouden blijft.
Introduceer split-horizon voor extern toegankelijke services
- Maak een publieke zone contoso.example met records die verwijzen naar het IP-adres van een globale HTTPS load balancer voor klanten. Maak een gelijknamige privézone, gekoppeld aan interne VPC’s, die dezelfde namen mapt naar interne ILB-adressen.
- Rationale: Externe gebruikers blijven de edge load balancers bereiken; interne services bereiken privé-ILB’s via RFC1918, wat de latentie en kosten optimaliseert terwijl consistente hostnamen behouden blijven.
Bied privétoegang tot Google API’s zonder via firewalls naar buiten te gaan
- Voor Contoso VM’s zonder externe IP-adressen, schakel Private Service Connect voor Google API’s in en maak de beheerde privé-DNS-zone voor googleapis.com aan die mapt naar PSC-endpoints.
- Rationale: Zorgt ervoor dat de toegang tot BigQuery en Pub/Sub privé en lokaal binnen de VPC blijft, waardoor externe egress-appliances worden vermeden en de beveiligingshouding behouden blijft.
Schakel observability en controle in
- Schakel Cloud DNS query logging in op het DNS-beleid van Contoso voor de betrokken VPC’s en authoritative query logging op publieke zones. Maak regels voor responsbeleid om bekende kwaadaardige domeinen voor de hele organisatie te blokkeren.
- Rationale: Query-telemetrie ondersteunt probleemoplossing en capaciteitsplanning; responsbeleid biedt centrale controle voor beveiliging zonder elke resolver te hoeven aanpassen.
Voer wijzigingsbeheer uit met veilige TTL’s
- Verlaag de TTL’s naar 60s voor records die worden gemigreerd, een week voor de wijzigingen. Na validatie en cutover (bijvoorbeeld het overschakelen van een service van on-premise naar een GCP ILB), verhoog de TTL’s geleidelijk naar 300–600s.
- Rationale: Korte TTL’s beperken het risico tijdens overgangen; het herstellen van hogere TTL’s verbetert de cache-efficiëntie na stabilisatie.
Test, valideer en versterk
- Voer vanaf canary VM’s aan beide kanten ‘dig’ uit met +trace en verifieer de autoritatieve paden, bevestig dat er geen pieken in SERVFAIL/NXDOMAIN in de logs zijn, en simuleer link-fouten om het DNS-gedrag met VPN-redundantie te observeren.
- Rationale: Proactieve validatie detecteert loop-/zichtbaarheidsproblemen vroegtijdig; foutsimulaties verifiëren dat de hybride resolutie transportincidenten overleeft zonder impact voor de gebruiker.