Cloud DNS overview

This page provides an overview of Cloud DNS features and capabilities. Cloud DNS is a high-performance, resilient, global Domain Name System (DNS) service that publishes your domain names to the global DNS in a cost-effective way.

DNS is a hierarchical distributed database that lets you store IP addresses and other data, and look them up by name. Cloud DNS lets you publish your zones and records in DNS without the burden of managing your own DNS servers and software.

Cloud DNS offers both public zones and private managed DNS zones. A public zone is visible to the public internet, while a private zone is visible only from one or more Virtual Private Cloud (VPC) networks that you specify.

For a list of general DNS terminology, see the General DNS overview.

For a list of key terminology on which Cloud DNS is built, see Key terms.

To get started using Cloud DNS, see the Quickstart.

Shared VPC considerations

To use a Cloud DNS managed private zone, Cloud DNS forwarding zone, or Cloud DNS peering zone with Shared VPC, you must create the zone in the host project, and then add one or more Shared VPC networks to the list of authorized networks for that zone.

For more information, see Best practices for Cloud DNS private zones.

VPC name resolution order

Each VPC network provides DNS name resolution services to the virtual machine (VM) instances that use it. When VMs use their metadata server 169.254.169.254 as their name server, Google Cloud searches for DNS records in the following order:

  • If your VPC network has an outbound server policy, Google Cloud forwards all DNS queries to those alternative servers. The VPC name resolution order consists only of this step.

  • If your VPC network does not have an outbound server policy:

    1. Google Cloud tries to find a private zone that matches as much of the requested record as possible (longest suffix matching). This includes the following:
      • Searching records that you created in private zones.
      • Querying the forwarding targets for forwarding zones.
      • Querying the name resolution order of another VPC network using peering zones.
    2. Google Cloud searches the automatically created Compute Engine internal DNS records for the project.
    3. Google Cloud queries publicly available zones, following the appropriately configured start of authority (SOA). This includes Cloud DNS public zones.

DNS forwarding methods

Google Cloud offers inbound and outbound DNS forwarding for private zones. You can configure DNS forwarding by creating a forwarding zone or a Cloud DNS server policy. The two methods are summarized in the following table.

DNS forwarding Cloud DNS methods
Inbound

Create an inbound server policy to enable an on-premises DNS client or server to send DNS requests to Cloud DNS. The DNS client or server can then resolve records according to a VPC network's name resolution order.

On-premises clients can resolve records in private zones, forwarding zones, and peering zones for which the VPC network has been authorized. On-premises clients use Cloud VPN or Cloud Interconnect to connect to the VPC network.

Outbound

You can configure VMs in a VPC network to do the following:

  • Send DNS requests to DNS name servers of your choosing. The name servers can be located in the same VPC network, in an on-premises network, or on the internet.
  • Resolve records hosted on name servers configured as forwarding targets of a forwarding zone authorized for use by your VPC network. For information about how Google Cloud routes traffic to a forwarding target's IP address, see Forwarding targets and routing methods.
  • Create an outbound server policy for the VPC network to send all DNS requests an alternative name server. When using an alternative name server, VMs in your VPC network are no longer able to resolve records in Cloud DNS private zones, forwarding zones, or peering zones. For additional details, see the VPC name resolution order.

You can simultaneously configure inbound and outbound DNS forwarding for a VPC network. Bi-directional forwarding lets VMs in your VPC network resolve records in an on-premises network or in a network hosted by a different cloud provider. This type of forwarding also enables hosts in the on-premises network to resolve records for your Google Cloud resources.

The Cloud DNS control plane uses an algorithm to determine the responsiveness of a forwarding target. Your outbound forwarded queries might sometimes result inSERVFAIL errors. For information about how to work around this issue, see Outbound forwarded queries receive SERVFAIL errors.

PTR records for RFC 1918 addresses in private zones

To perform reverse lookups with custom PTR records for RFC 1918 addresses, you must create a Cloud DNS private zone that is at least as specific as one of the following example zones. This is a consequence of the longest suffix matching described in VPC name resolution order earlier in this document.

Example zones include the following:

  • 10.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 16.172.in-addr.arpa., 17.172.in-addr.arpa., ... through 31.172.in-addr.arpa.

If you create a Cloud DNS private zone for RFC 1918 addresses, custom PTR records that you create for VMs in that zone are overridden by the PTR records that internal DNS creates automatically. This is because internal DNS PTR records are created in the previous list of more specific zones.

For example, suppose you create a managed private zone for in-addr.arpa. with the following PTR record for a VM whose IP address is 10.1.1.1:

1.1.1.10.in-addr.arpa. -> test.example.domain

PTR queries for 1.1.1.10.in-addr.arpa. are answered by the more specific 10.in-addr.arpa. internal DNS zone. The PTR record in your Cloud DNS private zone for test.example.domain is ignored.

To override the automatically created internal DNS PTR records for VMs, make sure that you create your custom PTR records in a private zone that is at least as specific as one of the zones presented in this section. For example, if you create the following PTR record in a private zone for 10.in-addr.arpa., your record overrides the automatically generated one: 1.1.1.10.in-addr.arpa. -> test.example.domain.

If you only need to override a portion of a network block, you can create more specific reverse Cloud DNS private zones. For example, a private zone for 5.10.in-addr.arpa. can be used to hold PTR records that override any internal DNS PTR records that are automatically created for VMs with IP addresses in the 10.5.0.0/16 address range.

Supported DNS record types

Cloud DNS supports the following types of records.

Record type Description
A

Address record, which maps host names to their IPv4 address.

AAAA

IPv6 address record, which maps host names to their IPv6 address.

CAA

Certificate Authority (CA) Authorization, which specifies which CAs are allowed to create certificates for a domain.

CNAME

Canonical name record, which specifies alias names.

Cloud DNS does not support resolving CNAMEs recursively across different managed private zones (CNAME chasing). For details, see CNAME record defined in a private zone not working.

IPSECKEY

IPsec tunnel gateway data and public keys for IPsec-capable clients to enable opportunistic encryption.

MX

Mail exchange record, which routes requests to mail servers.

NAPTR

Naming authority pointer record, defined by RFC 3403.

NS

Name server record, which delegates a DNS zone to an authoritative server.

PTR

Pointer record, which is often used for reverse DNS lookups.

SOA

Start of authority record, which specifies authoritative information about a DNS zone. An SOA resource record is created for you when you create your managed zone. You can modify the record as needed (for example, you can change the serial number to an arbitrary number to support date-based versioning).

SPF

Sender Policy Framework record, a deprecated record type formerly used in email validation systems (use a TXT record instead).

SRV

Service locator record, which is used by some voice over IP (VoIP), instant messaging protocols, and other applications.

SSHFP

SSH fingerprint for SSH clients to validate the public keys of SSH servers.

TLSA

TLS authentication record for TLS clients to validate X.509 server certificates.

TXT

Text record, which can contain arbitrary text and can also be used to define machine-readable data, such as security or abuse prevention information.

A TXT record can contain one or more text strings; the maximum length of each individual string is 255 characters. Mail agents and other software agents concatenate multiple strings. Enclose each string in quotation marks.

For example:

          "Hello world" "Bye world"
          

To work with DNS records, see Managing records.

Wildcard DNS records

Wildcard records are supported for all record types, except for NS records.

DNSSEC

Cloud DNS supports managed DNSSEC, protecting your domains from spoofing and cache poisoning attacks. When you use a validating resolver like Google Public DNS, DNSSEC provides strong authentication (but not encryption) of domain lookups. For more information about DNSSEC, see Managing DNSSEC configuration.

Forwarding zones

Cloud DNS forwarding zones let you configure target name servers for specific private zones. Using a forwarding zone is one way to implement outbound DNS forwarding from your VPC network.

A Cloud DNS forwarding zone is a special type of Cloud DNS private zone. Instead of creating records within the zone, you specify a set of forwarding targets. Each forwarding target is an IP address of a DNS server, located in your VPC network, or in an on-premises network connected to your VPC network by Cloud VPN or Cloud Interconnect.

Forwarding targets and routing methods

Cloud DNS supports three types of targets and offers standard or private methods for routing traffic to them.

Forwarding target Description Standard routing supports Private routing supports Source of requests
Type 1 An internal IP address of a Google Cloud VM in the same VPC network that is authorized to use the forwarding zone. Only RFC 1918 IP addresses—traffic always routed through an authorized VPC network. Any internal IP address, including non-RFC 1918 private IP addresses and privately re-used public IP addresses—traffic always routed through an authorized VPC network. 35.199.192.0/19
Type 2 An IP address of an on-premises system, connected to the VPC network authorized to query the forwarding zone, using Cloud VPN or Cloud Interconnect. Only RFC 1918 IP addresses—traffic always routed through an authorized VPC network. Any internal IP address, including non-RFC 1918 private IP addresses and privately re-used public IP addresses—traffic always routed through an authorized VPC network. 35.199.192.0/19
Type 3 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—make sure that private routing is not selected. Google Public DNS source ranges

You can choose one of the two following routing methods when you add the forwarding target to the forwarding zone:

  • Standard routing: Routes traffic through an authorized VPC network or over the internet based on whether the forwarding target is an RFC 1918 IP address. If the forwarding target is an RFC 1918 IP address, Cloud DNS classifies the target as either a Type 1 or Type 2 target, and routes requests through an authorized VPC network. If the target is not an RFC 1918 IP address, Cloud DNS classifies the target as Type 3, and expects the target to be internet accessible.

  • Private routing: Always routes traffic through an authorized VPC network, regardless of the target's IP address (RFC 1918 or not). Consequently, only Type 1 and Type 2 targets are supported.

To access a Type 1 or a Type 2 forwarding target, Cloud DNS uses routes in the authorized VPC network where the DNS client is located. These routes define a secure path to the forwarding target:

For additional guidance about network requirements for Type 1 and Type 2 targets, see forwarding target network requirements.

Using forwarding zones

VMs in a VPC network can use a Cloud DNS forwarding zone in the following cases:

  • The VPC network has been authorized to use the Cloud DNS forwarding zone. You can authorize multiple VPC networks in the same project to use the forwarding zone.
  • The guest operating system of each VM in the VPC network uses the VM's metadata server 169.254.169.254 as its name server.

Overlapping forwarding zones

Because Cloud DNS forwarding zones are a type of Cloud DNS managed private zone, you can create multiple zones that overlap. VMs configured as described earlier resolve a record according to the VPC name resolution order, using the zone with the longest suffix. For more information, see Overlapping zones.

Caching and forwarding zones

Cloud DNS caches responses for queries sent to Cloud DNS forwarding zones. Cloud DNS maintains a cache of responses from reachable forwarding targets for the shorter of the following time spans:

  • 60 seconds
  • The duration of the record's time-to-live (TTL)

When all of the forwarding targets for a forwarding zone become unreachable, Cloud DNS maintains its cache of the previously requested records in that zone for the duration of each record's TTL.

When to use peering instead

Cloud DNS cannot use transitive routing to connect to a forwarding target. To illustrate an invalid configuration, consider the following scenario:

  • You've used Cloud VPN or Cloud Interconnect to connect an on-premises network to a VPC network named vpc-net-a.

  • You've used VPC Network Peering to connect VPC network vpc-net-a to vpc-net-b. You've configured vpc-net-a to export custom routes, and vpc-net-b to import them.

  • You've created a forwarding zone whose forwarding targets are located in the on-premises network to which vpc-net-a is connected. You've authorized vpc-net-b to use that forwarding zone.

Resolving a record in a zone served by the forwarding targets fails in this scenario, even though there is connectivity from vpc-net-b to your on-premises network. To demonstrate this failure, perform the following tests from a VM in vpc-net-b:

  • Query the VM's metadata server 169.254.169.254 for a record defined in the forwarding zone. This query fails (expectedly) because Cloud DNS does not support transitive routing to forwarding targets. To use a forwarding zone, a VM must be configured to use its metadata server.

  • Query the forwarding target directly for that same record. Although Cloud DNS does not use this path, this query demonstrates that transitive connectivity succeeds.

You can use a Cloud DNS peering zone to fix this invalid scenario:

  1. Create a Cloud DNS peering zone authorized for vpc-net-b that targets vpc-net-a.
  2. Create a forwarding zone authorized for vpc-net-a whose forwarding targets are on-premises name servers.

You can perform these steps in any order. After completing these steps, Compute Engine instances in both vpc-net-a and vpc-net-b can query the on-premises forwarding targets.

DNS peering

DNS peering lets you send requests for records that come from one zone's namespace to another VPC network. For example, a SaaS provider can give a SaaS customer access to DNS records it manages.

To provide DNS peering, you must create a Cloud DNS peering zone and configure it to perform DNS lookups in a VPC network where the records for that zone's namespace are available. The VPC network where the DNS peering zone performs lookups is called the DNS producer network.

To use DNS peering, you must authorize a network to use a peering zone. The VPC network authorized to use the peering zone is called the DNS consumer network.

After Google Cloud resources in the DNS consumer network are authorized, they can perform lookups for records in the peering zone's namespace as if they were in the DNS producer network. Lookups for records in the peering zone's namespace follow the DNS producer network's name resolution order.

Therefore, Google Cloud resources in the DNS consumer network can look up records in the zone's namespace from the following sources available in the DNS producer network:

  • Cloud DNS managed private zones authorized for use by the DNS producer network.
  • Cloud DNS managed forwarding zones authorized for use by the DNS producer network.
  • Compute Engine internal DNS names in the DNS producer network.
  • An alternative name server, if an outbound server policy has been configured in the DNS producer network.

DNS peering limitations

Keep the following in mind when configuring DNS peering:

  • DNS peering is a one-way relationship. It allows Google Cloud resources in the DNS consumer network to look up records in the peering zone's namespace as if the Google Cloud resources were in the DNS producer network.
  • The DNS producer and consumer networks must be VPC networks.
  • DNS peering and VPC Network Peering are different services. DNS peering can be used with VPC Network Peering, but VPC Network Peering is not required for DNS peering.
  • Transitive DNS peering is supported, but only through a single transitive hop. In other words, no more than three VPC networks (with the network in the middle being the transitive hop) can be involved. For example, you can create a peering zone in vpc-net-a that targets vpc-net-b, and then create a peering zone in vpc-net-b that targets vpc-net-c.
  • If you are using DNS peering to target a forwarding zone, the target VPC network with the forwarding zone must contain a VM, an interconnect attachment (VLAN), or a Cloud VPN tunnel located in the same region as the source VM that uses the DNS peering zone. For details about this limitation, see Forwarding queries from VMs in a consumer VPC network to a producer VPC network not working.

To create a peering zone, you must have the DNS Peer IAM role for the project that contains the DNS producer network.

Overlapping zones

Two zones overlap with each other when the origin domain name of one zone is either identical to or is a subdomain of the origin of the other zone. For example:

  • A zone for gcp.example.com and another zone for gcp.example.com overlap because the domain names are identical.
  • A zone for dev.gcp.example.com and a zone for gcp.example.com overlap because dev.gcp.example.com is a subdomain of gcp.example.com.

Rules for overlapping zones

Cloud DNS enforces the following rules for overlapping zones:

  • Overlapping public zones are not allowed on the same Cloud DNS name servers. When you create overlapping zones, Cloud DNS attempts to put them on different name servers. If that is not possible, Cloud DNS fails to create the overlapping zone.

  • A private zone can overlap with any public zone.

  • Private zones scoped for different VPC networks can overlap with each other. For example, two VPC networks can each have a database VM named database.gcp.example.com in a zone gcp.example.com. Queries for database.gcp.example.com receive different answers according to the zone records defined in the zone authorized for each VPC network.

  • Two private zones that have been authorized to be accessible from the same VPC network cannot have identical origins unless one zone is a subdomain of the other. The metadata server uses longest suffix matching to determine which origin to query for records in a given zone.

Query resolution examples

Google Cloud resolves Cloud DNS zones as described in VPC name resolution order. When determining the zone to query for a given record, Cloud DNS tries to find a zone that matches as much of the requested record as possible (longest suffix matching).

Unless you have specified an alternative name server in an outbound server policy, Google Cloud first attempts to find a record in a private zone (or forwarding zone or peering zone) authorized for your VPC network before it looks for the record in a public zone.

The following examples illustrate the order that the metadata server uses when querying DNS records. For each of these examples, suppose that you have created two private zones, gcp.example.com and dev.gcp.example.com, and authorized access to them from the same VPC network. Google Cloud handles the DNS queries from VMs in a VPC network in the following way:

  • The metadata server uses public name servers to resolve a record for myapp.example.com because there is no private zone for example.com that has been authorized for the VPC network.

  • The metadata server resolves the record myapp.gcp.example.com using the authorized private zone gcp.example.com because gcp.example.com is the longest common suffix between the requested record name and available authorized private zones. NXDOMAIN is returned if there's no record for myapp.gcp.example.com defined in the gcp.example.com private zone, even if there is a record for myapp.gcp.example.com defined in a public zone.

  • Similarly, queries for myapp.dev.gcp.example.com are resolved according to records in the authorized private zone dev.gcp.example.com. NXDOMAIN is returned if there is no record for myapp.dev.gcp.example.com in the dev.gcp.example.com zone, even if there is a record for myapp.dev.gcp.example.com in another private or public zone.

  • Queries for myapp.prod.gcp.example.com are resolved according to records in the private zone gcp.example.com because gcp.example.com is the longest common suffix between the requested DNS record and the available private zones.

Split horizon DNS example

You can use a combination of public and private zones in a split horizon DNS configuration. Private zones enable you to define different responses to a query for the same record when the query originates from a VM within an authorized VPC network. Split horizon DNS is useful whenever you need to provide different records for the same DNS queries depending on the originating VPC network.

Consider the following split horizon example:

  • You've created a public zone, gcp.example.com, and you've configured its registrar to use Cloud DNS name servers.
  • You've created a private zone, gcp.example.com, and you've authorized your VPC network to access this zone.

In the private zone, you've created a single record as shown in the following table.

Record Type TTL (seconds) Data
foo.gcp.example.com A 5 10.128.1.35

In the public zone, you've created two records.

Record Type TTL (seconds) Data
foo.gcp.example.com A 5 104.198.6.142
bar.gcp.example.com A 50 104.198.7.145

The following queries are resolved as described:

  • A query for foo.gcp.example.com from a VM in your VPC network returns 10.128.1.35.
  • A query for foo.gcp.example.com from the internet returns 104.198.6.142.
  • A query for bar.gcp.example.com from a VM in your VPC network returns an NXDOMAIN error because there’s no record for bar.gcp.example.com in the private zone gcp.example.com.
  • A query for bar.gcp.example.com from the internet returns 104.198.7.145.

DNS server policies

You can configure one DNS server policy for each 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 policy

Each VPC network provides DNS name resolution services to the VMs that use it. When a VM uses its metadata server 169.254.169.254 as its name server, Google Cloud searches for DNS records according to the VPC name resolution order.

By default, a VPC network's name resolution services—through its name resolution order—are only available to that VPC network itself. You can create an inbound server policy in your VPC network to make these name resolution services available to an on-premises network that is connected using Cloud VPN or Cloud Interconnect.

When you create an inbound server policy, Cloud DNS takes an internal IP address from the primary IP address range of a subnet in each region that your VPC network uses. It uses these internal IP addresses as entry points for inbound DNS requests.

Inbound server policy entry points

The regional internal IP addresses used by Cloud DNS for the inbound server policy serve as entry points into the name resolution services of the VPC network. To use the inbound server policy, you must configure your on-premises systems or name servers to forward DNS queries to the proxy IP address located in the same region as the Cloud VPN tunnel or Cloud Interconnect attachment (VLAN) that connects your on-premises network to your VPC network.

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

Outbound server policy

You can change the VPC name resolution order by creating an outbound server policy that specifies a list of alternative name servers. When you specify alternative name servers for a VPC network, those servers are the only name servers that Google Cloud queries when handling DNS requests from VMs in your VPC network that are configured to use their metadata servers (169.254.169.254).

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

Alternative name servers and routing methods

Cloud DNS supports three types of alternative name servers and offers standard and private routing methods for routing traffic to them.

Alternative name servers are defined in the following table.

Alternative name server Description Standard routing supports Private routing supports Source of requests
Type 1 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, including non-RFC 1918 private IP addresses and privately re-used public IP addresses—traffic always routed through an authorized VPC network. 35.199.192.0/19
Type 2 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, including non-RFC 1918 private IP addresses and privately re-used public IP addresses—traffic always routed through an authorized VPC network. 35.199.192.0/19
Type 3 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

You can choose one of the following routing methods when you specify the alternative name server of an outbound server policy:

  • Standard routing: Routes traffic through an authorized VPC network or over the internet based on whether the alternative name server is an RFC 1918 IP address. 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 requests through an authorized VPC network. If the alternative name server is not an RFC 1918 IP address, Cloud DNS classifies the name server as Type 3, and expects the name server to be internet accessible.

  • Private routing: Always routes traffic through an authorized VPC network, regardless of the alternative name server's IP address (RFC 1918 or not). Consequently, only Type 1 and Type 2 name servers are supported.

To access a Type 1 or a Type 2 alternative name server, Cloud DNS uses routes in the authorized VPC network, where the DNS client is located. These routes define a secure path to the name server:

For additional guidance about network requirements for Type 1 and Type 2 name servers, see alternative name server network requirements.

Access control

You can manage the users who are allowed to make changes to your DNS records on the IAM & Admin page in the Google Cloud Console. For users to be authorized to make changes, they must have either the Editor role (roles/editor) or Owner role (roles/owner) in the Permissions section of the Cloud Console. The Viewer role (roles/viewer) grants read-only access to the Cloud DNS records.

These permissions also apply to service accounts that you might use to manage your DNS services.

Access control for managed zones

Users with the project Owner role or Editor role can manage or view the managed zones in the specific project that they are managing.

Users with the DNS Administrator role or DNS Reader role (roles/dns.admin or roles/dns.reader) can manage or view the managed zones across all the projects that they have access to.

Project Owners, Editors, DNS Administrators, and DNS Readers can view the list of private zones applied to any VPC network in the current project.

Performance and timing

Cloud DNS uses anycast to serve your managed zones from multiple locations around the world for high availability. Requests are automatically routed to the nearest location, reducing latency and improving authoritative name lookup performance for your users.

Propagation of changes

Changes are propagated in two parts. First, the change that you send through the API or command-line tool must be pushed to Cloud DNS's authoritative DNS servers. Second, DNS resolvers must pick up this change when their cache of the records expires.

The time-to-live (TTL) value that you set for your records, which is specified in seconds, controls the DNS resolver's cache. For example, if you set a TTL value of 86400 (the number of seconds in 24 hours), the DNS resolvers are instructed to cache the records for 24 hours. Some DNS resolvers ignore the TTL value or use their own values, which can delay the full propagation of records.

If you are planning for a change to services that requires a narrow window, you might want to change the TTL to a shorter value before making your change. This approach can help reduce the caching window and ensure a quicker change to your new record settings. After the change, you can change the value back to its previous TTL value to reduce load on the DNS resolvers.

What's next