On 10/07/2024 15:27, Philip Homburg wrote:
So the question becomes, do we want some limits in an RFC that everybody agrees on or do we want to keep the current informal system where limits are not fixed and people can get unlucky if they exceed limits they didn't know exist.
I do find the possible values in the document very strict at the moment and maybe further categorizing by QTYPE is even stricter. For example the KeyTrap vulnerability that is mentioned, is handled by the validator logic. I don't see a reason to restrict only to 3 DSes and hinder future operations and protocol development.
My first attempt would be to bring the number or RRs down to a "sensible number" than the current as-many-as-it-fits.
In contrast I do think that there should be a low limit on CNAME chains and NS records since they already allow for (resource) amplification factors that is not trivially tied to rogue users of resolvers.
In general having limits in an RFC that people can point to goes a long way than developers trying to argue with users; for example on what a sensible length of a CNAME chain is.
Best regards, -- Yorgos _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
