[dns-operations] friday version of dnscap
Michael Sinatra
michael at rancid.berkeley.edu
Mon May 7 17:12:01 UTC 2007
Paul Vixie wrote:
> 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?
In the past few days of playing around with DNSCAP, I find the -g option
quite useful, and I think it has a lot of potential for troubleshooting.
I'd like it to be at least an option for those of us willing to obtain
libbind.
In FreeBSD, the base 6-STABLE system (currently synchronized with 9.3.4)
has an /etc/make.conf option WITH_BIND_LIBS. Setting this option builds
libbind and appropriate headers into the base system during a buildworld
and allows dnscap to compile and run (although the build process does
complain about the lack of isc-config.sh).
I can think of two ways to fix it in /usr/ports: make it a build option
for the bind94 port or create a new port, bind94-libs (or
bind94-libbind). The new library/header-only port would probably make
things easier from a dependency perspective for dnscap--the dnscap port
could check for the presence of the library (either in the base system
or from the port) and then build the library/header-only port.
Since Doug Barton does most of the bind ports and base system
maintenance on FreeBSD, he may have some revisions to the above ideas.
But I think this may be the way to go with other packaging systems.
Gentoo Portage already has a bind-tools and a bind ebuild; the former
being for those who only want dig, nslookup, host, etc. and not named.
The only drawback of adding a bind-libs ebuild/port is that it means you
have to modify one more ebuild/port every time there's a new ISC version
of bind.
michael
More information about the dns-operations
mailing list