Re: Results of BIND RFC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

So first of all, yes Virginia, this was an April Fool's Day joke. To
both those for whom this post created a false sense of despair, and
(perhaps more importantly) to those for whom it created a false sense of
joy, my apologies. :)  And for the record, everything from here on is
"just the facts."

I have always said that I will remove BIND from the base when there is
clear community consensus to do so, and I stand by that. However the
discussion always seems to go along the lines that this thread did. A
vocal group who say, "YES!" and then a lot of people who want the
resolution tools (dig, host, nslookup) to stay, and the other end of the
bell-shaped curve with those who like having the whole thing in the
base. Toss in a few choruses of "The whole base should be more modular,"
(a viewpoint with which I have a great deal of sympathy btw) and the
soup is pretty well complete.

In regard to the tools issue, the problem is that you need a pretty good
majority of the code in order to build them. They require the libraries
to be built, and once you've done that, you might as well do the rest. :)

Total size of code in:
contrib/bind9:		14.0M
contrib/bind9/lib:	 7.6M
contrib/bind9/bin:	 2.5M
contrib/bind9/bin/dig:	 0.4M

The last is the directory that has the code for all 3 resolution tools,
FYI.

Therefore I think that the status quo of having it all in there, and
knobs to turn off the bits you don't want is a good one since it seems
to please the majority of our users. I will continue to maintain the
bind-tools port though, that's something that's been requested often,
and I think it's a good thing to have for those who want a different DNS
solution but still want access to those tools in a fairly painless
manner. And of course the ability to easily change/upgrade/manage what
version of BIND you use via the ports will continue to be a key
component of how we deal with this going forward.

Of course, the release synchronization problems I described in both the
original post and the AFD post are real, so stay tuned. :)

Answers to DNSSEC concerns below.

On 4/2/2010 3:52 AM, Robert Watson wrote:
> With an eye on the date of Doug's suggestive e-mail, I actually am concerned 
> that we maintain support for DNSSEC validation in the base system.  If this 
> can be accomplished by keeping DNS debugging tools and the lightweight 
> resolver in the base, then I'm fine with that world view.  However, if we 
> can't do DNSSEC record validation without installing the BIND package, then 
> that worries me.

Unfortunately this answer is more complicated than I'd like it to be. In
general, DNS resolution requires 4 components (and yes, this is pretty
well simplified, but I think the illustration serves to clarify my point):
1. An end-user application that makes a request
2. A stub resolver located on the local system
3. A resolving name server
4. An authoritative name server

At this time the DNSSEC protocol only clearly addresses the behavior of
4, and partially addresses the behavior of 3. There is no protocol
specification for 1 or 2. So in general if you want to be able to
validate DNSSEC signatures on the local system the only option available
to you is to run a local validating resolver. It doesn't have to be
BIND, unbound is also a good candidate, but you have to run something
locally to be sure that the response(s) you've received are valid.

Now that said, if you have a special purpose in mind to validate records
in a specific domain (or specific few domains) for which you are
prepared to individually manage trust anchors (the generic term of art
for DNSSEC keys) then you could do that using dig alone. However that
solution would not scale well, and I wouldn't recommend it for a
critical piece of the base or ports.

> As we go forward, DNSSEC is going to become increasingly important, and being 
> unable to bootstrap a system will be a problem, and it will become an 
> increasingly critical part of the security bootstrap process for networked 
> systems.

Since your description above is generic, I will generically agree with
you. :)  I think as time goes on and more intelligence about DNSSEC is
pushed to the edges I think it will be possible to have a validating
stub resolver, and on a trusted network reasonable to rely on an
external validating resolving name server. However there's an awful lot
of supposition there, and as I said above, the spec doesn't even exist
yet, never mind the code.

> While some DNSSEC folk consider it anathema ("DNS is not a directory 
> service!"), the ability to securely distribute keying material via an existing 
> network service has enourmous value: for example, early DNSSEC prototypes in 
> the late 1990's/early 2000's included SSH key distribution via cert records in 
> DNSSEC. 

The CERT record still exists, although not for ssh. See
http://tools.ietf.org/html/rfc4398. For ssh fingerprints there is the
SSHFP record, http://tools.ietf.org/html/rfc4255. And there are always
TXT records. :)

Now all THAT said, there is an element of DNSSEC that I am rather
strongly leaning toward putting in the ports, trust anchor
configuration. Currently you have essentially 2 choices for DNSSEC
validation, manually configure trust anchors, or use a DNS Lookaside
Validation (DLV) service, of which the most popular is ISC's. Both
options have their benefits and their drawbacks, which are outside the
scope of this post. OTOH, if things continue going according to plan the
root zone will be signed with real DNSSEC keys in July. That will make
it possible to do "regular" DNSSEC validation for those zones that are
signed from the root down by only configuring one trust anchor, the root
zone key. (If you need to validate something on a "secure island," i.e.,
one or more parent zones is not signed, you are back to the first 2
choices, but once again, out of scope.)

In the ideal world the root zone trust anchor would function like the
root.hints file does now. It is stable (not updated often) and failure
to update it in a timely manner would not be catastrophic.
Unfortunately, the first is not guaranteed, and the latter is the
opposite of the truth. There has already been on incident where an OS
distribution had shipped with trust anchors manually configured and when
they became outdated hilarity ensued. I would like to avoid that for our
users.

At this time my plan is to add hooks for "easy" incorporation of DNSSEC
validation into the base named.conf, with instructions for how to
install the port/package, the importance of keeping it up to date, etc.
Before I make any changes I'll be seeking input from experts in the
DNSSEC community and posting something a little more focused on -arch at
least. If the release engineer or security officer teams have
"something" in mind for FreeBSD that will require DNSSEC, we'll have to
coordinate efforts on this, but I don't imagine it will be too difficult
even with a bind-dnssec-config port.


hth,

Doug

- -- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)

iEYEAREDAAYFAku2QIgACgkQyIakK9Wy8PvMtQCeIu/32RGMIC/798V15aO/sjP3
788AoPf53oxsgutXPriuLOszcp2DBKc1
=hUnq
-----END PGP SIGNATURE-----