Overview

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

Introduction

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.

Cloud DNS concepts

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

Project
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. Managing Zones explains how to manage records.
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:

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

You can have multiple managed zones in a project.


Supported DNS record types

Cloud DNS supports the following types of records:

Record type Description
A

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

AAAA

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

CAA

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

CNAME

Canonical name record, which is used to specify alias names.

MX

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

NAPTR

Naming authority pointer record, defined by RFC3403.

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.

SPF

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

SRV

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

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.

Wildcard DNS records

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

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

Monitor your resources on the go

Get the Google Cloud Console app to help you manage your projects.

Send feedback about...

Cloud DNS Documentation