I should have included this URL, pointing to the article (via Google Translate) saying the outage was rooted in a key tag collision...
https://www.rbc.ru/technology_and_media/07/02/2024/65c38fea9a794752176bd3a0 On 2/12/24, 08:50, "Edward Lewis" <edward.le...@icann.org> wrote: On 2/9/24, 20:37, "Wellington, Brian" <bwell...@akamai.com> wrote: >The behavior was never added into any standards document because it has nothing to do with the standard. True - but still it created a situation where operators could get snagged on something. >If an implementation doesn’t support multiple keys with the same key tag when validating, that would be noncompliant. That was not the case, though. Also true, this is the reason why "colliding" key tags have not resulted in operational events (until, allegedly - assuming the English translation of the report I saw is accurate - the RU outage). But validation (and signing for that matter) is not the entirety of where DNSSEC operational gaffs can happen - it can happen in the handling of the keys, namely, inserting or deleting the wrong key when two or more have the same key tag. The issue is - by relying only on the 5-digit, easy to read, key tag, an operator may wind up including/excluding the wrong key. With the set of keys in operation at any time being 3-5, the benefit of having a key tag (to select a subset) isn't great enough to justify this risk. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
