> I would be quite happy to see an informational document that > describes the reasons that a validator should limit the number of > keys and signatures it checks. Maybe even a BCP. > > But for reasons already argued to death, I would be utterly opposed > to a document that purported to mandate that number to be 1.
Recently I saw a discussion about a situation where a popular piece of DNS software cannot resolve names from a big company when the resolver has a cold cache (because resolving the names exceed the limits of that software). Users are caught in the middle and see DNS errors. This is an instance where DNSOP doesn't make any progress. We can't seem to have a discussion what sensible limits are and as result DNS software does it's own thing and DNS becomes less stable. Being utterly opposed to something doesn't mean it's not going to happen. It just mean that the IETF will not document it. So instead of creating a document where consenting parties can describe how to deal with DNSSEC signing without key tag collisions, we get nothing. But that will not stop validators from dropping support for key tag collisions. Key tag collisions are extremely rare. Many signers don't generate key tag collisions. But when a key tag collision does happen, users are left to deal with the fallout. So by blocking a document that requires a signer to avoid key tag collsions, we create one more thing that we don't talk about. But if the IETF doesn't talk about something, it doesn't mean that it doesn't happen in the real world. And the internet suffers. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
