.gov DNSSEC operational message

Wed Dec 29 03:24:54 UTC 2010

> Date: Tue, 28 Dec 2010 21:17:57 -0500 (EST)
> From: Jay Ashworth <jra at baylink.com>
> 
> ----- Original Message -----
> > From: "Florian Weimer" <fw at deneb.enyo.de>
> > > That sounds like a policy decision... and I'm not sure I think it sounds
> > > like a *good* policy decision, but since no reasons were provided, it's
> > > difficult to tell.
> > 
> > I don't know if it influenced the policy decision, but as it is
> > currently specified, the protocol ensures that configuring an
> > additional trust anchor never decreases availability when you've also
> > got the root trust anchor configured, it can only increase it. This
> > means that there is little reason to configure such a trust anchor,
> > especially in the present scenario.
> 
> Not being a DNSSEC maven, the idea that there was no out-of-band way to 
> confirm what the in-band method was telling you seemed bad to me; Matt's 
> explanation, OTOH, seems sensible.

There is no reason that you could not do OOB transfers of keys, but it
would be so cumbersome with the need to maintain keys for every TLD
(and, for that matter, every zone under them) and deal with key rolls at
random intervals and confirm that the new keys you were getting were, in
fact legitimate would be more than overwhelming. It just does not scale.

DNSSEC(bis) was designed to deal with this by being able to
cryptographically confirm that all data is valid and all keys are
legitimate as long as you have the root key. I am not about to go into
how all of this is accomplished, but it does.

Some parts of it are still a bit fragile, but the basic DNSSEC spec is
now very solid and the implementations of it are getting to pretty
good. (Can hardly wait for BIND 10!)

I think the DNSSEC spec is a very good basket and I hope that the
current implementations are, as well. At least I am very confident
that they will fail-safe.
-- 
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