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](https://cloud.google.com/dns/pricing) 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](https://docs.cloud.google.com/dns/docs/zones/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](https://docs.cloud.google.com/dns/docs/zones/iam-per-resource-zones). For a list of general DNS terminology, see the [General DNS overview](https://docs.cloud.google.com/dns/docs/dns-overview). For a list of key terminology on which Cloud DNS is built, see [Key terms](https://docs.cloud.google.com/dns/docs/key-terms). To get started using Cloud DNS, see the [Quickstart](https://docs.cloud.google.com/dns/docs/set-up-dns-records-domain-name). ## 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](https://docs.cloud.google.com/vpc/docs/shared-vpc#concepts_and_terminology), 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](https://docs.cloud.google.com/dns/docs/zones/cross-project-binding). For more information, see [Best practices for Cloud DNS private zones](https://docs.cloud.google.com/dns/docs/best-practices-dns#best_practices_for_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*](https://docs.cloud.google.com/dns/docs/server-policies-overview#dns-server-policy-in) 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, see [Forwarding targets and routing methods](https://docs.cloud.google.com/dns/docs/zones/zones-overview#fz-targets). - Create an [*outbound server policy*](https://docs.cloud.google.com/dns/docs/server-policies-overview#dns-server-policy-out) 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](https://docs.cloud.google.com/dns/docs/vpc-name-res-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. > [!NOTE] > **Note:** Cloud DNS does *not* support DNS forwarding for public zones. Cloud DNS public zones must be authoritative. The Cloud DNS control plane uses the [forwarding target selection order](https://docs.cloud.google.com/dns/docs/zones/zones-overview#fz-target-selection) to select a forwarding target. Outbound forwarded queries might sometimes result in `SERVFAIL` errors if the forwarding targets are not reachable or if they don't respond quickly enough. For troubleshooting instructions, see [Outbound forwarded queries receive SERVFAIL errors](https://docs.cloud.google.com/dns/docs/troubleshooting#outbound-forwarded-queries-receive-servfail-errors). For information about how to apply server policies, see [Create DNS server policies](https://docs.cloud.google.com/dns/docs/policies#creating). To learn how to create a forwarding zone, see [Create a forwarding zone](https://docs.cloud.google.com/dns/docs/zones/forwarding-zones). ### Outbound endpoints > [!WARNING] > > **Preview** > > > This product or feature is > > subject to the "Pre-GA Offerings Terms" in the General Service Terms section > of the [Service Specific > Terms](https://docs.cloud.google.com/terms/service-terms#1). > > Pre-GA products and features are available "as is" and might have limited support. > > For more information, see the > [launch stage descriptions](https://cloud.google.com/products/#product-launch-stages). Outbound endpoints let you forward DNS queries by using private IP addresses from your VPC network. This approach provides granular control over outbound traffic and flexibility to unblock hybrid and multi-cloud DNS resolution use cases. For more information, see [Outbound endpoints overview](https://docs.cloud.google.com/dns/docs/outbound-endpoints-overview). ## 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 like [Google Public DNS](https://developers.google.com/speed/public-dns/), DNSSEC provides strong authentication (but not encryption) of domain lookups. For more information about DNSSEC, see [Managing DNSSEC configuration](https://docs.cloud.google.com/dns/docs/dnssec-config). ## Advanced threat detection Monitor your internet-bound DNS queries for malicious activity using DNS Armor, powered by [Infoblox](https://www.infoblox.com/threat-intel). Your internet-bound DNS query logs are analyzed by Infoblox for malicious patterns and other signs of compromise, providing visibility into threats without impacting your production traffic. For more information about DNS Armor threat detection, see [Advanced threat detection overview](https://docs.cloud.google.com/dns/docs/threat-detection). ## DNS64 You can connect your IPv6-only Compute Engine virtual machine (VM) instances to IPv4 destinations by using Cloud DNS DNS64. DNS64 provides a synthesized IPv6 address for each IPv4 destination. Cloud DNS creates a synthesized address by combining the [Well-Known Prefix (WKP)](https://www.rfc-editor.org/rfc/rfc6052#page-5) `64:ff9b::/96` with the 32 bits 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 destinations on the internet. To configure NAT64, follow the instructions in [Create a Cloud NAT gateway](https://docs.cloud.google.com/nat/docs/set-up-manage-network-address-translation#create-nat-gateway). The following example shows how an IPv6-only VM instance named `vmipv6` resolves the name of an IPv4-only destination. 1. The `vmipv6` VM instance initiates a DNS request to resolve the destination name to an IPv6 address. 2. If a `AAAA` record (IPv6 address) exists, Cloud DNS returns the IPv6 address, and the `vmipv6` VM instance uses it to connect to the destination. 3. If no `AAAA` record exists, but you configured DNS64, Cloud DNS searches for an `A` record (IPv4 address). If Cloud DNS finds an `A` record, it synthesizes a `AAAA` record by prefixing the IPv4 address with `64:ff9b::/96`. [![DNS64 translates an IPv4 address to a synthesized IPv6 address.](https://docs.cloud.google.com/static/dns/images/dns64.svg)](https://docs.cloud.google.com/static/dns/images/dns64.svg) DNS64 translates an IPv4 address to a synthesized IPv6 address (click to enlarge). For example, if the IPv4 address is `32.34.50.60`, the resulting synthesized IPv6 address is `64:ff9b::2022:323c`, where `2022:323c` is the hexadecimal equivalent of the IPv4 address. The `64:ff9b::/96` prefix is defined in [RFC 6052](https://datatracker.ietf.org/doc/html/rfc6052). Cloud DNS synthesizes 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 without allocating IPv4 addresses. - Transition to IPv6-only address infrastructure in stages while maintaining access to existing IPv4 infrastructure. - Avoid disruptions to critical services by ensuring continued access to environments with legacy IPv4 addresses during your transition to IPv6 addresses. To configure DNS64 for a VPC network, follow the instructions in [Configure DNS64](https://docs.cloud.google.com/dns/docs/configure-dns64). ## 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](https://console.cloud.google.com/iam-admin). 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](https://docs.cloud.google.com/dns/docs/access-control#roles). ### Access control for managed zones Users with the project [Owner role or Editor role](https://docs.cloud.google.com/iam/docs/roles-overview#basic) (`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](https://docs.cloud.google.com/iam/docs/understanding-custom-roles). ## Performance and timing Cloud DNS uses [anycast](http://wikipedia.org/wiki/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. > [!IMPORTANT] > **Important:** Many popular stub resolvers and recursive resolvers default to caching negative responses for up to 15 minutes. This behavior is commonly seen in [Microsoft Windows](https://docs.microsoft.com/windows-server/networking/dns/troubleshoot/disable-dns-client-side-caching), the [Java JVM](https://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html), [dnsmasq](http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html), and others. While waiting for changes to propagate to the authoritative name servers, be sure to [query against these name servers directly](https://docs.cloud.google.com/dns/docs/monitoring#verifying_dns_propagation) to avoid confusion. ## What's next - To get started using Cloud DNS, see [Quickstart: Set up DNS records for a domain name with Cloud DNS](https://docs.cloud.google.com/dns/docs/set-up-dns-records-domain-name). - To register and set up your domain, see the [Tutorial: Set up a domain by using Cloud DNS](https://docs.cloud.google.com/dns/docs/tutorials/create-domain-tutorial). - To learn about API client libraries, see [Samples and libraries](https://docs.cloud.google.com/dns/docs/reference/libraries). - To find solutions for common issues that you might encounter when using Cloud DNS, see [Troubleshooting](https://docs.cloud.google.com/dns/docs/troubleshooting).