[dns-operations] What would it take...

[Edward Lewis]

On 3/11/15, 13:31, "Doug Barton" <dougb at dougbarton.us> wrote:

>Neither solves the problem of authenticating the entity which is sending
>the DS update.

Note that my request was not for a means to update the parent but to
prevent the child from shooting themselves in the foot.  A much less
involved operation.

Perhaps I wasn't clear enough in my plea.

When it comes time to pull an aged KSK (aka SEP), it would be awesome if
the DS record set (where that is in use) references another published KSK.
 This isn't about making sure the needed DS record is there, it's about
making sure the old key isn't pulled when it's the only link left in the
chain.

Very rarely has retirement of a key been a critical need, and as far as I
know, never because of a compromise.  More often than not, guffaws would
have been avoided at no loss to operational stability by not taking the
step of removing the old key.  DNSSEC validation has been broken much more
often by operational errors than forged messages inserted into the stream.
 That can be fixed with better tooling.

Is there a reason the grand toolset cannot build in a breaking system to
prevent taking unwise steps?  Like refusing to remove a DNSKEY if the DS
set exists and does not reference any other key?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150311/49ad1c96/attachment.bin>