What's dnstraverse?

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.

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 (192.203.230.10) as initial root
Running query www.google.com type a
1 [www.google.com] E.ROOT-SERVERS.NET (192.203.230.10) <>
1.1 [www.google.com] B.GTLD-SERVERS.NET (192.33.14.30) <com>
1.1.1 [www.google.com] ns1.google.com (216.239.32.10) <google.com>
1.1.1.1 [www.l.google.com] a.l.google.com (209.85.139.9) <l.google.com>
1.1.1.2 [www.l.google.com] d.l.google.com (74.125.77.9) <l.google.com>
1.1.1.3 [www.l.google.com] b.l.google.com (74.125.45.9) <l.google.com>
1.1.1.4 [www.l.google.com] c.l.google.com (64.233.161.9) <l.google.com>
1.1.1.5 [www.l.google.com] e.l.google.com (209.85.137.9) <l.google.com>
1.1.1.6 [www.l.google.com] g.l.google.com (74.125.95.9) <l.google.com>
1.1.1.7 [www.l.google.com] f.l.google.com (72.14.235.9) <l.google.com>
1.1.2 [www.google.com] ns2.google.com (216.239.34.10) <google.com>
1.1.2.1 [www.l.google.com] g.l.google.com (74.125.95.9) <l.google.com>
1.1.2.2 [www.l.google.com] b.l.google.com (74.125.45.9) <l.google.com>
1.1.2.3 [www.l.google.com] d.l.google.com (74.125.77.9) <l.google.com>
1.1.2.4 [www.l.google.com] c.l.google.com (64.233.161.9) <l.google.com>
1.1.2.5 [www.l.google.com] a.l.google.com (209.85.139.9) <l.google.com>
1.1.2.6 [www.l.google.com] e.l.google.com (209.85.137.9) <l.google.com>
1.1.2.7 [www.l.google.com]This is the current query name f.l.google.com (72.14.235.9)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: 216.239.32.10   ISC BIND 9.2.3rc1 -- 9.4.0a0 (9.4.2-P1)
    ns2.google.com: 216.239.34.10   ISC BIND 9.2.3rc1 -- 9.4.0a0 (9.4.2-P1)
    ns3.google.com: 216.239.36.10   ISC BIND 9.2.3rc1 -- 9.4.0a0 (9.4.2-P1)
    ns4.google.com: 216.239.38.10   ISC BIND 9.2.3rc1 -- 9.4.0a0 (9.4.2-P1)
    a.l.google.com: 209.85.139.9    XBILL jnamed (dnsjava)
    b.l.google.com: 74.125.45.9     XBILL jnamed (dnsjava)
    c.l.google.com: 64.233.161.9    XBILL jnamed (dnsjava)
    d.l.google.com: 74.125.77.9     XBILL jnamed (dnsjava)
    e.l.google.com: 209.85.137.9    XBILL jnamed (dnsjava)
    f.l.google.com: 72.14.235.9     XBILL jnamed (dnsjava)
    g.l.google.com: 74.125.95.9     XBILL jnamed (dnsjava)
a.gtld-servers.net: 192.5.6.30      VeriSign ATLAS
b.gtld-servers.net: 192.33.14.30    VeriSign ATLAS
c.gtld-servers.net: 192.26.92.30    VeriSign ATLAS
d.gtld-servers.net: 192.31.80.30    VeriSign ATLAS
e.gtld-servers.net: 192.12.94.30    VeriSign ATLAS
f.gtld-servers.net: 192.35.51.30    VeriSign ATLAS
g.gtld-servers.net: 192.42.93.30    VeriSign ATLAS
h.gtld-servers.net: 192.54.112.30   VeriSign ATLAS
i.gtld-servers.net: 192.43.172.30   VeriSign ATLAS
j.gtld-servers.net: 192.48.79.30    VeriSign ATLAS
k.gtld-servers.net: 192.52.178.30   VeriSign ATLAS
l.gtld-servers.net: 192.41.162.30   VeriSign ATLAS
m.gtld-servers.net: 192.55.83.30    VeriSign ATLAS
d.root-servers.net: 128.8.10.90     ISC BIND 9.2.3rc1 -- 9.4.0a0 (9.4.2)

Results:
 14.3%: Answer from e.l.google.com (209.85.137.9)
            www.l.google.com.   300     IN      A       74.125.77.99
            www.l.google.com.   300     IN      A       74.125.77.147
            www.l.google.com.   300     IN      A       74.125.77.104

 14.3%: Answer from a.l.google.com (209.85.139.9)
            www.l.google.com.   300     IN      A       74.125.77.147
            www.l.google.com.   300     IN      A       74.125.77.104
            www.l.google.com.   300     IN      A       74.125.77.99

 14.3%: Answer from c.l.google.com (64.233.161.9)
            www.l.google.com.   300     IN      A       74.125.77.99
            www.l.google.com.   300     IN      A       74.125.77.104
            www.l.google.com.   300     IN      A       74.125.77.147

 14.3%: Answer from f.l.google.com (72.14.235.9)
            www.l.google.com.   300     IN      A       74.125.77.99
            www.l.google.com.   300     IN      A       74.125.77.147
            www.l.google.com.   300     IN      A       74.125.77.104

 14.3%: Answer from b.l.google.com (74.125.45.9)
            www.l.google.com.   300     IN      A       74.125.77.99
            www.l.google.com.   300     IN      A       74.125.77.147
            www.l.google.com.   300     IN      A       74.125.77.104

 14.3%: Answer from d.l.google.com (74.125.77.9)
            www.l.google.com.   300     IN      A       74.125.77.99
            www.l.google.com.   300     IN      A       74.125.77.104
            www.l.google.com.   300     IN      A       74.125.77.147

 14.3%: Answer from g.l.google.com (74.125.95.9)
            www.l.google.com.   300     IN      A       74.125.77.104
            www.l.google.com.   300     IN      A       74.125.77.147
            www.l.google.com.   300     IN      A       74.125.77.99

What's new?

dnstraverse has been released as an early beta, please check it out.

FAQ

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