But we can state that they should be avoided when generating new DNSKEYs. BIND has been avoiding key tag collisions for 2 decades now when generating new keys. Multi-signers all have to have the current published DNSKEY RRset which includes *all* DNSKEYs as part of their publication process. Key generation just needs to avoid key tag collisions with this set of DNSKEYs. The broker can reject new duplicate key tags if they happen to occur at the combining stage forcing a new key generation. Unless multi-signers synchronise DNSKEY generation the later should be a rare event.
> On 16 Feb 2024, at 07:53, Bob Harold <rharo...@umich.edu> wrote: > > I don't think we can completely avoid tag collisions in a multi-signer > situation. They could detect and correct a collision, but due to the long > TTL's in many TLD's, that could take 24 hours. So I think resolvers should > allow for at least a few collisions and not fail on the first one. > > -- > Bob Harold > > > On Thu, Feb 15, 2024 at 3:39 PM Ralf Weber <d...@fl1ger.de> wrote: > Moin! > > On 15 Feb 2024, at 11:35, Paul Hoffman wrote: > > Resolvers can already have policies that don't allow them; that has been > > true for 20 years. There is nothing stopping any resolver from saying "I > > found a keytag collision so I'm not going to validate". Fortunately, we're > > seeing resolvers instead saying "I'll bound the amount of work I do when I > > see colliding keytags". > > I don’t know which resolver had key tag collision limits for 20 years, but am > happy to be educated. Anyway outlawing key tag collisions was and IMHO still > is on the table. It’s just that we didn’t want to break anything immediately. > > > > Compare that to "we're going to change a 20-year-old spec, wait for years > > for the changes to be implemented, and only then change the way validators > > work". The current situation is much more sustainable. > > We have had in recent history a lot of drafts that even were implemented > before they became RFC and had much larger failure ratios. I see no reason to > not immediately implement and RFC that says key tag collisions are not > allowed. > > So long > -Ralf > ——- > Ralf Weber > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
