Professional Cloud Network Engineer
Google Cloud DNS for Google Kubernetes Engine (GKE) is a managed service that provides name resolution for Pods and Services without the operational overhead of running in-cluster DNS servers. In GKE Autopilot clusters, Cloud DNS is enabled by default, while in GKE Standard clusters, administrators can choose Cloud DNS during cluster creation or via an update. The service automatically creates standard A, AAAA, SRV, and PTR records inside private managed DNS zones and response policy zones to follow Kubernetes DNS specifications.
The Cloud DNS architecture in GKE separates control plane record management from local query resolution on the node data plane. In the GKE control plane, the clouddns-controller Pod monitors the Kubernetes API server for changes to Services and Pods and synchronizes those changes into a managed private zone. DNS PTR records used for reverse lookups are handled through response policy rules. When a workload Pod initiates a query, the lookup path follows the nameserver listed in the Pod's configuration file:
StudyCerts
StudyCerts169.254.20.10.169.254.169.254.Cloud DNS resolution scopes define the network boundary across which Kubernetes Service names can be discovered and resolved. GKE provides three distinct scopes based on the reachability requirements of the application:
svc.cluster.local. The controller creates one private zone and one response policy zone per Compute Engine zone in the region.In a Shared VPC topology, Cloud DNS for GKE provisions managed private DNS zones directly within the service project that hosts the GKE cluster. The GKE service account requires no permissions in the host project for forward lookups because both the cluster and its private zone stay inside the service project boundary. For clusters using VPC scope across multiple service projects attached to the same Shared VPC, the controller places a shared response policy zone in the host project. This centralized response policy zone allows all connected clusters across different service projects to share reverse lookup capabilities.
Cloud DNS for GKE supports custom stub domains and upstream servers configured in the cluster kube-dns ConfigMap on GKE Standard clusters. The clouddns-controller reads the stubDomains entries and translates each one into a dedicated Cloud DNS forwarding zone. If administrators define upstreamNameservers, the controller generates a root-level forwarding zone targeting those IPs. Unlike traditional in-cluster DNS where custom configurations apply only to Pod network namespaces, Cloud DNS forwarding rules apply uniformly to all nodes and Pods in the cluster.
Migrating an existing GKE Standard cluster between kube-dns and Cloud DNS requires specific version requirements and a phased rollout across node pools. VPC scope requires GKE version 1.19 or later, cluster scope requires version 1.24.7-gke.800 or 1.25.3-gke.700 or later, and additive VPC scope requires version 1.28 or later. When modifying the cluster DNS provider, administrators must update the control plane first and then recreate or upgrade all node pools so existing nodes and Pods update their nameserver settings. Sizing considerations require planning for managed zone capacity, which supports a maximum size of 50 MB (roughly 2,000,000 records), and headless Services, which support up to 3,500 IPv4 endpoints and 2,000 IPv6 endpoints per record set.
Hybrid DNS resolution connects Google Cloud resources and on-premises environments so that systems in both locations can resolve each other's domain names. This design relies on Cloud DNS to host cloud records and uses on-premises DNS servers for local enterprise domains. Bidirectional resolution allows workloads to communicate seamlessly without requiring administrators to duplicate records across environments manually.
A hybrid DNS architecture maintains two authoritative DNS systems: Cloud DNS for cloud domains and local DNS servers for on-premises domains. For bidirectional lookups to succeed, each DNS system forwards unfamiliar domain queries to the opposite environment. This pattern allows organizations to keep existing on-premises DNS infrastructure while leveraging Cloud DNS logging, monitoring, and scaling in Google Cloud. Hosting all records on one side or the other is often impractical due to increased query latency and dependencies on constant network connectivity.
DNS forwarding routes queries for specific domain names across network boundaries between Google Cloud and external environments. In Google Cloud, administrators configure a Cloud DNS forwarding zone that points to the IP addresses of the on-premises DNS servers. For the reverse path, administrators create an inbound DNS server policy inside the connected VPC network to assign inbound forwarder IP addresses. On-premises DNS servers are then configured with conditional forwarders that direct queries for cloud domains to these inbound forwarder addresses.
GKE clusters integrate into hybrid DNS architectures by using Cloud DNS as the cluster DNS provider instead of kube-dns. When Cloud DNS is enabled, custom stub domains configured in the cluster ConfigMap are translated into Cloud DNS forwarding zones that point to external resolvers. These forwarding configurations automatically apply to both Pods and cluster nodes, ensuring consistent resolution behavior across the entire workload footprint. Workloads can resolve on-premises records using these translated rules, while on-premises clients can resolve GKE Services when the cluster is configured with VPC scope.
DNS peering links multiple VPC networks together so that one VPC network can resolve private DNS zones hosted in another VPC network. DNS peering is unidirectional: a consumer VPC network forwards DNS requests for a specific zone to a producer VPC network that hosts the authoritative private zone. In a hub-and-spoke architecture, spoke VPCs peer their internal zones to a central hub project to simplify routing. This setup allows resources to resolve internal domain names across project boundaries without requiring full VPC Network Peering for data traffic.
In Shared VPC deployments, hosting private DNS zones in the host project allows all attached service projects to access common records centrally. A centralized DNS hub project often acts as the single point of contact for forwarding queries between Google Cloud and on-premises environments. When running multiple GKE clusters with VPC scope across different service projects, clusters can share a single host VPC network. Migrating existing clusters in this topology requires ensuring the response policy zone resides in the host project to maintain reverse lookup capabilities for all connected workloads.
Implementing hybrid DNS requires an ordered set of network and routing configurations across both environments. First, network firewall rules must permit UDP and TCP traffic on port 53 between the network endpoints. Second, Cloud Router must advertise the Cloud DNS inbound forwarder subnet 35.199.192.0/19 to the on-premises network via Border Gateway Protocol (BGP). Third, administrators create the required private zones, forwarding zones, and inbound server policies in Cloud DNS. Finally, local on-premises DNS servers are configured to forward cloud-bound queries to the assigned inbound forwarder addresses.
Optimizing in-cluster DNS resolution improves application response times and protects cluster networking from packet loss during high query volumes. By default, GKE uses kube-dns pods to resolve cluster-internal service names and forward external lookups. Deploying a node-level caching layer prevents heavy DNS query patterns from overwhelming network tables or adding latency to inter-service communication.
The default GKE DNS architecture routes all Pod name lookups through a centralized kube-dns service deployment. When an application Pod needs to resolve a domain, it sends a query across the virtual container network to the kube-dns Service IP address. Kube-dns replica pods process the request and return the corresponding Service IP or forward the query to external resolvers. Because every lookup must travel across the container network, high query volumes can introduce latency and consume significant network bandwidth.
NodeLocal DNSCache is an optional add-on that runs a caching agent as a DaemonSet instance on every node in the GKE cluster. The DaemonSet pod listens on a dedicated link-local IP address (169.254.20.10), and Pods on that node are configured to use this address as their primary nameserver. Caching responses directly on the node eliminates the network hops required to reach central kube-dns pods. This architecture ensures that frequently queried domain names are resolved locally with minimal processing delay.
NodeLocal DNSCache reduces query latency by serving DNS responses directly from the local node operating system memory. When a Pod issues a DNS lookup, the query reaches the local cache instance first; if the record exists within its Time to Live (TTL) period, the cache returns the IP immediately. This eliminates the latency introduced by routing packets through cluster switches and intermediate Service endpoints. Microservice architectures that perform frequent HTTP or gRPC requests benefit significantly from these shortened lookup times.
The Linux kernel uses a connection tracking (conntrack) table to monitor active network connections, and every DNS query routed across the network consumes a table entry. Under heavy traffic, simultaneous DNS lookups from hundreds of Pods can fill the conntrack table completely, causing the node to drop network packets and drop connections. NodeLocal DNSCache resolves this issue by handling most queries locally on the node using a loopback link, which bypasses conntrack table insertion. Only cache misses trigger network connections to upstream DNS servers, drastically reducing conntrack utilization and preventing table saturation.
DNS queries primarily use User Datagram Protocol (UDP), but they automatically switch to Transmission Control Protocol (TCP) when response payloads exceed standard size limits. NodeLocal DNSCache listens on both UDP and TCP ports and handles the protocol conversion when necessary. If an upstream DNS response is truncated over UDP, the local cache retries the query over TCP to retrieve the complete record set. This process ensures reliable delivery for large DNS records without requiring application code changes.
NodeLocal DNSCache works as an intermediate caching layer alongside kube-dns and Cloud DNS rather than replacing them entirely. When a local cache miss occurs, the NodeLocal DNSCache instance forwards the query upstream to kube-dns for internal service records or to Cloud DNS for external resolution. Kube-dns resolves internal cluster names and passes public queries to Cloud DNS, which handles authoritative resolution for cloud infrastructure and internet domains. This tiered setup maximizes cache hit rates on the node while maintaining full support for cluster-wide and hybrid naming rules.
Deploying NodeLocal DNSCache involves enabling the feature at the cluster level during creation or through an in-place cluster update. Once enabled, GKE automatically rolls out the DaemonSet pods to all existing and new worker nodes in the cluster. The deployment configuration automatically programs the upstream DNS service addresses and creates custom stub domain rules when specified. The DaemonSet manages the lifecycle of local cache instances automatically as nodes scale up or down across the cluster.
169.254.20.10 to serve cached DNS queries locally, bypassing the Linux kernel conntrack table for cache hits.35.199.192.0/19 over BGP.kube-dns ConfigMap are translated by Cloud DNS into dedicated forwarding zones that apply to both cluster nodes and Pods.Cluster scope restricts domain name resolution for Kubernetes Services strictly to workloads running inside the same cluster using the svc.cluster.local domain. VPC scope makes Service domain names resolvable across the entire VPC network, allowing Compute Engine VMs, other clusters, and connected on-premises systems to resolve GKE Services directly.
Standard DNS queries across the container network create entries in the Linux kernel connection tracking (conntrack) table, which can fill up and drop packets during high query volumes. NodeLocal DNSCache serves requests directly on the local node over a link-local address without creating conntrack entries, forwarding traffic over the network only when a cache miss occurs.
On-premises systems resolve cloud domain names by configuring conditional DNS forwarders that point to Google Cloud inbound forwarder IP addresses created by a Cloud DNS inbound server policy. For the network path to work, Cloud Router must advertise the 35.199.192.0/19 inbound forwarder address range to the on-premises network using BGP, and firewall rules must permit UDP and TCP traffic on port 53.
Prepare and test your skills
Prepare and test your skills