Results of BIND RFC

Sat Apr 3 06:42:48 UTC 2010

On 2 Apr 2010, at 23:07, Doug Barton <dougb at FreeBSD.org> wrote:

> -----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-----
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org 
> "