DNS Management in Google Cloud: Cloud DNS, DNSSEC, Private Zones

DNS Management in Google Cloud: Cloud DNS, DNSSEC, Private Zones

We had a client come to us with a problem: after migrating to GCP, some internal services stopped resolving, and certain domains were leaking to the internet. It turned out that DNS zones were created as public, even though they should have been private. We restructured the architecture in one day, eliminating security risks and unnecessary costs.

Cloud DNS is not just about moving a zone to GCP. It's a managed anycast DNS service with 100% SLA, integration with IAM, support for DNSSEC, and private zones for internal routing. The question is whether everything is configured correctly. We set up DNS in GCP turnkey: from simple zones to hybrid topologies with forwarding and split-horizon.

How Cloud DNS Solves DNS Leakage in Hybrid Networks

One of the most common mistakes is a public zone for an internal domain like internal.company.com. This creates a risk of DNS query leakage and unnecessary costs. The correct solution is a private zone, which resolves only within a VPC or via Cloud VPN/Interconnect.

Creating a private zone via gcloud:

gcloud dns managed-zones create internal-zone \
    --dns-name="internal.company.com." \
    --description="Internal services zone" \
    --visibility=private \
    --networks=projects/my-project/global/networks/default

For a public zone with DNSSEC:

gcloud dns managed-zones create public-zone \
    --dns-name="company.com." \
    --description="Public zone" \
    --visibility=public \
    --dnssec-state=on

After enabling DNSSEC, you must transfer the DS records to your registrar — without this, DNSSEC will not work and the zone will be validated as unsigned.

Why Use Terraform for DNS Zone Management?

Manually creating records in the GCP Console leads to drift between reality and documentation. We keep everything in Terraform:

resource "google_dns_managed_zone" "public" {
  name        = "company-public"
  dns_name    = "company.com."
  description = "Public DNS zone"

  dnssec_config {
    state = "on"
  }
}

resource "google_dns_record_set" "api" {
  name         = "api.company.com."
  managed_zone = google_dns_managed_zone.public.name
  type         = "A"
  ttl          = 300
  rrdatas      = [google_compute_global_address.lb.address]
}

resource "google_dns_record_set" "mx" {
  name         = "company.com."
  managed_zone = google_dns_managed_zone.public.name
  type         = "MX"
  ttl          = 3600
  rrdatas      = ["10 aspmx.l.google.com.", "20 alt1.aspmx.l.google.com."]
}

For A records pointing to load balancers with frequently changing backends, we keep TTLs at 60–300 seconds. For MX and NS, we use 3600+.

Comparison of Public and Private Zones

Split-Horizon DNS for Hybrid Environments

If you have Cloud VPN or Interconnect to on-premise, you need a split-horizon configuration: the same domain resolves differently from outside and inside the VPC. Cloud DNS supports this through forwarding zones:

gcloud dns managed-zones create onprem-forward \
  --dns-name="corp.internal." \
  --visibility=private \
  --networks=projects/my-project/global/networks/vpn-network \
  --forwarding-targets=10.0.0.53

Requests to *.corp.internal will be forwarded to the corporate DNS server 10.0.0.53 via the VPN tunnel.

DNS Monitoring: What to Track?

For production environments, it's critical to set up DNS query monitoring via Cloud Monitoring. Recommended metrics: number of queries per minute, error percentage (NXDOMAIN, SERVFAIL), response latency. If a threshold is exceeded (e.g., >5% errors), an alert triggers. 100% SLA on Cloud DNS is not a panacea — incorrect zone configuration can lead to service unavailability. Therefore, we also set up dashboards in Grafana with Loki for logging zone changes.

Disaster Recovery for DNS

DNS redundancy includes creating backup zones and secondary DNS via gcloud dns managed-zones create with --visibility=public and a separate managed zone. In case of failure, we automatically switch traffic to the backup zone. We test failover every 6 months.

What's Included in Cloud DNS Setup?

• Audit of current DNS infrastructure — identify zones, records, dependencies.
• Architecture design — determine private/public zones, DNSSEC, split-horizon.
• Implementation via IaC — Terraform or Pulumi with code review.
• Migration with service preservation — zero-downtime by gradually reducing TTL.
• Documentation — DNS schema, zone descriptions, team instructions.
• Engineer training — working with Cloud DNS, typical scenarios.
• Post-release support — 2 weeks of monitoring and adjustments.

Workflow

1. Analysis — obtain GCP access, study current network, Kubernetes, CI/CD.
2. Design — create DNS zone schema, define IAM roles and policies.
3. Implementation — write Terraform modules, deploy in test environment.
4. Testing — verify resolution from VPC, from internet, DNSSEC validation.
5. Deployment — apply to production with canary deployment.
6. Monitoring — set up alerts for DNS errors (e.g., via Cloud Monitoring).

Timeline and Cost

Estimated timeline: from 2 hours for a simple public zone to 3 days for a complex hybrid topology with fragmented zones and DNSSEC. Cost is calculated individually — depends on the number of zones, records, and integrations. We'll evaluate your project, contact us!

Common Mistakes and Checklist

• DNSSEC not enabled — zone remains unsigned, attacks possible.
• Private domain published — created a public zone for internal.company.com.
• Forgot about TTL — clients get old IP for a long time after change.
• No monitoring — DNS failure can go unnoticed until incident.
• Same TTL for all records — best to differentiate: 60-300s for A records with LB, 3600+ for MX, 86400 for NS.

We have configured DNS for projects with over 1 million queries per day. Our experience: 10+ years in GCP, certified Google Cloud Architects. We guarantee 100% SLA on Cloud DNS response time. Get a consultation — contact us!