GCP Cloud DNS: Managed Zones, DNSSEC, and Routing Policies

You've spent hours debugging a production outage, only to find it was a DNS misconfiguration. A stale record, a missing DNSSEC signature, or a routing policy that sent 50% of traffic to a dead backend. DNS is the silent killer of reliability. GCP Cloud DNS gives you the tools to avoid these pitfalls—if you know how to use them. This isn't a tutorial on DNS basics; it's a deep dive into managed zones, DNSSEC, and routing policies, with production patterns that keep your services available.

Managed Zones: Public vs Private

A managed zone is a container for DNS records. Public zones serve records to the internet; private zones are visible only within your VPC networks. The critical distinction: private zones can be shared across VPCs using peering, but they don't support DNSSEC. Always use private zones for internal service discovery—never expose internal hostnames publicly. For hybrid cloud, use forwarding zones to resolve on-premises DNS. A common mistake is creating a public zone for internal use, which leaks internal IPs. Instead, create a private zone and attach it to your VPC. You can also use a private zone with a custom domain for Kubernetes services, avoiding the default svc.cluster.local.

gcloud dns managed-zones create my-private-zone \
  --dns-name="internal.example.com" \
  --description="Private zone for internal services" \
  --visibility=private \
  --networks="https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default"

DNSSEC: Signing Your Zone

DNSSEC protects against DNS spoofing by cryptographically signing records. GCP Cloud DNS supports DNSSEC for public zones only. When enabled, Cloud DNS automatically generates a Zone Signing Key (ZSK) and a Key Signing Key (KSK). You must publish the DS record to your registrar. The biggest gotcha: DNSSEC adds overhead. Each signed response is larger, and misconfiguration can cause resolution failures. Always test in a staging zone first. Use dnssec-tools to verify signatures. If you're using a CDN or third-party DNS, ensure they support DNSSEC. A common failure: forgetting to update DS records after key rotation. Cloud DNS handles key rotation automatically, but you must update the DS record at your registrar.

gcloud dns managed-zones update my-public-zone \
  --dnssec-state=on \
  --ksk-algorithm=rsasha256 \
  --zsk-algorithm=rsasha256 \
  --denial-of-existence=nsect3 \
  --ksk-key-length=2048 \
  --zsk-key-length=1024

Routing Policies: Simple vs Weighted

Routing policies control how DNS queries are answered. Simple routing returns all records; weighted routing distributes traffic based on weights. Use weighted routing for canary deployments or A/B testing. The weight is relative—if you have two records with weights 1 and 1, each gets 50%. But DNS caching can skew results. Clients may cache the response for the TTL, so a canary might not see immediate traffic shift. Always set low TTLs (e.g., 60 seconds) during canary phases. A production pattern: use weighted routing with a health check. Cloud DNS does not natively health-check backends; you must use an external health checker or a load balancer. Combine weighted routing with a global load balancer for active-passive failover.

gcloud dns record-sets create canary.example.com \
  --zone=my-public-zone \
  --type=A \
  --ttl=60 \
  --routing-policy-type=WRR \
  --routing-policy-data="1.2.3.4=1;5.6.7.8=9"

Routing Policies: Geolocation and Failover

Geolocation routing answers based on the requester's region. Use it to direct users to the nearest backend for low latency. Failover routing lets you specify primary and secondary targets. Combine both for a global active-passive setup. The key: geolocation routing requires a default record for unmatched regions. Without it, queries from unmapped regions get no answer. Failover routing uses health checks—if the primary is unhealthy, DNS returns the secondary. But DNS failover is slow (TTL-dependent). For fast failover, use a load balancer with health checks. Cloud DNS failover is best for disaster recovery where minutes of downtime are acceptable.

gcloud dns record-sets create www.example.com \
  --zone=my-public-zone \
  --type=A \
  --ttl=300 \
  --routing-policy-type=GEO \
  --routing-policy-data="us-east1=1.2.3.4;us-west1=5.6.7.8;*=9.10.11.12" \
  --backup-data-type=TRICKLE \
  --backup-data="13.14.15.16"

Private DNS with Peering and Forwarding

Private zones can be shared across VPCs using DNS peering. This allows service discovery across projects. Forwarding zones send queries for specific domains to on-premises DNS servers. Use peering for GCP-to-GCP resolution; use forwarding for hybrid cloud. The gotcha: peering is unidirectional—you must create a peering zone in each VPC that needs resolution. Forwarding zones require a target DNS server IP and can use private or external IPs. For security, use private IPs for on-premises DNS over VPN or Interconnect. A common mistake: creating a peering zone but forgetting to add the source VPC network. Always verify with dig from a VM.

gcloud dns managed-zones create peer-zone \
  --dns-name="shared.internal.example.com" \
  --description="Peering zone for shared services" \
  --visibility=private \
  --networks="https://www.googleapis.com/compute/v1/projects/project-a/global/networks/vpc-a" \
  --peering-network="https://www.googleapis.com/compute/v1/projects/project-b/global/networks/vpc-b"

Automating DNS with Terraform

Manual DNS changes are error-prone. Use Terraform to manage zones and records as code. The google_dns_managed_zone and google_dns_record_set resources are straightforward. But watch out for dependencies: Terraform may try to delete a zone that still has records. Use lifecycle blocks to prevent accidental deletion. Also, DNSSEC is tricky to automate because the DS record must be published externally. Consider using a null resource to trigger a script that updates the registrar. For routing policies, Terraform supports routing_policy blocks. Always store state remotely and use version control.

resource "google_dns_managed_zone" "prod" {
  name        = "prod-zone"
  dns_name    = "prod.example.com."
  description = "Production DNS zone"
  visibility  = "public"
  dnssec_config {
    state         = "on"
    non_existence = "nsec3"
  }
}

resource "google_dns_record_set" "www" {
  name         = "www.prod.example.com."
  managed_zone = google_dns_managed_zone.prod.name
  type         = "A"
  ttl          = 300
  routing_policy {
    wrr {
      weight = 1
      rrdatas = ["1.2.3.4"]
    }
    wrr {
      weight = 9
      rrdatas = ["5.6.7.8"]
    }
  }
}

Monitoring and Auditing DNS

Cloud DNS logs queries to Cloud Logging if you enable logging. Use this to audit who is resolving what. But beware: logging costs money and can generate huge volumes. Enable it only for critical zones or during incidents. Set up metrics-based alerts for query volume spikes, which may indicate a DDoS or misconfiguration. Also, monitor DNSSEC validation failures. Use Cloud Monitoring to create dashboards. A production pattern: log all DNS changes via Cloud Audit Logs. This helps with compliance and troubleshooting. For private zones, log queries to detect unexpected resolution attempts.

gcloud dns managed-zones update my-public-zone \
  --log-dns-queries

Common Pitfalls and How to Avoid Them

1. TTL too high: During changes, high TTLs cause slow propagation. Always lower TTL before planned changes. 2. Missing DS record: DNSSEC breaks if DS record is missing. Automate DS record updates. 3. Private zone not attached: A private zone without VPC attachment is useless. Verify with gcloud dns managed-zones describe. 4. Routing policy without health checks: DNS failover is blind without health checks. Use external health checkers. 5. Zone deletion with records: You cannot delete a zone that has records. Use gcloud dns record-sets list to check. 6. Overlapping zones: If you have both public and private zones for the same domain, private takes precedence for VPC queries. This can cause confusion.

gcloud dns record-sets list --zone=my-public-zone --format="table(name,type,ttl,rrdatas)"

Disaster Recovery with DNS

DNS is critical for DR. Use failover routing to switch to a secondary region. But DNS failover is slow (minutes). For faster failover, use a global load balancer with health checks. Combine DNS with Cloud DNS for authoritative DNS and a load balancer for traffic. Test your DR plan regularly. A common mistake: forgetting to update DNS records after a failover test. Automate failover with scripts or Terraform. Also, consider using multiple DNS providers for redundancy. GCP Cloud DNS supports zone transfers (AXFR) to secondary DNS providers.

# Simulate failover by updating the failover routing policy
# Change primary to secondary IP
gcloud dns record-sets update www.example.com \
  --zone=my-public-zone \
  --routing-policy-type=FAILOVER \
  --routing-policy-data="primary=1.2.3.4;secondary=5.6.7.8" \
  --health-check="https://www.googleapis.com/compute/v1/projects/my-project/global/healthChecks/my-hc"

Cost Optimization

Cloud DNS pricing is based on the number of zones and queries. Public zones cost $0.20 per zone per month; private zones are $0.20 as well. Queries are $0.40 per million. DNSSEC adds no extra cost. To optimize, consolidate zones where possible. Use wildcard records to reduce record count. For high-volume domains, consider using Cloud DNS with a CDN to cache responses. Also, use private zones for internal traffic to avoid public query costs. Monitor query volume with Cloud Monitoring and set budgets.

# Estimate monthly cost for 10 zones and 10 million queries
# Zones: 10 * $0.20 = $2.00
# Queries: 10,000,000 * $0.40 / 1,000,000 = $4.00
# Total: $6.00/month

Security Best Practices

1. Enable DNSSEC for all public zones. 2. Use IAM roles to restrict DNS changes. 3. Enable audit logging for DNS changes. 4. Use private zones for internal services. 5. Avoid exposing internal IPs in public records. 6. Regularly rotate DNSSEC keys (Cloud DNS does this automatically). 7. Use VPC Service Controls to restrict DNS access. 8. Monitor for DNS tunneling. 9. Use Cloud Armor with DNS to mitigate DDoS. 10. Keep TTLs low for critical records. A common security issue: using default IAM roles that allow anyone in the project to modify DNS. Use custom roles with least privilege.

gcloud projects add-iam-policy-binding my-project \
  --member="user:admin@example.com" \
  --role="roles/dns.admin"