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

Petr Špaček petr.spacek at nic.cz
Mon Nov 5 10:01:22 UTC 2018

On 02. 11. 18 18:37, bert hubert wrote:
> 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.
> 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'?

FYI there is a tool made specifically for regression testing: Deckard

It is actually suite consisting of mock network, mock DNS responders,
mock DNS clients, etc...

You might want to use just single component of it, the DNS client. It
reads query&response packet descriptions in "rpl" format stolen from
Unbound/testbound and checks if answer to particular query matches
criteria specified using MATCH keyword. Example:


It can also do raw (invalid) packets if necessary.

Using the client separately would require some code changes but it
should be simple to implement if needed. Just let me know!

Petr Špaček  @  CZ.NIC

More information about the dns-operations mailing list