> On 16 Feb 2024, at 15:19, Joe Abley <jab...@strandkip.nl> wrote: > > Resolvers are routinely managed in order to safeguard local resources, harden > themselves against attacks, etc. Not every query gets answered. Seems to me > that limiting the time a validating resolver spends churning its organs over > a particular RRSIG and causing it to fail to validate if the indigestion gets > too bad is just another example of sensible local policy.
True. IMO, that shouldn’t be the only indigestion-avoidance remedy. > While I think some centralised guidance about how to harden your resolver > against this attack (or any attack) is useful (and similarly guidance to > avoid duplicate key tags seems like a great idea for signers) I am struggling > to see any of this as a problem with the protocol or a fundamental weakness > in DNSSEC that needs a "long-term solution". Guidance to signers is lovely. [I’m sure bad actors will faithfully follow it.] Saying “avoid duplicate key tags” is all very well. However it assumes everyone plays nice and that’s unlikely to be true. Despite our best efforts, malice and incompetence on the Interenet haven’t gone away. So IMO something is also needed on the validator side. Guidance to validators on what to do when they come across duplicate key tags would be lovely. A hard fail is a reasonable way to handle these errors. YMMV. Don’t chase > N duplicate key tags could also be a reasonable approach. For some value of N. It’s just a question on how and when to return a hard error. I think what’s needed here is something similar to RFC9276’s advice on unwise choices of NSEC3PARAM settings. Broadly speaking, it’s the same sort of signer and validator problem: signer does some/thing bad which hurts validating resolvers. RFC9276 says return SERVFAIL for badly chosen NSEC3PARAM values. IMO a BCP needs to say the same thing about key tag collisions. > If a zone's signatures and keys are constructed and published in such a way > that it causes indigestion in validators, and as a consequence validators > fail to return responses for data in that zone, that's a self-inflicted > problem and the zone administrator surely has every incentive to fix the > problem. If the tools the zone administrator is using make the problem hard > to make, then so much the better. If validators can also make this problem hard to make, that’s so much the better too. That should give signers a strong incentive to fix their self-inflicted problem and stop hurting validating resolvers. > The DNS is filled with misconfigurations and junk. Things get fixed if they > need to when things break. Sometimes things break in painful ways and so we > make changes to mitigate or avoid the pain. How is this not just another day > on the Internet? Who said it wasn’t? :-) _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
