Cloud DNS and routing

Cloud DNS basics

Cloud DNS is a managed, authoritative DNS service with a 100% availability SLA for authoritative serving. Resources: managed zones that hold resource record sets, plus policies.

Other objects: DNS server policies (inbound and outbound forwarding, logging), response policies (override or block responses for specific names inside a VPC, a private-DNS firewall) and routing policies on record sets.

Resolution order inside a VPC

A VM sends queries to the metadata server 169.254.169.254. Cloud DNS answers in this order:

1. Response policy rules matching the name.
2. Private zones (including forwarding and peering zones) visible to the VPC, using the most specific matching suffix.
3. Compute Engine internal DNS (names like vm.zone.c.project.internal; zonal DNS is the default for new projects, global DNS is the legacy form).
4. The public internet (public zones and recursive resolution).

If an outbound server policy with alternative name servers is set, all queries (except those for .internal names) go to those servers instead of the order above; private zones in that VPC stop working, so use forwarding zones for selective forwarding instead.

Records, TTL and migration

• Common records: A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, SRV, CAA. A CNAME cannot coexist with other records at the same name; an apex cannot be a CNAME (use A/alias records or a load balancer IP).
• Migrating to Cloud DNS: export the existing zone to a BIND zone file and import it (gcloud dns record-sets import --zone-file-format), lower TTL on the old records ahead of the cutover, create the zone and test it by querying the Cloud DNS name servers directly, then update the NS records at the registrar (or delegating parent zone). Keep the old servers running until the old TTLs expire. For private zones, create the private zone and attach VPCs before removing the old resolver.
• Delegation: a subdomain can be delegated to a separate Cloud DNS zone with NS records in the parent.
• Zone and record changes are atomic transactions (gcloud dns record-sets transaction or create/update); changes propagate fast within Cloud DNS, but caching resolvers obey TTLs.

DNSSEC

• Applies to public zones. Enable on the zone to sign records with KSK and ZSK; Cloud DNS manages the keys and rotates ZSKs. Algorithms include RSASHA256 and ECDSAP256SHA256.
• After enabling, get the DS record from Cloud DNS and add it at the registrar (parent zone). The chain of trust only works when both are in place. If the DS exists but the zone is unsigned (or keys mismatch), validating resolvers return SERVFAIL.
• Transfers between providers: disable DNSSEC and wait for DS removal and TTL before moving, or coordinate key rollover.
• DNSSEC protects integrity (prevents spoofed answers), not confidentiality.

DNS routing policies

Routing policies are attached to a record set and decide which answer a query receives.

Cloud DNS health checks for failover read the load balancer’s own health status, so the failover target must be an internal load balancer forwarding rule. For global external failover, use a global external LB (which already fails over across regions) or an external health-checking DNS provider. Routing policy changes act at DNS level only, so caching bounds failover speed: keep TTLs low (30 to 60 s) for failover records.

DNS server policies and hybrid DNS

On-premises and Google Cloud need to resolve each other’s names. The building blocks:

• Outbound (cloud to on-premises): a forwarding zone for corp.example.com pointing at on-premises name servers. Targets with RFC 1918 addresses are reached through the VPC over VPN or Interconnect (type default); for private routing (--private-forwarding) Cloud DNS always sends via the VPC even for public-looking IPs. Cloud DNS originates these queries from 35.199.192.0/19, so on-premises firewalls must allow that range and on-premises routing must send replies back to it. Cloud Router must advertise 35.199.192.0/19 as a custom range.
• Inbound (on-premises to cloud): an inbound server policy on the VPC creates inbound forwarding entry points, one internal IP per region from your subnets. On-premises DNS servers forward queries for the cloud zones (for example gcp.example.com) to those IPs over VPN or Interconnect. Check the entry point addresses with gcloud compute addresses list --filter="purpose=DNS_RESOLVER".
• DNS peering: VPC A’s zone peers to VPC B so queries go through B’s resolution order, including B’s private zones and forwarding zones. It is not transitive (A can use B’s configuration, but B’s peering zones are not followed on A’s behalf), and the peering project needs the DNS Peer role on the producer project.
• Cross-project binding lets the project that owns the zone (for example a service project or a DNS project) authorize VPCs in other projects to see it without copying the zone, ideal in a Shared VPC with many service projects.

Typical hybrid DNS topologies

• Hub and spoke: put the forwarding zones and the inbound policy in a hub VPC that connects to on-premises. Each spoke creates peering zones pointing to the hub for on-premises domains, and the hub owns the private zones that all spokes need. On-premises only knows the hub’s inbound entry points.
• Centralized private zones with cross-project binding: a DNS project hosts private zones; each VPC binds to it.
• Split-horizon DNS: a public and a private zone with the same name. Inside the VPC the private zone wins and returns internal IPs; outside it, the public zone returns public IPs. The private zone must contain every record that internal clients need, because a match on the private zone means no fallback to the public zone for names missing in it (NXDOMAIN).
• Self-hosted DNS integration: run BIND or similar on-premises or on VMs as authoritative or recursive servers, with Cloud DNS forwarding to them for specific zones and on-premises forwarding the cloud zones back. Use alternative name servers in an outbound policy only when everything must flow through your resolvers.
• DNS logging: enable query logging on a VPC server policy; logs go to Cloud Logging for troubleshooting.

GKE and DNS

• kube-dns is the default in-cluster DNS; NodeLocal DNSCache runs a caching agent on each node to cut latency.
• Cloud DNS for GKE replaces kube-dns with Cloud DNS for Service and Pod names. Cluster scope keeps names inside the cluster; additive VPC scope also makes headless Service names resolvable from the VPC (VMs outside the cluster); VPC scope shares across clusters. Better scale and no kube-dns pods to tune.
• ExternalDNS (operator) watches Services, Ingresses and Gateways and creates or updates Cloud DNS records. Give it a service account with dns.admin (Workload Identity) and set --provider=google with the project and domain filters.

VPC routing

A route has a destination CIDR, a next hop, a priority (0 to 65535, lower wins) and optionally network tags. A packet picks the route with the longest prefix match first; if several routes have the same prefix, the lowest priority number wins; if still tied, traffic is ECMP spread.

Static routes in practice

• Network tags: a static route with tags applies only to instances having one of those tags. Use tags to send only some VMs to an appliance or through a given VPN. Dynamic and subnet routes cannot use tags.
• Priority lets you set primary and backup static routes to the same prefix (for example two VPN tunnels: priority 100 primary, 200 backup).
• Next hop types:
  • Instance (single VM with IP forwarding enabled, canIpForward).
  • Internal passthrough NLB (--next-hop-ilb) for highly available appliances. The LB must be in the same VPC, and traffic keeps the original source and destination IP. This is the recommended NVA pattern. The route can be used from peered VPCs if exported.
  • VPN tunnel (static or policy-based VPN).
  • Default internet gateway.
  • IP address of a VM.
• Dynamic routing mode (regional vs global) controls where the Cloud Router’s learned routes apply (see hybrid notes). With global, routes learned in one region are used in all, with a cost penalty added across regions.
• Overlapping prefix rule of thumb: a more specific route wins even with a worse priority number. Priority is only compared among equal-length prefixes.

Policy-based routing

Policy-based routes (PBR) are a more specific traffic steering tool:

• Match on source range, destination range, protocol and ports, optional tags (applied to VMs via network tags or interconnect attachments), priority (1 to 65535, lower first).
• Action: forward to an internal passthrough NLB (the appliance cluster) or skip the policy (fall back to regular routes).
• Evaluated before regular routes, so they override longest-prefix match. Use PBR to force traffic through a firewall NVA regardless of routes, to inspect only certain protocols, or to redirect traffic from on-premises via a VLAN attachment into an appliance.
• Typical combination: PBR for ingress from Interconnect into a multi-NIC NVA, static routes with ILB next hop for east-west.

Route exchange over peering

• Both subnet routes (including secondary ranges of subnets) are exchanged automatically unless you turn off export or import.
• Custom routes (static and dynamic) are exchanged only if the exporter enables --export-custom-routes and the importer enables --import-custom-routes. This is how spokes learn on-premises routes from a hub VPC that has the VPN. Only one hop: spokes do not pass those routes to each other.
• If the peer uses PUPI, enable import and export of subnet routes with public IPs.
• Peered VPCs do not share firewall rules, tags or service accounts.
• Peering conflicts: identical destination routes learned from two peers with equal prefix cause ambiguity; fewer, more specific ranges avoid it. Static routes with the same destination as an imported route: the local wins.

Network Connectivity Center (NCC)

NCC is a hub-and-spoke control plane that connects VPCs, hybrid links and appliances so routes propagate through the hub, solving peering’s non-transitivity.

Hub and spokes

A hub is a global resource in a project; spokes attach to it.

Topologies

• Mesh: all VPC spokes in the hub can reach each other (full connectivity through the hub). Default for VPC spokes.
• Star: spokes are placed in a center group or an edge group. Edge spokes can reach only center spokes, and not each other. Typical for a shared-services VPC that serves many isolated tenants, or a central inspection VPC with isolated workloads. Center spokes reach all edge spokes.
• Hub-and-spoke with hybrid: hybrid spokes in the hub enable on-premises to reach all VPC spokes, and site-to-site data transfer connects two sites over Google’s backbone.
• Groups (for example default, center, edge) tie spokes to a routing policy. A hub can have preset topologies (mesh or star).

Features and configuration

• Include and exclude IP range filters on VPC spokes control which subnet ranges are exported to the hub, so overlapping or unwanted ranges are blocked. Excluded or overlapping ranges don’t propagate; if a conflict exists the first-created route wins and the other is flagged.
• Private NAT with NCC translates overlapping ranges between spokes. PSC propagation lets Private Service Connect endpoints in one spoke be reachable by other spokes in the hub (propagated PSC connections), avoiding an endpoint per VPC.
• Router appliance setup: create the VM(s) with IP forwarding, create a router appliance spoke referencing the VM instances, and set up BGP between a Cloud Router (in the same VPC) and the appliance. Used to bring SD-WAN branch routes into Google Cloud.
• Monitoring and troubleshooting: check the hub route tables and each spoke’s state, active vs inactive routes and reasons (overlap, excluded, filtered), use Connectivity Tests and Network Analyzer from Network Intelligence Center, and NCC Cloud Logging (spoke state changes, route events). Typical failures: overlapping subnets, a spoke in the wrong group, missing custom advertisement on the Cloud Router, firewall rules, or exclude filters.
• Transitivity: if “spoke A cannot reach spoke B”: confirm both are in the same hub and group, that the topology allows it (star: edge to edge is blocked), that the ranges do not overlap, and that firewall rules in both VPCs allow it. If “on-premises cannot reach a peered VPC”: peering does not carry routes into NCC; make that VPC a spoke or advertise its ranges via custom advertisement on the hybrid Cloud Router.