[dns-operations] [Ext] Re: .RU zone failed ZSK rotation

Edward Lewis edward.lewis at icann.org
Thu Feb 8 16:55:14 UTC 2024

On 2/8/24, 10:40, "dns-operations on behalf of Viktor Dukhovni" <dns-operations-bounces at dns-oarc.net on behalf of ietf-dane at dukhovni.org> wrote:

The chances of a remotely possibly event happening is 100% once it happens. __

So long as a hash is shorter than the data it covers, there's a chance there will be a collision.  Just a general statement.

>    There is no issue with DS record confusion.

I think you are underestimating how an operational step may go wrong.  In a previous gig, the crew that had terminal access to the DNS machinery were on a different floor than the crew that was in charge with contacting IANA.  There was a time when all of the first crew members assumed that one of the others in their crew told someone in the other crew to change the DS record.  Oops.

What I can see happening is ... having an old KSK tagged 11211 in the DS. The new KSK is also tagged 11211 and is added to the DS set.  No issue there.  A few weeks later, when the old key is to be retired, someone says "pull 11211" because that's easier than reading out the hash value.

>  And even if two keys  produced the same DS record, that'd be fine too, just publish one DS
>    record in support of both!  The only theoretical risk is erroneously
>    publishing two identical RRs in the DS RRset, which is not allowed,
>    and validators may balk...  In practice, this won't happen.

The protocol doesn't care.  It’s those who are doing the key management may mix them up.  The convenience of 5 digit tags engenders laziness when it comes to automation - you'd have to script up something that checks hashes or fill keys, but you might not script up something that is only 5 digits long.

I've seen that in action...at a root cause analysis meeting...when the issue was caused by the tech typing something in hex as opposed to using a fancy GUI because the budget didn't include the GUI update this time around.

More information about the dns-operations mailing list