Cloud DNS overview

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
Inbound

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

You can configure VMs in a VPC network to do the following:

  • Send DNS requests to DNS name servers of your choosing. The name servers can be located in the same VPC network, in an on-premises network, or on the internet.
  • Resolve records hosted on name servers configured as forwarding targets of a forwarding zone authorized for use by your VPC network. For information about how Google Cloud routes traffic to a forwarding target's IP address, see Forwarding targets and routing methods.
  • Create an outbound server policy for the VPC network to send all DNS requests to an alternative name server. When using an alternative name server, VMs in your VPC network are no longer able to resolve records in Cloud DNS private zones, forwarding zones, peering zones, or Compute Engine internal DNS zones. For additional details, see Name resolution order.

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

For information about how to apply server policies, see Create DNS server policies. To learn how to create a forwarding zone, see Create a forwarding zone.

DNSSEC

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.

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 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 (roles/dns.reader) 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/owner or 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 roles.

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.

What's next