Google PCNE: Cloud DNS, Service Discovery and Hybrid Name Resolution — Study Guide

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

Part of the Google Professional Cloud Network Engineer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

Cloud DNS is Google Cloud’s scalable, highly available DNS service that supports both public authoritative zones and private DNS for VPCs. It also provides hybrid name resolution primitives—forwarding, peering, inbound servers, response policies, and DNS policies—to integrate with on-premises DNS and multi-cloud. This section covers authoritative DNS lifecycle, private-zone visibility and sharing, hybrid resolution, service discovery patterns, security and integrity (including DNSSEC and zone transfers), advanced traffic management with routing policies, DNS for private service endpoints, and day-2 operations such as troubleshooting, caching, logging, and migration/coexistence strategies.

Authoritative DNS and the DNS Lifecycle

Managed zones and records
- A managed zone is a container for resource record sets (RRsets) for a single DNS name (zone apex).
- Record types: A, AAAA, CNAME, MX, TXT, SRV, PTR, NS, SOA (and more). Cloud DNS does not support CNAME at zone apex; use A/AAAA with a load balancer’s IP for apex mapping.
- Lifecycle: create zone, add/modify records (transactional changes), propagate, and operate (monitor/log/secure).
- Import from existing BIND files to accelerate migration:
  - Example: gcloud dns record-sets import ZONE_FILE –zone-file-format –zone MANAGED_ZONE
Public vs private zones
- Public zones are globally accessible via Google public authoritative nameservers. Delegate at the registrar by updating NS at the parent.
- Private zones answer only for attached VPC networks. They are resolved by Google’s VPC-scoped resolvers for instances in those VPCs and, optionally, hybrid clients via inbound forwarding.
Propagation and TTLs
- Within Google Cloud, record changes become active in seconds; external cache invalidation depends on TTL.
- TTL trade-offs: short TTLs enable agility and safer cutovers but increase query load and can reduce cache efficiency; long TTLs reduce load but prolong stale answers. Common practice: 60–300s for dynamic services; 600–3600s for stable records. Before cutovers, reduce TTL 24–48 hours in advance.

Private-Zone Visibility, VPC Association, and Cross-Project Design

Attaching private zones to VPCs
- A private zone is explicitly associated with one or more VPC networks. Association can span projects (with appropriate IAM such as dns.admin on the zone and permission to bind networks).
- Precedence: the longest-suffix match across private zones attached to a VPC wins; be careful when overlapping private zones (for example, svc.corp.internal. and corp.internal.).
- Cross-VPC sharing patterns
  - Direct attach: attach the same private zone to multiple VPCs. Operationally simple; avoid attaching where not needed to reduce blast radius.
  - Shared VPC: centralize DNS administration in the host project while exposing DNS to service projects by attaching subnets’ VPC to zones.
  - DNS peering zones: when VPC peering is used between networks, a peering zone in the consumer VPC can resolve private records from the producer VPC without duplicating zones.
Failure modes and guardrails
- Shadowing: a private zone with the same name as a public zone causes clients in attached VPCs to prefer private answers, potentially breaking access to public endpoints. Use split-horizon intentionally, document, and test.
- Over-attachment: attaching a private zone broadly can leak internal names. Follow least privilege and use separate subdomains (region/service scoped) to limit scope.
- IAM separation: delegate DNS change rights (dns.admin) separately from network attachment rights (permission to bind networks) to achieve separate admin domains.

Short example: create and attach a private zone

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

Hybrid Name Resolution: Forwarding, Peering, and Policies

Forwarding zones
- Authoritatively forward queries for a suffix (for example, onprem.corp.) to specific name servers (on-prem or other clouds). Use when you don’t host the zone in Cloud DNS but need seamless resolution from GCP.
- Avoid loops: ensure on-prem forwarders don’t point back to Cloud DNS for the same suffix.
Peering zones
- Resolve private zones hosted in a peered VPC. Requires VPC peering connectivity; not transitive. Use for hub-and-spoke designs to centralize private DNS in a hub VPC.
DNS policies
- Outbound forwarding: instances in a VPC send recursive queries to on-prem resolvers for domains not resolved in Cloud DNS private zones. Configure via a DNS policy with target name server IPs reachable over Cloud VPN/Interconnect.
- Inbound servers: on-prem resolvers forward queries to Google-provided inbound forwarding IPs (auto-allocated 35.199.192.0/20) to resolve Cloud DNS private zones. Use to extend GCP private DNS to on-prem and other clouds.
- Query logging: enable at the policy level to send resolver query logs to Cloud Logging for analysis and troubleshooting. For public zones, enable per-zone query logging for authoritative queries.
Response policies
- Define rules to modify responses (for example, return NXDOMAIN for known malicious domains, or synthesize internal A records to override public answers). Apply carefully; validate that critical third-party domains aren’t inadvertently blocked.
Connectivity prerequisites
- For outbound/inbound to work, ensure hybrid connectivity (Cloud VPN or Interconnect) and firewall rules allow UDP/TCP 53 both ways as needed. EDNS0 and UDP fragmentation behavior vary across networks—if MTU issues occur, allow TCP fallback and consider EDNS(0) buffer tuning on on-prem resolvers.
Common pitfalls
- Asymmetric reachability: if outbound forwarding points to on-prem resolvers but return traffic is blocked by firewall or routing asymmetry, queries time out. Verify Cloud Router learned routes, and allow DNS response flows.
- Split suffixes: overlapping enterprise suffixes (corp.local vs corp.internal) can cause unexpected resolver search-path matches. Standardize search paths and suffix ownership.

Short examples:

# 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, and Private Endpoints

Split-horizon DNS
- Serve different answers for the same name internally and externally. Typical pattern: public foo.example.com resolves to a public Anycast IP; internal foo.example.com resolves to an ILB’s RFC1918 address. Implement with a public zone and a private zone of the same name, carefully scoping the private zone to the appropriate VPCs.
Internal service naming
- Use consistent internal suffixes (for example, svc.corp.internal) and service-oriented records (A/AAAA, SRV, or discovery-specific TXT). Keep low TTLs for dynamically scaled services.
- GKE service discovery: cluster-internal names remain within CoreDNS (svc.cluster.local). For cross-namespace/VPC exposure, publish ILB VIPs into Cloud DNS private zones or use Service Directory integration.
Service Directory integration
- Publish service endpoints to DNS automatically via Service Directory and Cloud DNS, emitting SRV and A records per namespace/service. Useful for decoupling producers and consumers and supporting health-aware discovery of service instances.
Private service endpoints
- Private Service Connect (PSC) to Google APIs: steer googleapis.com privately using PSC endpoints, or use the Restricted Google APIs VIPs (199.36.153.8/30) with a private zone for googleapis.com. PSC gives regionally local, private IP connectivity with per-endpoint control; Restricted VIP is simpler but still uses public IP ranges reachable via default routes.
- PSC to producer services: create A/AAAA records in a private zone pointing to the PSC endpoint or ILB VIP. For custom internal domains, manage the private zone in Cloud DNS and attach to consumer VPCs.
Trade-offs
- PSC vs Restricted VIP: PSC offers granular control and avoids egress inspection paths; it requires endpoint/DNS setup per region. Restricted VIP is quick to deploy but uses shared VIPs and can interact with egress routing policies.
- Split-horizon risk: mis-scoped private zones can black-hole access to public SaaS. Validate via canary VMs and query logging before broad rollout.

Short example: internal ILB mapping

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

Security, Traffic Management, Operations, and Migration

DNSSEC and integrity
- Public zones: enable DNSSEC signing in Cloud DNS and publish DS at the registrar to protect against spoofing and cache poisoning. Plan key rollover windows and monitor for validation failures.
- Private zones: DNSSEC validation/signing is typically unnecessary because resolution happens over trusted networks; focus on transport security (hybrid links) and resolver hardening.
Managed zone transfers
- Cloud DNS can act as primary or secondary for AXFR/IXFR. Use TSIG to authenticate/authorize transfers and NOTIFY for timely propagation. Zone-transfer patterns simplify co-existence during migrations and support on-prem secondaries for regulatory or resiliency needs.
- Failure modes: transfer blocked by firewalls, TSIG key mismatch, SOA serial not incremented, or IXFR disabled on the primary causing full AXFRs.
Routing policies and health checks
- Cloud DNS supports traffic steering policies (weighted, geo, latency, and failover). Attach health checks to endpoints to automatically withdraw unhealthy answers.
- Design tips: keep record sets per policy target small; prefer regional scoping aligned with user footprint; combine low TTLs with failure-detection intervals to bound failover time.
- Pitfalls: over-granular geo maps can cause operational complexity; lack of consistent health signal leads to flapping—use stabilization thresholds and health-check timeouts aligned with application behavior.
Troubleshooting
- Tools: dig/nslookup with +trace, +short, and +dnssec to validate chains; review Cloud Logging for resolver query logs (DNS policies) and authoritative query logs (managed zones).
- Caching: confirm which resolver you are testing (VM’s /etc/resolv.conf usually points to Google’s VPC resolver). Flush local resolver caches when testing TTL changes. Consider negative caching (RFC 2308): NXDOMAIN responses are cached per SOA MINIMUM/negative TTL.
- Common issues: loops between outbound forwarding and on-prem conditional forwarders; blocked UDP 53 or MTU issues causing truncated responses; overshadowed public zones by private zones.
Operational patterns
- Change control: batch changes with transactions, reduce TTLs before cutovers, and use canary VPC attachment to validate visibility.
- Logging and monitoring: enable query logging selectively; export logs to BigQuery for trend analysis, and create alerts on SERVFAIL/NXDOMAIN spikes.
- Access control: separate record-change roles from network-attachment roles; enforce least privilege on response-policy editors to avoid inadvertent domain blocks.
Migration and coexistence
- Coexistence: stand up Cloud DNS as secondary via AXFR/IXFR while the on-prem DNS remains primary; or reverse (Cloud DNS primary, on-prem secondaries). Use TSIG and allow-listing.
- Conditional forwarding: for domains that remain on-prem, create forwarding zones or outbound forwarding policies. Ensure hybrid links are highly available (dual VPNs with distinct peers and Cloud Router).
- Multi-organization bridging: connect VPCs via Cloud VPN/Cloud Router, establish mutual conditional forwarding or peering as appropriate, and use zone transfers for zones being rehomed. Lower TTLs well before registrar NS or DS changes.

Short examples:

# 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

Practical Problem Scenario

Contoso Retail and Fabrikam Payments are separate Google Cloud organizations that must interoperate for one year while they integrate networks and DNS with minimal downtime. Each org uses non-overlapping 10.0.0.0/8 space. Contoso will host internal services under svc.contoso.internal; Fabrikam will continue to host pay.fabrikam.internal on-prem. Both sides need to resolve each other’s private names and gradually migrate some zones to Cloud DNS.

Approach:

Establish resilient hybrid connectivity
- Create two Cloud VPN tunnels between Contoso’s hub VPC and Fabrikam’s on-prem routers, each to a distinct Fabrikam public IP, with Cloud Router BGP on both tunnels.
- Rationale: Dual tunnels plus dynamic routing provide path redundancy and propagate routes for DNS targets automatically, reducing asymmetric routing risks for UDP/TCP 53.
Implement conditional name resolution in both directions
- At Contoso, create a forwarding zone fabrikam.internal that forwards to Fabrikam’s on-prem DNS servers (for example, 172.20.10.53 and 172.20.11.53) and attach it to app VPCs.
- At Fabrikam, configure conditional forwarders on the on-prem DNS to forward svc.contoso.internal to Contoso’s Cloud DNS inbound forwarding IPs provided by a Cloud DNS inbound policy.
- Rationale: Forwarding zones avoid duplicating authority and allow each side to keep its DNS where it is today. Inbound servers extend Cloud DNS private resolution to Fabrikam without changing its resolvers broadly.
Guard against forwarding loops and enforce visibility boundaries
- Ensure Fabrikam’s conditional forwarders do not forward contoso.internal back to Contoso for names Fabrikam still owns; similarly, Contoso should only forward fabrikam.internal.
- Attach Contoso’s private zones only to the VPCs that require them; do not globally attach to reduce the blast radius.
- Rationale: Eliminates DNS recursion loops and prevents private-zone shadowing of public domains.
Migrate a shared zone using managed zone transfers
- For a legacy shared zone legacy.shared.internal currently hosted on Fabrikam’s BIND primary, configure Cloud DNS as a secondary with TSIG and allow-list Fabrikam’s primary for AXFR/IXFR. Keep Fabrikam as primary during the coexistence period.
- Rationale: Secondary mode provides live synchronization without changing clients. It enables safe validation in Contoso while maintaining a single source of truth.
Introduce split-horizon for externally exposed services
- Create a public zone contoso.example with records pointing to a global HTTPS load balancer IP for customers. Create an identically named private zone attached to internal VPCs that maps the same names to internal ILB addresses.
- Rationale: External users continue to reach edge load balancers; internal services reach private ILBs over RFC1918, optimizing latency and cost while maintaining consistent hostnames.
Provide private access to Google APIs without egressing through firewalls
- For Contoso VMs without external IPs, enable Private Service Connect for Google APIs and create the managed private DNS zone for googleapis.com that maps to PSC endpoints.
- Rationale: Ensures BigQuery and Pub/Sub access remains private and local to the VPC, avoiding third-party egress appliances and preserving security posture.
Enable observability and control
- Turn on Cloud DNS query logging on Contoso’s DNS policy for involved VPCs and authoritative query logging on public zones. Create response policy rules to block known malicious domains organization-wide.
- Rationale: Query telemetry supports troubleshooting and capacity planning; response policies provide central control for security without touching every resolver.
Execute change management with safe TTLs
- Reduce TTLs to 60s for records being migrated a week before changes. After validation and cutover (for example, switching a service from on-prem to GCP ILB), gradually raise TTLs to 300–600s.
- Rationale: Short TTLs confine risk during transitions; restoring higher TTLs improves cache efficiency post-stabilization.
Test, validate, and harden
- From canary VMs on both sides, run dig with +trace and verify authoritative paths, confirm no SERVFAIL/NXDOMAIN spikes in logs, and simulate link failures to observe DNS behavior with VPN redundancy.
- Rationale: Proactive validation detects loop/visibility issues early; failure simulations verify that hybrid resolution survives transport incidents without user impact.