Weeeeeelll... We could say that signers MUST NOT create colliding key tags, and that verifiers and similar tooling must continue to work as they currently do.
That way, perhaps in (next decade + 1 year) we can discuss updating the verifier behavior. "The best time to plant a tree was 20 years ago. The second best time is now" and all that... W On Sun, Jul 13, 2025 at 10:12 PM, John R Levine <[email protected]> wrote: > On Mon, 14 Jul 2025, Mark Andrews wrote: > > John you keep stating that everything is working ok. We only have a small > percentage of all responses signed, multiple signers are already enforcing > the desired behaviour. There is also no requirement that every key signs > every RRset so there isn’t always another RRSIG to try to compare against. > There also isn’t a lot headroom in the system as the percentage of zones > being signed increases and with that more verifies per resolution. Having > trial and error in the protocol is a design error IMHO. We are trying to > fix that error. Yes there is an installed base but that is not a reason to > not fix the error. > > We're talking past each other. > > While I think it would be a fine idea for zone signers to avoid duplicate > keys, it should be obvious that no matter what we say, there will be > duplicate keys and resolvers have to defend against it, so nothing will get > simpler. > > As I said to Warren, as operational advice, sure. But writing MUST and > expecting things to change in the next decade is silly. > > R's, > John > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
