In message <4ae266e3-e9ed-48d4-beee-41fb5a547...@virtualized.org>, David Conrad writes: > Ed, > > On Sep 8, 2009, at 12:12 PM, Edward Lewis wrote: > >> So, in order to roll a key, you have to ensure DLV registries have > >> replaced the keys, even when the DLV registries obtain the > >> originals indirectly? > >> Seems a bit broken to me. > > That's not broken, that's reality. > > I disagree. Requiring every zone administrator that has signed their > zone to update folks they may not have the slightest idea about before > being able to roll a key is fundamentally broken.
Normal operations with a signed parent doesn't require you to inform everyone. "DS TTL + Parent Refresh" after the visible parents have changed should be enough. The child's key manager can work this out from data published in the DNS. You just don't start the timer ticking until you see the parent react. The root should be using RFC 5011, which provides timing guidance, for all clients. RFC 5011 support will be built into the validators if it is not already there. > I do not know the circumstances that resulted in ISC's DLV getting out > of sync with the ITAR, however since ISC harvests ITAR data, I believe > the responsibility is on ISC to keep the data up to date. In theory, > we (ICANN) could broadcast changes to re-distributors of the ITAR as > the occur, but what protocol should we use and what happens if > > > My guidance is that we (operators) have to take reasonable steps to > > prevent relying parties from suffering consequences. > > Lovely idea. When Bill's Bait and DLV Registry gets the ITAR data > from a third party and you, as a signed TLD zone operator, have no > relationship with either the third party or Bill's B&DLVR, how do you > propose doing this? Now extend that down into the rest of the tree. > How are zone administrators going to propagate these changes? > > > When an emergency supercession is needed, a nasty choice may need to > > be made. > > Well, yes. But somewhat irrelevant. > > > Instead of complaining more about this, we need to figure out what > > why this is a weakness in DNSSEC operations and come up with a > > solution. > > Correct me if I'm wrong, but the architecture of DNSSEC assumed > (rightly or wrongly) a single hierarchical deployment model. ISC has > now thrown a non-hierarchical component to deployment, DLV, into the > mix. It isn't particularly surprising that this has an impact on > DNSSEC operations. Perhaps the solution is to not use DLV? The ITAR is also not part of the standard proceedures .... The root should have been signed years ago .... There's lots of places to point fingers. > > It's too late for weeping and wailing... > > As current US politics empirically prove, it is NEVER too late for > weeping and wailing. > > Regards, > -drc > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
