This page describes the errors you might encounter using Cloud DNS, and tells you how to handle them.

Managed Zones

This section lists errors relating to managed zones.


Invalid value for ''

The managed zone creation operation can fail with this error if the managed zone name does not begin with a letter, end with a letter or digit, and contain only lowercase letters, digits, or dashes.


The specified managed zone is not available to be created.

The managed zone creation operation can fail with this error for the following reasons:

  • The DNS name of the proposed zone is reserved, for example, dot (.), .com, or
  • There are no more name servers available to host the DNS name of the zone. Cloud DNS uses a pool of name servers, and that pool is finite. A DNS query at any name server must map unambiguously to one managed zone.

Recommended action: If you are the registered owner of the DNS name in question, check for overlapping zones. To set up DNS for a domain and its subdomains, we recommend creating a single root zone and adding records for each subdomain in that zone.


Please verify ownership of the 'EXAMPLE.COM' domain (or a parent) at and try again.

Recommended action: When you receive this error, you must verify domain ownership and try again.


The errors in this section relate to records.


The specified resource cannot be deleted because it is not empty.

Recommended action: If you want to delete the resource, you must empty it first.


The specified resource record set is invalid because a zone must contain exactly one resource record set of a certain type at the apex.

"Apex" in the DNS context just means the DNS name with the fewest number of labels that are allowed in the zone. The apex of a zone is the DNS name equal to ManagedZone.dnsName.

This error means that you tried to make a change that would violate a DNS rule of the zone apex. The following actions can cause this error:

  • You tried to delete the required NS resource record set at the apex.
  • You tried to delete the required SOA resource record set at the apex.
  • You tried to create a resource record set of type SOA not at the apex.

Recommended action: If you get this error, you are trying to do something that isn’t allowed under the rules of DNS. Check your request for mistakes. There is no need to delete these required resource record sets.


The resource record set 'entity.change.additions[XX]' is only permitted to have one record because it is of type '<SOA_OR_CNAME>'.

The rules of DNS say that certain resource record sets can only consist of one resource record. Currently, this type can be either SOA or CNAME. You get this error if you try to create a change that would break those rules. For example:

  kind: "dns#rrset"
  name: "",
  type: "CNAME",
  rrdata: [ "", "" ],

Recommended action: If you get this error, check your request. You are trying to do something that isn’t allowed.


The resource record set 'entity.change.additions[XX]' is invalid because the DNS name 'EXAMPLE.COM' may have either one CNAME resource record set or resource record sets of other types, but not both.

This error can occur when you create two types of resource record sets, such as both an A record and a CNAME record for the same DNS name. A common cause of this error is trying to create a CNAME record at the zone apex. This is not possible because it would conflict with the required SOA and NS records of the same name.

Recommended action: Pick one or the other.


The specified resource record set has the wrong type to be a wildcard.

In DNS, a wildcard is a special type of resource record set that matches requests for non-existent domain names. One limitation of Cloud DNS is that you cannot create a wildcard resource record set of type NS.

Recommended action: Wildcard NS resource record sets are not supported at this time. Contact support or join cloud-dns-discuss and share what you are trying to accomplish.


This is a generic error that means something about your request was invalid, independent of the server’s state. The error message includes the path to the problematic part of the request, as well as the invalid value. This error could be triggered by many different things, such as:

  • You specified a resource record set with an invalid name. For example, “” is not a valid DNS name (empty middle label).
  • You specified a resource record set with an invalid type. For example A and CNAME are valid types, but “XXX” is not a valid type.
  • You specified a resource record set with no records in it.
  • You specified resource record data that is invalid. For example “” is valid resource record data for type A. “XXX” is invalid resource record data for type A.
  • You specified a resource record set with an invalid TTL. The TTL must be a non-negative integer.
  • You specified a resource name that is too long.

Recommended action: Fix your request.

General Errors

This section describes general errors.


The specified resource already exists; you cannot create a duplicate.

Recommended action: When creating a resource, use the appropriate get/list API to discover what resources already exist.


Access not configured

To resolve this error, you must enable the Cloud DNS API for your project.


Project EXAMPLE_PROJECT cannot accept requests while in an inactive billing state. Billing state may take several minutes to update.

Recommended action: Enabling billing for your project in the Settings section of your project in the GCP Console.


This is a generic error that means that something about the request is not compatible with the current state of the server resource. The client must do something to fix it and then try again. This can happen if you send a create change request that tries to delete a resource record set that doesn’t match the one that already exists (same name and type).

Re-read the current state of the zone and decide what you want to delete. It may have changed since you last looked at it.

The error message includes the path to the problematic part of your request. For example, entity.change.deletions[6] refers to the 7th element in the “deletions” array of the change object in the POST body of you request.

Recommended action: Fix the part of the request that is flagged as problematic.


This is a generic error that means some required part of the request is missing. For example, the managed zone create request requires a name, a DNS name, and a description. If any of these pieces is missing, the request will fail with this error.

Recommended action: Fill in the required parameter and try again.


The specified resource does not exist.

Recommended action: Make sure you are using the name of an existing resource.


You get this error when an impending change would exceed your current quota. For example, you are only allowed a certain number of resource record sets in each zone. The quota is associated with the project. If you need a quota increase, you must request it from Google customer service. New projects have a default quota. See the Projects.get operation for all the different dimensions that DNS limits.

Recommended action: Check your project to understand why you are already using so much of that resource. You can request increased quota by navigating to the Quotas Page on the GCP Console for the project you want to increase quota. You can also refer to Working with Quotas.

Private zones

This section covers issues with private zones.

Private zones problems in Shared VPC service projects

Refer to Private zones and Shared VPC on the overview page for important information about using private zones with Shared VPC networks.

Cannot create a private zone, cannot list or create policies

You must have the DNS Admin role to perform various Private zone actions, such as listing DNS server policies or creating a private zone. This role can be granted through the Cloud IAM tool.

Private zones are not resolving in the same VPC network

Make sure you are performing the test from a VM whose primary interface is on the same network as the private zone that you have created

A VM sends all traffic out of its primary interface unless the traffic is destined for a subnet attached to one of the other interfaces or if the VM has policy-based routing configured. As such, make sure your test VM has its primary interface on the same network as the private zone you're testing.

Determine the network your VM is using:

gcloud compute instances describe ${vm_name} \
     --zone=${gce_zone} \

Ensure that network is in the list of networks authorized to search your private zone:

gcloud dns managed-zones describe ${private-zone-name} \

Verify that the DNS name in the query matches your zone

GCP uses longest-suffix matching to decide which zone to query for a given DNS name. Make sure the suffix for the record you're querying matches at least one private zone accessible in your VPC network. For example, GCP will first look for in a zone that serves dev.gcp.example.lan, if accessible, before it looks for it in a zone that serves gcp.example.lan, if accessible.

The output of the following command shows the DNS suffix for a given private zone:

gcloud dns managed-zones describe ${private-zone-name} \

Query for the DNS name using the metadata server

Use dig to submit the DNS name query directly to the GCP metadata server,

dig ${dns-name} @

Use dig to query the VM's default name server:

dig ${dns-name}

If the output of the two dig commands produces different answers, check the ;; SERVER: section of the second command. The responding server should be the metadata server, If it is not, then you've configured the guest operating system to use a custom DNS name server instead of the default GCP metadata server. Cloud DNS private zones require that you use the metadata server for name resolution. Both the Linux Guest Environment and the Windows Guest Environment do this for you. If you've imported the image you're using for a VM, you should verify that the appropriate guest environment has been installed.

Private zones not resolving through Cloud VPN or Cloud Interconnect

First make sure you can successfully query and resolve the DNS name from within an authorized VPC network.

Verify connectivity through Cloud VPN or Cloud Interconnect

Ensure that connectivity from an on-premises system to your VPC network is operational. Specifically, TCP and UDP traffic on port 53 must be able to leave your on-premises network and be delivered to your VPC network. Verify the configuration of on-premises firewalls to make sure that such egress traffic is allowed.

As can use any protocol, such as ping (ICMP), to test connectivity to a sample VM in your VPC network from on-premises. While Cloud DNS requests are not sent to GCP VMs, testing connectivity to a sample VM allows you to verify connectivity through a Cloud VPN tunnel or Cloud Interconnect. Make sure you configure an appropriate ingress allow firewall rule for the sample GCP VM because the implied deny ingress rule blocks all incoming traffic otherwise.

Ensure inbound forwarding is enabled for the authorized VPC network

Inbound forwarding must be enabled for each VPC network that is authorized to query your Cloud DNS private zone. Use the following command to list all policies:

gcloud dns policies list

Identify the network in the output table, and check for the Forwarding field to see if forwarding is enabled.

Make sure the authorized network is a VPC network

DNS Forwarding requires subnets, which are only available to VPC networks, not legacy networks.

gcloud compute networks list \
     --format="csv[no-heading](name, SUBNET_MODE)"

Legacy networks are identified in the output as LEGACY.

Make sure there is a valid DNS forwarding address reserved in that network

The command below will show all the reserved DNS forwarder IP addresses in your project.

gcloud compute addresses list \
     --filter="purpose=DNS_RESOLVER" \
     --format='csv[no-heading](address, subnetwork)'

You can add an AND clause to the filter to limit the output to only the subnetwork that you care about.

Example: --filter="name ~ ^dns-forwarding AND subnetwork ${subnetwork-name}"

If you do not see an IP address in the network/region you expected, please file a ticket with Cloud Support.

Perform dig command pointing the query at the address that you found above. Do so from a VM in the same network. This test verifies that inbound forwarder is working, and the problem lies elsewhere.

dig ${dns-name} @ # - address returned by command above.

Repeat the same dig command but from a VM across the VPN.

CNAME record defined in a private zone is not working

CNAME records that refer to other records in the same private zone are supported. CNAME records that point to domain names defined in other private zones, .internal zones, or the Internet are not supported.

Forwarding zones

This section provides troubleshooting tips for forwarding zones. Some private zone issues also apply to forwarding zones. Please consult the Private zones troubleshooting section for additional tips.

Forwarding zones (Outbound forwarding) not working

First make sure you can successfully query and resolve the DNS name from within an authorized VPC network.

Forwarding queries from VMs in a consumer VPC network to a producer VPC network not working

If you are using DNS peering and you want to forward queries from VMs in a consumer VPC network to a producer VPC network, and then to one or more on-premises name servers, you must ensure that the producer VPC network has a VM or a VPN tunnel in the same region as the subnetwork used by the client VMs. For example, suppose that VPC1 uses a peering zone that sends queries for to VPC2. Suppose also that VPC2 has a private forwarding zone for that forwards the queries to an on-premises name server using a Cloud VPN tunnel or Cloud Interconnect. For a VM located in us-east1 in VPC1 to be able to query, VPC2 must also have a VM or VPN tunnel located in us-east1.

Verify connectivity through Cloud VPN or Cloud Interconnect

You can use any protocol, such as ping (ICMP), to test connectivity to a sample VM in your VPC network from on-premises. You should also attempt to query your on-premises name server directly from a sample GCP VM using a tool like dig:

dig ${dns-name} @192.168.x.x # - address of the onprem DNS server.

Check firewall rules in your VPC network

The implied allow egress firewall rule allows outbound connections and established responses from VMs in your VPC network unless you have created custom rules to deny egress. If you've created custom deny egress rules, you'll need to create higher priority allow rules that permit egress to at least your on-premises name servers.

Check on-premises firewall

Make sure that your on-premises firewall is configured to allow incoming traffic from and outgoing traffic to

Check logs in your on-premises firewall, looking for DNS requests from To search using a regex expression, use "35\.199\.(19[2-9]|20[0-9]|21[0-9]|22[0-3]).*"

Check on-premises name server

Verify that you do not have any ACL configured in your on-premises name server that would block queries from

Check your on-premises name server to see if it is receiving packets from If you have shell access, you can use a tool such as tcpdump to look for both incoming packets from and outgoing packets to

sudo tcpdump port 53 and tcp -vv

Verify return routes

Your on-premises network must have a route to the destination with a next hop being a VPN tunnel for the same VPC network that sent the DNS request as described in creating forwarding zones.

If you use multiple VPN tunnels to connect the same VPC network to your on-premises network, the response does not have to be delivered using the same tunnel that sent it. However, the response must be delivered using a VPN tunnel with a next hop in the same VPC network from which the request originated.

If you have connected more than one VPC network to your on-premises network, you must ensure that DNS replies are not sent to the wrong one. GCP discards DNS responses sent to the wrong VPC network.

CNAME record defined in a private zone is not working

Cloud DNS does not support recursively resolving an IP address via a CNAME that points to an A record in another managed private zone (CNAME chasing). For example, suppose you have two managed private zones, zone-a.private and zone-b.private, and you create records like this:

  • CNAME pointing to
  • A record pointing to

Cloud DNS will not resolve as because the two records are not in the same zone (zone-a.private and zone-b.private are different).

Cloud DNS does chase CNAMEs within a managed private zone.

Outbound forwarding to a name server that uses a non-RFC 1918 IP address fails

Cloud DNS always routes queries via the public Internet when the target name server has a non-RFC 1918 IP address. Name servers with non-RFC 1918 addresses that are not reachable from the public Internet cannot be used as forwarding targets.

This limitation applies even if there is a VPC route for the target name server; routes for non-RFC 1918 addresses have no effect on Cloud DNS's outbound forwarding behavior.

Outbound forwarding to a secondary NIC fails

Cloud DNS does not currently support forwarding to secondary NICs of Compute Engine VMs.

Inbound forwarding on a VPC using non-RFC 1918 address ranges fails

Cloud DNS does not support inbound forwarding if the VPC is using a non-RFC 1918 address range.

Next steps

  • The Overview provides more context on features.
  • See the Support area for pointers to additional help.
Oliko tästä sivusta apua? Kerro mielipiteesi

Palautteen aihe:

Tämä sivu
Cloud DNS Documentation