Cloud DNS

Introduction to Cloud DNS

Cloud DNS is Google Cloud's managed authoritative Domain Name System (DNS) service. It hosts your zones on Google's anycast nameservers, propagates changes within seconds, and provides a 100 percent availability service-level objective for public DNS queries. The PCNE exam treats Cloud DNS as the connective tissue that ties together VPCs, hybrid links, load balancers, and identity-aware proxies, so every Professional Cloud Network Engineer is expected to know not only what records to create but also which zone type, routing policy, and resolution flow fits each scenario.

This study note walks through every zone type Cloud DNS supports, the records each zone can hold, how DNSSEC and response policies harden the resolution path, and how routing policies turn a DNS answer into a traffic-engineering primitive. Concrete gcloud dns commands and resolution-order rules appear throughout because the exam frequently asks "which DNS server receives this query first" rather than abstract trivia.

白話文解釋（Plain English Explanation）

Before mapping every Cloud DNS feature to a gcloud flag, three concrete pictures make the moving parts click.

Think of Cloud DNS Like the Front Desk of a Large Office Tower

A visitor walks into the lobby of a 60-floor office tower and asks the concierge where "Acme Legal" sits. The concierge looks up the tenant directory and answers "floor 23, suite B". If the visitor instead asks for a tenant inside the private executive floor, the concierge phones the executive-floor receptionist who keeps a separate, unlisted directory. Cloud DNS plays both roles. A public managed zone is the public-facing concierge anyone on the internet can ask. A private managed zone is the executive-floor receptionist, only reachable from inside the building (your VPC). A forwarding zone is the concierge picking up the phone and calling an external directory (your on-premises DNS) when a guest asks about a tenant the building does not know. A peering zone is the concierge passing the question to the concierge of a sister building across the road, because the two buildings share a tenant list.

Think of DNSSEC Like a Wax Seal on a Royal Decree

In medieval times a king sent decrees across the kingdom, and the recipient verified authenticity by checking the wax seal pressed with the king's signet ring. An imposter could write a fake decree but could not forge the seal without the ring. DNSSEC works the same way. The zone owner signs each record set with a private key, and resolvers verify the signature against a published public key. An attacker who poisons a cache with a fake answer cannot forge the signature, so the resolver rejects the response. Without DNSSEC, a forged answer for your-bank.example flips through the resolution chain undetected and points clients at an attacker's IP. On Cloud DNS, flipping a single boolean on a public zone turns this protection on.

Think of DNS Routing Policies Like a Receptionist Who Answers Differently Based on Who Is Calling

A multinational law firm has one phone number that connects callers to different offices based on the caller's location. A caller from Tokyo gets routed to the Tokyo office; a caller from Frankfurt gets routed to Frankfurt. If Tokyo is shut for a holiday, calls failover to Singapore. If the firm wants to A/B test a new associate intake, ten percent of calls route to the new junior team. Cloud DNS routing policies do exactly this at the DNS layer. Instead of returning one fixed IP for api.example.com, the geo policy returns a regional IP, the failover policy returns a backup IP when the primary is unhealthy, and the weighted round-robin policy splits traffic by percentage. The client never sees the logic; it just resolves the name and gets a different answer depending on context.

Core Concepts of Cloud DNS

Several terms recur across the Cloud DNS console, the PCNE exam, and the gcloud dns command surface. Knowing them precisely matters.

Managed Zone

A managed zone is the top-level container that holds a single DNS namespace such as example.com. Each zone has a visibility (public or private), a DNS name (the trailing dot is mandatory in the API), and a list of authoritative nameservers Google assigns at creation. A project can hold many zones, and zones can overlap on name as long as their visibility differs (one public, one private with the same DNS name) — that is the basis of split-horizon DNS.

Record Set

A record set is a group of records sharing the same name, type, and TTL. The standard types Cloud DNS supports include A (IPv4 address), AAAA (IPv6 address), CNAME (canonical name alias), MX (mail exchange), TXT (free-form text, often SPF / DKIM / verification), SRV (service discovery for SIP / Kerberos / Autodiscover), CAA (certificate authority authorization), NS (nameserver delegation), PTR (reverse pointer), SOA (start of authority), and SPF. Record sets can be a plain list of values or a routing policy that returns different values based on geography or health.

Resolution Order Inside a VPC

When a VM in a VPC issues a DNS query, the metadata server 169.254.169.254 (or metadata.google.internal) hands it off through a strict resolution order: first Google's internal DNS for *.internal and *.google.internal, then any Cloud DNS private zones authorized for the VPC, then any DNS server policy forwarders or response policy rules, and finally Google's public resolver if nothing matched. Misordering expectations here is the single most common trap on the PCNE.

DNS Server Policy

A server policy attaches to a VPC network (not to a zone) and changes how the metadata resolver behaves. An inbound server policy reserves an internal IP in each region of the VPC that on-premises resolvers can hit to look up Cloud DNS private zones. An outbound server policy forwards every unmatched query to a list of alternative name servers, bypassing Google Public DNS for whatever is not handled by the private zones.

Routing Policy

A routing policy turns a single record set into a smart record. Cloud DNS supports four routing policy types: weighted round-robin (split traffic by percentage), geolocation (return different IPs based on the originating region), failover (return primary IPs while healthy, backup IPs when primary fails health checks), and the newest addition, geo-fenced routing with multiple-answer responses. Routing policies require a health check for failover and use the EDNS Client Subnet extension for geolocation.

Public Managed Zones

A public managed zone makes your domain resolvable from anywhere on the internet. You create the zone, copy the four nameservers Google assigns (ns-cloud-{a,b,c,d}1.googledomains.com.) into your registrar, and Cloud DNS starts answering authoritatively within seconds.

Creating a Public Zone

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

The --dnssec-state=on flag enables DNSSEC signing immediately at zone creation, which is the preferred path because retro-fitting DNSSEC requires careful DS-record rollover at the registrar.

Anycast Nameservers

Each public zone is served from Google's global anycast nameserver fleet — the four ns-cloud-* names resolve to the same IPs from anywhere in the world, but BGP steers the query to the nearest Google point of presence. The result is sub-50 ms resolution latency for most clients and resilience against regional outages: if one PoP goes dark, the anycast announcement withdraws and the next-nearest PoP picks up the queries without any DNS change.

Public Zone Record Types You Will Configure

A production public zone almost always contains:

• An A and / or AAAA record at the apex (example.com.) pointing to a load balancer IP.
• A CNAME for www.example.com. pointing back to the apex (or a separate A if your provider does not let you CNAME the apex).
• MX records pointing to Google Workspace or another mail provider, plus TXT records carrying SPF (v=spf1 include:_spf.google.com ~all), DKIM, and DMARC policies.
• CAA records (0 issue "letsencrypt.org") restricting which CAs may issue certificates for the domain. The PCNE exam loves CAA because it is cheap insurance against mis-issued certs.
• Optional SRV records for SIP, XMPP, Kerberos, or Microsoft Exchange Autodiscover.

Private Managed Zones

A private managed zone is reachable only from VPC networks you authorize. Private zones do not require an apex constraint, do not appear in any public delegation, and resolve only inside Google Cloud — they will return NXDOMAIN to an external dig.

Authorizing VPCs

gcloud dns managed-zones create internal-services \
  --dns-name=svc.internal. \
  --description="Service discovery for prod" \
  --visibility=private \
  --networks=prod-vpc,shared-svc-vpc

The --networks flag lists every VPC allowed to resolve names from this zone. A VPC that is not on the list will not see the zone even if it is in the same project. You can add or remove networks later with gcloud dns managed-zones update.

Split-Horizon DNS

Split-horizon resolution returns different answers for the same name to internal versus external clients. The pattern on Cloud DNS is straightforward: create a public zone for example.com. with the customer-facing IPs, and create a private zone for example.com. authorized to your VPCs with internal IPs. When a VM inside the VPC resolves api.example.com, the private zone wins because private zones rank ahead of public zones in the metadata resolver's order. When an external client resolves the same name, only the public zone is reachable.

Cross-Project Bindings

Shared VPC topologies frequently host the private zone in the host project but want service projects to resolve it. As long as the service project's VMs run on the shared VPC, the binding works without any per-project zone copy. For non-shared cross-project resolution, you use DNS peering instead.

DNS Forwarding Zones and Server Policies

Hybrid connectivity requires bidirectional DNS: on-premises clients need to look up cloud names, and cloud workloads need to look up on-premises names.

Outbound Forwarding (Cloud → On-Prem)

A forwarding zone is a special private zone that, instead of holding records, holds a list of alternative name servers. When a VPC VM queries a name in the forwarding zone's DNS name, Cloud DNS proxies the query to the listed servers via your Cloud VPN or Cloud Interconnect.

gcloud dns managed-zones create onprem-corp \
  --dns-name=corp.example.internal. \
  --visibility=private \
  --networks=prod-vpc \
  --forwarding-targets=10.10.0.53,10.10.0.54

The forwarders must be reachable over RFC 1918 space across the hybrid link. Cloud DNS sources the egress query from the 35.199.192.0/19 block, which you must permit on your on-premises firewall and route back over the VPN / Interconnect.

Inbound Server Policy (On-Prem → Cloud)

An inbound server policy attaches to a VPC and reserves a regional internal IP in each subnet's region that on-premises resolvers can target.

gcloud dns policies create allow-inbound \
  --networks=prod-vpc \
  --enable-inbound-forwarding \
  --description="Allow on-prem to query private zones"

After creation, gcloud dns policies describe lists the regional IPs. The on-premises BIND or Windows DNS forwards everything for the cloud's private domain to those IPs.

Forwarding Modes: Standard vs Private

The forwarding flow has two transport modes. Standard mode sends queries over the public internet to forwarder IPs (rare). Private mode sends them over the VPC's RFC 1918 reachability via Cloud VPN, Cloud Interconnect, or Network Connectivity Center. The PCNE will sometimes present a scenario where a forwarder is "behind" the VPN — only private mode works there.

DNS Peering Zones

DNS peering lets one VPC reuse another VPC's name resolution without copying records. The consumer VPC creates a peering zone that points at the producer VPC; queries that match the peering zone's DNS name are answered using the producer VPC's full resolution order — including its private zones, forwarding zones, and Google internal DNS.

gcloud dns managed-zones create hub-services-peer \
  --dns-name=services.internal. \
  --visibility=private \
  --networks=spoke-vpc \
  --dns-peering-network=projects/HUB_PROJECT/global/networks/hub-vpc

This pattern underpins hub-and-spoke architectures where a single hub VPC owns the private zones, the forwarders to on-premises, and the response policies, while every spoke VPC peers in. Without DNS peering, every spoke would need its own copy of every zone, drifting over time.

Response Policy Zones (DNS Firewall)

A response policy zone (RPZ) is Cloud DNS's DNS-layer firewall. It overrides or blocks specific names before the resolver returns them to the client. Each policy attaches to one or more VPCs and contains rules that match a DNS name pattern and apply an action: rewrite to a different value, return NXDOMAIN, return a fixed IP, or passthrough.

Use Cases

The two dominant use cases on the PCNE are blocking malware C2 domains (return NXDOMAIN for known-bad hostnames) and overriding a public hostname with an internal IP (storage.googleapis.com → a Private Google Access endpoint). The override pattern lets you keep client SDKs unchanged while forcing traffic onto private connectivity.

gcloud dns response-policies create corp-rpz \
  --networks=prod-vpc \
  --description="Block known malware C2 + redirect GCS to PGA"

gcloud dns response-policies rules create block-c2 \
  --response-policy=corp-rpz \
  --dns-name="malware-c2.example." \
  --behavior=bypassResponsePolicy=false \
  --local-data='name=malware-c2.example.,type=A,ttl=60,rrdatas=0.0.0.0'

Resolution Order with RPZ

A response policy intercepts queries before any zone lookup. The order becomes: response policy → private zones (and peering / forwarding zones) → public zones → Google Public DNS. Knowing this order is exam-mandatory — a private zone for example.com. will lose to an RPZ rule that matches the same name.

DNSSEC on Cloud DNS

DNSSEC adds cryptographic signatures to DNS records so that resolvers can detect cache poisoning and on-path tampering.

Enabling DNSSEC

For a new zone:

gcloud dns managed-zones create example-public \
  --dns-name=example.com. \
  --visibility=public \
  --dnssec-state=on

For an existing zone, flip the state and Cloud DNS will sign all records and generate DNSKEY and RRSIG sets within minutes.

The DS Record Hand-Off

Enabling DNSSEC at Cloud DNS alone is not enough. You must publish the DS (Delegation Signer) record at your registrar so the parent zone (com., org., etc.) advertises that your zone is signed. Without the DS, validating resolvers see an unsigned delegation and ignore the RRSIGs entirely. Retrieve the DS values with gcloud dns dns-keys list --zone=example-public and paste them into the registrar UI.

Algorithm Choice

Cloud DNS supports RSASHA256, RSASHA512, and the elliptic-curve ECDSAP256SHA256 and ECDSAP384SHA384. ECDSAP256SHA256 is the recommended default — short signatures, fast verification, and broad resolver support. Stick with RSASHA256 only if you have an older resolver fleet that cannot validate ECDSA.

DNS Routing Policies

A routing policy turns a single record set into a traffic-engineering knob. The PCNE expects fluency in all four types.

Weighted Round-Robin

Each backend gets a non-negative integer weight. Cloud DNS returns IPs in proportion to the weights. A 90 / 10 split is the canonical pattern for canary deployments at the DNS layer.

gcloud dns record-sets create api.example.com. \
  --zone=example-public --type=A --ttl=60 \
  --routing-policy-type=WRR \
  --routing-policy-data="35.1.1.1=90;35.2.2.2=10"

Geolocation

The policy maps GCP regions or client subnets to IP sets. Clients in us-east1 receive the US backend; clients in asia-northeast1 receive the Tokyo backend. Cloud DNS uses the EDNS Client Subnet (ECS) extension to determine the client region; resolvers that strip ECS will fall through to the nearest configured region by Google's anycast attribution.

Failover

Failover combines a primary and a backup IP with a Cloud DNS health check (separate from load balancer health checks). While the primary passes health, Cloud DNS returns only the primary. When the primary fails, Cloud DNS returns the backup. The backup IP must be reachable but its own health is not checked.

Multi-Value (Public Routing)

The newest routing policy type, multi-value, returns up to 10 healthy IPs from a larger pool, randomizing the order. It is the closest Cloud DNS gets to a poor-man's load balancer for clients that do their own retry.

Internal DNS and the .internal Domain

Every GCE VM is automatically assigned two DNS names. The new-style name <vm-name>.<zone>.c.<project>.internal resolves from anywhere in the project's VPCs. The legacy zonal DNS name <vm-name>.c.<project>.internal exists only when the VPC uses zonal DNS. New projects default to global internal DNS, which is what the PCNE expects.

Why It Matters

The *.internal namespace is Google-managed and always wins resolution order — you cannot create a private zone for internal. to override it. If you need a custom internal hostname scheme (api.prod.svc.example.), put it in your own private zone with a different parent name, never under .internal.

DNS Names for Other Services

Several Google APIs publish private DNS names you can use through Private Google Access or Private Service Connect: storage.googleapis.com, bigquery.googleapis.com, compute.googleapis.com. Pair these with a response policy to override them to PGA endpoints (199.36.153.8/30 for restricted.googleapis.com).

BIND-Compatible Zone Files

Cloud DNS imports and exports zone files in standard BIND format, which simplifies migrating an existing zone from Route 53, on-premises BIND, or any other authoritative server.

Importing a Zone File

gcloud dns record-sets import example.zone \
  --zone=example-public \
  --zone-file-format

A typical BIND file contains an SOA record, NS records, and the bulk record set. Cloud DNS auto-generates SOA and NS records based on the assigned anycast nameservers, so import-time conflicts on SOA / NS are rewritten to Google's values.

Exporting a Zone File

gcloud dns record-sets export current.zone \
  --zone=example-public \
  --zone-file-format

The output is a valid BIND zone file, suitable for backup, audit, or migration. Pair this with version control to track every change.

Bulk Edits via Transactions

For atomic multi-record changes, use a transaction:

gcloud dns record-sets transaction start --zone=example-public
gcloud dns record-sets transaction add 35.1.1.1 --name=api.example.com. --ttl=60 --type=A --zone=example-public
gcloud dns record-sets transaction remove 35.0.0.1 --name=api.example.com. --ttl=60 --type=A --zone=example-public
gcloud dns record-sets transaction execute --zone=example-public

Transactions roll back cleanly on any single failure, which is the safe path for blue-green DNS cutovers.

Logging, IAM, and Operations

Cloud DNS integrates with Cloud Audit Logs and Cloud Logging for both control-plane and data-plane visibility.

Audit Logs

Every Create, Update, and Delete API call lands in the cloudaudit.googleapis.com/activity log. Use this stream to alert on unexpected record changes — an unplanned DELETE on the apex A record is an incident worth paging on.

Query Logging

For private zones, enable DNS query logging on the VPC policy. Each query a VM makes appears in dns.googleapis.com/dns_queries with the source IP, queried name, response code, and authoritative source. The data is invaluable for diagnosing why a workload "cannot resolve" a name — usually it queried the wrong namespace or hit a response policy.

IAM Roles

The roles you care about: roles/dns.admin (full read-write), roles/dns.reader (read all zones), and roles/dns.peer (allow another project's VPC to be the producer side of a peering zone). Granting roles/dns.admin at the project level is broad; for tighter blast radius, grant it on a specific managed zone.

FAQs

What is the difference between a forwarding zone and an outbound server policy?

A forwarding zone forwards queries for a specific DNS name (such as corp.example.internal.) to the configured forwarders. An outbound server policy forwards every unmatched query from the VPC to the configured forwarders, replacing Google Public DNS for fallthrough. Use a forwarding zone for surgical hybrid resolution; use an outbound server policy when on-premises is the authoritative source for everything.

Can I peer a private zone with a VPC in a different organization?

Yes, as long as the producer-side VPC grants the roles/dns.peer role on the network to the consumer project's service account. The consumer creates the peering zone pointing at the producer VPC, and resolution flows across the org boundary without VPC Network Peering.

Why does my DNSSEC-signed zone still get "insecure" responses?

Almost always because the DS record at the registrar is missing, stale, or points at a key Cloud DNS has already rotated. Re-run gcloud dns dns-keys list --zone=ZONE to get the current DS digest, paste it at the registrar, and wait for the parent zone's TTL to expire (usually 24 to 48 hours).

Does Cloud DNS support split-horizon for the same domain in the same project?

Yes. Create one public managed zone and one private managed zone with the same --dns-name. The private zone wins for VMs in authorized VPCs; the public zone serves the internet. The two zones hold independent record sets, so the same name can resolve to different IPs depending on the caller.

How do I block a malicious domain across every VPC in my organization?

Create a single response policy with rules that return NXDOMAIN for the target names, then attach the policy to every VPC that needs the protection. For organization-wide policies, automate the network attachment via Terraform or Cloud Asset Inventory so newly created VPCs inherit the same blocklist.

What is the TTL behaviour for routing policies?

Cloud DNS honours the TTL you set on the record set, but routing policies make TTL more consequential. A 300-second TTL on a failover policy means clients can be pinned to a failing IP for up to five minutes after the health check fails. Set TTLs to 30 to 60 seconds on routing-policy records and accept the higher query volume.