Understanding DNS private and public zones and setting up split-horizon DNS.

Cloud DNS Managed Zones are containers for DNS records that share the same DNS name suffix. The main difference between public and private zones is who can see them. A public managed zone makes its records resolvable from anywhere on the internet. You use it to publish services like websites. For a domain to resolve publicly, you must update your domain registrar's settings to point to the name servers Google Cloud DNS provides for the zone. Public zones also support DNSSEC, which adds a layer of security by digitally signing the DNS records.

A private managed zone is different because its records are only visible from specific Virtual Private Cloud (VPC) networks that you authorize. This keeps internal DNS data, like private IP addresses for your backend services, secure and hidden from the internet. Private zones do not support DNSSEC. You control access through VPC binding, which is the process of listing which VPC networks are allowed to query the zone. You set this list when you create the zone and can update it later.

In more complex setups, you might use a Shared VPC, where one project (the host) owns the network and other projects (service projects) use it. Through cross-project binding, a service project can create a private DNS zone and authorize it for the host project's shared network. This lets VMs in the shared network resolve the service project's internal records. The service project needs permission to create zones, and the host project must grant permission to bind to its network.

Split-horizon DNS is an architecture that uses both zone types together. You create two zones with the same name (like example.com)—one public and one private. Internet clients querying the name get the public IP address from the public zone. Meanwhile, clients inside your authorized VPC networks query the same name and get a private IP address from the private zone. This lets internal and external users use the same domain name to reach the appropriate endpoint for their network location.

Cloud DNS has rules to manage situations where multiple zones could answer a query, especially when namespaces overlap. The service uses resolution precedence to decide which answer to give. Generally, the most specific match wins. For example, a query from a VM inside a VPC will get an answer from a private zone bound to that VPC, even if a public zone with the same domain exists. This prevents conflicts and ensures internal clients reach the correct, private resources.

For resolution across different VPCs or to on-premises networks, Cloud DNS uses features like DNS peering and forwarding. A DNS peering zone allows one VPC to forward queries for a specific domain to another VPC's DNS resolver. This enables seamless name resolution between VPCs without merging networks. For hybrid connections, an inbound server policy allows on-premises systems to resolve private zones inside a Google Cloud VPC. Queries from on-premises travel over a Cloud VPN or Cloud Interconnect link to a regional entry point IP in the VPC.

Within Google Kubernetes Engine (GKE), you can use cluster-scoped DNS. This isolates service name resolution to a single GKE cluster, so identical service names in different clusters don't conflict. You can bind a private zone directly to a GKE cluster, and queries from that cluster will check its cluster-scoped zone before looking at VPC-scoped zones. Administrators can also enforce zonal DNS via an organization policy, which isolates DNS registration issues to individual compute zones for better reliability.

Designing a split-horizon DNS setup involves creating coordinated public and private zones to provide different answers based on the client's origin. The goal is for internal VPC clients to resolve to private IP addresses while external internet clients resolve to public endpoints, all using the same domain name. This requires careful planning of the query resolution path to ensure consistent service availability.

The first step is creating the two managed zones with the same DNS name. In the public zone, you add records that point to public IP addresses, like those of a global load balancer. In the private zone, you add records for the same names but point them to internal private IP addresses. You then bind the private zone to the VPC networks where your internal workloads run. The key relationship is that for any query coming from an authorized VPC, the private zone's record takes precedence over the public zone's record.

Zone visibility and network authorization are critical. For private zones in a Shared VPC setup, you use cross-project binding to authorize the host project's network. This allows VMs in the shared network to resolve the private records, supporting hub-and-spoke architectures without complex workarounds. The order of resolution is also important: for a GKE cluster, Cloud DNS checks cluster-scoped zones first, then VPC-scoped zones, and finally public zones.

To extend this pattern to hybrid environments, you can use DNS forwarding zones or inbound server policies. A forwarding zone directs queries for a specific domain to your on-premises DNS servers, allowing cloud resources to resolve internal on-premises names. Conversely, an inbound server policy lets on-premises clients resolve records in your cloud private zones. This two-way resolution ensures that all parts of a hybrid application can connect using consistent domain names, regardless of where the workload runs.

Key Facts

• A public Cloud DNS managed zone is resolvable from the internet and supports DNSSEC, while a private zone is only resolvable from explicitly authorized VPC networks and does not support DNSSEC.
• Split-horizon DNS uses separate public and private zones with the same domain name to provide different IP addresses (public or private) to clients based on whether their query originates from the internet or an authorized internal network.
• VPC binding authorizes specific VPC networks to query a private zone, and in a Shared VPC environment, cross-project binding allows a service project's private zone to be used by the host project's shared network.
• For queries from authorized VPCs, records in a bound private zone take precedence over records in a public zone of the same name, ensuring internal clients reach private endpoints.
• Cloud DNS supports cluster-scoped DNS for GKE, isolating name resolution to a specific cluster, and uses features like DNS peering zones and inbound server policies to enable cross-VPC and hybrid on-premises resolution.