dnstraverse is an open source Ruby Gem API and associated command line program that lets you check a DNS entry by traversing all possible routes of the DNS. It works much like a real DNS resolver would do, but follows every answer comprehensively from the roots down.
- Get a list of roots with help from your local resolver
- Ask each root for your DNS entry
- Follow every referral (and traverse all resolutions required) in turn, recursively (keeping state and cache)
- Collate all the results together and display the results
dnstraverse is a free program, you can download it and use it as much as you like.
dnstraverse in action
$ dnstraverse --udp-size 1000 -v www.google.com Using E.ROOT-SERVERS.NET (22.214.171.124) as initial root Running query www.google.com type a 1 [www.google.com] E.ROOT-SERVERS.NET (126.96.36.199) <> 1.1 [www.google.com] B.GTLD-SERVERS.NET (188.8.131.52) <com> 1.1.1 [www.google.com] ns1.google.com (184.108.40.206) <google.com> 220.127.116.11 [www.l.google.com] a.l.google.com (18.104.22.168) <l.google.com> 22.214.171.124 [www.l.google.com] d.l.google.com (126.96.36.199) <l.google.com> 188.8.131.52 [www.l.google.com] b.l.google.com (184.108.40.206) <l.google.com> 220.127.116.11 [www.l.google.com] c.l.google.com (18.104.22.168) <l.google.com> 22.214.171.124 [www.l.google.com] e.l.google.com (126.96.36.199) <l.google.com> 188.8.131.52 [www.l.google.com] g.l.google.com (184.108.40.206) <l.google.com> 220.127.116.11 [www.l.google.com] f.l.google.com (18.104.22.168) <l.google.com> 1.1.2 [www.google.com] ns2.google.com (22.214.171.124) <google.com> 126.96.36.199 [www.l.google.com] g.l.google.com (188.8.131.52) <l.google.com> 184.108.40.206 [www.l.google.com] b.l.google.com (220.127.116.11) <l.google.com> 18.104.22.168 [www.l.google.com] d.l.google.com (22.214.171.124) <l.google.com> 126.96.36.199 [www.l.google.com] c.l.google.com (188.8.131.52) <l.google.com> 184.108.40.206 [www.l.google.com] a.l.google.com (220.127.116.11) <l.google.com> 18.104.22.168 [www.l.google.com] e.l.google.com (22.214.171.124) <l.google.com> 126.96.36.199 [www.l.google.com]This is the current query name f.l.google.com (188.8.131.52)This is the server name and IP address <l.google.com>This is the current bailiwick [cut for this web page] The following servers were encountered: ns1.google.com: 184.108.40.206 ISC BIND 9.2.3rc1 -- 9.4.0a0 (9.4.2-P1) ns2.google.com: 220.127.116.11 ISC BIND 9.2.3rc1 -- 9.4.0a0 (9.4.2-P1) ns3.google.com: 18.104.22.168 ISC BIND 9.2.3rc1 -- 9.4.0a0 (9.4.2-P1) ns4.google.com: 22.214.171.124 ISC BIND 9.2.3rc1 -- 9.4.0a0 (9.4.2-P1) a.l.google.com: 126.96.36.199 XBILL jnamed (dnsjava) b.l.google.com: 188.8.131.52 XBILL jnamed (dnsjava) c.l.google.com: 184.108.40.206 XBILL jnamed (dnsjava) d.l.google.com: 220.127.116.11 XBILL jnamed (dnsjava) e.l.google.com: 18.104.22.168 XBILL jnamed (dnsjava) f.l.google.com: 22.214.171.124 XBILL jnamed (dnsjava) g.l.google.com: 126.96.36.199 XBILL jnamed (dnsjava) a.gtld-servers.net: 188.8.131.52 VeriSign ATLAS b.gtld-servers.net: 184.108.40.206 VeriSign ATLAS c.gtld-servers.net: 220.127.116.11 VeriSign ATLAS d.gtld-servers.net: 18.104.22.168 VeriSign ATLAS e.gtld-servers.net: 22.214.171.124 VeriSign ATLAS f.gtld-servers.net: 126.96.36.199 VeriSign ATLAS g.gtld-servers.net: 188.8.131.52 VeriSign ATLAS h.gtld-servers.net: 184.108.40.206 VeriSign ATLAS i.gtld-servers.net: 220.127.116.11 VeriSign ATLAS j.gtld-servers.net: 18.104.22.168 VeriSign ATLAS k.gtld-servers.net: 22.214.171.124 VeriSign ATLAS l.gtld-servers.net: 126.96.36.199 VeriSign ATLAS m.gtld-servers.net: 188.8.131.52 VeriSign ATLAS d.root-servers.net: 184.108.40.206 ISC BIND 9.2.3rc1 -- 9.4.0a0 (9.4.2) Results: 14.3%: Answer from e.l.google.com (220.127.116.11) www.l.google.com. 300 IN A 18.104.22.168 www.l.google.com. 300 IN A 22.214.171.124 www.l.google.com. 300 IN A 126.96.36.199 14.3%: Answer from a.l.google.com (188.8.131.52) www.l.google.com. 300 IN A 184.108.40.206 www.l.google.com. 300 IN A 220.127.116.11 www.l.google.com. 300 IN A 18.104.22.168 14.3%: Answer from c.l.google.com (22.214.171.124) www.l.google.com. 300 IN A 126.96.36.199 www.l.google.com. 300 IN A 188.8.131.52 www.l.google.com. 300 IN A 184.108.40.206 14.3%: Answer from f.l.google.com (220.127.116.11) www.l.google.com. 300 IN A 18.104.22.168 www.l.google.com. 300 IN A 22.214.171.124 www.l.google.com. 300 IN A 126.96.36.199 14.3%: Answer from b.l.google.com (188.8.131.52) www.l.google.com. 300 IN A 184.108.40.206 www.l.google.com. 300 IN A 220.127.116.11 www.l.google.com. 300 IN A 18.104.22.168 14.3%: Answer from d.l.google.com (22.214.171.124) www.l.google.com. 300 IN A 126.96.36.199 www.l.google.com. 300 IN A 188.8.131.52 www.l.google.com. 300 IN A 184.108.40.206 14.3%: Answer from g.l.google.com (220.127.116.11) www.l.google.com. 300 IN A 18.104.22.168 www.l.google.com. 300 IN A 22.214.171.124 www.l.google.com. 300 IN A 126.96.36.199
dnstraverse has been released as an early beta, please check it out.
- Does dnstraverse understand the bailiwick rules?
- Yes, dnstraverse keeps track of the bailiwick from the referring parent and discards entries that are outside before placing either them in the cache or using them. This means additional record hints are typically ignored and a traversal resolution is started similiar to how a real resolver would operate.
- How does dnstraverse deal with a referral without an accompanying IP address?
- dnstraverse will resolve the name by looking up the best starting servers from the resolver cache specific to this branch of the tree and then doing a traversal for the name. dnstraverse always does a traverse to find information and won't fill in details from the local resolver.
- Why does dnstraverse only look at one root?
- By default dnstraverse only uses one root. You can pass --all-root-servers to make it access and correlate all of them, however since most DNS problems are not because of a root server problem, the default mode is to only use one of them.
- What's the difference between fast mode (--fast) and normal mode?
- In the real world a resolver has a cache. When you ask it a question, it uses the cache to find the closest authoritative resolver. For example, if you ask your resolver for www.google.com and it already knows an authoritative nameserver for .com then it won't have to go and ask the roots from scratch, it can start from the .com resolvers. In normal mode, dnstraverse maintains a cache for every step of every branch of the tree, and won't assume that a referral to the same place that it has already seen will end in the same result because the cache might have different items in it for each branch. In fast mode, dnstraverse will make the assumption that the cache won't make any difference to the result, and therefore it re-uses earlier results. In almost all circumstances fast mode will end up with the same results.
- Does dnstraverse ask the same questions over and over again for each branch of the tree?
- No, dnstraverse has a low level cache and will only ask a question once to a given server, irrespective of any other options (e.g. --fast mode or not).
- Does dnstraverse support EDNS0?
- Yes, by default dnstraverse has EDNS0 turned on with a size of 2048. You can change this with the --udp-size option. If you specify 512 this will turn of EDNS0.
- How do I debug a problem?
- dnstraverse debug mode can be turned on with -d, and will also turn on lower level debugging if two -d arguments are passed.
- What does --show-resolves do?
- When asking resolvers about a DNS entry sometimes dnstraverse will be given a referral to a DNS server without an IP address. In these situations dnstraverse does a traversal resolution of the referral. If you you would like to see progress of this as it goes, pass the option. Otherwise, dnstraverse will tell you the results of the resolution when it has completed, and then continue on with the traversal of the main request.
- What does NODATA mean?
- NODATA typically means that the name you are looking for exists but there is no such record of the type you've requested.
- What does No glue mean?
- dnstraverse detects this condition if the referred name server is within the current bailiwick but no IP address has been supplied. For example if dnstraverse is told by an authoritative server for example.com that ns.example.com is responsible for example.com, but that this authoritative server doesn't know the IP address for ns.example.com, then it is said to be missing the glue record that identifies the server. dnstraverse has nobody to go to next, so this error is generated as the domain is unreachable.
- Is "No glue at A.ROOT-SERVERS.NET (188.8.131.52) for M.GTLD-SERVERS.net" a problem?
- This normally happens if you turn off EDNS0 by specifying a UDP size of 512. This is because now that IPv6 exists, it is not possible for all the referrals from the root servers (both A and AAAA) to fit in a single packet. Therefore, they omit some. It is not something you need to worry about. If you allow dnstraverse to use the EDNS0 extensions then the errors from this condition will go away.
- dnstraverse says there's no glue, but there are AAAA records present, why?
- dnstraverse is not IPv6 aware yet, sorry. It produces results as per an IPv4 client.
- How does this compare to the dnscheck service?
- This implementation is more accurate than the Perl-based dnscheck service, including DNS bailiwick concepts, simulation of the resolver cache and more accurate resolver behaviour. The source to the older dnscheck service is not available.