Troubleshooting

If you have problems resolving domains using Google Public DNS, first check the Google Public DNS homepage at https://dns.google/. It has a simple DNS lookup form, shown here.

If your browser can't find the dns.google server, or it doesn't respond, check that you can reach the Google Public DNS servers using command-line diagnostics.

Type google.com (or any domain name or IP address) and press Enter to see a detailed DNS results page like the following:

Troubleshooting Google Public DNS

There are many possible kinds of DNS resolution problems; follow the directions under the heading that most closely matches your issue. If you need to report a problem and get help, include the output of any commands or text from diagnostic pages in your report.

Problems resolving a domain

If Google Public DNS has problems resolving a certain domain name, enter it on the dns.google detail page. If the problem is with a particular DNS resource record (RR) type, enter it in the "RR type" text field (you can also enter a number). Press Enter or click Resolve to see the results.

In the detailed results, there may be a line with "Comment": at the bottom with diagnostics about your DNS query. For example, you might see
"DNSSEC validation failure. Check http://dnsviz.net/d/dnssec-failed.org/dnssec/ and http://dnssec-debugger.verisignlabs.com/dnssec-failed.org for errors"

Visit all comment URLs (they aren't links, copy and paste them into a browser) to see detailed diagnostics that can identify the cause of resolution problems.

If there is a Comment line that matches one of the following entries, click the corresponding link to go directly to a specific diagnostic step, or just start with the first step of Domain troubleshooting.

DNSSEC validation failure

If you see this, disable validation by clicking the DNSSEC toggle, and click Resolve to retry the query. If that succeeds ("Status": 0), there is a DNSSEC problem; see DNSSEC troubleshooting. Otherwise, see Name server troubleshooting.

Name servers

See Name server troubleshooting.

Resolution failure or Lame delegation

See Delegation troubleshooting.

If you have problems with large records (usually DNSSEC keys or TXT records), read about troubleshoting large responses.

Returning the wrong answers for a domain

There are many reasons Google Public DNS can return wrong answers; try any of the following that seem possible given your knowledge of the domain.

If the servers for a domain have recently changed

Especially if the domain has new DNS servers or a new DNS registrar, Google Public DNS may be returning old (but unexpired) cached answers. Use Flush Cache (documentation) to flush the registered domain and the specific domain name returning a stale answer.

If you still get stale answers after flushing, query the SOA RR type for the registered domain on the dns.google detail page. and check the zone serial number (the first number in the "Answer" "data"). If you sometimes get different serial numbers, some of the authoritative name servers may be serving stale data, and the DNS operator for the domain needs to fix the problem.

If the addresses for a Content Delivery Network (CDN) domain are far away

When there is a closer address that should have been returned, it is possible the authoritative name servers do not properly implement EDNS Client Subnet (ECS). The DNS operators for the domain should confirm they are following all the guidelines on that page. If the domain is a Google property, such as www.google.com or www.youtube.com, please see How to Get Help.

If your applications see different addresses from the dns.google web results

If the dns.google web site is blocked or shows very different results, first check that you are using Google Public DNS. If you are, different answers could be due to DNS hijacking by a captive Wi-Fi portal, malware on your router, your ISP, or its networks. See the troubleshooting directions for blocking and hijacking.

Resolving domains is too slow

While tools like traceroute and ping report network latencies, they do not measure the speed of DNS resolution, and are only helpful when trying to find the location of delays, or to confirm network reachability. Google does not block ICMP or random UDP to Google Public DNS IP addresses, but there are rate limits on ICMP error replies, and ICMP traffic may be de-prioritized within Google networks.

To measure DNS resolution speed you need to use a DNS testing tool, like farrokhi/dnsdiag (Python, GitHub) or dnsping (C#, SourceForge). More comprehensive measurements can be performed with tools like Namebench or the GRC DNS Benchmark (for Windows).

Determine metro serving your queries

The network distance between your device and the Google Public DNS resolver directly contributes to the resolution speed. We implement the Nameserver Identifier Option to report the airport code of the metro where the DNS query is handled. If the metro location is far away from your location the query latency will be higher. This can be due to various reasons including sub-optimal routing between your network and Google, or lack of serving capacity in a closer metro.

To find the airport code, you can make a query to our DNS resolvers with EDNS option nameserver identifier (NSID) set. The response will be in the format gpdns-<airport code>. Run the following command to find out which metro your response is coming from:

$ dig @dns.google. +nsid | grep NSID
; NSID: 67 70 64 6e 73 2d 63 68 73 ("gpdns-chs")
$ dig www.google.com @dns.google. +nsid | grep NSID
; NSID: 67 70 64 6e 73 2d 63 68 73 ("gpdns-chs")

Resolution over IPv6 is slower

If resolution latencies over IPv6 are significantly longer than for IPv4, IPv6 connectivity between your ISP and Google may be sub-optimal. ISPs peering with Google should check for much larger hop counts in IPv6 traceroute output (see reaching the Google Public DNS servers) or other issues with BGP routing shown on their ISP dashboard and email the Google NOC if their IPv6 routing appears to be landing in a different metro than IPv4.

No response to (some of) my DNS queries

It is normal for a very small fraction of UDP DNS requests to be dropped, but if you see drops for one percent or more of your queries, use a DNS testing tool like those in the previous section.

If a DNS testing tool shows high levels of unanswered queries (and especially if ping and traceroute do not show comparable drop rates), check whether your IP address is generating more than 1000 queries per second, which can trigger rate limiting. If so, you can request a rate limit increase on our issue tracker.

DNS blocking and hijacking

If you don't get any responses to DNS queries (but the dns.google page works) UDP and TCP queries may be blocked or hijacked. Run these commands to check if UDP and TCP queries reach Google Public DNS:

nslookup -debug -type=TXT test.dns.google.com. dns.google.
nslookup -debug -type=TXT -vc locations.dns.google.com. dns.google.

dig -t TXT test.dns.google.com. '@dns.google.'
dig -t TXT +tcp locations.dns.google.com. '@dns.google.'

If the first command's output shows "Thanks for using Google Public DNS." your UDP queries are reaching Google Public DNS; if the second command's output includes locations.publicdns.goog. your TCP queries are reaching Google too.

If the output shows NXDOMAIN then you are reaching another DNS resolver. If the output shows a timeout, DNS queries to Google Public DNS are blocked. Use the UDP or DNS traceroute commands in the following section to see where hijacking or blocking may be happening.

Check that you are reaching the Google Public DNS servers

If you cannot open the dns.google homepage, there may be a network problem or blocking that prevents you from reaching Google Public DNS.

If your system is configured to use Google Public DNS as its DNS resolver, you may need to replace the name dns.google in the following commands with the Google Public DNS IP addresses. Try with the name first, and if it fails, use 8.8.8.8 or another address.

Open a terminal window with a command prompt and run these traceroute commands:

tracert -d -w 2000 dns.google

tracert -6 -d -w 2000 dns.google

/usr/sbin/traceroute -n -w 2 -m 30 dns.google

/usr/sbin/traceroute6 -n -w 2 -m 30 dns.google

sudo /usr/sbin/traceroute -n -w 2 -m 30 dns.google

If the last line of the output does not show a Google Public DNS IP address (8.8.8.8, 8.8.4.4, or an IPv6 address starting with 2001:4860:4860), there may be a network problem preventing you from reaching Google.

On non-Windows systems, repeat the commands above with an -I or -U option, to use ICMP packets or non-DNS UDP packets sent to the DNS port (53). If the -I option is not recognized, try the ping command to send ICMP:

ping -c 2 dns.google

The dnstraceroute command of the farrokhi/dnsdiag DNS testing tools described under Resolving domains is too slow can be used to trace the route of real DNS queries (even on Windows).

If some of these commands work and others return network errors or timeouts, network filtering may be preventing you from reaching Google Public DNS. Contact your network administrator or ISP support to confirm this.

If none of these commands are successful, contact your (upstream) ISP, or if you are an ISP that peers with Google, contact the Google NOC. The last line of traceroute output that does not have three stars * * * (showing consistent timeouts) may indicate where the problem is occurring.