Please note that the contents of this offline web site may be out of date. To access the most recent documentation visit the online version .
Note that links that point to online resources are green in color and will open in a new window.
We would love it if you could give us feedback about this material by filling this form (You have to be online to fill it)



What is Google Cloud DNS?

Google Cloud DNS is a high-performance, resilient, global DNS service that provides a cost-effective way to make your applications and services available to your users. This programmable, authoritative DNS service can be used to easily publish and manage DNS records using the same infrastructure relied upon by Google.

Overview

The Domain Name System (DNS) is a hierarchical distributed database that lets you store IP addresses and other data and look it 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. You use the gcloud tool or the REST API directly to work with Cloud DNS. The following sections provide an overview of the components of the DNS system and how you work with them.

Cloud DNS API concepts

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

Project
The project is a concept common to many Google Cloud services. In Cloud DNS, a 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. You can control which team members have permission to work with your Cloud DNS resources at the project level using the Google Developers Console . A user must be an owner or editor to be able to make changes to the zones or records. A user with viewer permission can only list and read data. Your Developers Console project must have billing enabled to use Cloud DNS. Your Cloud DNS usage and charges will be aggregated by project and pricing tiers will be applied at the project level each month.
Managed zones

The managed zone is the container for DNS records for the same DNS name prefix and has a set of name servers that accept and responds to queries. 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 . A managed zone is a container for DNS records that live in a common partition of the DNS namespace, for example <something> .example.com or <otherthing> . <something> .example.com . All records in a managed zone are hosted on the same Google operated name servers, which are selected by the system at creation time. These name servers will respond to DNS queries against your managed zone according to how you configure the zone. A project can contain multiple, uniquely named managed zones and charges accrue for each zone for every day that they exist.

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 (see below). 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.

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.

For example, to change a host from one IP address to another IP address, you should submit a Change request that contains both the deletion of the old A record and the addition of the new A record. Because both changes are handled in a single operation, your authoritative DNS servers will only serve the before-change state or the after-change state. The alternative approach, performing the deletion and addition as two separate changes, creates a temporary in-between state where neither A record exists for the target IP.

The diagram below illustrates the relationships:

/projects/example-project
../managedZones/examplezone (example.com)
../rrsets 
example.com.  SOA  [email protected].
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  [email protected].
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 record types

Google Cloud DNS supports the following types of DNS records:

Record type Description
A

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

Example of the resource record set representation: 

{
  "kind": "dns#resourceRecordSet",
  "name": "example.com.",
  "rrdatas": [
      "1.2.3.4"
  ],
  "ttl": 86400,
  "type": "A"
}
AAAA

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

Example of the resource record set representation: 

{
  "kind": "dns#resourceRecordSet",
  "name": "example.com.",
  "rrdatas": [
      "2607:f8b0:400a:801::1005"
  ],
  "ttl": 86400,
  "type": "AAAA"
}
CNAME

Canonical name record, which is used to alias names.

Example of the resource record set representation: 

{
  "kind": "dns#resourceRecordSet",
  "name": "mail.example.com.",
  "rrdatas": [
      "example.com."
  ],
  "ttl": 86400,
  "type": "CNAME"
}

Note that the hostnames must end with periods ( . ) in the rrdatas fields to be fully-qualified DNS names.

MX

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

Example of the resource record set representation: 

{
  "kind": "dns#resourceRecordSet",
  "name": "example.com.",
  "rrdatas": [
      "10 mail.example.com.",
      "20 mail2.example.com."
  ],
  "ttl": 86400,
  "type": "MX"
}

Note that the hostnames must end with periods ( . ) in the rrdatas fields to be fully-qualified DNS names.

NS

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

Example of the resource record set representation: 

{
  "kind": "dns#resourceRecordSet",
  "name": "example.com.",
  "rrdatas": [
      "ns-cloud1.googledomains.com."
  ],
  "ttl": 86400,
  "type": "NS"
}

Note that the hostnames must end with periods ( . ) in the rrdatas fields to be fully-qualified DNS names.

PTR

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

Example of the resource record set representation: 

{
  "kind": "dns#resourceRecordSet",
  "name": "1",
  "rrdatas": [
      "example.com."
  ],
  "ttl": 86400,
  "type": "PTR"
}
SOA

Start of authority record, which specifies authoritative information about a DNS zone. A SOA resource record is created for you when you create your managed zone. You can modify the record as needed.

Example of the resource record set representation: 

{
  "kind": "dns#resourceRecordSet",
  "name": "example.com.",
  "rrdatas": [
    "ns-cloud1.googledomains.com. dns-admin.google.com. 1 21600 3600 1209600 300"
  ],
  "ttl": 21600,
  "type": "SOA"
}

Note that the hostnames must end with periods ( . ) in the rrdatas fields to be fully-qualified DNS names.

SPF

Sender policy framework record, which is used in email validation systems.

Example of the resource record set representation: 

{
  "kind": "dns#resourceRecordSet",
  "name": "example.com.",
  "rrdatas": [
    "v=spf1 mx:example.com -all"
  ],
  "ttl": 21600,
  "type": "SPF"
}
SRV

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

Example of the resource record set representation: 

{
  "kind": "dns#resourceRecordSet",
  "name": "sip.example.com.",
  "rrdatas": [
    "0 5 5060 sip.example.com."
  ],
  "ttl": 21600,
  "type": "SRV"
}

Note that the hostnames must end with periods ( . ) in the rrdatas fields to be fully-qualified DNS names.

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.

Example of the resource record set representation: 

{
  "kind": "dns#resourceRecordSet",
  "name": "example.com.",
  "rrdatas": [
    "google-site-verification=xxxxxxxxxxxxYYYYYYXXX"
  ],
  "ttl": 21600,
  "type": "TXT"
}

The TXT record consists of a list of character strings ( RFC 1035 ). In zone file format, you write this as a sequence of white space separated strings. Each string can be quoted or unquoted. If one of your strings contains embedded white space, you must use the quoted form, for example: 

{
  "kind": "dns#resourceRecordSet",
  "name": "example.com.",
  "rrdatas": [
    "\"v=spf1 include:_spf.google.com ~all\""
  ],
  "ttl": 21600,
  "type": "TXT"
}

The preceding resource record set consists of a single TXT resource record that contains a single character string with embedded spaces.

Wildcard DNS records

Wildcard records are supported for all record types, except for NS records. For example, you might want to map all subdomains to the IP address 1.2.3.4 with the following Change request: 

{
"additions": [
    {
        "kind": "dns#resourceRecordSet",
        "name": "*.example.com.",
        "rrdatas": [
            "1.2.3.4"
        ],
        "ttl": 21600,
        "type": "A"
    }
]
}

Access control

You can manage the users that are allowed to make changes to your DNS records in the Google Developers 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 Developers Console. The viewer permission level allows for 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 many redundant locations around the world for high availability and low latency, which results in improved performance for your users.

Propagation of changes

Changes are propagated in two parts: first the change that you send via the API or command-line tool must be pushed to Cloud DNS's authoritative DNS servers, and second, DNS resolvers must pick up this change when their cache of the records expire.

The DNS resolver's cache is controlled by the time-to-live ( TTL ) value that you set for your records and 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 in advance of your change to a shorter TTL value. This change 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.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License , and code samples are licensed under the Apache 2.0 License . For details, see our Site Policies .

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.