Domain Troubleshooting

When Google Public DNS cannot resolve a domain, it is often due to a problem with that domain or its authoritative name servers. The following steps can help determine what causes the problem, so that domain administrators can resolve it themselves.

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).

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

Archived DNSViz page

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 or yellow ⚠︎ icons for suggestions on how to fix them.

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 whether other public resolvers resolve the domain

If you did not find any cause of the problem after following the steps above, run the following commands at a command prompt, replacing example.test. with the domain in question (and preserving 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. If no similar problems have been reported for the domain (or its TLD) on the issue tracker, you should report the issue to us, including command output and diagnostic page text or screenshots in your report.