[dns-operations] friday version of dnscap

[Paul Vixie]

> > but apparently it's a lot harder to fix the rpm system on linux?
> 
> I've got a faint recollection that libbind is somehow unsupported
> upstream.  We (speaking with my non-RPM distro hat) don't want to ship
> anything that's considered dead by the original programmers.

bind8 is considered "in end-of-life" by the original programmers.  security
fixes only.  however, libbind is also shipped as part of bind9, and anyone
who makes a bind9 package, rpm, or port ought to be using "--enable-libbind"
so that this API will be present in the result.

> Perhaps I'm mixing things up, but I thought that liblwres was the way
> to go.

you're mixing things up.

> > i've already grown accustomed to -g.  i could #ifdef it maybe?  something
> > like "#ifndef NO_LIBBIND_AVAILABLE" ?
> 
> On my system, fp_nquery is part of libresolv, but the output format
> does not separate the different sections in the response, unlike dig.
> This makes it somewhat ambiguous and potentially less useful.

that's just a matter of _res.pfcode settings.  i'm using the defaults, so, on
my system i don't get the intersection headers either.  there's no ambiguity
since the rr's are always displayed in order and the section sizes are always
shown in the message header.  i prefer not to see this extra stuff outside of
an actual "dig" invocation... but i could add a command line argument that let
someone set pfcode, like dig does.  i wouldn't want to teach it to accept
symbolic arguments, you'd have to know the right 0xmumble to get the output
you wanted... but it's easy to do and i'll add that if it would be useful?

i wonder, though, since you say your libresolv has this.  can you really link
against -lresolv on that platform rather than -lbind and get a working binary?
(can anyone else who had trouble with ns_put32 say whether -lresolv fixes it?)