Professional Cloud Network Engineer
A hybrid DNS architecture connects on-premises and Google Cloud environments so that resources in both locations can resolve each other's domain names. The core service enabling this is Cloud DNS, which manages DNS zones and policies. The design focuses on bidirectional name resolution, which requires setting up DNS forwarding for on-premises domains and ensuring proper network routing and firewall rules for DNS query traffic.
To allow Google Cloud resources to resolve on-premises domain names, you configure a Cloud DNS forwarding zone. This private zone forwards queries for a specific domain to designated name servers located on-premises. Cloud DNS sends these forwarded queries from a specific source IP range, 35.199.192.0/19. For the on-premises DNS servers to receive these queries, your hybrid network must have established connectivity, such as Cloud VPN or Cloud Interconnect. The on-premises firewall must also allow inbound TCP and UDP traffic on port 53 from this 35.199.192.0/19 source range.
To allow on-premises resources to resolve names hosted in Cloud DNS private zones, you configure an inbound server policy. This policy defines entry points—specific IP addresses within your VPC—where Cloud DNS will listen for incoming DNS queries from outside Google Cloud. You then configure your on-premises DNS servers or clients to send queries for Google Cloud domains to these entry point IP addresses. This setup completes the bidirectional resolution path.
The flow of DNS queries and responses depends on correct routing configuration across the hybrid connection. For queries originating from Cloud DNS (outbound forwarding), your on-premises network must have a route for the destination 35.199.192.0/19. The next hop for this route must point back to the Cloud VPN tunnel, Cloud Interconnect VLAN attachment, or Cloud Router in the same VPC network and region where the query originated. You can advertise this 35.199.192.0/19 prefix from Google Cloud to on-premises by configuring the Cloud Router in custom advertisement mode. Responses from the on-premises DNS servers must return via the same hybrid path; they cannot be routed over the public internet.
Hybrid architectures often use Private Service Connect to privately expose services across VPC networks. For DNS resolution in these scenarios, you can configure Cloud DNS private peering zones. A peering zone in one VPC network (the consumer) can forward queries to a private zone in another VPC network (the producer). This allows resources, like an API gateway using Private Service Connect endpoints, to resolve the private DNS names of backend services hosted in a different project or network, completing the secure service access pattern.
Cloud DNS is Google's managed DNS service that provides scalable, reliable name resolution for Google Cloud resources, on-premises environments, and multi-cloud deployments. When designing DNS topologies for complex Google Cloud architectures, network architects must consider how DNS queries flow between multiple VPC networks, Shared VPC configurations, and hybrid connectivity scenarios involving on-premises infrastructure.
A private managed zone is a Cloud DNS zone that is accessible only from within specified VPC networks, keeping DNS records hidden from the public internet. By default, private zones are scoped to the VPC network where they are created, meaning resources in other VPC networks cannot resolve names from that zone. This default behavior provides strong isolation but requires explicit configuration when cross-VPC name resolution is needed. Private zones support various record types, allowing you to define internal service endpoints and application-specific DNS names that remain private.
DNS peering (also called peering zones) enables DNS query forwarding between Cloud DNS zones in different VPC networks without requiring the zones to be publicly visible. A peering zone acts as a forwarder: when a resource in the consuming VPC queries for a name in the peering zone's namespace, the query is forwarded to the VPC network where the zone is hosted (the DNS producer network). To configure DNS peering, the DNS producer must explicitly share their private zone with the consuming VPC network by creating a peering zone in the consuming project that references the producer's VPC network and project ID.
In Shared VPC configurations, the host project's network is shared with service projects. When a service project's private DNS zone relies on the shared network, the producer project ID and VPC network referenced in the DNS configuration correspond to the host project. Architects must ensure that service projects configure their peering zones to point to the host project, not to themselves, when resolving names from zones hosted in the host project.
Namespace overlaps occur when two private zones in different VPC networks cover the same DNS namespace, leading to unpredictable resolution behavior. The primary mitigation strategy is to use unique, non-overlapping namespaces across projects. Split-horizon conflicts arise when you need the same domain name to resolve to different IP addresses depending on the source network. Cloud DNS does not natively support this; you must create separate zones for each horizon and ensure clients query the appropriate zone based on their network context. Forwarding loops occur when DNS queries bounce between resolvers in a circular pattern. To prevent them, architects should document the complete DNS query flow for each namespace and ensure peering relationships form a clear hierarchy.
Cloud DNS server policies control how Cloud DNS responds to queries from different sources. An inbound server policy allows on-premises or external clients to use Cloud DNS as a recursive resolver, forwarding their queries into Google Cloud. An outbound server policy controls how Cloud DNS forwards queries that it cannot answer from its own zones—for example, forwarding queries for on-premises domain names to on-premises DNS infrastructure. This allows Google Cloud resources to resolve on-premises names without exposing those names to the public internet.
Cloud DNS supports forwarding queries to alternative name servers when the requested record is not found in Cloud DNS zones. Type 2 alternative name servers use the 35.199.192.0/19 IP address range as the source for queries, and the on-premises network must have routes that direct traffic to this range back through the hybrid connection. Type 3 alternative name servers use Google's public DNS infrastructure and do not require special routing within the VPC network. For Type 2, the on-premises network must configure routes for the 35.199.192.0/19 destination with next hops pointing to Cloud VPN tunnels or Cloud Interconnect attachments in the same region where the query originated.
Cloud DNS resources are protected by Identity and Access Management (IAM) roles that control who can view, create, or modify DNS zones and records. The DNS Admin role grants full control, while the DNS Viewer role provides read-only access. For Shared VPC environments, IAM policies must be configured at both the host project level and the service project level. When configuring DNS peering between projects, the producer project must grant the consumer project permission to peer by creating the peering zone with the correct references to the producer's project ID and VPC network name.
Google Cloud DNS provides scalable, managed domain name resolution across Virtual Private Cloud (VPC) networks, on-premises environments, and public internet endpoints. Administrators use inbound and outbound server policies, response policies, and peering zones to control how queries navigate network boundaries. By pairing these DNS configurations with health-checked backends and security monitoring, organizations ensure high availability and prevent unauthorized name resolution across hybrid topologies.
DNS server policies regulate query flow between Google Cloud VPC networks and external environments. An inbound server policy creates entry-point IP addresses within VPC subnets, allowing external clients to resolve private Cloud DNS records across Cloud VPN or Cloud Interconnect connections. An outbound server policy forwards VPC queries to external alternative name servers by selecting either private or public routing paths. Traffic routing for outbound forwarding depends strictly on the alternative server type: Type 2 uses VPC routes with queries from 35.199.192.0/19, while Type 3 uses standard internet routing.
When deploying Type 2 private forwarding, firewall rules must allow ingress on destination port 53 for both UDP and TCP from 35.199.192.0/19. On-premises routers require routes for 35.199.192.0/19 pointing back to Cloud Routers, Cloud VPN tunnels, or Cloud Interconnect VLAN attachments in the originating VPC region. Return packets must maintain the exact alternative server source IP address and return to the specific querying Cloud DNS IP; otherwise, Cloud DNS drops the response.
Traffic steering in hybrid environments directs network requests across multiple backends based on availability and endpoint health. Cloud load balancers integrate with network endpoint groups (NEGs), such as internet FQDN NEGs or non-GCP private IP NEGs, to steer traffic between cloud workloads and on-premises services. A global forwarding rule intercepts traffic on configured ports, passing requests through target proxies to URL maps that define destination services.
Backend services verify the availability of these remote systems using health checks. Standard Google Cloud health checks query instances directly from centralized probing ranges. When using NON_GCP_PRIVATE_IP_PORT endpoints, proxy clients like Envoy execute distributed health checking directly from their data planes. This distributed probing increases network traffic significantly, requiring careful capacity planning across hybrid interconnects.
DNS Response Policies (RPZ) allow administrators to intercept and modify DNS answers before queries complete, enforcing granular routing and access restrictions. A response policy rule can override public answers to redirect traffic toward a restricted virtual IP (VIP) or block queries matching malicious patterns. For example, applying a local data rule for *.googleapis.com. to resolve to restricted.googleapis.com. keeps API traffic inside a VPC Service Controls boundary, preventing data exfiltration.
Specific domains can bypass these broad interceptions by applying a rule with the behavior flag set to bypassResponsePolicy. To monitor for unauthorized resolution attempts, organizations capture analytical and audit logs and forward them to Google Security Operations (Google SecOps). Access to these DNS resources is protected by Identity and Access Management (IAM) roles, including specific roles for security monitoring and policy administration.
StudyCerts
StudyCerts35.199.192.0/19, requiring corresponding firewall rules and network routes on the on-premises side.35.199.192.0/19 prefix via Cloud Router, is mandatory for DNS query responses to successfully return from on-premises to Google Cloud.A DNS forwarding zone is used to send queries for a specific domain (like an on-premises domain) to external name servers outside of Cloud DNS. A DNS peering zone is used to forward queries for a domain to a private Cloud DNS zone hosted in a different VPC network within Google Cloud, enabling cross-VPC resolution without exposing records publicly.
Use Type 2 alternative name servers when you need to forward DNS queries privately to on-premises or other private DNS servers over a hybrid connection like Cloud VPN or Cloud Interconnect. Use Type 3 alternative name servers when you want to forward queries to public DNS resolvers over the standard internet, as it does not require special routing configuration for the 35.199.192.0/19 range.
To prevent namespace overlaps, design and use unique, non-overlapping DNS namespaces for each project or team, such as using project-specific suffixes (e.g., project-a.internal.example.com). Alternatively, use DNS forwarding policies to explicitly route queries for overlapping namespaces to the correct resolver based on the source VPC network.
Network routing is critical for hybrid DNS because queries and responses must traverse the same secure path. For Cloud DNS to resolve on-premises names, the on-premises network must have a route for the 35.199.192.0/19 source IP range pointing back to the hybrid connection (Cloud VPN/Interconnect) in the correct region. Without this symmetric routing, responses will be lost and resolution will fail.
Prepare and test your skills
Prepare and test your skills