This page provides solutions for common issues that you might encounter whenusing Cloud DNS to create public zones, private zones,reverse lookup zones, forwarding zones, and resource records.

Public zones

This section covers issues with public zones.

Cannot create a public zone

If you get anattempted action failed error, it means that the Cloud DNSAPI is not enabled on your project.

To enable the Cloud DNS API, follow these steps:

1. In the Google Cloud console, go to theAPI Library page.

   Go to the API Library

2. ForSelect a recent project, select the Google Cloud project whereyou want to enable the API.

3. On theAPI library page, use theSearch for APIs & Services box tosearch forCloud DNS API. A page describing the API appears.

4. ClickEnable.

Private zones

This section covers issues with private zones.

Private zone problems in Shared VPC service projects

For important information about using private zones with Shared VPCnetworks, seePrivate zones and Shared VPC.

Cannot create a private zone, cannot list or create policies

You must have theDNS Administrator role toperform various private zone actions, such as listing Domain Name System (DNS)server policies or creating a private zone. This role can begranted through theIdentity and Access Management (IAM) tool.

Private zones not resolving in the same VPC network

First, make sure that you're performing the test from the same network.

Verify that your VM instance's primary interface is on the same network as the private zone that you have created

A virtual machine (VM) instance sends all traffic out of its primary interfaceunless the traffic is destined for a subnet attached to one of the otherinterfaces or if the VM haspolicy routingconfigured. Make sure that your test VM has its primary interface on the samenetwork as the private zone that you're testing.

Determine that your VM is using:

gcloud compute instances describeVM_NAME \    --zone=GCE_ZONE \    --format="csv[no-heading](networkInterfaces['network'])"

Ensure that the network is in the list of networks authorized to query yourprivate zone:

gcloud dns managed-zones describePRIVATE_ZONE_NAME \    --format="csv(privateVisibilityConfig['networks'])"

Verify that the DNS name in the query matches your zone

Google Cloud resolves a record according to thename resolution order, using the zone withthe longest suffix to decide which zone to query for a given DNS name. Make surethat the suffix for the record that you're querying matches at least one privatezone accessible in your VPC network. For example, Google Cloudfirst looks formyapp.dev.gcp.example.lan in a zone that servesdev.gcp.example.lan, if accessible, before it looks for it in a zone thatservesgcp.example.lan, if accessible.

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

gcloud dns managed-zones describePRIVATE_ZONE_NAME \    --format="csv[no-heading](dnsName)"

Query for the DNS name using the metadata server

Usedig to submit the DNS name query directly to the Google Cloudmetadata server,169.254.169.254:

digDNS_NAME @169.254.169.254

Usedig to query the VM's default name server:

digDNS_NAME

If the output of the twodig commands produces different answers, check the;; SERVER: section of the second command. The responding server must be themetadata server,169.254.169.254. If it is not, then you've configured theguest operating system to use a custom DNS name server instead of the defaultGoogle Cloud metadata server. Cloud DNS private zones requirethat you use the metadata server for name resolution. Both theLinux guestenvironment and theWindowsguest environmentdo this for you. If you've imported the image that you're using for a VM,verify that the appropriate guest environment has been installed.

Private zones not resolving through Cloud VPN or Cloud Interconnect

First make sure that you can successfully query and resolve the DNS name fromwithin anauthorized VPCnetwork.

Verify connectivity through Cloud VPN or Cloud Interconnect

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

You can use any protocol, such asping (ICMP), to test connectivity to asample VM in your VPC network from on-premises. WhileCloud DNS requests are not sent to Google Cloud VMs,testing connectivity to a sample VM lets you verify connectivity through aCloud VPN tunnel or Cloud Interconnect connection. Make sure thatyou configure an appropriate ingress allow firewall rule for the sampleGoogle Cloud VM because theimplied deny ingressrule blocks all incoming trafficotherwise.

Ensure inbound forwarding is enabled for the authorized VPC network

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

gcloud dns policies list

Identify the network in the output table, and check for theForwarding fieldto see if forwarding is enabled.

Make sure the authorized network is a VPC network

DNS forwarding requires subnets, which are only available toVPCnetworks,notlegacynetworks.

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

Legacy networks are identified in the output asLEGACY.

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

The following command shows all the reserved DNS forwarding IP addresses in yourproject.

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

You can add anAND clause to the filter to limit the output to only thesubnetwork that you care about.

Example:

--filter="name ~ ^dns-forwarding AND subnetwork ~SUBNETWORK_NAME"

If you don't see an IP address in the network or region that you expected, filea ticket withGoogle Cloud Support.

Run thedig command pointing the query at the address that you found in thepreceding command. Do so from a VM in the same network. This test verifiesthat the inbound forwarder is working, and that the problem lies elsewhere.

digDNS_NAME @10.150.0.1 # address returned by previous command

Repeat the samedig command but from an on-premises host across the VPN.

CNAME record defined in a private zone not working

Cloud DNS only chases CNAME records as described inCNAME chasing.

Reverse lookup zones

This section provides troubleshooting tips for reverse lookup zones.Some private zone issues also apply to reverse lookup zones. For additionaltips, see thePrivate zones troubleshooting section.

VM with non-RFC 1918 address not resolving

If you have a non-RFC 1918 address, reconcile your VM.

Reconciliate your VM with a non-RFC 1918 address

If you created a VM during the non-RFC 1918 alpha beforeCloud DNS support was launched, these VMs might not resolvecorrectly. To resolve this issue, restart your VMs.

Forwarding zones

This section provides troubleshooting tips for forwarding zones.Some private zone issues also apply to forwarding zones. For additionaltips, see thePrivate zones troubleshooting section.

Forwarding zones (outbound forwarding) not working

First make sure that you can successfully query and resolve the DNS name fromwithin anauthorized VPCnetwork.

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 ina consumer VPC network to a producer VPC network,and then to one or more on-premises name servers, make sure that one of thefollowing prerequisites is met:

• The producer VPC network has itsdynamic routing modeset toGLOBAL

• The VM in the consumer VPC network is in the same region as theVPN tunnel or Cloud Interconnect in the producer VPC

• (Classic VPN only) The producer VPC network has astatic routeconfigured to send traffic destined for the on-premise name servers through theClassic VPN tunnel. The producer VPC network must also have a VM or aVPN 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 forexample.com. to VPC2. Suppose also that VPC2 has a private forwarding zone forexample.com. that forwards the queries to an on-premises name server using aClassic VPN tunnel.

    For a VM located inus-east1 in VPC1 to be able to queryexample.com., VPC2must have a VM located inus-east1. Astatic routemust also be configured covering the CIDR ranges of the on-premises name servers,with the next hop configured as the Classic VPN tunnel.

    Verify connectivity through Cloud VPN or Cloud Interconnect

You can use any protocol, such asping (ICMP), to test connectivity to asample VM in your VPC network from on-premises. You must alsoattempt to query your on-premises name server directly from a sampleGoogle Cloud VM by using a tool likedig:

digDNS_NAME @192.168.x.x # address of the onprem DNS server

Check firewall rules in your VPC network

Theimplied allow egress firewallrule allows outbound connectionsand established responses from VMs in your VPC network unlessyou have created custom rules to deny egress. If you've created custom denyegress rules, you'll need to create higher priority allow rules that permitegress to at least your on-premises name servers.

Check on-premises firewall

Make sure that your on-premises firewall is configured to allow incoming trafficfrom and outgoing traffic to35.199.192.0/19.

Check logs in your on-premises firewall, looking for DNS requests from35.199.192.0/19. To use aregex expression to search, use the following:

"35\.199\.(19[2-9]|20[0-9]|21[0-9]|22[0-3]).*"

Check on-premises name server

Verify that you don't have any ACL configured in your on-premises name serverthat would block queries from35.199.192.0/19.

Check your on-premises name server to see if it is receiving packets from35.199.192.0/19. If you have shell access, you can use a tool such astcpdump to look for both incoming packets from and outgoing packets to35.199.192.0/19:

sudo tcpdump port 53 and tcp -vv

Verify return routes

Your on-premises network must have a route to the35.199.192.0/19 destinationwith the next hop being a VPN tunnel or Interconnect connection for the sameVPC network that sent the DNS request. This behavior is describedinCreating forwarding zones.

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

If you have connected more than one VPC network to youron-premises network, you must ensure that DNS replies are not sent to the wrongone. Google Cloud discards DNS responses sent to the wrongVPC network. For a recommended solution, see ourBest practicesguide.

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

By default, Cloud DNS uses standard routing, whichroutes queries through the public internet when the target name server has anon-RFC 1918 IP address. Standard routing doesn't support forwarding queriesto name servers with non-RFC 1918 addresses that are not reachable from thepublic internet.

To forward queries to a name server that uses anon-RFC 1918 IP address through your VPC network, configurethe Cloud DNS forwarding zone or server policy to use private routingfor the target name server.

For an explanation of the differences between standard and private routing, seeforwarding targets and routing methods.

This limitation applies even if there is a VPC route for thetarget name server; routes for non-RFC 1918 addresses have no effect onCloud DNS's outbound forwarding behavior when standard routing isconfigured.

Outbound forwarding to a secondary NIC fails

Make sure that you have set up your secondary network interface controller (NIC)correctly.

For instructions about how to set up additional NICs, seeCreating virtualmachine instances with multiple networkinterfaces.

Outbound forwarded queries receive SERVFAIL errors

If Cloud DNS receives an error from all target name servers or does notreceive a response from any of the target name servers, it returns aSERVFAILerror.

To resolve this issue, verify that your on-premises name servers are properlyconfigured. Then, verify that your on-premises name servers respond to queriesfrom the Cloud DNS address range described inOpen Google Cloudand on-premises firewalls to allow DNStrafficwithin 4 seconds. If your on-premises name servers consult upstream name servers(for example, due to being configured as caching resolvers), check that thereare no issues with upstream name servers.

Additionally, if the forwarding target is an on-premises system, be awarethat the routes configured for that path can be custom dynamic routes or customstatic routes, with the important exception thatcustom static routes withnetwork tags are not valid for forwarding DNS queries. Ensure that the routeused to reach the on-premises name server does not specify a network tag.

Resource records

This section provides troubleshooting tips for resource records.

Unexpected data when querying for resource record sets present in the zone

There are several reasons why you might receive unexpected data when querying forresource record sets present in a Cloud DNS managed zone:

1. Resource record sets created by using the@ syntax specified inRFC 1035are not supported. Cloud DNS interprets the@ symbol in suchresource record sets literally; therefore, in theexample.com. zone, arecord set created for the QNAME@ is interpreted as@.example.com.instead ofexample.com.. To resolve this issue, ensure that you createrecord sets without the@ symbol; all names are relative to the apex of thezone.

2. Like all records, wildcard CNAME records are subject to theexistence rules described inRFC 4592. For example,suppose that you define the following record sets in theexample.com.zone:

   *.images.example.com. IN CNAME _static.example.com.

   srv1.images.example.com. IN A 192.0.2.91

   _static.example.com. IN A 192.0.2.92

   A query forpublic.srv1.images.example.com. returnsNOERROR with anempty answer section. The existence of a recordbetween the CNAME and theQNAME prevents the CNAME from being returned, but there's no record thatmatches the QNAME exactly, so Cloud DNS returns an empty answer.This is standard DNS behavior.

Google Cloud VM shows incorrect pointer (PTR) records

When a VM is migrated during a maintenance event, the PTR record logic doesn'thandle some edge cases correctly and reverts the DNS PTR records to thegoogleusercontent.com fully qualified domain name (FQDN). To restorefunctionality, apply the PTR record again.

For details about how to apply PTR records on a VM, seeCreating a PTR recordfor a VM instance.

Cloud DNS resource record sets returned in random order

Consistent with DNS industry practices, Cloud DNS nameservers now randomize the order of the resource record sets and ignore theordering given by the authoritative server. This is normal DNS behavior andapplies to both publicand private Cloud DNS zones.

Unsupported zonal resource type

When you enter the--location flag to agcloud command or API request fora feature that targets a different Cloud DNS zone, the request isrejected. For example, if you send a zonal-only feature request to a globalserver, or a global-only feature request to a zonal server, the server rejectsthe request and gives an _UNSUPPORTED_ZONAL_RESOURCETYPE error.

For a list of resources and features that zonal Cloud DNS supports, seezonalCloud DNS support.

Advanced threat detection

This section provides information about issues that you might encounter whenusing DNS Armor and provides suggestions for how to fix each of them.

Metrics show no or very low DNS queries being sent to the threat detector

First, verify that you have a DNS threat detector.

Verify your DNS threat detector

1. In the Google Cloud console, go to theAdvanced threat detection page.

   Go to Advanced threat detection

2. Verify that you have a threat detector listed.

Verify region support

1. Make sure thatLocations contains theregion serving your workflow's DNS queries.

Verify that you have internet-bound queries

Query logs are only sent when internet-bound queries or requests are made of your network.

1. In the Google Cloud console, go to the Monitoring page.

   Go to Monitoring

2. InMetric selectCloud DNS Query, then chooseQuery andDNS response counts.

3. View the metrics for target types that are internet-bound.

Alternatively, if you have enabled Cloud logging for DNS queries, use theLogs Explorer to verify that you have internet-bound queries.

1. In the Google Cloud console, go to theLogs Explorer page.

   Go to Logs Explorer

2. View your DNS logs and check for internet-bound queries.

Threat event logs aren't returned

If threat events aren't received by Cloud Logging, first verify that an advanced threat detector is set up on theDashboard. Note that threat event logs are only returned when a threat is detected.

Verify threat detection is enabled

1. In the Google Cloud console, go to theAdvanced threat detection page.

   Go to Advanced threat detection

2. Verify that you have a threat detector listed.

DNS threats events aren't generated for some abusive or bad domains

Some DNS threat events for abusive or bad domains might not be generatedfor domains obtained from public bad domain lists on the Internet as DNS threatdomains change frequently. Old or expired domains from those lists don'tgenerate DNS threat events.

The following are test domains you can use to verify DNS threat domains:

• dnst-gcp-blox.com
• ftags-gcp-blox.com
• dga-gcp-blox.com

Verify that DNS threat events are generated for test domains

1. Sign in to a VM that is part of project you're monitoring.

2. Open a terminal and issue a dig command for one of the test domains.

   domain=TEST_DOMAIN
   dig $domain -t A

   ReplaceTEST_DOMAIN with one of the listed domains.

3. Open the Google Cloud console, go to theLogs Explorer page.

   Go to Logs Explorer

4. Run the following query:resource.type="networksecurity.googleapis.com/DnsThreatDetector"

5. Search for the test domain you used in the dig command.

   These domains generate DNS threat events. If you can't find DNS logs for thelisted domains, contactSupport.

What's next

• To learn more about Cloud DNS features, seeCloud DNS overview.
• To resolve errors, seeError messages.
• To get additional help, seeSupport.