Cross-project binding is a Cloud DNS feature that allows each service project to create and manage its own DNS zones while binding those zones to a Shared VPC network owned by a host project. This approach provides better autonomy for service project administrators and creates a more precise permission boundary for DNS zone administration without requiring the creation of placeholder VPC networks. When cross-project binding is enabled, all DNS zones become directly associated with the Shared VPC network, enabling any-to-any DNS resolution where any virtual machine in the Shared VPC network can resolve names from the associated zones.
Cross-project binding eliminates the transitive hop limit that exists in traditional DNS peering architectures, making it suitable for hub-and-spoke network designs where DNS resolution must traverse multiple network segments. Host project administrators no longer need to manage DNS configurations for service projects, while Identity and Access Management (IAM) roles continue to apply at the project level, maintaining security boundaries. This binding is particularly valuable in organizations with multiple teams or departments that need independent DNS management but share a common network infrastructure.
Inbound resolution policies control which networks can resolve names in private DNS zones. When you configure a private zone, you specify which VPC networks are authorized to query the zone for name resolution. DNS server policies can be created to define inbound forwarding, allowing external queries from on-premises networks or other VPCs to reach private zones. The policy specifies which networks are permitted to send DNS queries to the zone, creating a controlled boundary for name resolution that prevents unauthorized access to internal DNS records.
DNS policies can bind to multiple VPC networks across different projects, enabling centralized DNS management while distributing resolution authority. When creating a policy, you must have the dns.networks.bindPrivateDNSPolicy permission on each project containing the VPC networks the policy will serve. This binding mechanism allows a single policy to control DNS behavior across a multi-project environment, applying forwarding rules, inbound query controls, and response policies uniformly across all bound networks.
Service Directory integration with Cloud DNS provides additional security and service discovery capabilities. When implementing DNS security policies through Service Directory, you can register both Google Kubernetes Engine (GKE) and non-GKE services in a single registry and configure Cloud DNS to populate records matching those services. This integration enables per-service level access permissions and metadata storage, extending DNS resolution beyond simple name-to-address mapping into a comprehensive service discovery solution that works across hybrid and multi-cloud environments.
DNS forwarding paths in hybrid environments establish the network and directory routes necessary for resolving domain queries between Google Cloud and on-premises networks. Organizations design these resolution paths by mapping DNS domain namespaces, provisioning dedicated hybrid network connections, and structuring Virtual Private Cloud (VPC) projects to support centralized name lookup and authentication traffic.
DNS domain mapping defines how internal and external domain namespaces are structured and resolved across hybrid environments. Active Directory environments rely on specific Active Directory DNS domains, which can be configured as globally reachable names like corp.example.com or private local names like corp.local and corp.internal. Separate mail exchange (MX) domains, such as example.com, frequently coexist with these directory domain structures and require distinct name resolution paths. Domain controllers resolve naming requests locally within their specific domain, whereas global catalog servers provide wider directory data across all domains in an Active Directory forest.
Hybrid network transport paths carry name resolution and directory traffic between on-premises DNS infrastructure and Google Cloud VPC networks. Network administrators establish this connectivity using Cloud Interconnectâthrough Dedicated Interconnect or Partner Interconnectâor Cloud VPN tunnels to deliver reliable network paths. Dynamic routing across these connections is handled by Cloud Router, which uses Border Gateway Protocol (BGP) to exchange subnet routes between networks without sitting directly in the data plane. When Cloud Router uses global dynamic routing, it advertises all VPC subnets across regions but applies a Multi-Exit Discriminator (MED) metric penalty to out-of-region paths to keep local network paths preferred.
Shared VPC centralizes hybrid forwarding infrastructure and routing policies within a single host project, allowing connected service projects to share common hybrid paths. Workload instances in multiple attached service projects resolve names and route traffic across the host project's Cloud VPN or Cloud Interconnect attachments without needing duplicate hybrid circuits. Network administrators centrally manage subnets, routes, and firewall rules in the host project, while individual project teams retain autonomous administrative control over their application workloads. This topology prevents overlapping IP address configurations and enforces uniform security boundaries for cross-project network traffic.
Directory integration patterns determine the path and survivability of domain name and authentication requests across hybrid boundaries. In an extended domain pattern, administrators deploy domain controllers directly onto Google Cloud subnets assigned to dedicated Active Directory sites, ensuring client queries route to local instances rather than traversing hybrid links. In a resource forest pattern, a separate forest operates in Google Cloud and connects to an on-premises forest via a one-way forest trust, allowing user authentication queries to traverse hybrid connections while maintaining administrative isolation. Deploying read-only domain controllers (RODCs) to Google Cloud provides local domain data caching, though administrators must evaluate the tradeoff between caching credentials for offline availability and managing identity security risks.
DNS peering is a strategy that allows separate Virtual Private Cloud (VPC) networks to resolve each other's private DNS records without merging their networks or routing traffic through the public internet. In Google Cloud, this is implemented using Cloud DNS private peering zones. The core relationship involves a DNS producer network, which hosts the authoritative DNS records, and one or more DNS consumer networks, which create a peering zone to forward queries to the producer.
A Cloud DNS private peering zone is a special DNS zone created in a consumer VPC network that forwards queries for a specific domain namespace (like example.com) to the VPC network where the actual records are hosted. The network hosting the authoritative records is called the DNS producer network. The peering zone does not contain its own records; it acts as a forwarding path. This setup is essential for enabling services in one VPC, such as Apigee or application backends, to resolve private endpoint names hosted in another project's VPC.
Configuring DNS peering involves a clear sequence of operations across different projects and networks. First, in the DNS producer project, you must create a standard Cloud DNS private zone and populate it with the necessary DNS records (e.g., A records pointing to private IPs). Then, in the consumer project, you create the peering zone, specifying the producer's VPC network and project ID. A critical dependency is that the consumer's VPC network must have network connectivity (like VPC peering or VPN) to the producer's VPC network for the DNS queries to be routable. The lifecycle of the peering zone is tied to the producer network; if the producer network is deleted, the peering zone becomes inactive and queries will fail.
DNS peering is primarily used for private, hybrid architectures. A key use case is enabling a managed service like Apigee (in a service producer VPC) to resolve private backend endpoints hosted in a customer's VPC. Another is allowing Google Kubernetes Engine (GKE) private clusters or Vertex AI jobs within a service perimeter to resolve private registry domains (pkg.dev) via a restricted VIP. Public DNS peering is not a standard concept; DNS peering is designed for private, RFC 1918 address spaces within Google Cloud or connected hybrid networks. The decision to use DNS peering is driven by the need for private resolution across network boundaries without exposing DNS data to the public internet.
Since DNS peering links resources across different Google Cloud projects, Identity and Access Management (IAM) is crucial for security. The principal in the consumer project (often a service account used by a managed service) must be granted the DNS Peer (roles/dns.peer) role on the producer project or, in a Shared VPC setup, on the host project. This role permits the creation and use of the peering zone. Without this permission, the peering operation will fail. In a Shared VPC architecture, the PRODUCER_PROJECT_ID and PRODUCER_VPC_NETWORK referenced in the peering configuration both correspond to the host project, not the service project.
Connectivity issues in DNS peering often stem from misconfigured network reachability or zone overlaps. DNS queries flow from the consumer's peering zone to the producer's private zone over the IP network connecting the two VPCs. Therefore, standard network troubleshooting applies: firewall rules must allow TCP/UDP port 53, and routes must exist between the networks. A major constraint is that the domain namespace of a peering zone cannot overlap with any existing private zone in the consumer's VPC. If there is an overlap, the peering zone cannot be created. To resolve this, you must ensure unique domain naming or reconfigure the existing zones.
StudyCerts
StudyCertsroles/dns.peer) role must be granted on the host project, and the PRODUCER_PROJECT_ID and PRODUCER_VPC_NETWORK in the peering configuration both refer to the host project.Cross-project binding directly associates DNS zones in service projects with a Shared VPC network in a host project, enabling any-to-any resolution without a hop limit. DNS peering uses a peering zone in a consumer network that forwards queries to a producer network's private zone, and each peering hop can introduce a transitive hop limit. Cross-project binding is simpler for hub-and-spoke designs, while DNS peering is used when networks are not in a Shared VPC topology.
Use the extended domain pattern when you want client queries to route to local domain controllers in Google Cloud rather than traversing hybrid links, which improves performance and availability. Use the resource forest pattern when you need administrative isolation between the Google Cloud and on-premises environments, connecting them via a one-way forest trust that allows authentication queries to traverse the hybrid connection.
The lifecycle of a DNS peering zone is tied to the DNS producer network because the peering zone does not contain its own recordsâit acts only as a forwarding path to the producer's private zone. When the producer network is deleted, the target for the forwarded queries no longer exists, so the peering zone becomes inactive and all queries to that domain namespace will fail.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills