DNS server policies in Google Cloud are configuration objects that control which networks, VMs, or external IP addresses can send DNS queries to Cloud DNS, and they also control how queries flow between on-premises environments and Google Cloud. A DNS server policy is configured as either an inbound server policy or an outbound server policy. Inbound policies let on-premises DNS clients send requests directly to Cloud DNS, while outbound policies control how VMs inside a VPC forward DNS queries to external name servers.
An inbound server policy authorizes specific networks to query Cloud DNS and creates virtual IP addresses, called inbound forwarder IP addresses, that on-premises clients can use as their DNS servers. On-premises clients reach those IP addresses through Cloud VPN or Cloud Interconnect, and Cloud DNS then resolves the request using the VPC network's name resolution order. That order can include private zones, forwarding zones, and peering zones that the VPC has been authorized to use. An outbound server policy configures the DNS name servers that VMs should use, and it can use different forwarder configurations for different VPC networks or default forwarding to Google's public DNS resolvers.
Cloud DNS uses Identity and Access Management (IAM) to control who can manage DNS resources at the project level and at the individual zone level. IAM roles such as DNS Administrator and DNS Reader can be assigned to users, groups, or service accounts so that only authorized principals can create, modify, or view zones and policies. In a Shared VPC setup, DNS zones are created in the host project and the Shared VPC networks that need access must be explicitly authorized, or zones can be placed in a service project using cross-project binding. This layered access control enforces least privilege across both DNS management and DNS queries.
Query logging records every DNS query that Cloud DNS processes, which supports security analysis, compliance auditing, and troubleshooting. When query logging is enabled for a zone, Cloud DNS sends log entries to Cloud Logging (formerly Stackdriver Logging). Each log entry includes the source IP address, the requested domain name, the query type such as A, AAAA, or MX, and the response Cloud DNS provided. Log sinks can export these records to Cloud Storage, Pub/Sub, or BigQuery for long-term retention and advanced analysis.
A public zone is visible to the entire internet and hosts records that anyone on the internet can resolve, while a private zone is visible only from the VPC networks that you explicitly authorize. DNS server policies for private zones control which VPC networks can resolve records and, through inbound policies, which on-premises networks can reach the private zone using the inbound forwarder IP addresses. Public zones do not need DNS server policies for access control because they are already accessible from the internet, but IAM policies still control who can manage the zone and its records. In hybrid environments, private zones are typically used for internal applications, and DNS server policies let on-premises clients resolve those internal names while the records remain hidden from the public internet.
A hybrid DNS resolution architecture allows domain name resolution to work continuously in both directions between a Virtual Private Cloud (VPC) network in Google Cloud and an on-premises or external private DNS infrastructure. It uses Cloud DNS inbound server policies to let on-premises systems query cloud-hosted private zones, and it uses outbound DNS forwarding zones and server policies to send cloud queries to external name servers. The architecture also depends on underlying connectivity through Cloud Interconnect or Cloud VPN, precise routing configuration, and matching firewall rules on both sides.
Outbound DNS resolution lets Compute Engine VMs in Google Cloud resolve private names hosted on on-premises DNS servers. When a VM queries an on-premises domain, Cloud DNS intercepts the request and forwards it across Cloud VPN or Cloud Interconnect to the on-premises Type 2 alternative name server. All outbound queries generated by Cloud DNS originate from the fixed Google-managed IP address range 35.199.192.0/19, and routing relies only on dynamic routes or static routes that apply network-wide without VM tags.
The on-premises network must allow ingress TCP and UDP traffic on port 53 from the 35.199.192.0/19 source range. The on-premises network also needs routes back to 35.199.192.0/19 using next hops that terminate on Cloud VPN tunnels, Cloud Interconnect VLAN attachments, or Cloud Router instances located in the same VPC network and region where the query originated. To accomplish this, Cloud Router uses custom advertisement mode to advertise the 35.199.192.0/19 prefix over Border Gateway Protocol (BGP) sessions to the on-premises environment.
Cloud DNS also validates incoming response packets against the original request. The response sent by the on-premises name server must have a source IP address identical to the target IP address to which Cloud DNS sent the query; Cloud DNS discards responses from unexpected IP addresses. Response packets cannot travel over the public internet, through a different VPC network, or through a different region of the originating VPC. If forwarding to Type 3 alternative name servers across the public internet is required, Cloud DNS uses Google Public DNS source ranges rather than VPC-internal paths.
Inbound DNS resolution lets on-premises clients resolve private zones, peered zones, and internal records hosted in a VPC network. The administrator creates an inbound DNS server policy on the target VPC network, and that policy provisions an inbound forwarder entry point IP address in each subnet of the VPC. On-premises DNS servers are then configured with conditional forwarding rules that send queries for cloud-specific domain names to those entry point IP addresses across Cloud Interconnect or Cloud VPN. On-premises firewalls must permit outbound TCP and UDP port 53 traffic destined for the VPC entry point addresses, and Cloud DNS resolves the query using the private zones and VPC peering configurations applied to that VPC.
Cloud DNS private peering allows DNS resolution requests to cross VPC network boundaries without exposing services to the public internet. A DNS peering zone is a private zone configured in a consumer VPC network that directs lookups to a DNS producer network where the authoritative records reside. This setup lets workloads in one VPC query private records hosted in another project or network, such as when integrating managed services or Shared VPC environments. The identity creating the configuration needs the DNS Peer role (roles/dns.peer) on the host or producer project. VPC network peerings must also have custom route export and import enabled when private service domains rely on dynamic network routes between networks.
Hybrid DNS failures generally fall into four categories: firewall rule misconfigurations, missing return routes, asymmetric or invalid return paths, and response IP mismatches. Firewall rules may drop on-premises ingress queries from 35.199.192.0/19 on port 53, or on-premises routers may lack a valid return route for 35.199.192.0/19 when Cloud Router BGP sessions fail to advertise that prefix. Responses may fail when the on-premises environment routes them through an internet gateway, a mismatched cloud region, or an alternate VPC network, or when a downstream forwarder answers from an IP address different from the designated alternative name server.
Intermittent failures in high-availability environments usually mean routing or firewall propagation is incomplete across redundant connections. If multiple Cloud VPN tunnels or Cloud Interconnect VLAN attachments exist, every path must permit 35.199.192.0/19 and receive the corresponding advertised routes. Organization Policy constraints can also block resolution, such as the Define allowed APIs and services list constraint blocking dns.googleapis.com or the Restrict VPC peering usage constraint preventing DNS peering attachments. End-to-end validation includes checking policy attachments, testing queries directly against inbound entry points, and reviewing Cloud Router BGP routing tables.
DNS forwarding in Google Cloud directs DNS queries from resources inside a VPC network to specific external DNS name servers. Conditional forwarding is a specific form of DNS forwarding in which queries for particular domain suffixes are sent to designated servers, optimizing the resolution path and reducing latency. Both approaches are important for hybrid environments where cloud and on-premises systems must resolve each other's names.
A Cloud DNS forwarding zone is a private DNS zone configured for outbound DNS forwarding. When you create one, you authorize one or more VPC networks to use it and specify the IP addresses of the target name servers, which can be on-premises or in another cloud. Queries from authorized VPCs for any domain are then sent to those specified servers instead of the default Google Cloud resolvers. Use this approach when you want all DNS queries from a VPC to be resolved by your own DNS infrastructure.
A Cloud DNS server policy configures inbound DNS forwarding, allowing clients outside Google Cloud to send queries to Cloud DNS. You create the inbound server policy on a VPC network, and it provides specific DNS server IP addresses. On-premises DNS clients or servers can then send queries to those IP addresses over a hybrid connection such as Cloud VPN or Cloud Interconnect. Those clients can resolve records in any private zone, forwarding zone, or peering zone for which the VPC network is authorized, following the VPC's standard name resolution order.
Conditional forwarding is implemented by creating a forwarding zone for a specific domain name. For example, to resolve the on-premises domain corp.example.com, you create a private forwarding zone with that name, authorize your VPC networks, and specify the IP addresses of the on-premises DNS servers for that domain. Queries from the VPC for *.corp.example.com are sent directly to those on-premises servers, while queries for other domains use the default resolution path. This approach is more efficient than forwarding all queries because it avoids unnecessary network hops for cloud-native domains.
The DNS query flow depends on which direction the query travels. For outbound conditional forwarding, a VM in a VPC makes a query, Cloud DNS checks for a forwarding zone that matches the query's domain suffix, and if a match is found, the query is sent directly to the target name servers defined in that zone. For inbound forwarding, an on-premises client sends a query to a DNS server IP address provided by a Cloud DNS server policy, the query enters the VPC, and Cloud DNS resolves it according to that VPC's zones and policies. Firewall rules on both Google Cloud and on-premises must allow DNS traffic, typically UDP and TCP port 53, to and from the relevant IP addresses.
An inbound DNS server policy lets on-premises clients send DNS queries to Cloud DNS through forwarder entry point IP addresses. An outbound DNS server policy controls which external name servers VMs inside a VPC use when they forward DNS queries.
Use conditional forwarding when only specific domains need to be resolved by on-premises or third-party DNS servers. Create a forwarding zone for the domain suffix so only matching queries go to those servers, while all other queries use the default Cloud DNS resolution path.
Cloud DNS validates that the response source IP matches the target IP address to which it sent the query. It also requires the response to use the correct return path, not the public internet, a different VPC, or a different region, so responses that violate those checks are discarded.
Common causes include firewall rules dropping port 53 traffic from 35.199.192.0/19, missing return routes for that range, invalid return paths, and downstream forwarders answering from an unexpected IP address. In high-availability environments, every redundant VPN tunnel and Interconnect VLAN attachment must also permit the traffic and receive the advertised routes.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts