DNS server policies

You can configure one DNS server policy for each Virtual Private Cloud (VPC) network. The policy can specify inbound DNS forwarding, outbound DNS forwarding, or both. In this section, inbound server policy refers to a policy that permits inbound DNS forwarding. Outbound server policy refers to one possible method for implementing outbound DNS forwarding. It is possible for a policy to be both an inbound server policy and an outbound server policy if it implements the features of both.

For more information, see Applying Cloud DNS server policies.

Inbound server policies

Each VPC network provides Cloud DNS name resolution services to virtual machine (VM) instances that have a network interface (vNIC) attached to the VPC network. When a VM uses its metadata server 169.254.169.254 as its name server, Google Cloud searches for Cloud DNS resources according to the VPC network name resolution order.

To make a VPC network's name resolution services available to on-premises networks that are connected to the VPC network by using Cloud VPN tunnels, Cloud Interconnect VLAN attachments, or Router appliances, you can use an inbound server policy.

When you create an inbound server policy, Cloud DNS creates inbound server policy entry points in the VPC network to which the server policy is applied. Inbound server policy entry points are internal IPv4 addresses sourced from the primary IPv4 address range of every subnet in the applicable VPC network, except for subnets with specific --purpose data, such as proxy-only subnets for certain load balancers and subnets used by Cloud NAT for Private NAT.

For example, if you have a VPC network that contains two subnets in the same region and a third subnet in a different region, when you configure an inbound server policy for the VPC network, Cloud DNS uses a total of three IPv4 addresses as inbound server policy entry points, one per subnet.

Note: You can't use inbound server policies with legacy networks because these policies require VPC networks.

For information about how to create an inbound server policy for a VPC, see Create an inbound server policy.

Network and region for inbound queries

To process DNS queries that are sent to inbound server policy entry points, Cloud DNS associates the query with a VPC network and a region:

• The associated VPC network for a DNS query is the VPC network that contains the Cloud VPN tunnel, Cloud Interconnect VLAN attachment, or network interface of the Router appliance that receives the packets for the DNS query.

  • Google recommends creating an inbound server policy in the VPC network that connects to your on-premises network. That way, the inbound server policy entry points are located in the same VPC network as the Cloud VPN tunnels, Cloud Interconnect VLAN attachments, or Router appliances that connect to the on-premises network.

  • It is possible for an on-premises network to send queries to inbound server policy entry points in a different VPC network—for example, if the VPC network containing the Cloud VPN tunnels, Cloud Interconnect VLAN attachments, or Router appliances that connect to the on-premises network is also connected to a different VPC network using VPC Network Peering. However, we don't recommend using this configuration because the associated VPC network for DNS queries doesn't match the VPC network containing the inbound server policy entry points, which means that DNS queries are not resolved using Cloud DNS private zones and response policies in the VPC network containing the inbound server policy. To avoid confusion, we recommend the following configuration steps instead:

    1. Create an inbound server policy in the VPC network that connects to the on-premises network using Cloud VPN tunnels, Cloud Interconnect VLAN attachments, or Router appliances.
    2. Configure on-premises systems to send DNS queries to the inbound server policy entry points configured in the previous step.

    3. Configure Cloud DNS resources authorized for the VPC network that connects to the on-premises network. Use one or more of the following methods:

       • Add the VPC network that connects to the on-premises network to the list of authorized networks for the Cloud DNS private zones that are authorized for the other VPC network: If a Cloud DNS private zone and the VPC network that connects to the on-premises network are in different projects of the same organization, use the full network URL when authorizing the network. For more information, see Set up cross-project binding.
       • Cloud DNS peering zones authorized for the VPC network that connects to the on-premises network: Set the target network of the peering zone to the other VPC network. It doesn't matter whether the VPC network that connects to the on-premises network is connected to the peering zone's target VPC network using VPC Network Peering because Cloud DNS peering zones don't rely on VPC Network Peering for network connectivity.

• The associated region for a DNS query is always the region that contains the Cloud VPN tunnel, Cloud Interconnect VLAN attachment, or network interface of the Router appliance that receives the packets for the DNS query, not the region of the subnet containing the inbound server policy entry point.

  • For example, if the packets for a DNS query enter a VPC network using a Cloud VPN tunnel located in the us-east1 region and are sent to an inbound server policy entry point in the us-west1 region, the associated region for the DNS query is us-east1.
  • As a best practice, send DNS queries to the IPv4 address of an inbound server policy entry point in the same region as the Cloud VPN tunnel, Cloud Interconnect VLAN attachment, or Router appliance.
  • The associated region for a DNS query is important if you use geolocation routing policies. For more information, see Manage DNS routing policies and health checks.

Inbound server policy entry point route advertisement

Because inbound server policy entry point IP addresses are taken from the primary IPv4 address ranges of subnets, Cloud Routers advertise those IP addresses when the Border Gateway Protocol (BGP) session for a Cloud VPN tunnel, Cloud Interconnect VLAN attachment, or Router appliance is configured to use the Cloud Router default advertisement mode. You can also configure a BGP session to advertise inbound server policy entry point IP addresses if you use the Cloud Router custom advertisement mode in one of the following ways:

• You advertise subnet IP address ranges in addition to your custom prefixes.
• You include inbound server policy entry point IP addresses in your custom prefix advertisements.

Outbound server policies

You can modify the Cloud DNS name resolution order of a VPC network by creating an outbound server policy that specifies a list of alternative name servers. When a VM uses its metadata server 169.254.169.254 as its name server, and when you have specified alternative name servers for a VPC network, Cloud DNS sends all queries to the alternative name servers unless the queries are matched by a Google Kubernetes Engine cluster-scoped response policy or GKE cluster-scoped private zone.

When two or more alternative name servers exist in an outbound server policy, Cloud DNS ranks the alternative name servers and queries them as described in the first step of the VPC name resolution order.

Important: Review the VPC network resolution order carefully. Use of alternative name servers disables the resolution of many Cloud DNS features, and can also affect the resolution of public DNS queries, depending on the configuration of the alternative name servers. For more information about other strategies for outbound DNS forwarding, see DNS forwarding methods in the Cloud DNS overview.

For information about how to create outbound server policies, see Creating an outbound server policy.

Alternative name server types, routing methods, and addresses

Cloud DNS supports three types of alternative name servers and offers standard or private routing methods for connectivity.

Alternative name server type	Standard routing supports	Private routing supports	Query source address range
Type 1 name server An internal IP address of a Google Cloud VM in the same VPC network where the outbound server policy is defined.	Only RFC 1918 IP addresses—traffic always routed through an authorized VPC network.	Any internal IP address, such as an RFC 1918 private address, a non-RFC 1918 private IP addresses, or a privately reused external IP address, except for a prohibited alternative name server IP address—traffic always routed through an authorized VPC network.	35.199.192.0/19
Type 2 name server An IP address of an on-premises system, connected to the VPC network with the outbound server policy, using Cloud VPN or Cloud Interconnect.	Only RFC 1918 IP addresses—traffic always routed through an authorized VPC network.	Any internal IP address, such as an RFC 1918 private address, a non-RFC 1918 private IP addresses, or a privately reused external IP address, except for a prohibited alternative name server IP address— traffic always routed through an authorized VPC network.	35.199.192.0/19
Type 3 name server An external IP address of a DNS name server accessible to the internet or the external IP address of a Google Cloud resource—for example, the external IP address of a VM in another VPC network.	Only internet-routable external IP addresses—traffic always routed to the internet or to the external IP address of a Google Cloud resource.	Private routing isn't supported.	Google Public DNS source ranges

Cloud DNS offers two routing methods for querying alternative name servers:

• Standard routing: Cloud DNS determines the type of the alternative name server using its IP address, and then uses either private or public routing:

  • If the alternative name server is an RFC 1918 IP address, Cloud DNS classifies the name server as either a Type 1 or Type 2 name server, and routes queries through an authorized VPC network (private routing).

  • If the alternative name server is not an RFC 1918 IP address, Cloud DNS classifies the name server as Type 3, and expects the alternative name server to be internet accessible. Cloud DNS routes queries over the internet (public routing).

• Private routing: Cloud DNS treats the alternative name server as either Type 1 or Type 2. Cloud DNS always routes traffic through an authorized VPC network, regardless of the alternative name server's IP address (RFC 1918 or not).

Important: A Type 1 alternative name server cannot be located in a VPC network that's connected to the VPC network with the outbound server policy. It doesn't matter how the two VPC networks are connected—for example, using VPC Network Peering or Cloud VPN tunnels.

Prohibited alternative name server IP addresses

You cannot use the following IP addresses for Cloud DNS alternative name servers:

• 169.254.0.0/16
• 192.0.0.0/24
• 192.0.2.0/24
• 192.88.99.0/24
• 198.51.100.0/24
• 203.0.113.0/24
• 224.0.0.0/4
• 240.0.0.0/4
• ::1/128
• ::/128
• 2001:db8::/32
• fe80::/10
• fec0::/10
• ff00::/8

Alternative name server network requirements

Network requirements for alternative name servers vary based on the alternative name server's type. To determine the type for an alternative name server, see Alternative name server types, routing methods, and addresses. Then refer to one of the following sections for network requirements.

Network requirements for Type 1 alternative name servers

Cloud DNS sends packets whose sources are from the 35.199.192.0/19 IP address range to the Type 1 alternative name server IP address. Google Cloud routes packets for queries using local subnet routes in the VPC network. Ensure you haven't created any policy-based routes whose destinations include Type 1 alternative name server IP addresses.

To allow incoming packets on alternative name server VMs, you must create ingress allow VPC firewall rules or rules in firewall policies with the following characteristics:

• Targets: must include the alternative name server VMs
• Sources: 35.199.192.0/19
• Protocols: TCP and UDP
• Port: 53

Cloud DNS requires that each alternative name server send response packets back to the Cloud DNS IP address in 35.199.192.0/19 from which the query originated. Sources for response packets must match the IP address of the alternative name server to which Cloud DNS sends the original query. Cloud DNS ignores responses if they come from an unexpected IP address source—for example, the IP address of another name server to which an alternative name server might forward a query.

When a Type 1 alternative name server sends response packets to 35.199.192.0/19, it uses a special routing path.

Network requirements for Type 2 alternative name servers

Cloud DNS sends packets whose sources are from the 35.199.192.0/19 IP address range to Type 2 alternative name servers. Cloud DNS relies on the following types of routes within the VPC network to which the outbound server policy applies:

• Static routes except for static routes that only apply to VMs by network tag
• Dynamic routes

To allow incoming packets on Type 2 alternative name servers, make sure that you configure ingress allow firewall rules that are applicable to the alternative name servers and any relevant on-premises network equipment with firewall features. The effective firewall configuration must allow both TCP and UDP protocols with destination port 53 and 35.199.192.0/19 sources.

Cloud DNS requires that each alternative name server send response packets back to the Cloud DNS IP address in 35.199.192.0/19 from which the query originated. Sources for response packets must match the IP address of the alternative name server to which Cloud DNS sends the original query. Cloud DNS ignores responses if they come from an unexpected IP address source—for example, the IP address of another name server to which an alternative name server might forward a query.

Your on-premises network must have routes for the 35.199.192.0/19 destination whose next hops are Cloud VPN tunnels, Cloud Interconnect VLAN attachments, or Cloud Routers located in the same VPC network and region from which Cloud DNS sends the query. As long as the next hops meet those network and region requirements, Google Cloud doesn't require a symmetric return path. Responses from Type 2 alternative name servers cannot be routed using any of the following next hops:

• Next hops on the internet
• Next hops in a VPC network that is different from the VPC network where the queries originated
• Next hops in the same VPC network but in a region that is different from the region where the queries originated

To configure the 35.199.192.0/19 routes in your on-premises network, use the Cloud Router custom advertisement mode and include 35.199.192.0/19 as a custom prefix in the BGP sessions of the relevant Cloud VPN tunnels, Cloud Interconnect VLAN attachments, or Cloud Routers that connect your VPC network to the on-premises network that contains the Type 2 alternative name server. Alternatively, you can configure equivalent static routes in your on-premises network.

Network requirements for Type 3 alternative name servers

Cloud DNS sends packets whose sources match the Google Public DNS source ranges to Type 3 alternative name servers. Cloud DNS uses public routing— it does not rely on any routes within the VPC network to which the outbound server policy applies.

To allow incoming packets on Type 3 alternative name servers, make sure that the effective firewall configuration that is applicable to the alternative name server permits packets from the Google Public DNS source ranges.

What's next

• To configure and apply DNS server policies, see Apply DNS server policies.