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 globalDNS in acost-effective way.

DNS is a hierarchical distributed database that lets you store IP addresses andother data and look them up by name. Cloud DNS lets you publish yourzones and records in DNS without the burden of managing your own DNS serversand 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 isvisible only from one or more Virtual Private Cloud (VPC) networks that youspecify. For detailed information about zones, seeDNS zones overview.

Cloud DNS supports Identity and Access Management (IAM) permissions at theproject level and individual DNS zone level. For information about how toset individual resource IAM permissions, seeCreate a zonewith specific IAMpermissions.

For a list of general DNS terminology, see theGeneral DNS overview.

For a list of key terminology on which Cloud DNS is built, seeKey terms.

To get started using Cloud DNS, see theQuickstart.

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 forwardingzone, or Cloud DNS peering zone with Shared VPC, you mustcreate the zone in thehost project, and then add oneor more Shared VPC networks to the list of authorized networksfor that zone. Alternatively, you can set up the zone in a service project usingcross-project binding.

For more information, seeBest 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 aCloud DNS server policy. The two methods are summarized in thefollowing table.

DNS forwarding	Cloud DNS methods
Inbound	Create aninbound 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, seeForwarding targets and routing methods. Create anoutbound 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, seeName resolution order.

You can simultaneously configure inbound and outbound DNS forwarding for aVPC network. Bi-directional forwarding lets VMs in yourVPC network resolve records in an on-premises network or in anetwork hosted by a different cloud provider. This type of forwarding alsoenables hosts in the on-premises network to resolve records for yourGoogle Cloud resources.

Note: Cloud DNS doesnot support DNS forwarding for public zones.Cloud DNS public zones must be authoritative.

The Cloud DNS control plane uses theforwarding target selectionorder to select a forwarding target. Outbound forwardedqueries might sometimes result inSERVFAIL errors if the forwarding targetsare not reachable or if they don't respond quickly enough. For troubleshootinginstructions, seeOutbound forwarded queries receive SERVFAILerrors.

For information about how to apply server policies, seeCreate DNSserver policies. To learn how to create aforwarding zone, seeCreate a forwardingzone.

DNSSEC

Cloud DNS supports managed Domain Name System Security Extensions(DNSSEC), protecting your domains from spoofing and cache poisoning attacks.When you use a validating resolver likeGoogle Public DNS,DNSSEC provides strong authentication (but not encryption) of domain lookups.For more information about DNSSEC, seeManaging DNSSEC configuration.

Advanced threat detection (Preview)

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

Monitor your internet-bound DNS queries for malicious activity usingDNS Armor (Preview), powered byInfoblox.Your internet-bound DNS query logs are analyzed by Infoblox for malicious patterns andother signs of compromise, providing visibility into threats without impactingyour production traffic. For more information about DNS Armor threatdetection, seeAdvanced threat detection overview.

DNS64

You can connect your IPv6-only Compute Engine virtual machine (VM)instances to IPv4 destinations byusing Cloud DNS DNS64. DNS64 provides a synthesized IPv6 address foreach IPv4 destination. Cloud DNS creates a synthesized address bycombining theWell-Known Prefix(WKP)64:ff9b::/96 with the 32bits of the destination IPv4 address.

Set up DNS64 and network address translation with Public NAT(NAT64) to enable your IPv6-only VM instances to communicate with IPv4 destinationson the internet. To configure NAT64, follow the instructions inCreate a Cloud NAT gateway.

The following example shows how an IPv6-only VM instancenamedvmipv6 resolves the name of an IPv4-only destination.

1. Thevmipv6 VM instance initiates a DNS request to resolve the destination name to anIPv6 address.

2. If aAAAA record (IPv6 address) exists, Cloud DNS returns the IPv6address, and thevmipv6 VM instance uses it to connect to the destination.

3. If noAAAA record exists, but you configured DNS64, Cloud DNSsearches for anA record (IPv4 address). If Cloud DNS finds anArecord, it synthesizes aAAAA record by prefixing the IPv4 address with64:ff9b::/96.

For example, if the IPv4 address is32.34.50.60, the resulting synthesizedIPv6 address is64:ff9b::2022:323c, where2022:323c is the hexadecimalequivalent of the IPv4 address. The64:ff9b::/96 prefix is defined inRFC6052. Cloud DNSsynthesizes these IPv6 addresses even when you host the DNS records on-premises,as long as you enable DNS forwarding in Cloud DNS.

You can use DNS64 in the following scenarios:

• Adhere to mandates requiring a shift to IPv6 addresses withoutallocating IPv4 addresses.
• Transition to IPv6-only address infrastructure in stages while maintainingaccess to existing IPv4 infrastructure.
• Avoid disruptions to critical services byensuring continued access to environments with legacy IPv4 addressesduring your transition to IPv6 addresses.

To configure DNS64 for a VPC network, follow the instructions inConfigure DNS64.

Access control

You can manage the users who are allowed to make changes to your DNS recordson theIAM & Admin page in theGoogle Cloud console.For users to be authorized to make changes, they must have theDNS Administrator role (roles/dns.admin) in the Permissionssection 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 manageyour DNS services.

To view the permissions assigned to these roles, seeRoles.

Access control for managed zones

Users with the projectOwner role or Editor role(roles/owner orroles/editor) can manage or view the managed zones in the specificproject that they are managing.

Users with the DNS Administrator role or DNS Reader role can manage or view themanaged zones across all the projects that they have access to.

Project Owners, Editors, DNS Administrators, and DNS Readers can view the listof 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 haveOwner access to the project that owns that resource. The DNS Administratorrole does not have thesetIamPolicy permission. As a project owner, you canalso create custom IAM roles for your specific needs. Fordetailed information, seeUnderstanding IAM customroles.

Performance and timing

Cloud DNS usesanycastto serve your managed zones from multiple locations around the world for highavailability. Requests are automatically routed to the nearest location,reducing latency and improving authoritative name lookup performance for yourusers.

Propagation of changes

Changes are propagated in two parts. First, the change that you send throughthe API or command-line tool must be pushed to Cloud DNS'sauthoritative DNS servers. Second, DNS resolvers must pick up this change whentheir cache of the records expires.

The time to live (TTL) value that you set for your records, which is specifiedin seconds, controls the DNS resolver's cache. For example, if you set a TTLvalue of 86400 (the number of seconds in 24 hours), the DNS resolvers areinstructed to cache the records for 24 hours. Some DNS resolvers ignore theTTL value or use their own values, which can delay the full propagation ofrecords.

If you are planning for a change to services that requires a narrow window, youmight want to change the TTL to a shorter value before makingyour change—the new shorter TTL value is applied after the previous TTL value expiresin the resolver cache. This approach can help reduce the caching window and ensure aquicker change to your new record settings. After the change, you can change thevalue back to its previous TTL value to reduce load on the DNS resolvers.

Important: Many popular stub resolvers and recursive resolvers default tocaching negative responses for up to 15 minutes. This behavior is commonly seeninMicrosoft Windows,theJava JVM,dnsmasq,and others. While waiting for changes to propagate to the authoritativename servers, be sure toquery against these name servers directlyto avoid confusion.

What's next

• To get started using Cloud DNS, seeQuickstart: Set up DNS records for a domain name with Cloud DNS.

• To register and set up your domain, see theTutorial: Set up a domain by using Cloud DNS.

• To learn about API client libraries, seeSamples and libraries.

• To find solutions for common issues that you might encounter when usingCloud DNS, seeTroubleshooting.