Cloud DNS
Cloud DNS is Google's managed DNS service with a 100% availability SLA, anycast authoritative name servers, and support for both public and private zones. It is not just "managed DNS" — Cloud DNS Routing Policies provide serverless geo-, weighted-, and failover-routing without a separate traffic manager, and private zones give you internal name resolution that is not resolvable from the public internet (only from authorized VPCs and the forwarding paths you configure).
The 100% SLA is unusual in cloud services and reflects that DNS resolution rides Google's anycast network: queries are served from a nearby POP, with no single point of failure.
Public zoneexample.comns-cloud-* authoritative name servers (not the 8.8.8.8 public resolver). Anyone can resolve the records.Private zoneinternal.example.comPublic Zones
A public zone is an authoritative DNS zone for a domain you own, visible on the public internet. You delegate the domain to Google's name servers (the four ns-cloud-*.googledomains.com servers Cloud DNS assigns to the zone) and manage records in the Cloud DNS API or console. Records support the usual types: A, AAAA, CNAME, MX, TXT, SRV, CAA, and so on. Manage public zones through infrastructure-as-code from day one — manual record edits in a DNS console are a recurring source of outages.
Private Zones
A private zone is visible only to VMs in the VPCs you authorize. Use private zones for everything internal: service discovery hostnames, database endpoints, internal load balancer DNS names. Never expose internal hostnames in public DNS — public DNS is enumerable, and the service-naming scheme alone reveals architectural details to anyone curious. Private zones cost essentially the same as public zones and are the correct default for internal resolution.
DNS Forwarding and Hybrid Resolution
DNS Forwarding lets Cloud DNS forward queries to specific resolvers — typically on-prem DNS servers when a hybrid setup has internal names served from the corporate network. The reverse pattern (on-prem clients resolving Google-internal names) uses inbound forwarding through a Cloud DNS forwarder address. Both directions need to be configured explicitly; "I can resolve from cloud but not from on-prem" almost always means the inbound path was forgotten.
Routing Policies
Cloud DNS Routing Policies attach to a record and serve different answers based on the query context. Four types:
- Weighted — split traffic among multiple answers by configurable weight; the basis for blue-green and canary releases.
- Geolocation — return different answers based on the resolving client's geographic region; the basis for serving users from their nearest region.
- Failover (primary/backup) — return the primary answer when its health check passes, otherwise the backup; the basis for active-passive multi-region.
- Health-checked — pull answers out of rotation when their attached health check fails, no manual intervention required.
DNSSEC and Operational Concerns
DNSSEC signs records so resolving clients can verify they were not tampered with in transit. Enable it on every public zone — the operational cost is near zero, and the absence of DNSSEC is a finding in most security audits. Key rotation is handled automatically by Cloud DNS in the standard configuration. The one operational concern: parent-zone DS record updates must happen via the registrar; misalignment between zone signing and registrar DS records breaks resolution entirely.
- Editing public DNS records manually in the console — there is no audit trail of intent, and every change is a deploy with no review.
- Putting internal hostnames in public DNS — service names leak architectural information to anyone running enumeration.
- No DNS-based failover when active-passive multi-region is the intended posture — discovering the failover plan does not exist during an actual incident.
- DNSSEC disabled on public zones — easy to enable, hard to justify leaving off.
- Configuring DNS Forwarding in only one direction in a hybrid setup — cloud-to-on-prem works, on-prem-to-cloud silently fails.
- High TTLs (hours) on records that participate in failover — the cache lag becomes the actual recovery time.
- Manage all zones through Terraform or Pulumi from day one. DNS records belong in source control.
- Private zones for everything internal. The public DNS surface should contain only externally-facing records.
- Enable DNSSEC on every public zone. Verify the registrar DS records match.
- Use routing policies (geo, failover, weighted) for multi-region availability and progressive rollouts.
- Configure DNS Forwarding in both directions when integrating with on-prem.
- Short TTLs (30 to 60 seconds) on records that participate in health-checked routing; longer TTLs on stable records.
Knowledge Check
When should you use a Cloud DNS private zone instead of a public zone?
- When the zone holds fewer than 100 records, since public zones are billed per record above that threshold while private zones are flat-rate
- For any hostnames that should be visible only to workloads inside specific VPCs, so internal names do not leak into enumerable public DNS
- When DNSSEC is not needed; private zones are the only zones that support DNSSEC
- When you need a 100% SLA; public zones do not include the SLA guarantee
Which Cloud DNS Routing Policy is the basis for active-passive multi-region failover?
- Weighted routing
- Geolocation routing
- Failover (primary/backup) routing
- Latency-based routing — Cloud DNS routes to the lowest-latency endpoint automatically
Why enable DNSSEC on public zones?
- DNSSEC encrypts DNS query traffic to prevent eavesdropping by intermediate resolvers
- DNSSEC signs records so resolving clients can verify they were not tampered with in transit; operational cost is near zero
- DNSSEC is a prerequisite for creating private zones, since Cloud DNS signs internal records before attaching them to a VPC
- DNSSEC enables faster global propagation of record changes by pre-signing zone updates and pushing them to Google's edge resolvers ahead of TTL expiry
A hybrid setup has DNS Forwarding configured from Cloud DNS to on-prem, but on-prem clients cannot resolve cloud-internal names. What is the typical cause?
- DNSSEC validation on the internal cloud zone is rejecting the forwarded queries before on-prem clients can resolve the names
- The reverse path — inbound forwarding from on-prem to a Cloud DNS forwarder address — was not configured
- Private zones cannot be resolved from outside the VPC under any configuration
- TTLs on cloud records are too long, so on-prem caches stale answers
Why set short TTLs on records that participate in health-checked routing?
- Short TTLs reduce Cloud DNS query billing
- When Cloud DNS pulls a failed endpoint out of rotation, the change does not take effect until cached entries expire — the TTL is effectively the recovery time
- DNSSEC requires TTLs under 60 seconds for signature validity
- The health-check probes themselves only fire as often as the record TTL allows, so a long TTL throttles how frequently Cloud DNS can detect that an endpoint has failed
You got correct