Professional Cloud Network Engineer
Cloud DNS provides mechanisms for enabling name resolution across multiple projects and VPC networks, primarily through DNS peering and forwarding configurations. These capabilities allow organizations to resolve private DNS zones hosted in one project from resources located in another project, supporting multi-project architectures while maintaining logical network isolation.
DNS peering is a configuration that allows a DNS consumer network to forward DNS queries to a DNS producer network for resolution. When a DNS consumer network peers with a DNS producer network, Google Cloud resources in the consumer network can look up records in the peering zone’s namespace as if those resources were located in the producer network itself. The DNS producer network performs the actual DNS lookups against its managed private zones, forwarding zones, Compute Engine internal DNS names, or any alternative name servers configured through an outbound server policy.
DNS peering has several important characteristics that architects must understand. First, it is a one-way relationship—the consumer can query the producer, but the producer cannot automatically resolve names from the consumer. Second, both the DNS producer and consumer networks must be VPC networks, though they can belong to the same organization or different organizations. Third, while DNS peering and VPC Network Peering are related concepts, they are distinct services; VPC Network Peering does not automatically share DNS information, so DNS peering must be configured separately even when VPC Peering is in use. Finally, transitive DNS peering is supported but limited to a single transitive hop, meaning no more than three VPC networks can be involved in a peering chain—for example, network A can peer with network B, and network B can peer with network C, but network A cannot directly resolve names from network C without explicit configuration.
To implement DNS peering, you create a peering zone in the consumer VPC network that targets the producer VPC network. The peering zone specifies the DNS namespace that should be forwarded to the producer, and the consumer network must be authorized to access that namespace. When configuring peering zones, architects should consider that if the target is a forwarding zone and global dynamic routing is disabled on the producer VPC, the producer VPC must contain a VM, VLAN attachment, or Cloud VPN tunnel in the same region as the source VM using the peering zone. This regional colocation requirement ensures that DNS queries traverse the expected network path and avoid latency or connectivity issues.
When designing DNS architectures that span multiple projects, there are two primary patterns to consider. The first pattern uses DNS peering directly, where each consumer project creates a peering zone pointing to the producer project’s VPC network. This approach works well when consumer projects need to resolve a specific set of zones hosted in the producer project, and it provides clear isolation between projects since the peering relationship must be explicitly established. The second pattern involves using forwarding zones in the producer project, where the producer project configures forwarding zones to forward queries for specific DNS suffixes to on-premises DNS servers or other VPC networks; consumer projects then peer to the producer to leverage these forwarding configurations.
For organizations using Shared VPC, the client VM and the VM associated with an internal DNS record can be located in separate projects but must use the same Shared VPC network. Clients must issue fully qualified domain name (FQDN) queries for internal DNS records rather than relying on partial queries and DNS search domains, because DNS search domains differ between projects. This requirement stems from the fact that the domain name portion of each internal DNS A record contains the project ID of the project containing the VM, and whether zonal or global internal DNS names are used depends on the configuration of the project that contains the VM.
Managing DNS across projects requires appropriate IAM roles to control who can create and modify DNS zones, policies, and peering relationships. The DNS Administrator role (roles/dns.admin) provides full control over DNS resources within a project, while the DNS Reader role (roles/dns.reader) provides read-only access. For cross-project scenarios, organizations should consider using organization-level policies to enforce DNS settings consistently and service accounts when configuring automated DNS operations. Service accounts used for DNS operations require the appropriate DNS roles granted on the target projects, and architects should follow the principle of least privilege when assigning these permissions.
When implementing cross-project DNS resolution, organizations should also consider enabling DNSSEC (Domain Name System Security Extensions) to authenticate DNS responses and prevent attackers from manipulating or poisoning DNS queries. DNSSEC can be enabled at the DNS zone level, the top-level domain level, and the DNS resolution level, providing defense in depth for DNS infrastructure.
Cloud DNS provides managed name resolution services that allow resources across different networks and environments to communicate securely. Organizations configure DNS peering to share private namespace lookups across separate networks without combining network traffic paths. Applying server policies, routing configurations, and security extensions ensures DNS queries resolve reliably while protecting name resolution infrastructure from tampering.
Cloud DNS peering is a one-way relationship that allows a DNS consumer network to forward name resolution queries to a DNS producer network. Resources in the consumer network resolve names using the producer network’s private zones, forwarding zones, Compute Engine internal DNS names, and alternative name servers defined by outbound policies. Peering operates purely at the DNS control plane and does not require VPC Network Peering for IP connectivity. Google Cloud supports peering across different organizations as well as transitive peering through a single intermediate hop across a maximum of three Virtual Private Cloud (VPC) networks.
DNS server policies define the rules for handling incoming queries from external networks and outgoing queries to designated name servers. An inbound server policy assigns entry-point IP addresses within a VPC network so on-premises clients can forward queries to Cloud DNS over Cloud VPN or Cloud Interconnect. When Cloud DNS forwards queries to target name servers in a VPC network or on-premises environment, it originates requests from the source range 35.199.192.0/19. Target virtual machines and local firewalls must include ingress allow rules for TCP and UDP port 53 traffic coming from this 35.199.192.0/19 range.
DNS routing policies govern how Cloud DNS distributes traffic across backend endpoints based on health, weights, or geography. Administrators can configure weighted round-robin policies to balance traffic by ratio, geolocation policies to route users to the closest region, or failover policies to provide disaster recovery. Failover configurations route queries to primary health-checked internal load balancers and shift traffic to backup geolocation targets if the primary endpoints fail. Routing policies also support trickle traffic to evaluate backup systems continuously and geofencing to prevent queries from leaving a designated geographic region during regional outages.
DNS security controls protect name resolution against cache poisoning and enforce organizational reliability standards. Enabling Domain Name System Security Extensions (DNSSEC) across private or public zones, top-level domains, and resolvers ensures query responses are authenticated and have not been altered. Organization policies enhance isolation by enforcing constraints like compute.setNewProjectDefaultToZonalDNSOnly to restrict internal DNS registration failure domains. To override automatically generated internal PTR records for private RFC 1918 IP addresses, administrators must configure reverse lookup zones with specific subnets such as 10.in-addr.arpa. or 168.192.in-addr.arpa..
Troubleshooting and validating cross-project DNS resolution involves diagnosing failures in DNS peering and binding configurations, tracing query flows using logs, and ensuring end-to-end name resolution works across projects and hybrid environments. This process focuses on identifying where DNS queries fail when resources in one project need to resolve names hosted in another project’s private DNS zones.
A common resolution failure in cross-project DNS occurs when a query from a DNS consumer network cannot reach the records in a DNS producer network’s private zone. The failure can stem from misconfigured DNS peering zones, network connectivity issues, or incorrect firewall rules. To diagnose this, you must first verify that the DNS peering relationship is correctly established: a peering zone in the consumer network must target the producer network, and the producer network must have a private zone shared with the consumer network. If queries fail intermittently from some nodes, the issue might be related to underlying network paths or node-specific firewall rules blocking UDP port 53. A key troubleshooting step is to run a Connectivity Test from the problematic source (a Pod or node) to the destination (the kube-dns Pod IP or the DNS server’s IP) to identify packet loss or blocked ports.
Cloud Logging and DNS query logs are essential for tracing the flow of a DNS query across project boundaries. You enable DNS logging in your DNS server policy and then reproduce the issue. A successful query that traverses a peering zone will generate a log entry with resource.type="dns_query" and specific labels indicating the flow. For example, a log entry might show "source_type": "peering-zone" and "target_type": "forwarding-zone", confirming the query passed from the consumer’s peering zone to the producer’s forwarding zone. If the logs show no such entries, the query may be failing before reaching the Cloud DNS infrastructure, pointing to a client-side or network configuration problem. You can also check for changes to upstream DNS servers or stub domains in your cluster by querying logs with specific filters for the kube-dns container.
Validating end-to-end resolution requires testing from a client in the consumer network to a fully qualified domain name (FQDN) hosted in the producer’s private zone. The validation must account for the VPC name resolution order: the client’s query first checks for private zones attached to its local network, then proceeds through peering zones, forwarding zones, and finally to alternative name servers. To validate, use a tool like dig from a test instance within the consumer VPC network. Ensure the query uses the FQDN, not a shortened name, because DNS search domains differ per project, especially in Shared VPC environments. If the FQDN resolves correctly, the cross-project DNS binding or peering is functioning. If resolution fails, you must verify each step in the resolution chain: the peering zone’s target network, the producer zone’s sharing settings, and any firewall rules that must allow traffic from the 35.199.192.0/19 range to reach on-premises DNS servers.
Some resolution failures are caused not by Cloud DNS but by client-side behaviors or network connectivity. For instance, if DNS queries fail intermittently with timeouts, the root cause could be an overloaded kube-dns Pod or a misconfigured ndots setting in a Pod’s /etc/resolv.conf file, which causes unnecessary search domain queries. Adjusting ndots to 1 or appending a dot to the queried domain can resolve this. Furthermore, if the DNS server is on-premises, you must ensure firewall rules allow connections from the Cloud DNS forwarder IP range. For issues with Google Cloud APIs or other non-DNS connections, consider client-side factors like TCP connection resets from stateful firewalls using iptables or the need to implement exponential backoff for 429 responses.
StudyCerts
StudyCerts35.199.192.0/19; firewalls must allow TCP and UDP port 53 from this range.DNS peering is a separate configuration that shares DNS namespace resolution between VPC networks, while VPC Network Peering provides IP connectivity. Even when VPC Network Peering is established, DNS information is not automatically shared; you must configure DNS peering separately.
Use direct DNS peering when consumer projects need to resolve a specific set of zones hosted in the producer project, providing clear isolation. Use forwarding zones in the producer project when consumer projects need to leverage forwarding configurations to on-premises DNS servers or other VPC networks, and then peer to the producer to access those forwarded names.
Enable DNS logging in your DNS server policy, reproduce the issue, and inspect Cloud Logging entries with resource.type="dns_query". Look for labels such as "source_type": "peering-zone" and "target_type": "forwarding-zone" to confirm the query path. If no logs appear, the failure likely occurs before reaching Cloud DNS, indicating a client-side or network problem.
Prepare and test your skills
Prepare and test your skills