The dig program now needs some additional options for useful DNS server testing

November 27, 2017

I've been using the venerable dig program for a long time as my primary tool to diagnose odd name server behavior. Recently, I've discovered that I need to start using some additional options in order for it to make useful tests, where by 'useful tests' I mean that dig's results correspond to results I would get through a real DNS server such as Unbound.

(Generally my first test with DNS issues is just to query my local Unbound server, but if I want to figure out why that failed I need some tool that will let me find out specific details about what didn't work.)

For some time now I've known that some nameservers reject your queries if you ask for recursive lookups, so I try to use +norecurs. In exploring an issue today, I discovered that some nameservers also don't respond if you ask for some EDNS options, which it turns out that dig apparently now sets by default. Specifically they don't respond to DNS queries that include an EDNS COOKIE option, although they will respond to queries that are merely EDNS ones without the COOKIE option or any other options.

(Some experimentation with dig suggests that including any EDNS option causes these DNS servers to not respond. I tried both +nocookie +nsid and +nocookie +expire, and neither got a response.)

This means that for testing I now want to use 'dig +norecurs +nocookie', at least. It's possible that I want to go all the way to 'dig +norecurs +noedns', although that may be sufficiently different from what modern DNS servers send that I'll get failures when a real DNS server would succeed. I expect that I'm going to want to wrap all of this in a script, because otherwise I'll never remember to set all of the switches all of the time and I'll sometimes get mysterious failures.

(Some experimentation suggests that my Unbound setup sends EDNS0 queries with the 'DNSSEC Okay' bit set and no EDNS options, which would be 'dig +norecurs +nocookie +dnssec' if I'm understanding the dig manpage correctly. These options appear to produce DNS queries that the balky DNS server will respond to. With three options, I definitely want to wrap this in a script.)

What this suggests to me in general is that dig is not going to be the best tool for this sort of thing in the future. The Dig people clearly feel free to change its default behavior, and in ways that don't necessarily match what DNS servers do; future versions may include more such changes, causing more silent failures or behavior differences until I notice and carefully read the manpage to find what to turn off in this new version.

(A casual search turns up drill, which is another thing from NLNet Labs, the authors of Unbound and NSD. Like dig, it defaults to 'recursion allowed' queries, but that's probably going to be a common behavior. Drill does have an interesting -T option to do a full trace from the root nameservers on down, bypassing whatever your local DNS resolver may have cached. Unfortunately it doesn't have an option to report the IP address of the DNS server it gets each set of answers from; you have to go all the way to dumping the full queries with -V 5.)

Comments on this page:

By Perry Lorier at 2017-11-27 05:00:44:

DNS servers (or their firewalls) that drop packets with edns0 options, are technically violating the spec, they're supposed to ignore unknown options (or FORMERR if they don't understand edns0 at all). No comfort if you're actually need to query them tho. Hopefully by having people complain to them that dig doesn't work with their setup will get them to fix it, but that's likely to be a very long term fix rather than a short term one.

Recursive resolvers (such as Unbound) have the advantage of state, it can probe and see if the nameserver is likely to respond correctly to various options and decide if it's going to use them or not.

dig also has a trace function: dig +trace, which by default lists which server it got what reply from.

Another useful tool when debugging DNS (especially DNSSEC failures) is

From at 2017-11-27 10:00:18:

Hmm, I seem to remember drill -T being dropped. Or was it just -TD? Not sure.

Either way, dnstracer -s . $domain is much easier to read.

Written on 27 November 2017.
« One way of capturing debugging state information in a systemd-based system
Code stability in my one Django web application »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Nov 27 02:20:26 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.