Date: Wed, 23 Jul 2008 10:46:43 +1000 From: Mark Andrews <Mark_Andrews@isc.org> To: Paul Schmehl <pschmehl_lists_nada@tx.rr.com> Cc: freebsd-stable@freebsd.org, Doug Barton <dougb@freebsd.org> Subject: Re: FreeBSD 7.1 and BIND exploit Message-ID: <200807230046.m6N0khvt008606@drugs.dv.isc.org> In-Reply-To: Your message of "Tue, 22 Jul 2008 12:52:15 EST." <34182EE347F910EA2A64DF03@utd65257.utdallas.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> --On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton <dougb@FreeBSD.org> > wrote: > > > Matthew Seaman wrote: > > > >> Are there any plans to enable DNSSEC capability in the resolver built > >> into FreeBSD? > > > > The server is already capable of it. I'm seriously considering enabling the > > define to make the CLI tools (dig/host/nslookup) capable as well (there is > > already an OPTION for this in ports). > > > > The problem is that _using_ DNSSEC requires configuration changes in > > named.conf, and more importantly, configuration of "trust anchors" (even fo > r > > the command line stuff) since the root is not signed. It's not hard to do > > that with the DLV system that ISC has in place, and I would be willing to > > create a conf file that shows how to do that for users to include if they > > choose to. I am not comfortable enabling it by default (not yet anyway), it > 's > > too big of a POLA issue. > > > > I just played around with it recently. It's not that easy to understand > initially *and* the trust anchors thing is a royal PITA. > > Once you implement DNSSEC you *must* generate keys every 30 days. So, I thin > k, > if you're going to enable it by default, there needs to be a script in period > ic > that will do all the magic to change keys every 30 days. Maybe put vars in > /etc/rc.conf to override the default key lengths and other portions of the > commands that could change per installation. WRONG. You need to re-sign the zone an expire period before the signatures expire. You need to generate new keys periodically but no where near every 30 days. KSKs annually. This is what the TLD's are doing and that is a very conservative exposure period. In practice it could be multiple years between key rollovers. The reason it is done this frequently is so humans don't forget what they need to do. ZSKs are generally weaker than KSKs but again they don't need to be done monthly. > If I were to implement it, I'd write a shell script to turn the keys over and > cron it because doing it manually every 30 days ain't gonna happen. Too many > ways to forget to do it. (I did the same for the root servers so that named. > ca > gets updated automagically every month.) > > But until root is signed, it's not worth it for those of us who don't have > dedicated staff doing dns only. There are solutions to the root not being signed. If all the TLD were signed the trust anchor work load would not be too great to managed by hand. For those that want a single trust anchor solution there is DLV. Sign your zone. Add it to a DLV. Ask you parent to sign their zone. If you don't sign you parent has no insentive to sign. This can be driven bottom up. That is one of the reasons why DLV was invented to provide incentive for the parent zones to sign. Mark > -- > Paul Schmehl > As if it wasn't already obvious, > my opinions are my own and not > those of my employer. > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200807230046.m6N0khvt008606>