This page provides an overview of Cloud DNS features and capabilities. 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 DNS without the burden of managing your own DNS servers and software.
Cloud DNS offers both public zones 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 Virtual Private Cloud (VPC) networks that you specify. For detailed information about zones, see DNS zones overview.
Cloud DNS supports Identity and Access Management (IAM) permissions at the project level and individual DNS zone level. For information about how to set individual resource IAM permissions, see Create a zone with specific IAM permissions.
For a list of general DNS terminology, see the General DNS overview.
For a list of key terminology on which Cloud DNS is built, see Key terms.
To get started using Cloud DNS, see the Quickstart.
Try it for yourself
If you're new to Google Cloud, create an account to evaluate how Cloud DNS performs in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.Try Cloud DNS free
Shared VPC considerations
To use a Cloud DNS managed private zone, Cloud DNS forwarding zone, or Cloud DNS peering zone with Shared VPC, you must create the zone in the host project, and then add one or more Shared VPC networks to the list of authorized networks for that zone. Alternatively, you can set up the zone in a service project using cross-project binding.
For more information, see Best practices for Cloud DNS private zones.
DNS forwarding methods
Google Cloud offers inbound and outbound DNS forwarding for private zones. You can configure DNS forwarding by creating a forwarding zone or a Cloud DNS server policy. The two methods are summarized in the following table.
|DNS forwarding||Cloud DNS methods|
Create an inbound server policy to enable an on-premises DNS client or server to send DNS requests to Cloud DNS. The DNS client or server can then resolve records according to a VPC network's name resolution order.
On-premises clients can resolve records in private zones, forwarding zones, and peering zones for which the VPC network has been authorized. On-premises clients use Cloud VPN or Cloud Interconnect to connect to the VPC network.
You can configure VMs in a VPC network to do the following:
You can simultaneously configure inbound and outbound DNS forwarding for a VPC network. Bi-directional forwarding lets VMs in your VPC network resolve records in an on-premises network or in a network hosted by a different cloud provider. This type of forwarding also enables hosts in the on-premises network to resolve records for your Google Cloud resources.
The Cloud DNS control plane uses the forwarding target selection
order to select a forwarding target. Outbound forwarded
queries might sometimes result in
SERVFAIL errors if the forwarding targets
are not reachable or if they do not respond quickly enough. For troubleshooting
instructions, see Outbound forwarded queries receive SERVFAIL
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. For more information about DNSSEC, see Managing DNSSEC configuration.
You can manage the users who are allowed to make changes to your DNS records
on the IAM & Admin page in the
Google Cloud console.
For users to be authorized to make changes, they must have the
DNS Administrator role (
roles/dns.admin) in the Permissions
section of the Google Cloud console. The DNS Reader role (
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.
To view the permissions assigned to these roles, see Roles.
Access control for managed zones
Users with the project Owner role or Editor role
roles/editor) can manage or view the managed zones in the specific
project that they are managing.
Users with the DNS Administrator role or DNS Reader role can manage or view the managed zones across all the projects that they have access to.
Project Owners, Editors, DNS Administrators, and DNS Readers can view the list of private zones applied to any VPC network in the current project.
Per resource permission access
To configure a policy on a DNS resource such as a managed zone, you must have
Owner access to the project that owns that resource. The DNS Administrator
role does not have the
setIamPolicy permission. As a project owner, you can
also create custom IAM roles for your specific needs. For
detailed information, see Understanding IAM custom
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 time-to-live (TTL) value that you set for your records, which is specified in seconds, controls the DNS resolver's cache. 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, which 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 before making your change—the new shorter TTL value is applied after the previous TTL value expires in the resolver cache. 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 Quickstart: Set up DNS records for a domain name with Cloud DNS.
To register and set up your domain, see the Tutorial: Set up a domain by using Cloud DNS.
To learn about API client libraries, see Samples and libraries.
To find solutions for common issues that you might encounter when using Cloud DNS, see Troubleshooting.