Diagnosing resolution problems

If you are encountering problems when resolving particular names, and want to verify whether the problem is with Google Public DNS, please try resolve the domain first at: https://dns.google.com. If the result does not pinpoint the problem, you can run the following diagnostic procedure. If you want to report a problem to our user group, please copy and paste the results of the commands in your email. This information is vital to help us to identify the cause of the problem.

Step 1: Check to see if the authoritative name servers are correct

If Google Public DNS (or any open resolver) has trouble resolving a site, or returns inconsistent answers, sometimes it is because the authoritative name servers are having trouble. There are various tools and sites to help you check this.

Some users (and Google Public DNS engineers) have found intoDNS very helpful. For example, if you have trouble visiting www.example.com, visit http://intodns.com/ and enter example.com (the domain for www.example.com), or visit http://intodns.com/example.com directly.

Additionally, DNSViz is useful for diagnosing DNSSEC related issues. For example, visit http://dnsviz.net/ and enter example.com (the domain for www.example.com), or visit http://dnsviz.net/d/example.com/dnssec/ directly.

If these tools identify a name server configuration issue, please contact the owner of the name server to fix it.

DNSSEC failure often happens after a zone has switched from a hosting service that supports DNSSEC to one that does not support DNSSEC. If the previous hosting service did not remove the DS records from the parent zone (.com for example.com), and the new hosting service is unable to add the DNSKEY records to the child zone (example.com), Google Public DNS cannot validate the zone and returns SERVFAIL. The solution is to ask the previous hosting service to remove those obsolete DS records.

If none of these tools finds any issue with the name server, continue to step 2.

Step 2: Verify that your client can communicate with the Google Public DNS servers

IPv4

Open a command prompt, and run the following command:

Windows

tracert -d 8.8.8.8

Mac OS X

/usr/sbin/traceroute -n -w 2 -q 2 -m 30 8.8.8.8

Linux

sudo traceroute -n -w 2 -q 2 -m 30 8.8.8.8

If the last line of the output does not list 8.8.8.8 as the final hop, or if there are significant timeouts, there may be a network problem preventing you from contacting our servers. Please include the output of the command in any communication with the Google Public DNS team.

If the last line of the output does list 8.8.8.8 as the final hop, continue to step 3.

IPv6

Open a command prompt, and run the following command:

Windows

tracert -d 2001:4860:4860::8888

Mac OS X

/usr/sbin/traceroute6 -n -w 2 -q 2 -m 30 2001:4860:4860::8888

Linux

sudo traceroute -n -w 2 -q 2 -m 30 2001:4860:4860::8888

If the last line of the output does not list 2001:4860:4860::8888 as the final hop, or if there are significant timeouts, there may be a network problem preventing you from contacting our servers. Try configuring Google Public DNS for IPv4 to diagnose whether the problem is due to IPv6 connectivity on your network. If IPv4 works for you, you may want to revert your IPv6 configuration and use Google Public DNS with IPv4 exclusively. Otherwise, please include the output of the command in any communication with the Google Public DNS team.

If the last line of the output does list 2001:4860:4860::8888 as the final hop, continue to step 3.

Step 3: Verify that Google Public DNS can resolve the selected hostname

In the following steps, replace www.example.com. with the name that you had difficulty resolving. (Put a period at the end of the name to avoid problems with domain suffixes and search lists.)

IPv4

At the command prompt, run the following command:

Windows

nslookup -debug www.example.com. 8.8.8.8

Mac and Linux

dig @8.8.8.8 www.example.com.

If the output shows an answer section with an A record for the hostname, then Google Public DNS is able to resolve the name. Check your settings to make sure your system is correctly configured to use Google Public DNS. If you are still unable to solve the problem, please include the output of the command in any communication with the Google Public DNS team.

If the output does not show an answer for the hostname, continue to step 4.

IPv6

At the command prompt, run the following command:

Windows

nslookup -debug -type=AAAA www.example.com. 2001:4860:4860::8888

Mac and Linux

dig @2001:4860:4860::8888 www.example.com. AAAA

If the output shows an answer section with an AAAA record for the hostname, then Google Public DNS is able to resolve the name. Check your settings to make sure your system is correctly configured to use Google Public DNS. If you are still unable to solve the problem, please include the output of the command in any communication with the Google Public DNS team.

If the output shows an answer section with an A (IPv4) record for the hostname, then Google Public DNS is able to resolve the name, but the host and/or its name server are not configured to return IPv6 results. If you want to verify that you are correctly receiving AAAA records, you can use the hostname ipv6.google.com as a generic test.

If the output for ipv6.google.com, or another host for which you are certain IPv6 records exist, does not show an answer, continue to step 4.

Step 4: Verify that Google Public DNS can resolve the selected hostname without performing DNSSEC validation

Google Public DNS performs DNSSEC validation for all DNS queries by default. When a name server fails DNSSEC validation, Google Public DNS returns SERVFAIL. To verify whether Google Public DNS can resolve the hostname without performing DNSSEC validation, run the following command:

IPv4

Windows

Unfortunately, nslookup does not support DNSSEC and cannot help diagnosis here. Continue to step 5.

Mac and Linux

dig @8.8.8.8 www.example.com. +cd

IPv6

Windows

Unfortunately, nslookup does not support DNSSEC and cannot help diagnosis here. Continue to step 5.

Mac and Linux

dig @2001:4860:4860::8888 www.example.com. AAAA +cd

If you cannot get a successful result without DNSSEC validation either, continue to step 5.

If you get a successful result, this usually indicates a DNSSEC misconfiguration at the name server. Please make sure that you have followed through step 1. If none of the tools finds any issue with the name server, continue to step 5.

Step 5: Verify that another open resolver can resolve the selected hostname

At the command prompt, run one of the following commands:

Windows

nslookup www.example.com. 4.2.2.1
nslookup www.example.com. 4.2.2.2
nslookup www.example.com. 208.67.222.222
nslookup www.example.com. 208.67.220.220

Mac and Linux

dig www.example.com. @4.2.2.1
dig www.example.com. @4.2.2.2
dig www.example.com. @208.67.222.222
dig www.example.com. @208.67.220.220

(The first two commands test Level 3's DNS servers. The last two commands test OpenDNS's DNS servers.)

If you are unable to get a successful result, this means that there is most likely a problem with the server you are trying to contact. Wait some time and try running the tests again. This may be a temporary problem on the server's side that will likely resolve itself eventually. If it does not, you should contact the owner of the server.

If you are able to get a successful result, there may be a problem with Google Public DNS. Please follow the directions to report an issue to the Google Public DNS team, and include the output of the commands you ran in the report.