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

[Mukund Sivaraman]

On Fri, Nov 02, 2018 at 12:37:00PM +0100, bert hubert wrote:
> 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'?

Somewhat in a similar vein, recently I was thinking about the roles of
"bin" programs of BIND that Loop inherited. Loop cannot install a
/usr/bin/dig program, and there'd be no point in shipping a dig tool
that exactly matched BIND's dig. To start with, I merged dnsperf as a
first-class program of Loop as it was a libdns user and useful with
performance testing, and also removed nslookup from Loop's tree.

dig's output doesn't change too much these days, but the metadata
(headers, OPT, etc.) isn't the greatest format to parse. The actual RRs
use the presentation format output functions, so they won't vary. dig
accepts a variety of arguments to customize the output and it's possible
to have it generate parseable output that won't vary (notwithstanding
the default IDN processing which agreeably is unexpected).

Stephen Morris (ISC) often pointed out during BIND development that
using dig to test named meant that the same library functions were being
used by both programs, and it was possible that some errors could go
undetected due to it because both programs behaved the same way and
couldn't detect problems.  An example of this is testing AXFR output, or
TSIG support, or COOKIE support, or even basic presentation format
output. There have been examples bugs in some of these that went
undetected.

In making a list, I was thinking that in today's age of getopt_long(),
dig's command-line syntax is a litte ugly and something to update in a
re-implementation.

ISC has written some diagnosis tools such as
<https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing> which
overlap the diagnosis area of dig.

A query tool can serve some purposes:

* General lookup
* Diagnosis of protocol/feature support
* Load generation and printing of graphs, etc.
* Tracing resolution and DNSSEC validation (along the lines of dnsviz), and related diagnosis
* Pretty-printing to assist a user (i.e., printing more than just the presentation format)
* Pretty-printing for parsing in formats such as XML,JSON

I feel that having separate query tool flavours by different parties is
useful and necessary, but a 3rd party tool is good to have too.

		Mukund