[dns-operations] friday version of dnscap

[Paul Vixie]

> > what's your advice, then?  if i remove the "-g" feature and recode ns_put32
> > to be a macro call, then the libbind dependency will go away.  or, i could
> > put a copy of libbind into the dnscap tarball.
> 
> Where does dig get its output routines from?  It doesn't appear to
> link against libbind.  Has it got its own copy?

dig in bind9 has its own.  dig in bind8 uses libbind's fp_nquery().

> From a distribution maintainer's point of view, duplicating the code
> is a bad idea, especially since it's exposed to network traffic.  If a
> problem comes up, we want to issue a single update (well, for each
> supported branch).  Hunting down all copies of zlib was quite painful.

so, i think the reason i didn't notice that libbind is hard to get from
/usr/ports is that i don't use /usr/ports for bind9, i do the old dance:

	   (untar or cvs update)
	   ./configure ... --enable-libbind
	   make
	   make install
	   make clean

i think that if /usr/ports' version of bind9 does not build with
--enable-libbind then it should be revised, and when dnscat goes into
/usr/ports, the port for dnscap should depend on the revised bind9 port.

but apparently it's a lot harder to fix the rpm system on linux?

i've already grown accustomed to -g.  i could #ifdef it maybe?  something
like "#ifndef NO_LIBBIND_AVAILABLE" ?

how much should the lack of bind9 installation automation limit dnscat's
feature level?