On 4 Apr 2013, at 21:19, Paul Hoffman <[email protected]> wrote:

>> I think nothing is needed here except perhaps a statement of the bleeding 
>> obvious: "if you miss too many key rollovers, Very Bad Things will happen so 
>> make sure you have a foolproof way of recovering from that".
> 
> We need that statement because it's *not* bleeding obvious.

Words fail me. If this really does need to be written down somewhere, then 
let's do it. I'll be happy to help write such a document. And add a section on 
what bears do in the woods. :-) Though I understand ICANN already has published 
something which covers this. Well OK, the key rollover bit...

> I cannot think of a single thing built into a 2007-era ISO of a Linux distro 
> that would have the property similar to "it will automatically give 
> mysterious results for DNS service". It might have lots of unsafe software 
> turned on, but none that will say "I'll serve you" but then it doesn't.

There's no need to discuss what things 2007 vintage Linux gets wrong or right. 
I doubt if any production software from that time did anything remotely useful 
with DNSSEC validation, but let that pass.

The issue should be making sure current and future platforms that come with 
DNSSEC validation enabled by default have got some sort of safety net to 
recover from missing a key rollover. I would hope/expect anyone shipping such 
stuff today or in the future would have the clue to do that without needing to 
be told. It seems improbable anyone would hard-wire any fundamental 
configuration information when it's already known that data MUST change from 
time to time. Though if someone does do that, fine: it's their look-out.
 
>> eg Have some out of band means of fetching and verifying the current version 
>> of the One True Trust Anchor.
> 
> And has the IETF supplied anything like that?

Not yet but ICANN has done this IIRC.

> If not, should ICANN wait for the first roll until we have?

No. A certain level of clue is needed to do DNSSEC validation and get it right. 
This *has* to include providing a reliable way to recover from losing the 
fundamental trust anchor. YMMV. At present the validating DNSSEC installed base 
is fairly small and doesn't yet have to rely on Standards-Track RFCs (or 
whatever) to tell them what to do. It would of course be nice to have these 
RFCs. However IMO their absence is not a showstopper for rolling the root key. 
DNSSEC validation is still something for consenting adults who (should) know 
what they are doing.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to