[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