On 3/11/15, 13:31, "Doug Barton" <do...@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?
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
