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.
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
somebody misses an update?
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?
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
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
