Results of BIND RFC

> Date: Fri, 2 Apr 2010 03:14:54 -0700
> From: Jeremy Chadwick <freebsd at jdc.parodius.com>
> Sender: owner-freebsd-stable at freebsd.org>> On Fri, Apr 02, 2010 at 09:24:51AM +0000, Poul-Henning Kamp wrote:
> > In message <20100402021715.669838e0.stas at FreeBSD.org>, Stanislav Sedov writes:
> > >On Fri, 02 Apr 2010 08:55:07 +0000
> > >"Poul-Henning Kamp" <phk at phk.freebsd.dk> mentioned:
> >
> > >Sorry, I think I was not clear enough.
> >
> > Sorry for misunderstanding.
> >
> > Yes, the case can certainly be made that DNS query tool belongs in the
> > base system.
>> I disagree (so what else is new?) It should be kept out of the base
> system. KISS:
>> Doug pulling BIND out of the base system / going ports-only = excellent.
>> Doug making a separate port for BIND-esque DNS query/maintenance tools =
> excellent.
>> Both of the above can be made into packages. Vendors who use FreeBSD
> can incorporate said package(s) into their build infrastructure. Folks
> who do not have Internet connections (yet for some reason want said DNS
> tools) can install the package(s) from CD/DVD/USB.
>> I want the bikeshed to be black. :-)
I have very mixed feelings on this. I agree with arguments I have seen
on both sides. I like being able to install FreeBSD and have a well
integrated system with all of the basic tools installed for basic
use. Things play together well.
I don't use many of the base system tools. I use cups, postfix,
customized ssh, and the ports version of BIND. I don't build the stuff I
don't need (src.conf) and I don't mind them being there.
On the other hand, for complex, heavy duty ports, keeping up to date
with externally maintains tools (contrib) is a pain and the base system
can get stuck with rather out of date tools as a result. (Remember
perl?) Unless there is very strong support for a contributed tools, it's
hopeless and, if the tool is evolving rapidly, as BIND is with DNSSEC,
it's still hopeless.
I have seen suggestions that some tools be kept in the base
system. nslookup (an evil tool that I think should be put out of its
misery) and dig (a good tool that not enough people understand how to
use) have been explicitly mentioned. The problem is that dig needs to
be in reasonable feature sync with the resolver or it can have
problems.
Finally, what about a stub resolver? This really MUST be in the base
system and, it should understand DNSSEC soon, which just complicates
things.
I prefer my bikeshed in green. Black is too goth and too hot for my
tastes.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751