... up to the DNS server that answers it? When I use the public DNS server provided by Google (8.8.8.8), this is the DNS server reported by "nslookup" (8.8.8.8), however the www.dnsleaktest.com website shows a different IP number, actually two, 74.125.189.22 and 74.125.189.23. Is there a way to trace the route taken by the DNS query from 8.8.8.8 to 74.125.189.22, including other DNS servers eventually queried in-between? I tried nslookup's debug options, but there is no reference to 74.125.189.22 in the debug info.
5 Answers
Yes you can use dig +trace but it only works externally.
I do this on a daily basis at work. And I can tell you there is no tool that will 'trace' the path of DNS forwarding that happens in Enterprise environments.
There are two models of DNS traversal.
- Root Hints and Zone Delegation
- Conditional and Global Forwarding
Number 1 is how the public internet works. This is easy to trace. You can use
dig +trace
Number 2 is how internal DNS at companies works. This cannot be traced with a command
When I have to trace #2, I do it manually
- Check ipconfig /all to identify my first hop DNS servers
- Log in to the first hop DNS server (linux or windows)
- Map out the zone specific forwarding rules, and the global forwarding
- Use above rules to identify where queries go, for the domain I'm troubleshooting
- Log in to the next server (in the forwarding path) and repeat
- Until I hit the Authoritative Nameserver
I dont believe this is possible. When you make a DNS request, it goes to your DNS server. Your DNS server tries to resolve the name and if it cant, it moves up the DNS name hierarchy, becoming the requester. In short, once a request is made the requester is just waiting for a response from the next server.
8.8.8.8 is not a single DNS server, it is rather an anycast network of DNS servers, hundreds of them, installed all over the world. When you use google's public dns as your DNS, the internet will guide your DNS query to the nearest google dns server. This dns server will operate as a usual DNS resolver name server.
- If it has a cached, unexpired result for the query, it will send that as an answer.
- If not, it will look up which name servers are authoritative for the specific domain, and will retrieve the result from them. It will run the look up recursively, resolving any CNAMEs that it will find, until it responds with an actual IP or NXDOMAIN ( domain not found).
In case no 2, the request from Google Name servers to the authoritative server will flow from one of hundreds google's public ips, but not from the anycast ip (8.8.8.8) as anycast addresses are used to define only destinations, not sources. Hence the IPs you see in the site, which you should be able to verify from any whois service that they belong to google.
I've never used it myself , but it seems that dnsracer does what you want.
http://www.mavetju.org/unix/dnstracer.php
I am not sure there is such a tool available on Windows, but there is an available package in Linux Debian repository.
-
2
-
@JdeBP It would be nice at times to know which DNS server was responsible for resolving a particular address.– bvjApr 1, 2015 at 19:31
-
It's dead easy to determine that, because it is configured at your end. It's (the anycast instance of) the server at 8.8.8.8, in the case of the question at hand, for example, as configured in Control Panel on that computer. It is there that the process of query resolution happens.– JdeBPApr 4, 2015 at 19:21
Try going to https://www.grc.com/dns/dns.htm to see which DNS servers you are currently using. Also make sure in your windows network settings that your DNS settings are set to the google dns at 8.8.8.8
and 8.8.4.4
.
As for the 74.125.189.22 IP range still seem to be Google but pointing to Google Translate.
If I were you I'd follow these steps.
- Change TCP/IP Settings in Windows 7 to verify I'm using the above mentioned google DNS.
- Use DNS Nameserver Spoofability Test to make sure the only DNS being used is the Google DNS.