How to Set Up Cloud DNS | Managed Zones, Records, and Domain Delegation

What Cloud DNS actually is

Cloud DNS is GCP’s managed authoritative DNS service. You give it a domain name, create records inside it, and it answers DNS queries for that domain on Google’s global infrastructure. You do not manage DNS server software or worry about availability.

Before you look at commands, three terms are worth understanding clearly:

• Managed zone: the container that holds all the DNS records for one domain. If you own example.com, you create one zone for it. If you also own myapp.io, that is a separate zone.
• DNS record: an entry inside a zone that maps a name to something useful. An A record maps www.example.com to an IP address. An MX record tells email servers where to deliver mail for that domain.
• Delegation: the step where you tell your domain registrar to stop answering DNS queries for your domain and hand that authority to Cloud DNS. You do this by updating the name server addresses in your registrar’s control panel.

Public zones serve records to anyone on the internet. Private zones only resolve inside your GCP VPC. This page covers public zone setup. If you are trying to give internal services readable names inside a VPC, see Private DNS Zones instead.

For a broader explanation of how GCP’s DNS layers fit together, see DNS in GCP.

How Cloud DNS setup works, from start to finish

The full setup flow for a public domain has five stages:

1. Enable the Cloud DNS API in your GCP project. This only needs to happen once.
2. Create a public managed zone for your domain. GCP assigns four name server addresses to the zone.
3. Add your DNS records to the zone: A records for your web server, MX records for email, TXT records for verification, and so on.
4. Update your domain registrar to use Cloud DNS’s name servers. This is the delegation step. It tells the internet that Cloud DNS is now authoritative for your domain.
5. Wait for propagation and verify. Changes can take up to 48 hours to spread to all resolvers worldwide, though in practice it is usually much faster.

When to use this

Cloud DNS is the right choice when you are doing any of the following:

• Moving a domain’s DNS management into GCP so it lives alongside your infrastructure
• Setting up records for a load balancer, Cloud Run service, or GCP-hosted website
• Managing email records (MX, SPF, DKIM) for a domain your organisation owns
• Adding verification TXT records required by Google Workspace, domain validation, or third-party services
• Using Terraform to keep your DNS records in version control alongside other infrastructure
• Setting up SSL certificates that require DNS-based domain ownership verification

If your goal is resolving internal service names inside a VPC (for example, giving a database a human-readable hostname), you do not need a public zone. See Private DNS Zones for that setup.

Step 1: Enable Cloud DNS

Cloud DNS is a GCP API that must be enabled before you can create zones or records. If you have already created any DNS resources in the Console, it is already enabled.

# Enable the Cloud DNS API
gcloud services enable dns.googleapis.com

# Confirm it is enabled
gcloud services list --enabled --filter="name:dns.googleapis.com"

Step 2: Create a public managed zone

A managed zone is the container for all the records belonging to your domain. Create one zone per domain. The —dns-name value must include the trailing dot. This must be a fully qualified domain name.

# Create a public managed zone for example.com
gcloud dns managed-zones create example-com-zone \
  --dns-name=example.com. \
  --description="Public zone for example.com" \
  --visibility=public

# Get the four name servers GCP assigned to this zone
gcloud dns managed-zones describe example-com-zone \
  --format="get(nameServers)"

The output will be four addresses in the format ns-cloud-XX.googledomains.com.. Copy all four. You will need them for the delegation step.

Step 3: Delegate your domain at the registrar

Log in to wherever you bought your domain (GoDaddy, Namecheap, Google Domains, Cloudflare, or any other registrar). Find the nameserver settings for your domain, usually under a label like “DNS”, “Nameservers”, or “Domain settings”. Replace whatever nameservers are listed there with the four Cloud DNS nameservers from the previous step.

A few things to be aware of:

• You are replacing the registrar’s nameservers entirely, not adding records. DNS record management moves to Cloud DNS once this is done.
• Do this after you have added your critical DNS records to Cloud DNS. Email records (MX) are particularly important. If they are missing during the switchover, email delivery will fail.
• Delegation can take up to 48 hours to propagate globally. Plan any domain migrations for a low-traffic period.

Step 4: Add your DNS records

With the zone created, you can add records. The most common types are A (IPv4 address), CNAME (alias to another name), MX (email routing), and TXT (verification and policy records). Note the trailing dot on all fully qualified domain names. Cloud DNS requires it.

# Create an A record pointing www.example.com to an IP address
gcloud dns record-sets create www.example.com. \
  --zone=example-com-zone \
  --type=A \
  --ttl=300 \
  --rrdatas=203.0.113.10

# Create a CNAME aliasing blog.example.com to a storage bucket
gcloud dns record-sets create blog.example.com. \
  --zone=example-com-zone \
  --type=CNAME \
  --ttl=300 \
  --rrdatas=my-bucket.storage.googleapis.com.

# Create MX records for Google Workspace email
gcloud dns record-sets create example.com. \
  --zone=example-com-zone \
  --type=MX \
  --ttl=3600 \
  --rrdatas="1 aspmx.l.google.com.,5 alt1.aspmx.l.google.com.,5 alt2.aspmx.l.google.com."

# Create a TXT record for SPF email policy
gcloud dns record-sets create example.com. \
  --zone=example-com-zone \
  --type=TXT \
  --ttl=300 \
  --rrdatas='"v=spf1 include:_spf.google.com ~all"'

# List all records in the zone to review what exists
gcloud dns record-sets list --zone=example-com-zone

If you are setting up records to point to a GCP load balancer, the A record will use the load balancer’s external IP. See HTTP Load Balancer Setup for how to reserve and retrieve that IP address.

Step 5: Make batch changes safely with transactions

When you need to update several records at once, for example removing old records and adding new ones as part of a migration, transactions let you stage all the changes together and apply them atomically. If any record in the transaction fails validation, none of the changes are applied.

# Start a transaction
gcloud dns record-sets transaction start --zone=example-com-zone

# Stage the changes: remove an old record and add a new one
gcloud dns record-sets transaction remove "203.0.113.10" \
  --zone=example-com-zone \
  --name=www.example.com. \
  --type=A \
  --ttl=300

gcloud dns record-sets transaction add "203.0.113.20" \
  --zone=example-com-zone \
  --name=www.example.com. \
  --type=A \
  --ttl=300

# Also add a new subdomain in the same transaction
gcloud dns record-sets transaction add "203.0.113.20" \
  --zone=example-com-zone \
  --name=api.example.com. \
  --type=A \
  --ttl=300

# Review what the transaction will do before committing
gcloud dns record-sets transaction describe --zone=example-com-zone

# Apply all changes at once
gcloud dns record-sets transaction execute --zone=example-com-zone

# If you want to cancel instead:
# gcloud dns record-sets transaction abort --zone=example-com-zone

Transactions are particularly useful when updating records that depend on each other, such as removing a CNAME and replacing it with an A record. That cannot be done as two separate operations because the zone would temporarily be invalid between them.

Step 6: Manage Cloud DNS with Terraform

For any environment beyond a quick test, managing DNS records via Terraform is worth the setup cost. Your DNS configuration lives in version control alongside the rest of your infrastructure, changes go through code review, and you can reproduce the entire zone from scratch if needed.

# Create the managed zone
resource "google_dns_managed_zone" "example" {
  name        = "example-com-zone"
  dns_name    = "example.com."
  description = "Public zone for example.com"
  visibility  = "public"
}

# A record for the www subdomain
resource "google_dns_record_set" "www" {
  name         = "www.${google_dns_managed_zone.example.dns_name}"
  managed_zone = google_dns_managed_zone.example.name
  type         = "A"
  ttl          = 300
  rrdatas      = ["203.0.113.10"]
}

# MX records for email
resource "google_dns_record_set" "mx" {
  name         = google_dns_managed_zone.example.dns_name
  managed_zone = google_dns_managed_zone.example.name
  type         = "MX"
  ttl          = 3600
  rrdatas = [
    "1 aspmx.l.google.com.",
    "5 alt1.aspmx.l.google.com.",
  ]
}

See Infrastructure as Code in GCP for a broader look at managing GCP resources through Terraform, including state management and workspace conventions.

Step 7: Verify that everything is working

After adding records and updating delegation, verify at the authoritative level before testing through your local resolver. Your local resolver might have cached old records from before the change.

# Query Cloud DNS directly to confirm the record exists at the authoritative source
# Replace ns-cloud-c1.googledomains.com with one of the nameservers from your zone
dig @ns-cloud-c1.googledomains.com. www.example.com A

# Check that delegation is working by tracing the full resolution path
dig +trace example.com NS

# Test from inside a GCP VM (uses the VPC resolver, confirms routing from GCP's perspective)
gcloud compute ssh test-vm \
  --zone=europe-west1-b \
  --tunnel-through-iap \
  --command="dig www.example.com A"

The dig +trace command shows the full resolution chain from the root servers down to Cloud DNS. If the chain ends at Google’s name servers, delegation is complete. If you hit DNS issues that are harder to diagnose, see Troubleshooting Network Issues for a structured debugging process.

Public zones vs private zones

Cloud DNS supports two zone types. The difference matters because using the wrong one causes problems that are frustrating to debug.

• Public zones are authoritative for records on the public internet. Anyone can query them. Use these for domains your users or external services need to reach: websites, APIs, email servers, and domain verification records.
• Private zones are only resolvable from within the VPCs you specify. External resolvers cannot see them. Use these for internal service names, database hostnames, or any name that should not be visible outside your network.

See Private DNS Zones for the full setup guide, including DNS peering and on-premises forwarding. For the full picture of how public and private zones interact with the VPC resolver, see DNS in GCP.