Google PCNE: Cloud DNS, individuazione dei servizi e risoluzione dei nomi ibrida — Guida allo studio

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

Fa parte della Google Professional Cloud Network Engineer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Cloud DNS è il servizio DNS scalabile e ad alta disponibilità di Google Cloud che supporta sia zone autoritative pubbliche sia DNS privato per le reti VPC. Fornisce inoltre primitive di risoluzione dei nomi in modalità ibrida — forwarding, peering, server in entrata, policy di risposta e policy DNS — per l’integrazione con DNS on-premise e multi-cloud. Questa sezione tratta il ciclo di vita del DNS autoritativo, la visibilità e la condivisione delle zone private, la risoluzione ibrida, i pattern di service discovery, la sicurezza e l’integrità (inclusi DNSSEC e trasferimenti di zona), la gestione avanzata del traffico con policy di routing, il DNS per endpoint di servizi privati e le operazioni di “day-2” come troubleshooting, caching, logging e strategie di migrazione/coesistenza.

DNS autoritativo e ciclo di vita del DNS

Zone gestite e record
- Una zona gestita (managed zone) è un contenitore per set di record di risorse (RRset) relativi a un singolo nome DNS (apice della zona).
- Tipi di record: A, AAAA, CNAME, MX, TXT, SRV, PTR, NS, SOA (e altri). Cloud DNS non supporta record CNAME all’apice della zona; utilizzare record A/AAAA con l’IP di un load balancer per il mapping dell’apice.
- Ciclo di vita: creazione della zona, aggiunta/modifica dei record (modifiche transazionali), propagazione e operatività (monitoraggio/logging/messa in sicurezza).
- Importazione da file BIND esistenti per accelerare la migrazione:
  - Esempio: gcloud dns record-sets import ZONE_FILE –zone-file-format –zone MANAGED_ZONE
Zone pubbliche e private a confronto
- Le zone pubbliche sono accessibili a livello globale tramite i nameserver autoritativi pubblici di Google. La delega viene effettuata presso il registrar aggiornando i record NS nella zona padre.
- Le zone private rispondono solo per le reti VPC a cui sono collegate. Vengono risolte dai resolver di Google con scope a livello di VPC per le istanze in tali VPC e, opzionalmente, da client ibridi tramite l’inoltro in entrata (inbound forwarding).
Propagazione e TTL
- All’interno di Google Cloud, le modifiche ai record diventano attive in pochi secondi; l’invalidazione della cache esterna dipende dal TTL.
- Compromessi legati al TTL: TTL brevi consentono maggiore agilità e cutover più sicuri, ma aumentano il carico di query e possono ridurre l’efficienza della cache; TTL lunghi riducono il carico ma prolungano la presenza di risposte obsolete. Pratica comune: 60–300s per servizi dinamici; 600–3600s per record stabili. Prima dei cutover, ridurre il TTL con 24–48 ore di anticipo.

Visibilità delle zone private, associazione a VPC e design cross-project

Collegamento delle zone private ai VPC
- Una zona privata è associata esplicitamente a una o più reti VPC. L’associazione può estendersi su più progetti (con autorizzazioni IAM appropriate, come dns.admin sulla zona e il permesso di associare le reti).
- Precedenza: vince la corrispondenza del suffisso più lungo tra le zone private collegate a un VPC; prestare attenzione quando si sovrappongono zone private (ad esempio, svc.corp.internal. e corp.internal.).
- Pattern di condivisione cross-VPC
  - Collegamento diretto (Direct attach): collega la stessa zona privata a più VPC. Operativamente semplice; evitare di collegarla dove non necessario per ridurre il “blast radius” (raggio d’impatto).
  - Shared VPC: centralizza l’amministrazione DNS nel progetto host esponendo il DNS ai progetti di servizio tramite il collegamento del VPC delle subnet alle zone.
  - Zone di peering DNS: quando si utilizza il VPC peering tra reti, una zona di peering nel VPC consumer può risolvere i record privati dal VPC producer senza duplicare le zone.
Modalità di fallimento e misure di protezione
- Shadowing: una zona privata con lo stesso nome di una zona pubblica fa sì che i client nei VPC collegati preferiscano le risposte private, potenzialmente interrompendo l’accesso agli endpoint pubblici. Utilizzare lo split-horizon in modo intenzionale, documentandolo e testandolo.
- Collegamento eccessivo (Over-attachment): collegare una zona privata in modo esteso può causare la fuga di nomi interni. Seguire il principio del privilegio minimo e utilizzare sottodomini separati (con scope di regione/servizio) per limitare l’ambito.
- Separazione IAM: delegare i diritti di modifica del DNS (dns.admin) separatamente dai diritti di collegamento alla rete (permesso di associare le reti) per ottenere domini amministrativi separati.

Breve esempio: creare e collegare una zona privata

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

Risoluzione dei nomi ibrida: Inoltro, Peering e Policy

Zone di inoltro
- Inoltrano in modo autoritativo le query per un suffisso (ad esempio, onprem.corp.) a name server specifici (on-premise o in altri cloud). Da utilizzare quando non si ospita la zona in Cloud DNS ma è necessaria una risoluzione trasparente da GCP.
- Evitare i loop: assicurarsi che i forwarder on-premise non puntino nuovamente a Cloud DNS per lo stesso suffisso.
Zone di peering
- Risolvono zone private ospitate in un VPC in peering. Richiede connettività VPC peering; non è transitivo. Da utilizzare per architetture hub-and-spoke per centralizzare il DNS privato in un VPC hub.
Policy DNS
- Inoltro in uscita (outbound): le istanze in un VPC inviano query ricorsive ai resolver on-premise per domini non risolti nelle zone private di Cloud DNS. Si configura tramite una policy DNS con gli IP dei name server di destinazione raggiungibili tramite Cloud VPN/Interconnect.
- Server in entrata (inbound): i resolver on-premise inoltrano le query agli IP di inoltro in entrata forniti da Google (auto-allocati su 35.199.192.0/20) per risolvere le zone private di Cloud DNS. Da utilizzare per estendere il DNS privato di GCP all’ambiente on-premise e ad altri cloud.
- Logging delle query: si abilita a livello di policy per inviare i log delle query dei resolver a Cloud Logging per analisi e troubleshooting. Per le zone pubbliche, abilitare il logging delle query per zona per le query autoritative.
Policy di risposta
- Definiscono regole per modificare le risposte (ad esempio, restituire NXDOMAIN per domini malevoli noti, o sintetizzare record A interni per sovrascrivere le risposte pubbliche). Applicare con cautela; verificare che domini critici di terze parti non vengano bloccati inavvertitamente.
Prerequisiti di connettività
- Affinché l’inoltro in uscita/entrata funzioni, assicurarsi che la connettività ibrida (Cloud VPN o Interconnect) e le regole firewall consentano il traffico UDP/TCP sulla porta 53 in entrambe le direzioni, secondo necessità. Il comportamento di EDNS0 e della frammentazione UDP varia tra le reti: se si verificano problemi di MTU, consentire il fallback su TCP e considerare l’ottimizzazione del buffer EDNS(0) sui resolver on-premise.
Errori comuni
- Raggiungibilità asimmetrica: se l’inoltro in uscita punta a resolver on-premise ma il traffico di ritorno è bloccato da firewall o da asimmetria di routing, le query andranno in timeout. Verificare le route apprese dal Cloud Router e consentire i flussi di risposta DNS.
- Suffissi sovrapposti: suffissi aziendali che si sovrappongono (es. corp.local vs corp.internal) possono causare corrispondenze inaspettate nel percorso di ricerca del resolver. Standardizzare i percorsi di ricerca e la proprietà dei suffissi.

Esempi brevi:

# 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 ed Endpoint Privati

DNS Split-horizon
- Fornisce risposte diverse per lo stesso nome internamente ed esternamente. Pattern tipico: foo.example.com pubblico si risolve in un IP Anycast pubblico; foo.example.com interno si risolve in un indirizzo RFC1918 di un ILB. Si implementa con una zona pubblica e una zona privata con lo stesso nome, definendo attentamente l’ambito della zona privata ai VPC appropriati.
Denominazione dei servizi interni
- Utilizzare suffissi interni coerenti (ad esempio, svc.corp.internal) e record orientati ai servizi (A/AAAA, SRV, o TXT specifici per la discovery). Mantenere TTL bassi per i servizi scalati dinamicamente.
- Service discovery in GKE: i nomi interni al cluster rimangono all’interno di CoreDNS (svc.cluster.local). Per l’esposizione tra namespace/VPC, pubblicare i VIP degli ILB nelle zone private di Cloud DNS o utilizzare l’integrazione con Service Directory.
Integrazione con Service Directory
- Pubblica automaticamente gli endpoint dei servizi su DNS tramite Service Directory e Cloud DNS, emettendo record SRV e A per namespace/servizio. Utile per disaccoppiare producer e consumer e supportare una discovery delle istanze di servizio consapevole del loro stato di salute (health-aware).
Endpoint di servizio privati
- Private Service Connect (PSC) verso le API di Google: instrada privatamente googleapis.com utilizzando endpoint PSC, oppure utilizza i VIP delle API di Google con accesso limitato (199.36.153.8/30) con una zona privata per googleapis.com. PSC offre connettività IP privata e locale a livello regionale con controllo per singolo endpoint; il VIP con accesso limitato è più semplice ma utilizza comunque intervalli di IP pubblici raggiungibili tramite le route predefinite.
- PSC verso i servizi producer: creare record A/AAAA in una zona privata che puntano all’endpoint PSC o al VIP dell’ILB. Per domini interni personalizzati, gestire la zona privata in Cloud DNS e associarla ai VPC consumer.
Compromessi
- PSC vs VIP con accesso limitato: PSC offre un controllo granulare ed evita i percorsi di ispezione del traffico in uscita (egress); richiede la configurazione di endpoint/DNS per regione. Il VIP con accesso limitato è rapido da implementare ma utilizza VIP condivisi e può interagire con le policy di routing in uscita.
- Rischio dello split-horizon: zone private con un ambito definito in modo errato possono creare un “black hole” per l’accesso a servizi SaaS pubblici. Verificare tramite VM canary e logging delle query prima di un rollout su larga scala.

Esempio breve: mappatura di un ILB interno

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

Sicurezza, gestione del traffico, operazioni e migrazione

DNSSEC e integrità
- Zone pubbliche: abilitare la firma DNSSEC in Cloud DNS e pubblicare i record DS presso il registrar per proteggersi da spoofing e cache poisoning. Pianificare le finestre di rollover delle chiavi e monitorare i fallimenti di validazione.
- Zone private: la validazione/firma DNSSEC è tipicamente non necessaria perché la risoluzione avviene su reti fidate; concentrarsi sulla sicurezza del trasporto (collegamenti ibridi) e sull’hardening del resolver.
Trasferimenti di zone gestite
- Cloud DNS può agire come primario o secondario per AXFR/IXFR. Usare TSIG per autenticare/autorizzare i trasferimenti e NOTIFY per una propagazione tempestiva. I pattern di trasferimento di zona semplificano la coesistenza durante le migrazioni e supportano i secondari on-premise per esigenze normative o di resilienza.
- Modalità di fallimento: trasferimento bloccato da firewall, discrepanza della chiave TSIG, numero di serie SOA non incrementato o IXFR disabilitato sul primario che causa trasferimenti AXFR completi.
Policy di routing e health check
- Cloud DNS supporta policy di traffic steering (ponderate, geografiche, di latenza e di failover). Associare degli health check agli endpoint per ritirare automaticamente le risposte non integre.
- Suggerimenti di progettazione: mantenere ridotti i set di record per ogni target della policy; preferire uno scoping regionale allineato con la user footprint; combinare TTL bassi con intervalli di rilevamento dei guasti per limitare il tempo di failover.
- Insidie: mappe geografiche troppo granulari possono causare complessità operativa; la mancanza di un segnale di health consistente porta al flapping—usare soglie di stabilizzazione e timeout degli health check allineati con il comportamento dell’applicazione.
Risoluzione dei problemi
- Strumenti: dig/nslookup con +trace, +short e +dnssec per validare le catene; esaminare Cloud Logging per i log delle query del resolver (policy DNS) e i log delle query autoritative (zone gestite).
- Caching: confermare quale resolver si sta testando (il file /etc/resolv.conf della VM di solito punta al resolver VPC di Google). Svuotare le cache dei resolver locali quando si testano le modifiche al TTL. Considerare il caching negativo (RFC 2308): le risposte NXDOMAIN vengono messe in cache secondo il valore MINIMUM/negative TTL del record SOA.
- Problemi comuni: loop tra l’inoltro in uscita e i forwarder condizionali on-premise; porta UDP 53 bloccata o problemi di MTU che causano risposte troncate; zone pubbliche mascherate da zone private.
Pattern operativi
- Controllo delle modifiche: raggruppare le modifiche con le transazioni, ridurre i TTL prima dei cutover e usare il collegamento di un VPC canary per validare la visibilità.
- Logging e monitoraggio: abilitare il logging delle query in modo selettivo; esportare i log in BigQuery per l’analisi dei trend e creare alert su picchi di SERVFAIL/NXDOMAIN.
- Controllo degli accessi: separare i ruoli per la modifica dei record dai ruoli per il collegamento delle reti; applicare il principio del privilegio minimo agli editor delle policy di risposta per evitare blocchi di dominio involontari.
Migrazione e coesistenza
- Coesistenza: configurare Cloud DNS come secondario tramite AXFR/IXFR mentre il DNS on-premise rimane primario; o viceversa (Cloud DNS primario, secondari on-premise). Usare TSIG e l’allow-listing.
- Inoltro condizionale: per i domini che rimangono on-premise, creare zone di inoltro o policy di inoltro in uscita. Assicurarsi che i collegamenti ibridi siano ad alta disponibilità (doppie VPN con peer distinti e Cloud Router).
- Bridging multi-organizzazione: connettere i VPC tramite Cloud VPN/Cloud Router, stabilire un inoltro condizionale reciproco o il peering a seconda dei casi, e usare i trasferimenti di zona per le zone in fase di rilocazione. Abbassare i TTL ben prima delle modifiche ai record NS o DS del registrar.

Esempi brevi:

# 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

Scenario pratico di un problema

Contoso Retail e Fabrikam Payments sono due organizzazioni Google Cloud separate che devono interoperare per un anno mentre integrano le reti e il DNS con un downtime minimo. Ciascuna organizzazione utilizza uno spazio di indirizzi non sovrapposto 10.0.0.0/8. Contoso ospiterà i servizi interni sotto svc.contoso.internal; Fabrikam continuerà a ospitare pay.fabrikam.internal on-premise. Entrambe le parti devono risolvere i nomi privati dell’altra e migrare gradualmente alcune zone su Cloud DNS.

Approccio:

Stabilire una connettività ibrida resiliente
- Creare due tunnel Cloud VPN tra il VPC hub di Contoso e i router on-premise di Fabrikam, ciascuno verso un IP pubblico distinto di Fabrikam, con BGP di Cloud Router su entrambi i tunnel.
- Motivazione: i doppi tunnel più il routing dinamico forniscono ridondanza del percorso e propagano automaticamente le route per i target DNS, riducendo i rischi di routing asimmetrico per UDP/TCP 53.
Implementare la risoluzione dei nomi condizionale in entrambe le direzioni
- In Contoso, creare una zona di inoltro fabrikam.internal che inoltri le richieste ai server DNS on-premise di Fabrikam (ad esempio, 172.20.10.53 e 172.20.11.53) e collegarla ai VPC delle applicazioni.
- In Fabrikam, configurare i forwarder condizionali sul DNS on-premise per inoltrare svc.contoso.internal agli IP di inoltro in entrata di Cloud DNS di Contoso, forniti da una policy in entrata di Cloud DNS.
- Motivazione: le zone di inoltro evitano la duplicazione dell’autorità e consentono a ciascuna parte di mantenere il proprio DNS dove si trova attualmente. I server in entrata estendono la risoluzione privata di Cloud DNS a Fabrikam senza modificare ampiamente i suoi resolver.
Proteggersi dai loop di inoltro e applicare i confini di visibilità
- Assicurarsi che i forwarder condizionali di Fabrikam non inoltrino nuovamente contoso.internal a Contoso per i nomi che Fabrikam possiede ancora; allo stesso modo, Contoso dovrebbe inoltrare solo fabrikam.internal.
- Collegare le zone private di Contoso solo ai VPC che le richiedono; non collegarle globalmente per ridurre il raggio d’impatto (blast radius).
- Motivazione: elimina i loop di ricorsione DNS e previene il mascheramento (shadowing) dei domini pubblici da parte delle zone private.
Migrare una zona condivisa utilizzando i trasferimenti di zone gestite
- Per una zona condivisa legacy legacy.shared.internal attualmente ospitata sul primario BIND di Fabrikam, configurare Cloud DNS come secondario con TSIG e inserire nell’allow-list il primario di Fabrikam per AXFR/IXFR. Mantenere Fabrikam come primario durante il periodo di coesistenza.
- Motivazione: la modalità secondaria fornisce una sincronizzazione in tempo reale senza modificare i client. Permette una validazione sicura in Contoso mantenendo un’unica fonte di verità (source of truth).
Introdurre lo split-horizon per i servizi esposti esternamente
- Creare una zona pubblica contoso.example con record che puntano all’IP di un load balancer HTTPS globale per i clienti. Creare una zona privata con lo stesso nome, collegata ai VPC interni, che mappa gli stessi nomi a indirizzi ILB interni.
- Motivazione: gli utenti esterni continuano a raggiungere i load balancer perimetrali (edge); i servizi interni raggiungono gli ILB privati su indirizzi RFC1918, ottimizzando latenza e costi e mantenendo al contempo nomi host coerenti.
Fornire accesso privato alle API di Google senza uscire attraverso i firewall
- Per le VM di Contoso senza IP esterni, abilitare Private Service Connect per le API di Google e creare la zona DNS privata gestita per googleapis.com che mappa agli endpoint PSC.
- Motivazione: assicura che l’accesso a BigQuery e Pub/Sub rimanga privato e locale al VPC, evitando appliance di terze parti per il traffico in uscita (egress) e preservando la postura di sicurezza.
Abilitare l’osservabilità e il controllo
- Attivare il logging delle query di Cloud DNS sulla policy DNS di Contoso per i VPC coinvolti e il logging delle query autoritative sulle zone pubbliche. Creare regole di policy di risposta per bloccare i domini malevoli noti a livello di organizzazione.
- Motivazione: la telemetria delle query supporta la risoluzione dei problemi e la pianificazione della capacità; le policy di risposta forniscono un controllo centralizzato per la sicurezza senza dover intervenire su ogni singolo resolver.
Eseguire la gestione delle modifiche con TTL sicuri
- Ridurre i TTL a 60 secondi per i record in fase di migrazione una settimana prima delle modifiche. Dopo la validazione e il cutover (ad esempio, il passaggio di un servizio da on-premise a un ILB di GCP), aumentare gradualmente i TTL a 300–600 secondi.
- Motivazione: TTL brevi limitano il rischio durante le transizioni; ripristinare TTL più alti migliora l’efficienza della cache dopo la stabilizzazione.
Testare, validare e rafforzare (harden)
- Da VM canary su entrambi i lati, eseguire dig con +trace e verificare i percorsi autoritativi, confermare l’assenza di picchi di SERVFAIL/NXDOMAIN nei log e simulare guasti dei collegamenti per osservare il comportamento del DNS con la ridondanza della VPN.
- Motivazione: la validazione proattiva rileva precocemente problemi di loop/visibilità; le simulazioni di guasto verificano che la risoluzione ibrida sopravviva a incidenti di trasporto senza impatto per l’utente.