On Tue, 15 Jul 2025, Philip Homburg wrote:
This is not expensive. It is still cheap with the limit or 2 or 3
failures allowed. I mean, compare this to do doing DoH to all auth
servers, this crypto operation amounts to nothing.
It is exactly this limit that causes trouble for some validator software.
Can you explain in some detail what the complexity here is? I thought it
was an easy limit to add based on number of RRSIGs of a single RRset to
count, or perhaps for more complicated scenarios, counting the
validation failures per QNAME being resolved? And since there are other
things that could cause these, eg trees of NS/CNAME redirects to other
abusive failing RRSIGs, wouldn't this complexity need to be implemented
regardless of keytag collisions?
I don't know why you are comparing this to DoH to all auth servers. As
far as I know, no resolver does DoH all auth servers, if only because most
auth servers don't support DoH in the first place.
I was putting the CPU cost in perspective, as I thought that was the
main motivation these days for this whole keytag discussion. But I think
you are now referring to "causes trouble for some validator software"
being some code complexity that I don't fully understand?
Regardless, before writing RFCs that prohibit colliding key tags, it
would be good to fully understand the issues and remedies. I think
this is what Paul H was referring to when he talked about writing
down things.
Paul
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
