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
