[dns-operations] dig, drill, delve, kdig, sdig, tdig mission statements

[bert hubert]

Hi everyone,

Now that we are discussing one specific, if important, DNS query tool here
on this general DNS list, let me butt in a bit with some unsolicited
product management advice.

(btw, this is not a rant on dig, I use it all the time, but it is a call to
think about what we want from our tooling)

Some things a DNS query tool could strive to be:

 * A query generator that prints responses as they are received. Suitable
   for (regression) testing or automated processing. No surprises, it is not
   a "helpful" tool.

 * A tool to get answers: will retransmit, fall back to TCP, also try IPv6,
   even if you didn't ask for it, turn on or off EDNS and DNSSEC as needed
   or as policy or dreams & aspirations dictate

 * A tool that is as helpful as possible for human users: print out key tags
   as derived from records, chase signatures, emit remaining lifetime of
   signatures

I'm sure there are other usecases that could be covered. Like nslookup.

Way back when in the mists of time, PowerDNS used 'dig' for its regression
testing but it broke all the time because dig found ways of printing things
better. This led us to write 'sdig' or simple dig with the only goal of
creating output that would not vary from month to month. Initially 'sdig'
was a script that called 'dig' to make its output canonic. 

It seems to me that with the wealth of development power we now have
available for DNS it would be good if we not all made our own dig with big
dreams and aspirations, but that we pick some roles. 

One thing I miss is a tool that explicitly picks role '1' as its goal in
life. It might even have JSON output, but it clearly does only what you ask
it to. So it does not sneakily try IPv6 when you did not ask for it. Nor
does it accidentally do IDN processing because a library was found that
could do it. Or suddenly add EDNS cookies because we think they are cool
etc.

Now it may be that 'kdig' or 'drill' or 'delve' has a mode where it already
does what I hope, in which case we might as well pick that one as the tool
to use for automation & testing. 'dig' could then be free to do IDN or emoji
or whatever if there is a need.

My question to the current query tool writers, how do you feel about where
your tool fits? Or what its role in life is in terms of (automated) protocol
agility, pretty printing, turning on features? Do you agree it would be good
to have one tool or one mode that focuses on role '1'?

Thanks!

	Bert