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 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. Use split horizon DNS when you need your VPC to respond to identical DNS queries with different sets of DNS information, based on the source network of the DNS request.
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.
- 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 may 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. DNS queries for private zones are restricted to your VPC networks and Shared VPC. When you use private zones in a Shared VPC, the private zones resources must be created within the host project and associated with the Shared VPC network.
Shared VPC service projects are not automatically enabled for private zones, even when their host projects are. You can initiate this process manually by creating a private zone in the service project. This enables private zones on the VMs in that service project.
A private zone is a container of DNS records that is only visible from one or more VPC networks that you specify. For example, you can create a private zone dev.gcp.example.com to host the internal DNS records for the experimental applications on your dev network in GCP. A private zone is visible only within the project where it was defined.
DNS Name Type TTL (seconds) Data db-01.dev.gcp.example.com A 5 10.128.1.35 instance-01.dev.gcp.example.com A 50 10.128.1.10
You can query private zones through GCP's default internal name server (169.254.169.254). In other words, you can resolve resource record sets that you create inside your private managed zones through the default GCP internal name server. By default, any VM instance can query private zones with a standard DNS query, provided the instance is in a VPC network that has permission to see that private DNS zone.
For example, consider a situation in which you have a resource record set that points at an application database. Your application database clients might have that DNS name set in the configuration for connecting to the database. The database client resolves the DNS name using the host resolver, which connects to the GCP's default internal name server,
169.254.169.254, and eventually resolves the name to the value you specified.
You can update the list of VPC networks that can access a private zone. This makes the zone visible to added VPC networks and invisible to removed VPC networks. You can remove all VPC networks from a private zone, which makes it invisible to all VPC networks.
Private zones do not support DNS security extensions (DNSSEC).
- Default .internal private zone
GCP includes an .internal private zone and automatically names VM instances and other GCP resources in this namespace, for example:
DNS Name Type TTL (seconds) Data instance-1.us-central1-a.c.myproject-1.internal A 5 10.128.0.11
By default, the .internal DNS name of your GCP resource is only visible on the VPC network where the resource is available.
- 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
Changerequest 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
Changerequest 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:
example.com. SOA firstname.lastname@example.org. example.com. NS zns-1.google.com. example.com. MX 10 mail.example.com. www A 188.8.131.52 184.108.40.206
3 user2@ 2014-03-31T18:59:23.587Z PENDING DEL www A 220.127.116.11 ADD www A 18.104.22.168 22.214.171.124 2 user1@ 2014-03-31T16:34:18.58Z DONE 1 devops@ 2014-03-28T12:46:09.23Z DONE
example.org. SOA email@example.com. example.org. NS zns-1.google.com. www A 126.96.36.199
2 user2@ 2014-04-02T18:53:55.132Z PENDING DEL www A 188.8.131.52 ADD www A 184.108.40.206 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:
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
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
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.
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 this 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 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, read the section on split horizon DNS.
Query resolution with overlapping zones
Two private zones visible to the same VPC network cannot have identical origins. However, on the same VPC network, the origin of one private zone can be the subdomain of another private zone. GCP’s internal DNS name server uses longest-suffix matching to decide which zone to apply when answering internal DNS queries from VMs.
For example, assume that there are only two private zones, gcp.example.com and dev.gcp.example.com.
- Queries for myapp.example.com are resolved through the Internet because there is no private zone for example.com.
- Queries for myapp.gcp.example.com are resolved according to records defined in the private zone gcp.example.com because gcp.example.com is the longest common suffix between the domain name being queried and the available private zones. NXDOMAIN is returned if there’s no record matching myapp in the private zone (even if the same domain myapp.gcp.example.com may actually exist on the Internet).
- Similarly, queries for myapp.dev.gcp.example.com are resolved according to records defined in the private zone dev.gcp.example.com. NXDOMAIN is returned if there’s no record matching myapp in the private zone dev.gcp.example.com (even if the other private zone gcp.example.com may contains a record for myapp.dev.gcp.example.com).
- Queries for myapp.prod.gcp.example.com are resolved according to records defined in the private zone gcp.example.com, because gcp.example.com is the longest common suffix between the domain name being queried and the available private zones.
Split horizon DNS
Split horizon DNS enables your VPC network to respond to identical DNS queries with different sets of DNS information, based on the source network of the DNS request. Consider a situation where you have development, corporate, and production networks.
- You can define a private zone to direct internal development environment traffic to servers in your development network.
- You can define a different private zone under the same DNS name for traffic from users on your corporate network.
- You can define a public zone under the same name to serve users from your production network.
For example, assume that you have a private zone, gcp.example.com, with a single record and a public zone, gcp.example.com, with two records. For the public zone, assume also that the registrar is configured properly.
The private zone with a single record:
|DNS Name||Type||TTL (seconds)||Data|
The public zone with two records:
|DNS Name||Type||TTL (seconds)||Data|
This DNS configuration works as follows:
- A query for foo.gcp.example.com from the internal VPC network returns 10.128.1.35.
- A query for foo.gcp.example.com from the Internet returns 220.127.116.11.
- A query for bar.gcp.example.com from the internal VPC network returns an NXDOMAIN error because there’s no record bar.gcp.example.com in the private zone gcp.example.com.
- A query for bar.gcp.example.com from the Internet returns 18.104.22.168.
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
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
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.
To get started using Cloud DNS, see the Quickstart.