[dns-operations] good async DNS library

[Matthew Pounsett]

On Thu, 25 Apr 2019 at 17:15, Klaus Darilion
<klaus.mailinglists at pernau.at> wrote:
>
> Hi all!
>
> For various monitoring scripts we use Perl's NET::DNS and
> Net::DNS::Async. Unfortunately they have various problems, ie
> Net::DNS::Async does not support DNSSEC and sending to other ports than
> 54, with Net::DNS's timeout/retries settings I never get the expected
> results ....

For *monitoring* code, I still haven't found anything that measures up
to Net::DNS.

For python, dnspython is an excellent library for writing an
application that needs answers out of the DNS, but falls short when it
comes to features you need for doing testing.    It really wants to be
either a stub resolver or a recursive resolver, so it takes a bunch of
boilerplate code to just send a single -RD query to a single server
and get back a reasonable response.  It also tends to do undesirable
things like throw exceptions for successful responses, because it
thinks answers like NXDOMAIN are errors.  And for testing zone
transfers, I found I had to write my own xfr method from scratch,
because the dnspython method for doing that either throws an exception
or returns a zone object.. nothing in between.. which means you can't
do things like examine the rcode of the response.

GetDNS is also excellent as a general application library, and is less
pathological for monitoring, but last time I looked there were still
some big holes in the python bindings related to things I wanted to do
when writing test code.  It's been a while though, so you might find
it worth looking at.

Neither library allows you to fiddle very deep in the message layers,
which makes them unsatisfactory for monitoring infrastructures load
balanced with ECMP.  To do that, properly, you need to be able to set
the IP TTL to 1, so that there's no chance your test queries (intended
for loopback) will leave the host and get a response from another
server.  Net::DNS is the only library I've encountered that allows
messing with the IP layer, because you have access to the underlying
Net::Cmd goo.