From owner-freebsd-arch@FreeBSD.ORG Sat Apr 3 07:08:43 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82EEF106566B; Sat, 3 Apr 2010 07:08:43 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 1FDDF8FC37; Sat, 3 Apr 2010 07:08:43 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so914054qwe.7 for ; Sat, 03 Apr 2010 00:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:x-mailer :subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc; bh=0/zXFXIwFGd/89S946cC8du1WDsVaxpLCMP44n3djfg=; b=FM3lONotc0ScvWRqCYXr4EyoS1H0pPQAPROzqTETEEjG6EwiLsnNH5ofuxVO3kp7KK upbCO9nclJbFuJnMwO5zZ/WIGU3/lDyKYfUMBxX0ZG5vukRQBFk2rj6dTCKyc1eD5qbg tryHC0IKk1x9CVyAry8DKi6JFem609M2Yk58o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:x-mailer:subject:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc; b=dtmRjvNZGfDJaZzX5Q6HzYT0Gi/ksOGch/eDTtkIAqBh4kVM7pAmfIkGvTYF6R0z3Y wK+aNqACMK5/LYh1tdN8TQYs3IroRIGnE/dKEuf0xlp8J/+RgG6Cdr9qFaJU/QLAHjTV 3hm5igiuXI+tSF1e75D8TjKJWk13mtS9qYaiI= Received: by 10.224.71.130 with SMTP id h2mr1025528qaj.246.1270276966765; Fri, 02 Apr 2010 23:42:46 -0700 (PDT) Received: from [192.168.0.7] ([72.14.241.40]) by mx.google.com with ESMTPS id 7sm901679qwf.44.2010.04.02.23.42.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 23:42:45 -0700 (PDT) From: Arseny Nasokin To: Doug Barton In-Reply-To: <4BB64088.8030003@FreeBSD.org> X-Mailer: iPhone Mail (7D11) References: <11351.1270198507@critter.freebsd.dk> <4BB64088.8030003@FreeBSD.org> Message-Id: <22D22D6D-8976-4EBD-9351-965A33544013@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7D11) Date: Sat, 3 Apr 2010 10:42:40 +0400 Cc: "freebsd-current@FreeBSD.org" , "freebsd-stable@FreeBSD.org" , "freebsd-arch@FreeBSD.org" Subject: Re: Results of BIND RFC X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 07:08:43 -0000 On 2 Apr 2010, at 23:07, Doug Barton 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > "