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.
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:
- 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.
- Configure on-premises systems to send DNS queries to the inbound server policy entry points configured in the previous step.
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 theus-west1
region, the associated region for the DNS query isus-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.
- For example, if the packets for a DNS query enter a VPC
network using a Cloud VPN tunnel located in the
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.
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).
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
andUDP
- 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.