Date: Tue, 28 Dec 2010 21:17:57 -0500 (EST) From: Jay Ashworth <jra@baylink.com>
----- Original Message -----
From: "Florian Weimer" <fw@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@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751