This page provides an overview of Cloud DNS features and capabilities. To get started using Cloud DNS, see the Quickstart.


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 the DNS without the burden of managing your own DNS servers and software.

General DNS concepts

For a list of general DNS terminology, refer to RFC 7719.

Cloud DNS offers both public 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 VPC networks that you specify.

Private zones enable you to create split horizon DNS configurations because you can create a private zone with a different set of DNS records, specific to your VPC network.

Cloud DNS concepts

The Cloud DNS API is built around projects, managed zones, record sets, and changes to record sets.

A Google Cloud Platform Console project is a container for resources, a domain for access control, and the place where billing is configured and aggregated. Every Cloud DNS resource lives within a project and every Cloud DNS operation must specify the project to work with.
Managed zones
The managed zone holds DNS records for the same DNS name suffix (example.com, for example). A project can have multiple managed zones, but they must each have a unique name. In Cloud DNS, the managed zone is the resource that models a DNS zone. All records in a managed zone are hosted on the same Google-operated name servers. These name servers respond to DNS queries against your managed zone according to how you configure the zone. A project can contain multiple managed zones. Charges accrue for each zone for each day that the managed zone exists. Managed zones support labels, which you can use to help organize your billing. Managing Zones explains how to manage records within the zones.
Public zones

A public zone is visible to the Internet. Cloud DNS has public authoritative name servers that respond to queries about public zones regardless of where the queries originate. You can create DNS records in a public zone to publish your service on the Internet. For example, you might create the following record in a public zone example.com for your public web site www.example.com.

DNS Name Type TTL (seconds) Data
www.example.com A 300 [public_ip_address]

Cloud DNS assigns a set of name servers when a public zone is created. For the DNS records in a public zone to be resolvable over the Internet, you must update the name server setting of your domain registration at your registrar.

Private zones

Private zones enable you to manage custom domain names for your virtual machines, load balancers, and other GCP resources without exposing the underlying DNS data to the public Internet. A private zone is a container of DNS records that can only be queried by one or more VPC networks that you authorize.

A private zone can only be queried by resources in the same project where it is defined. The VPC networks that you authorize must be located in the same project as the private zone. You can override this restriction by setting up DNS peering with another network.

You specify the list of authorized VPC networks that can query your private zone when you create or update it. Only authorized networks are allowed to query your private zone; if you do not specify any authorized networks, you cannot query the private zone at all.

You can use private zones with Shared VPC. Refer to Private zones and Shared VPC on this page for important information about using private zones with Shared VPC networks.

Private zones do not support DNS security extensions (DNSSEC).

Requests for DNS records in private zones must be submitted through the metadata server,, which is the default internal name server for VMs created from Google-supplied images. You can submit queries to this name server from any VM that uses an authorized VPC network.

For example, you can create a private zone for dev.gcp.example.com to host internal DNS records for experimental applications. The following table shows example records in that zone. Database clients can connect to the database server, db-01.dev.gcp.example.com, using its internal DNS name instead of its IP address. Database clients resolve this internal DNS name using the host resolver on the VM, which submits the DNS query to the metadata server, The metadata server acts as a recursive resolver to query your private zone.

DNS Name Type TTL (seconds) Data
db-01.dev.gcp.example.com A 5
instance-01.dev.gcp.example.com A 50
Forwarding zones

You can set up DNS forwarding between non-GCP name servers and GCP's internal name servers. See DNS forwarding for more information.

Peering zones

When two networks are peered they do not automatically share DNS information with each other. You can set up DNS peering between two VPC networks so that when a resource on a customer network makes a DNS request, the request is forwarded to the DNS resolver on the producer network.

Zone operations

Any changes that you make to managed zones in Cloud DNS are recorded in the operations collection, which lists managed zone updates (modifying descriptions or DNSSEC state or configuration).


A domain name registrar is an organization that manages the reservation of Internet domain names. A registrar must be accredited by a generic top-level domain (gTLD) registry or a country code top-level domain (ccTLD) registry.

Internal DNS

GCP creates internal DNS names for VMs automatically, even if you do not use Cloud DNS. For more information about internal DNS, refer to the internal DNS documentation.

Delegated subzones

DNS allows the owner of a zone to delegate a subdomain to a different name server using NS records. Resolvers follow these records and send queries for the subdomain to the target name server specified in the delegation.

Resource record sets collection

The resource record sets collection holds the current state of the DNS records that make up a managed zone. You can read this collection but you do not modify it directly. Rather, you edit the resource record sets in a managed zone by creating a Change request in the changes collection. The resource record sets collection reflects all your changes immediately. However, there is a delay between when changes are made in the API and the time that they take effect at your authoritative DNS servers. Managing Records explains how to manage records.

Resource record changes

When you want to make a change to the resource record sets collection, you submit a Change request containing additions or deletions. Additions and deletions can be done in bulk, in a single atomic transaction, and take effect at the same time in each authoritative DNS server.

The diagram below illustrates a simultaneous add and delete:

../managedZones/examplezone (example.com)
example.com.  SOA  admin@example.com.
example.com.  NS   zns-1.google.com.
example.com.  MX   10 mail.example.com.
www           A
3  user2@    2014-03-31T18:59:23.587Z  PENDING
   DEL  www  A
   ADD  www  A
2  user1@    2014-03-31T16:34:18.58Z  DONE
1  devops@   2014-03-28T12:46:09.23Z  DONE
../managedZones/myorg (example.org)
example.org.  SOA  admin@example.org.
example.org.  NS   zns-1.google.com.
www           A
2  user2@    2014-04-02T18:53:55.132Z  PENDING
   DEL  www  A
   ADD  www  A
1  devops@   2014-03-230T07:22:35.192Z  DONE

You can have multiple managed zones in a project.

SOA serial number format

The serial numbers of SOA records created in Cloud DNS managed zones monotonically increase with each transactional change to a zone's record sets made using the gcloud dns record-sets transaction command. You are free to manually change the serial number of an SOA record to an arbitrary number, however, including an ISO 8601-formatted date as recommended in RFC 1912. For example, in the following SOA record:

ns-gcp-private.googledomains.com. cloud-dns-hostmaster.google.com. [serial number] 21600 3600 259200 300

You can change the serial number directly from the Google Cloud Platform Console by entering the desired value into the third space-delimited field of the record.

DNS Server Policy

A DNS server policy allows you access to name resolution services provided by GCP in a VPC network with inbound forwarding, or change the VPC name resolution order with outbound forwarding.

Domains, Subdomains, and Delegation

Most subdomains are just records in the managed zone for the parent domain. Subdomains that are delegated by creating NS (name server) records in their parent domain's zone need to have their own zones as well. Create managed zones for parent domains in Cloud DNS before creating any zones for their delegated subdomains. Do this even if you are hosting the parent domain on another DNS service. If you have several subdomain zones but don't create the parent zone, it can be complicated to create the parent zone if you later decide to move it to Cloud DNS.


The Domain Name System Security Extensions (DNSSEC) is a suite of Internet Engineering Task Force (IETF) extensions to DNS which authenticate responses to domain name lookups. DNSSEC does not provide privacy protections for those lookups, but prevents attackers from manipulating or poisoning the responses to DNS requests.

DNSKEYs collection

The DNSKEYs collection holds the current state of the DNSKEY records used to sign a DNSSEC-enabled managed zone. You can only read this collection; all changes to the DNSKEYs are made by Cloud DNS. The DNSKEYs collection has all the information that domain registrars require to activate DNSSEC.

VPC name resolution order

Each VPC network provides DNS name resolution services to the VM instances that use it. When VMs use their metadata server,, as their name server, GCP searches for DNS records according to the following order:

  1. If a DNS policy that specifies an alternative name server for outbound forwarding has been configured for the VPC network, GCP forwards all DNS queries to that server only. See outbound DNS forwarding using an alternative name server for more details.
  2. GCP queries the following GCP name resolution services, in order, using longest-suffix matching:
    • GCP queries all Cloud DNS managed private forwarding zones that have been authorized for the VPC network, sending requests to the IP addresses of the forwarding targets.
    • GCP queries all Cloud DNS managed private zones that have been authorized for the VPC network for records in those zones.
    • GCP searches the automatically created Compute Engine internal DNS records for the project.
  3. GCP queries publicly available zones, following the appropriately configured start-of-authority (SOA). This includes Cloud DNS public zones.

Using PTR records in private zones

As a consequence of the longest-prefix matching described in VPC name resolution order, in order to perform reverse lookups with custom PTR records, you should create a Cloud DNS private zone that is at least as specific as one of 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 in-addr.arpa., custom PTR records for VM instances that you create in that zone are hidden by the PTR records that Compute Engine internal DNS creates automatically. This is because Compute Engine 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 instance whose IP address is -> test.example.domain

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

To override the automatically created Compute Engine 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: -> test.example.domain

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

Supported DNS record types

Cloud DNS supports the following types of records:

Record type Description

Address record, which is used to map host names to their IPv4 address.


IPv6 Address record, which is used to map host names to their IPv6 address.


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


Canonical name record, which is used to specify alias names.
Cloud DNS does not support resolving CNAMEs recursively across different managed private zones (CNAME chasing). Refer to troubleshooting for details.


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


Mail exchange record, which is used in routing requests to mail servers.


Naming authority pointer record, defined by RFC 3403.


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


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


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


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


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


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


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


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 may contain one or more text strings; the maximum length of each individual string is 255 characters. Mail agents and other software agents will concatenate multiple strings. Enclose each string in quotation marks. For example:

"Hello world" "Bye world"

Managing Records shows how to work with DNS records.

Wildcard DNS records

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


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.

You can enable DNSSEC for a managed zone with this command:

gcloud dns managed-zones update my-zone --dnssec-state on

Newly created zones can also have DNSSEC enabled as well:

gcloud dns managed-zones create my-zone \
    --description "Signed Zone" --dns-name myzone.example --dnssec-state=on

There are also a number of DNSSEC parameters you can specify if the default settings are not appropriate for your deployment.

DNS forwarding

You can set up DNS forwarding between your non-GCP name servers and GCP's internal name servers. Configuring bi-directional forwarding allows instances in your VPC network to look up the addresses of hosts in your on-premises or multi-cloud networks and allows hosts on linked networks to look up addresses for resources in your VPC network.

GCP supports DNS forwarding in the following ways:

  • VPC networks support both inbound and outbound DNS forwarding using DNS server policies. Inbound requests must originate from systems in networks connected to the VPC by Cloud VPN tunnel or Cloud Interconnect, such as an on-premises data center.

  • Cloud DNS private managed zones support outbound DNS forwarding by means of forwarding zones.

The following example illustrates two VPC networks, prod and dev, that have DNS forwarding configured:

DNS forwarding with on-premises DNS servers (click to enlarge)
DNS forwarding with on-premises DNS servers (click to enlarge)
  • The dev network is connected to an on-premises data center in Europe with a Cloud VPN tunnel using dynamic routing.
  • The prod network is connected to on-premises data centers in Asia, Europe, and the US with Cloud VPN tunnels using dynamic routing.
  • All networks have been configured to use global dynamic routing.
  • All three data centers are connected to one another. IP addresses used by each on-premises and VPC network are RFC 1918 IP addresses, and they do not overlap.
  • On-premises BIND servers are located at each on-premises data center, and those name servers are configured in a redundant fashion to serve the corp.example.com zone.
  • You have created DNS policies for both the dev and prod Cloud VPN networks to enable outbound forwarding to the on-premises name servers.
  • VMs in GCP use their metadata server,, to resolve GCP internal DNS, any authorized Cloud DNS private zones for the respective dev or prod networks, public DNS zones, and your on-premises corp.example.com zone.

DNS server policy

A DNS server policy allows you to configure inbound and outbound DNS forwarding for a VPC network. You can apply one DNS server policy to a given VPC network.

See using DNS server policies for step-by-step directions.

Inbound DNS forwarding

Each VPC network provides DNS name resolution services to the VM instances that use it. When VMs use their metadata server,, as their name server, GCP searches for DNS records according to the VPC name resolution order.

By default, the VPC network's name resolution services are not available outside of that network. You can make them available to systems in on-premises networks connected using Cloud VPN or Cloud Interconnect by creating a DNS policy to enable inbound DNS forwarding to the VPC network. When enabled, systems in the connected networks can query an internal IP address in your VPC network in order to make use of its name resolution services.

See creating a DNS policy that enables inbound DNS forwarding for how to configure a DNS policy that allows inbound forwarding to your VPC network. When configured, GCP allocates an internal IP address in a subnet (in a region) of your VPC network to serve as a proxy for inbound DNS requests. You can specify a region or let GCP choose one automatically. Each DNS policy for inbound DNS forwarding allocates a single proxy IP address for inbound requests; however, this single IP address merely serves as an entry point into the name resolution services of the VPC network. You can then configure your on-premises name servers to forward to the proxy address as necessary.

Outbound DNS forwarding using an alternative name server

You can change the VPC name resolution order by creating a DNS policy that specifies a list of alternative name servers. When you do this, the alternative name servers become the only source that GCP queries for all DNS requests submitted by VMs in the VPC using their metadata server,

See creating a DNS policy that enables an alternative name server for how to configure a DNS policy for outbound forwarding. If you specify alternative name servers using RFC 1918 IP addresses, those must be either internal IP addresses of other GCP VMs in your VPC network or systems in your on-premises network connected to your VPC network using Cloud VPN or Cloud Interconnect. If you specify alternative name servers using public IP addresses, they must be accessible on the Internet.

DNS forwarding zones

In addition to an alternative name server, another form of outbound DNS forwarding is available through the definition of a forwarding zone. This is similar in setup to a private zone in that it is associated with a DNS name and can be bound to multiple networks. However, the forwarding zone does not contain any records. All matching queries for a forwarding zone are forwarded to a set of destination DNS servers instead. As is the case with alternative name server, the destination is a list of IP addresses.

The system attempts to resolve the name through all destination name servers. In the above example, matching queries are forwarded to either all or a subset of,, and Note that the system may change the resolution strategy given server responsiveness and changing network conditions.

When the forwarding conditions of multiple forwarding zones overlap with each other, the zone with the longest-match for a query trumps the others. For example, assuming a DNS server contains three forwarding zones:

  • Forwarding zone 1: onprem.example.com, destination:
  • Forwarding zone 2: dev.onprem.example.com, destination:
  • Forwarding zone 3: prod.onprem.example.com, destination:

A query for mysvc.onprem.example.com is forwarded according to zone 1; a query for mysvc.dev.onprem.example.com is forwarded to according to zone 2; a query for mysvc.prod.onprem.example.com is forwarded to according to zone 3.

See Creating forwarding zones for instructions.

DNS peering

DNS peering allows one VPC network to forward specified DNS requests to another VPC network.

When you peer two VPC networks using VPC Network Peering, the instances in the peered networks can reach each other using internal IP addresses. However, peered networks do not automatically exchange DNS information. DNS peering allows you to configure a DNS peering zone on one network (consumer network) that forwards the DNS requests it is configured to handle to the DNS resolver in another network (producer network).

DNS peering is one way: a single peering relationship allows one network to forward DNS requests to another network. Bi-directional peering requires two peering relationships.

To establish DNS peering, you need the following:

  • one or more private or forwarding zones in the network that resolves the DNS requests
  • a peering zone in the network that forwards the request to the other network
  • permission, via the dns.peer IAM role, for the peering zone to forward requests the network with the private zone

Use case

SaaS example

An SaaS provider (producer) wants to give their SaaS customer (consumer) access to a service hosted in a peered network. The producer creates a network that hosts the service, then peers it with the consumer network. The producer also wants to provide the DNS names that the consumers use to access the service.

The consumer may grant the producer use of a service account that the producer can use to create a peering zone in the consumer network. The producer also grants that service account the dns.peer role in their own network, so requests from peering zone can reach the resolver zone. Or, the producer can instruct the consumer how to do the correct setup.

Intra-organization setup

Ordinarily, a private zone can be configured such that every network in a project can reach it. However, an organization may have many projects, but want every network in every project to use a single private zone for all internal resolution. This can be accomplished by creating a private zone in one project, then creating peering zones for every other project to point to the private zone.

What's next for peering zones

See Configuring peering zones for instructions.

Private zones and Shared VPC

To use private zones with Shared VPC you must create your private zone in the host project, and you must add the appropriate Shared VPC network to the list of authorized networks for that zone.

Overlapping zones

A project can have multiple managed 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, dev.gcp.example.com and gcp.example.com are overlapping zones.

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

Overlapping is permitted between public and private zones.

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 will receive different answers according to the zone records defined for the respective VPC networks. For more information, refer to split horizon DNS.

Query resolution with overlapping zones

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 in determining which origin to query for records in a given zone.

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

  • The metadata server uses public name servers to resolve myapp.example.com because there is no private zone for example.com.
  • The metadata server resolves myapp.gcp.example.com using the private zone gcp.example.com because gcp.example.com is the longest common suffix between the requested DNS record and available 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 name server.
  • Similarly, queries for myapp.dev.gcp.example.com are resolved according to records in the private zone dev.gcp.example.com. NXDOMAIN is returned if there’s 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

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. Split horizon DNS is useful if you have separate development, corporate, and production VPC networks:

  • You can define a private zone and authorize access from a development VPC network so that queries from VMs in that network for DNS records in that zone are directed to other VMs in the same network.
  • You can define a second private zone serving the same DNS records (names) with different answers, authorizing access from a corporate network.
  • You can define a third, public zone serving the same DNS records with appropriate public answers suitable for production.

For example, suppose you have created both a public zone and a private zone for gcp.example.com, you've configured the registrar for gcp.example.com to use Cloud DNS name servers, so that your public zone is accessible on the Internet, and you've authorized access to the private zone from your VPC network.

In the private zone, you create a single record:

DNS Name Type TTL (seconds) Data
foo.gcp.example.com A 5

In the public zone, you create two records:

DNS Name Type TTL (seconds) Data
foo.gcp.example.com A 5
bar.gcp.example.com A 50

The following examples illustrate how queries to DNS records are resolved:

  • A query for foo.gcp.example.com from a VM in your VPC network returns
  • A query for foo.gcp.example.com from the Internet returns
  • 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

Access control

General 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 Platform Console. For users to be authorized to make changes, they must be listed as either an editor or owner in the Permissions section of the GCP Console. The viewer permission level 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 or Project editor role can manage or view the managed zones in the specific project that they are managing.

Users with the DNS Administrator or DNS Reader role can manage or view the managed zones across all the projects that they have access to.

Project owners, editors, DNS admins and 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 DNS resolver's cache is controlled by the time-to-live (TTL) value that you set for your records, which is specified in seconds. 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 that 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 prior to 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.

Next steps

To get started using Cloud DNS, see the Quickstart.

Was this page helpful? Let us know how we did:

Send feedback about...

Cloud DNS Documentation