What Cloud DNS Provides
Cloud DNS is Google's managed authoritative DNS service, letting you publish DNS zones and records that are served from Google's global anycast network of name servers, meaning a query for your domain gets answered by whichever Google DNS edge location is closest to the asker, typically in milliseconds. Cloud DNS supports both public zones, which answer queries from anywhere on the internet, and private zones, which only resolve for VPCs you explicitly associate with the zone, letting internal services use friendly hostnames like db.internal.corp without exposing those records publicly.
Cricket analogy: This is like a cricket board's official website publishing match schedules from servers positioned near fans worldwide, so an Indian fan and an Australian fan both get the fixture list back in milliseconds.
Zones, Records, and Record Types
A managed zone in Cloud DNS represents authority over a specific DNS namespace, such as example.com, and contains the actual resource records: A records mapping a hostname to an IPv4 address, AAAA records for IPv6, CNAME records aliasing one hostname to another, MX records for mail routing, and TXT records commonly used for domain verification or SPF/DKIM email authentication. Each record set has a TTL (time to live) that controls how long resolvers are permitted to cache the answer before re-querying, and lowering the TTL before a planned change, like a load balancer IP migration, is a standard practice to reduce propagation delay.
Cricket analogy: This is like a scorecard listing every player's specific role, batter, bowler, or all-rounder, with each entry cached in fans' memory only until the next official team-sheet update is published.
DNSSEC and Delegation
Cloud DNS supports DNSSEC (Domain Name System Security Extensions), which cryptographically signs zone data so resolvers can verify that answers haven't been tampered with in transit, protecting against cache-poisoning and spoofing attacks; enabling it on a managed zone requires publishing a DS record with your domain registrar to establish the chain of trust from the parent zone. Delegation works by the parent zone, like the .com registry, publishing NS records that point to Cloud DNS's name servers for your specific domain, which is why after creating a managed zone you must update your domain registrar's nameserver settings to match the ones Cloud DNS assigns.
Cricket analogy: This is like a match referee's decision being cryptographically confirmed by the third umpire's review system, so no one downstream can dispute or tamper with the final given-out call.
# Create a public managed zone for example.com
gcloud dns managed-zones create example-public-zone \
--dns-name=example.com. \
--description="Public zone for example.com" \
--visibility=public
# Add an A record pointing app.example.com to the load balancer's IP
gcloud dns record-sets create app.example.com. \
--zone=example-public-zone \
--type=A \
--ttl=300 \
--rrdatas=203.0.113.10
# List the assigned Cloud DNS name servers to configure at your registrar
gcloud dns managed-zones describe example-public-zone --format="value(nameServers)"Cloud DNS private zones can be associated with multiple VPCs, and Google also offers DNS peering, which lets one VPC's private zone resolve names defined in another VPC's private zone, and forwarding zones, which route specific domain queries to an on-premises DNS server over Cloud VPN or Interconnect.
Lowering a record's TTL must happen well before a planned change, not at the moment of the change, because existing resolvers may have already cached the old TTL value and won't re-check until it expires. A common mistake is changing the IP and the TTL simultaneously, which does nothing to speed up propagation for clients that cached the record under the previous, longer TTL.
- Cloud DNS is Google's managed, authoritative DNS service served from a global anycast name server network.
- Public zones answer queries from anywhere on the internet; private zones only resolve for explicitly associated VPCs.
- Common record types include A, AAAA, CNAME, MX, and TXT, each with a TTL controlling resolver caching duration.
- Lower TTLs before a planned IP change to reduce propagation delay; changing TTL and IP simultaneously doesn't help already-cached clients.
- DNSSEC cryptographically signs zone data to protect against cache-poisoning and spoofing, requiring a DS record at the registrar.
- Delegation requires updating your domain registrar's nameserver records to match the ones Cloud DNS assigns to your managed zone.
- DNS peering and forwarding zones extend private zones across VPCs or to on-premises DNS servers.
Practice what you learned
1. What is the key difference between a public and a private managed zone in Cloud DNS?
2. What does a record's TTL (time to live) control?
3. Why is it a common mistake to lower a record's TTL at the same moment you change its value?
4. What must you publish at your domain registrar to complete the DNSSEC chain of trust for a Cloud DNS zone?
5. What does DNS delegation to Cloud DNS require at the domain registrar?
Was this page helpful?
You May Also Like
Cloud Load Balancing Basics
Learn how GCP's fully managed, globally distributed load balancers route traffic to healthy backends, and the key differences between global, regional, external, and internal load balancer types.
VPC Networks in GCP
Understand how Google Cloud's Virtual Private Cloud works as a global, software-defined network spanning regional subnets, and how VPC Peering and Shared VPC connect and centralize networks across projects.
Cloud CDN Basics
Learn how Cloud CDN caches content at Google's global edge locations by attaching to a load balancer's backend, how cache keys and cache modes control what gets cached, and how invalidation and signed URLs work.