This page describes how to configure Cloud DNS server policies and use them with Virtual Private Cloud (VPC) networks. Before you use this page, review the DNS server policies 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.
- If you don't already have one, sign up for a Google Account.
- Enable the Cloud DNS API in the console. You can choose an existing Compute Engine or App Engine project, or you can create a new project.
- If you need to make requests to the REST API, you need to create an OAuth 2.0 ID: Setting up OAuth 2.0.
- 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 console. You could also ask your user to provide the project name that they want to use in your app.
-
The client ID (
If you have not run the Google Cloud CLI 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.
Create DNS server policies
Each DNS server policy object can define any of the following server policies:
- An inbound server policy, enabling inbound forwarding
- An outbound server policy, specifying one or more alternative name servers
- Both an inbound and an outbound server policy
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.
Create 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 policyDESCRIPTION
: a description for the policyVPC_NETWORK_LIST
: a comma-delimited list of VPC networks where inbound forwarding addresses must be created
Terraform
Create 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 policyDESCRIPTION
: a description for the policyVPC_NETWORK_LIST
: a comma-delimited list of VPC networks that query the alternative name serversALTERNATIVE_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 addressesPRIVATE_ALTERNATIVE_NAMESERVER_LIST
: a comma-delimited list of IP addresses that you can use as alternative name servers, accessed by using private routing
Create 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 policyDESCRIPTION
: a description for the policyVPC_NETWORK_LIST
: a comma-delimited list of VPC networks where inbound forwarding addresses must be created and that must query the alternative name serversALTERNATIVE_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.
List 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. VM instances can access the inbound forwarder through any of the internal IP addresses in the same VPC network. To access inbound forwarding, either the network interface must have an external IP address or a subnet of the NIC must have Private Google Access enabled.
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)'
Update DNS policies
The following sections provide information about changing VPC networks and enabling or disabling inbound forwarding.
Change 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 policyVPC_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
Enable or disable 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.
List DNS policies
gcloud
To list DNS server policies in your project, run the dns policies
list
command:
gcloud dns policies list
Delete 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. |
Cloud DNS uses the |
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 port53
.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 networkFor 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 the35.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 to35.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 include35.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
- To find solutions for common issues that you might encounter when using Cloud DNS, see Troubleshooting.
- To get an overview of Cloud DNS, see Cloud DNS overview.