> As John is (perhaps) eluding to. I would also rather see an RFC > describing how a resolver should work nowadays. Documenting all > the foot guns and ways to avoid them. Something along the lines of > RFC 5452.
It is not clear to me how this would help except for some areas where the current RFCs poorly define what needs to be done. For example, recursors should limit the length of a CNAME chain. That should come as no surprise and it not really worth writing down in a new RFC. What is interesting is what the limit should be. Length 5, length 20, length 100? It's the same with key tags. It's not hard to figure out that a resolver should limit the amount of work. But what should the limit be? Looking at RFC 5452 and https://nlnetlabs.nl/projects/unbound/security-advisories/ it seems to me that attack mitigations can be grouped into two categories: 1) one-sided mitigations by a resolver that require no standard action 2) mitigations where coordination with operators of authoritative servers is required. There are many actions that defend against off-path attacks that fall in the first category. It would be nice to write them down, but who is going to do the work? Asking for such an RFC seems a bit like asking for a pony. There are two other aspects to consider. The first is that diversity among resolvers is good. Writing down exact mitigation techniques may reduce diversity. It may also prove to be a moving target. We have a structural mechanism in place that defends against off-path attacks: COOKIES. However, that has seen relatively low adaoption. Probably not something an additional RFC would fix. The second category is where recursors could use additional standards. Right now there are domains operated by a popular cloud provider that result in SERVFAIL with a popular DNS resolver with a cold cache and default settings. This is a real problem. Certainly for operators of recursive resolvers. They can chose between living with failures or increasing limits and risk more server DoS attacks. And for this category, discussions in this wg go nowhere with very few exceptions. The current thread is a clear example. As far as I can tell, in all what has been said, we have not seen a single operator of a DNSSEC signer (or implementor signer that is not a hobby signer) explain what the issues are to avoid key tag collisions, how much work it would be to change the signer, etc. Instead there is a downplaying of the problem. It would not help recursors. Which is weird when the request to avoid key tags collisions comes exactly from implementors or validating recursors. There are also benefits for signers to avoid key tag collisions. But signers can just avoid them on their own, no need for coordination. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
