Applying Cloud DNS server policies

This page describes how to configure Cloud DNS server policies and use them with Virtual Private Cloud (VPC) networks. Before you use this page, familiarize yourself with Cloud DNS concepts.

Before you begin

The Cloud DNS API requires that you create a Google Cloud project and enable the Cloud DNS API.

If you are creating an application that uses the REST API, you must also create an OAuth 2.0 client ID.

  1. If you don't already have one, sign up for a Google account.
  2. Enable the Cloud DNS API in the Cloud Console. You can choose an existing Compute Engine or App Engine project, or you can create a new project.
  3. If you need to make requests to the REST API, you will need to create an OAuth 2.0 ID: Setting up OAuth 2.0.
  4. Note the following information in the project that you will need to input in later steps:
    • The client ID (xxxxxx.apps.googleusercontent.com).
    • The project ID that you wish to use. You can find the ID at the top of the Overview page in the Cloud Console. You could also ask your user to provide the project name that they want to use in your app.

If you have not run the gcloud command-line tool previously, you must run the following command to specify the project name and authenticate with the Cloud Console:

gcloud auth login

To choose a different project than one you have chosen previously, specify the --project option at the command line.

Creating DNS server policies

Each DNS server policy object can define any of the following server policies:

Each VPC network can reference no more than one DNS server policy. If you need to define both inbound and outbound forwarding for a VPC network, create one policy that defines both an inbound and an outbound policy.

For more information on DNS server policies, see DNS server policies.

Creating an inbound server policy

To create an inbound server policy, follow these instructions. Cloud DNS creates a set of inbound forwarder IP addresses in each VPC network where the policy applies. After you've created your policy, you can list the entry points that Cloud DNS creates.

gcloud

To create a new inbound server policy, use the dns policies create command:

gcloud dns policies create name \
    --description=description \
    --networks=vpc-network-list \
    --enable-inbound-forwarding

Replace the following command options:

  • name: A name for the policy
  • description: A description for the policy
  • vpc-network-list: A comma-delimited list of VPC networks where inbound forwarding addresses must be created

Creating an outbound server policy

You can create an outbound server policy to modify the name resolution order of a VPC network by directing all DNS queries to an alternative name server. To do so, follow these instructions. Before you begin, ensure that you understand the differences between standard and private routing and the network requirements for alternative name servers.

gcloud

To create a new outbound server policy, use the dns policies create command:

gcloud dns policies create name \
    --description=description \
    --networks=vpc-network-list \
    --alternative-name-servers=alternative-nameserver-list \
    --private-alternative-name-servers=private-alternative-nameserver-list

Replace the following command options:

  • name: A name for the policy
  • description: A description for the policy
  • vpc-network-list: A comma-delimited list of VPC networks that query the alternative name servers
  • alternative-nameserver-list: A comma-delimited list of IP addresses to be used as alternative name servers. Private routing is only used for alternative name servers that have RFC 1918 addresses.
  • private-alternative-nameserver-list: A comma-delimited list of IP addresses to be used as alternative name servers, accessed using private routing. For more information, see Alternative name servers and routing methods.

Creating a server policy for both

gcloud

To create a new DNS server policy for both inbound and outbound forwarding, use the dns policies create command:

gcloud dns policies create name \
    --description=description \
    --networks=vpc-network-list \
    --alternative-name-servers=alternative-nameserver-list \
    --private-alternative-name-servers=private-alternative-nameserver-list \
    --enable-inbound-forwarding

Replace the following command options:

  • name: A name for the policy
  • description: A description for the policy
  • vpc-network-list: A comma-delimited list of VPC networks where inbound forwarding addresses must be created and that must query the alternative name servers
  • alternative-nameserver-list: A comma-delimited list of IP addresses to be used as alternative name servers. Private routing is only used for alternative name servers that have RFC 1918 addresses.
  • private-alternative-nameserver-list: A comma-delimited list of IP addresses to be used as alternative name servers, accessed using private routing. For more information, see Alternative name servers and routing methods.

Listing inbound forwarder entry points

When an inbound server policy applies to a VPC network, Cloud DNS creates a set of regional internal IP addresses that serve as destinations to which your on-premises systems or name resolvers can send DNS requests. These addresses serve as entry points to the name resolution order of your VPC network.

Google Cloud firewall rules do not apply to the regional internal addresses that act as entry points for inbound forwarders. Cloud DNS accepts TCP and UDP traffic on port 53 automatically.

Each inbound forwarder accepts and receives queries from Cloud VPN tunnels or Cloud Interconnect attachments (VLANs) in the same region as the regional internal IP address.

gcloud

To list the set of regional internal IP addresses that serve as entry points for inbound forwarding, use the compute addresses list command:

gcloud compute addresses list \
    --filter='purpose = "DNS_RESOLVER"' \
    --format='csv(address, region, subnetwork)'

Updating DNS policies

Changing VPC networks

When you change the list of VPC networks to which a DNS policy applies:

  • If the policy specifies an inbound policy, entry points for inbound forwarders are created in VPC networks as needed
  • If the policy specifies an outbound policy, the name resolution order of each VPC network is updated to direct all requests to an alternative name server

gcloud

To modify the list of networks to which a DNS server policy applies, use the dns policies update command:

gcloud dns policies update name \
    --networks=vpc-network-list

Replace the following command options:

  • name: A name for the policy
  • vpc-network-list: A comma-delimited list of VPC networks to which the policy applies. The list of VPC networks that you specify replaces the previous list.

Enabling or disabling inbound forwarding

You can enable inbound forwarding for a DNS server policy that defines only an outbound policy (alternative name server). You can also disable inbound forwarding for an existing DNS policy.

gcloud

To enable inbound forwarding for a DNS server policy, use the dns policies update command:

gcloud dns policies update name \
    --enable-inbound-forwarding

To disable inbound forwarding for a DNS server policy, use the dns policies update command:

gcloud dns policies update name \
    --no-enable-inbound-forwarding

Replace the following command options:

  • name: The name of the policy

Listing DNS policies

gcloud

To list DNS server policies in your project, use the dns policies list command:

gcloud dns policies list

Deleting a DNS policy

gcloud

To create a server policy, use the dns policies delete command:

gcloud dns policies delete name

Replace the following command options:

  • name: The name of the policy to remove

Alternative name server network requirements

When Cloud DNS sends requests to alternative name servers, it sends packets with the source ranges listed in the following table. For additional background information about the different types of name servers, see alternative name servers and routing methods.

Alternative name server type Source ranges
  • Type 1 name servers
    (VMs in a VPC network with the outbound policy)
  • Type 2 name servers
    (On-premises, connected to a VPC network with the outbound policy)
35.199.192.0/19
Cloud DNS uses the 35.199.192.0/19 source range for all customers. This range is only accessible from a Google Cloud VPC network or from an on-premises network connected to a VPC network.
  • Type 3 name servers
    (internet accessible)
Google Public DNS source ranges

Type 1 and 2 alternative name servers

Cloud DNS requires the following in order to access a Type 1 or a Type 2 alternative name server. These requirements are the same whether the name server is an RFC 1918 IP address and you're using standard routing or if you've explicitly chosen private routing:

  • Firewall configuration for 35.199.192.0/19: For Type 1 name servers, create an ingress allow firewall rule for TCP and UDP port 53, applicable to your alternative name servers in each VPC network configured to use an outbound policy that specifies the name server. For Type 2 name servers, configure an on-premises network firewall and similar equipment to permit TCP and UDP port 53.
  • Route to the alternative name server: For Type 1 name servers, Cloud DNS uses a subnet route to access the name server in the VPC network configured to use an outbound policy that specifies the name server. For Type 2 name servers, Cloud DNS uses either custom dynamic or custom static routes, except for tagged static routes, to access the name server.
  • Return route to 35.199.192.0/19 through the same VPC network: For Type 1 name servers, Google Cloud automatically adds a special return route for the 35.199.192.0/19 destination. For Type 2 name servers, your on-premises network must have a route for the 35.199.192.0/19 destination, whose next hop is in the same VPC network and region where the request originated, through a Cloud VPN tunnel or Cloud Interconnect attachment (VLAN). For information on how to meet this requirement, see return route strategies for type 2 name servers.

  • Direct response from alternative name server: Cloud DNS requires that the alternative name server that receives packets be the one that sends replies to 35.199.192.0/19. If your name server sends the request to a different name server, and that other name server responds to 35.199.192.0/19, Cloud DNS ignores the response. For security reasons, Google Cloud expects the source address of each alternative name server's DNS reply to match the IP address of the alternative name server.

Return route strategies for type 2 name servers

Responses from Type 2 name servers cannot be sent over the internet, through a different VPC network, or to a different region (even in the same VPC network). Responses must return to the same region and VPC network, though they can use any Cloud VPN tunnel or Cloud Interconnect attachment (VLAN) in that same region and same network.

  • For Cloud VPN tunnels that use static routing, manually create a route in your on-premises network whose destination is 35.199.192.0/19 and whose next hop is the Cloud VPN tunnel. For Cloud VPN tunnels that use policy-based routing, configure the Cloud VPN's local traffic selector and the on-premises VPN gateway's remote traffic selector to include 35.199.192.0/19.
  • For Cloud VPN tunnels that use dynamic routing or for Cloud Interconnect, configure a custom route advertisement for 35.199.192.0/19 on the BGP session of the Cloud Router that manages the tunnel or interconnect attachment (VLAN).

Type 3 alternative name servers

When Cloud DNS accesses a non-RFC 1918 IP address using standard routing, it expects the alternative name server to be publicly accessible.

Next steps