Domain Troubleshooting

  • This guide helps domain administrators troubleshoot DNS resolution failures specifically with Google Public DNS, focusing on problems originating from the domain itself.

  • Troubleshooting involves checking DNSSEC configuration, authoritative name server health, delegation setup, and response sizes using tools like dig, DNSViz, and DNSSEC Analyzer.

  • Common issues include DNSSEC errors, large or slow responses, incorrect delegation, and unreachable authoritative servers.

  • Extended DNS Errors (EDEs) provide detailed error codes for deeper diagnosis, helping pinpoint the root cause of resolution failures.

  • Domain administrators can resolve issues by correcting DNSSEC settings, optimizing response sizes, ensuring name server accessibility, and addressing delegation problems.

When Google Public DNS cannot resolve a domain, it is often due to a problem with that domain or its authoritative name servers. This guide can help you locate the root cause of the problem, so that domain administrators can resolve it themselves.

General Tips

Use the general tips below to help with your troubleshooting efforts.

Comparison with results from other public resolvers may indicate that the problem is broader than just with Google Public DNS. The focus should then shift to looking directly at responses from the authoritative nameservers.

The response from Google Public DNS may include Extended DNS Errors (EDEs) which provide additional details about how a particular query failed. For example, they can be used to pinpoint problems with a particular upstream source or indicate that authoritative servers were unreachable or refused service. See the EDE overview below for more details.

Check whether lookups work with other public resolvers

If other public resolvers also encounter similar difficulties, the issue is most likely to be a problem with the domain's authoritative servers.

To see whether lookups work with other major public DNS resolvers, run the following commands at a command prompt, replacing example.test. with the domain in question (be sure, however, to keep the trailing dots):

Windows

nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.

macOS or Linux

dig example.test. @resolver1.opendns.com.
dig example.test. @dns.quad9.net.
dig example.test. @one.one.one.one.

These commands use the DNS resolvers of OpenDNS, Quad9 and Cloudflare 1.1.1.1. If you get resolution failures from two of these as well as Google Public DNS, the problem is likely with the domain or its name servers.

If you get a successful result from more than one other public resolver, there may be a problem with Google Public DNS. Make sure the domain's firewalls or nameservers aren't blocking DNS traffic from Google Public DNS IP address blocks or imposing overly strict query rate limits.

If no similar problems have been reported for the domain (or its TLD) on the issue tracker, you should report the issue, including command output and diagnostic page text or screenshots in your report.

Examine Extended DNS Error information

The Extended DNS Error option augments DNS responses with details of why a DNS query has failed. This allows further troubleshooting to focus on the reported symptoms.

Command-line DNS query utilities, such as dig (but not the rather outdated nslookup), can be used to observe the list of EDEs included in a response. See the ede list at the end of the document for an overview of the EDEs you can expect to find. Two examples with dig illustrate the presence of decoded EDEs in the OPT PSEUDOSECTION of the DNS response.

Example 1: DNSSEC validation failure.

The dnsec-failed.org domain is deliberately configured to fail DNSSEC validation. It is delegated as DNSSEC-signed the parent domain (.ORG), but lacks any matching signed zone-apex DNSKEY records. The problem zone where DNSSEC validation failed is reported in the EDE text:

$ dig @8.8.8.8 +nsid +nocmd +nostats -t A dnssec-failed.org.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47238
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; NSID: 67 70 64 6e 73 2d 61 74 6c ("gpdns-atl")
; EDE: 9 (DNSKEY Missing): (No DNSKEY matches DS RRs of dnssec-failed.org)
;; QUESTION SECTION:
;dnssec-failed.org.             IN      A

Example 2: All nameservers refuse to serve the domain.

In this example (not actual domain used), the nameservers to which the test.example domain is delegated by the .example TLD are not configured to serve this zone. They all return REFUSED. The overall error status is No reachable authority:

$ dig @8.8.8.8 +nsid +nocmd +nostats -t A www.test.example
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46708
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; NSID: 67 70 64 6e 73 2d 61 74 6c ("gpdns-atl")
; EDE: 23 (Network Error): ([192.0.2.1] rcode=REFUSED for www.test.example/a)
; EDE: 23 (Network Error): ([2001:db8::1] rcode=REFUSED for www.test.example/a)
; EDE: 23 (Network Error): ([192.0.2.2] rcode=REFUSED for www.test.example/a)
; EDE: 23 (Network Error): ([192.0.2.3] rcode=REFUSED for www.test.example/a)
; EDE: 23 (Network Error): ([192.0.2.4] rcode=REFUSED for www.test.example/a)
; EDE: 22 (No Reachable Authority): (At delegation test.example for www.test.example/a)
;; QUESTION SECTION:
;www.test.example.    IN      A

Step by step triage

Before starting these steps, check the domain at dns.google as described on the general troubleshooting page, which may refer you to a particular diagnostic step below. Otherwise, try all the following steps until you find the cause.

Step 1: Check for DNSSEC validation problems

If dns.google web lookups for the domain show "Status": 2 (SERVFAIL) and queries without DNSSEC succeed, there may be a DNSSSEC problem with the domain's name servers or its top-level domain (TLD) registry (which publishes DS records for DNSSEC validation of registered domains).

TIP: Details of the DNSSEC-validation problems encountered are typically included in the EDEs of the Google Public DNS response.

Changes in registrar or DNS service

DNSSEC problems can occur after a domain switches from a registrar or DNS service that supports DNSSEC to one that doesn't. If the previous service leaves stale DS records in the TLD registry, and the new service does not create new DNSKEY records with matching DS records in the TLD registry, validating resolvers like Google Public DNS cannot resolve the domain.

If this happens, ask your domain registrar to remove stale DS records from the TLD registry.

DNSSEC responses are too large

Another cause of DNSSEC problems can be DNSSEC responses that are too large to fit in one IP packet, creating fragmented responses that may be dropped. If DNSViz shows "no response received until UDP payload size was decreased" errors, DNSSEC failures may be caused by very large responses. Response sizes can be reduced by one or more of the following actions:

  • Configure "minimal responses" for authoritative name servers
  • Reduce the number of active DNSKEY records to two or three
  • Use 1280 or 2048 bit DNSKEY records (RFC 6781, StackExchange)
  • Switch from RSA signatures to smaller ECDSA signatures (RFC 8624)

Also check for any other DNSSEC problems reported by the tools in step 2. Examples include bad NSEC or NSEC3 denial-of-existence records proving there are no subdomains (PowerDNS with zones stored in external databases may have these) or expired RRSIG signatures (with broken manually configured signing processes).

Step 2: Check the authoritative name servers