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 the DNS server policies section in the Cloud DNS overview.

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 need to create an OAuth 2.0 ID: Setting up OAuth 2.0.
  4. In the project, note the following information that you will need to input in later steps:
    • The client ID (xxxxxx.apps.googleusercontent.com).
    • The project ID that you want 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 Google 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.

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 create your policy, you can list the entry points that Cloud DNS creates.

gcloud

To create an inbound server policy, run the dns policies create command:

gcloud dns policies create NAME \
    --description=DESCRIPTION \
    --networks=VPC_NETWORK_LIST \
    --enable-inbound-forwarding

Replace the following:

  • 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 an outbound server policy, run 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:

  • 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 that you can use 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 that you can use as alternative name servers, accessed by using private routing

Creating a server policy for both

gcloud

To create a DNS server policy for both inbound and outbound forwarding, run 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:

  • 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 that you can use 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 that you can use as alternative name servers, accessed by using private routing.

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, run the compute addresses list command:

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

Updating DNS policies

The following sections provide information about changing VPC networks and enabling or disabling inbound forwarding.

Changing VPC networks

The following list describes what happens 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, run the dns policies update command:

gcloud dns policies update NAME \
    --networks=VPC_NETWORK_LIST

Replace the following:

  • 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, run the dns policies update command:

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

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

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

Replace NAME with the name of the policy.

Listing DNS policies

gcloud

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

gcloud dns policies list

Deleting a DNS policy

gcloud

To delete a server policy, run the dns policies delete command:

gcloud dns policies delete NAME

Replace NAME with the name of the policy to delete.

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 server

An internal IP address of a Google Cloud VM in the same VPC network with the outbound policy.

Type 2 name server

An IP address of an on-premises system, connected to the VPC network with the outbound policy, using Cloud VPN or Cloud Interconnect.

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 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.

 Google Public DNS source ranges

Type 1 and Type 2 alternative name servers

Cloud DNS requires the following 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 choose 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 about 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, although 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 VLAN attachment.

Type 3 alternative name servers

When Cloud DNS uses standard routing to access an external IP address, it expects the alternative name server to be either a system on the internet, publicly accessible, or an external IP address of a Google Cloud resource.

For example, a Type 3 alternative name server includes the external IP address of a VM in a different VPC network.

Private routing to Type 3 alternative name servers is not supported.

What's next