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


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

When to use Cloud DNS

DNS is a hierarchical distributed database that lets you store IP addresses and other data, and look them up by name. Google 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 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.
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.
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.
Zone operations
Any changes that you make to managed zones in Google 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.
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.

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 Google Cloud DNS. The DNSKEYs collection has all the information that domain registrars require to activate DNSSEC.

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.


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.


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"

Wildcard DNS records

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


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

Access control

You can manage the users that are allowed to make changes to your DNS records in 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.

Performance and timing

Google 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