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
DSrecords in the TLD registry, and the new service does not create newDNSKEYrecords with matchingDSrecords 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
DNSKEYrecords to two or three - Use 1280 or 2048 bit
DNSKEYrecords (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
If Google Public DNS (or any open resolver) has a problem resolving a domain, DNSViz shows domain and name server issues that cause it. Go to the DNSViz web page and enter the problematic domain name. If DNSViz has no historical data, or only has data that is more than a day old (such as shown on the page here) click the large Analyze button to reveal a smaller Analyze button below (if it's not already visible) and click that too. When the analysis completes, click "Continue" to show results. Click the red errors and yellow warnings on the left sidebar to reveal details, or hold the pointer over objects in the diagram to pop-up that info in context.
If earlier diagnostics indicated possible DNSSEC problems with the domain,
go to the DNSSEC Analyzer web page
and enter the domain name. If this analyzer reports DNSSEC errors or warnings,
hold the pointer over the red
The intoDNS web page reports on non-DNSSEC problems with the domain entered on the main page and also shows suggestions for fixing them.
Domain administrators should fix most of the errors these tools report, since they can cause problems not just for Google Public DNS but also other resolvers.
Step 3: Check for delegation problems
Google Public DNS is a "parent-centric" resolver, which only uses the name servers returned in referrals from the parent domain. If the name server names and glue addresses in the TLD are stale or incorrect, this can cause delegation problems.
If either DNSViz or intoDNS report warnings about inconsistencies between the name servers delegated in the TLD and those present in the child domain itself, those may need to be addressed before Google Public DNS can resolve the domain. If these tools report that the registered domain does not exist (NXDOMAIN), check that the domain is not expired or on registration hold for any reason.
Delegation problems can also be caused by a failure to resolve the names of the
name servers for a domain. Check the A and AAAA records for the name servers
on dns.google to see if there are problems with the name servers' domains.
Step 4: Check for large responses
DNS relies upon UDP to carry the majority of its traffic. Large UDP datagrams are subject to fragmentation and fragmented UDP suffers from unreliable delivery. This was the focus of DNS Flag Day 2020, an effort to improve reliability of DNS globally. Google Public DNS has participated in this effort, and limits the size of UDP responses it will accept over UDP. Try a query like those below, with your own command prompt or a Google Cloud Shell:
$ dig +short example.com NS ns1.example.com ns2.example.com $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY ...
These queries for various record types are specifying:
+dnssec- Enable DNSSEC, especially returning the required records for DNSSEC validation when they are available. These can expand the size of the result significantly. This emulates Google Public DNS's behavior.
+bufsize=1400- Limit the allowed UDP buffer size. This emulates Google Public DNS's behavior, as of the DNS Flag Day 2020 effort.
+timeout=1- Set the timeout to one second. This emulates Google Public DNS's behavior.
@ns1.example.com- Which authoritative server to query -- keep the
@sign but otherwise replace with your own domain's authoritative server, as shown by the first command.
Observe the output; do you see a line like:
;; Truncated, retrying in TCP mode.- This indicates that the response was larger than the requested UDP buffer size, so it was truncated and in response the client switched to TCP. Your authoritative servers should be capable of handling DNS traffic on TCP port 53. (See RFC 7766 which requires that "implementations MUST support both UDP and TCP transport".)
;; MSG SIZE rcvd: 2198- For any number above 1400? This again indicates a large response.
;; Query time: 727 msec- For any number above 500? Slow responses (especially those near or above 1 second) may be discarded by Google Public DNS. This is especially likely if some time was spent on a UDP attempt which was then followed by a TCP attempt. Geographical location of server and client can greatly affect latency.
;; connection timed out; no servers could be reached- Especially when only for some queries, this indicates a problem whereby your server is unable to answer DNS queries in a timely fashion.
You can try the following query variations:
- Adding a
+tcpparameter. - This forces
digto use TCP immediately, you can check whether your authoritative server handles TCP queries directly this way. - Removing the
+bufsize=1400parameter. - This will restore
dig's default behavior, (a bufsize of 4096). If your queries fail with this setting but work without it, this is a hint that your server does not handle TCP failover well. Relying on UDP to carry large responses only works sometimes. The best course of action is to support TCP transport for DNS. - Repeating at each name server.
- The example above has two authoritative name servers (
ns1andns2). Some problems are caused by different servers returning different answers. Check that they all answer consistently by repeating the same queries at all authoritative servers.
If all queries' responses were small (1400 bytes or fewer), fast (preferably 500 milliseconds or faster), and reliable (work consistently over TCP and UDP), then response size is not your concern; read the other troubleshooting sections. Even if your responses are fast, queries from geographically far away might be slower.
If any of these checks failed (large? slow? unreliable?) the primary course of action is to A) make sure that your server responds with UDP truncation, when its response exceeds the requested UDP buffer size and B) that it can handle the TCP query retry which will follow. Several tools can help you diagnose DNS reliability issues:
- DNSViz
- DNSSEC Debugger
- EDNS Compliance Tester
- DNS Checker -- be sure to uncheck the "CD" (disable checking DNSSEC) box
If any errors or warnings are revealed by these tools, be sure to address them. Also be sure to read all the other troubleshooting instructions on this site.
Reported Extended DNS Errors
This section lists most of the EDE codes the Google Public DNS implementation
may return for DNS resolution errors. EDEs are solely a diagnostic aid, DNS
client behaviour must not depend on the presence or content of EDEs. The
numeric info codes and descriptive extra text returned may change at any
time without notice.
For a description of the EDE protocol see the Extended DNS Error RFC and the IANA EDE registry for the current set of assigned codes.
| Error Type & RFC link |
Example Text | Causes |
|---|---|---|
| Stale Answer EDE 3 |
For mx1.example.org/a
|
The nameservers for a zone consistently returned error responses or were non-responsive so an expired, but still usable, cached response was returned. |
| DNSSEC Bogus EDE 6 |
No valid RRSIGs for example.org/mx
|
Only invalid or unsupported signatures were returned with one of the response RRsets. DNSSEC-signed zones must have valid signatures for all authoritative RRsets. |
| DNSKEY Missing EDE 9 |
No DNSKEY matches DS RRs of example.org
|
The zone apex DNSKEY records couldn't be obtained from the nameservers for a signed zone, or none of the obtained keys match the DS records obtained from the parent zone. A delegation with parent-side DS records MUST have matching DNSKEYs at the child zone apex. |
| RRSIGs Missing EDE 10 |
For example.org/mx
|
DNSSEC signatures were missing from authoritative responses for a signed zone. All nameservers for the child side of a DNSSEC-signed delegation must fully support DNSSEC, and all authoritative zone data must be signed. |
| NSEC Missing EDE 12 |
Invalid denial of existence of example.org/mx
|
The NSEC or NSEC3 records to authenticate a wildcard, NODATA or NXDOMAIN response were missing or incomplete. |
| No Reachable Authority EDE 22 |
At delegation example.org for mx1.example.org/a
|
Every nameserver for the reported zone returned an error response or failed to respond. |
| Network Error EDE 23 |
[192.0.2.1] rcode=SERVFAIL for example.org/mx
|
The responsible nameserver returned an unexpected error, rather than a
normal NOERROR, NODATA, or NXDOMAIN response. This indicates a problem
with either how the specific query is handled or with the zone as a whole.
Please note that a Network Error is reported only when a nameserver actually responds. If none of the nameservers respond, the reported EDE is No Reachable Authority.
|
| Lame Delegation EDE 0 |
[192.0.2.1] Lame delegation at example.org for ap.example.org/mx
|
A nameserver's delegation response was a referral to a zone that was not closer to the query domain than its zone of authority. |
| Irrelevant Answer EDE 0 |
[192.0.2.1] All answers irrelevant at example.org for mx1.example.org/a
|
The response section of the response only contained records that don't match the query name and type and aren't an alias (CNAME) for the name. The responding nameserver implementation is not compliant with DNS standards. |
| CNAME Loop EDE 0 |
CNAME cycle at www.example.org/a
|
The chain of aliases received in response to a query is either too long or contains a cycle. The aliases configured for the query name must be loop-free and the chain shouldn't have more than approximately 10 aliases. |
| Work Limits Exceeded EDE 0 |
Query or time limits exceeded for www.example.org/a
|
Processing of the input request required too many queries or too much time. |