[dns-operations] friday version of dnscap
paul at vix.com
Mon May 7 15:59:22 UTC 2007
> > 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
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
More information about the dns-operations