Why EDNS0
Because DNSSEC
Why DNSSEC
Because cache poisoning
Why cache poisioning
Because remote, shared caches
Why remote, shared caches
Was the idea for remote, shared caches suggested in RFC 1035.RFC 1035 suggests that the resolver and the cache are part of the user's operating system.
"User queries will typically be operating system calls, and the resolver and its cache will be part of the host operating system."
The expectation is that the cache is local, not remote.
"Resolvers answer user queries with information they acquire via queries to foreign name servers and the local cache."
Mockpatris' DNS does not direct anyone to make use of remote, shared caches. It is entirely optional.
"Foreign nameservers" refers to authoritative servers, not third party caches.
DNS can work without using third party DNS service. I have been using it this way for 14 years. Remote, shared caches are optional. As is making remote DNS queries contemporaneous with HTTP requests, generally. For myself, the DNS data I need can be collected in bulk and stored.
IMO, a general historical principle that applies to computer software is that "features" can carry risks. In a non-DNS context, Apple's latest "Lockdown Mode" has now provided a popular contemporary illustration. Not every "feature" makes sense for every user in every situation. EDNS0 is an optional feature. Some computer owners may choose not to use it.
There are risks in DNS "extensions".^1 It is for users to decide whether they wish to undertake those risks by using them. Personally, I still adhere to original DNS packet sizes on the networks I control. The now relatively small 512 byte packets are one of the things I like most about DNS. I do not enable EDNS0. I do not send ECS.
NB. I am not against extensions, per se. RFC 1035 contemplated them. I remain keen to to learn what the "Z" bits will be eventually be used for. However using remote caches "safely" and facilitating someone else's DNS-based load balancing are not "features" that interest me.
1. EDNS0/DNSSEC becoming a DoS vector and user privacy leakage via ECS.
Notes
EDNS0 may have spawned further extensions with different impetuses. EDNS Client Subnet (ECS) being an obvious example. Here I refer to what appears to be the initial impetus for EDNS0.
ECS has been the source of problems, e.g, with user privacy.^2 Its impetus was to help CDNs, not users.^3 It may or may not also be used to further the commercially useful data collection (read: advertising-related services) of those who provide third party DNS service.
Remote, shared caches are sometimes referred to as "open resolvers". Problems have been associated with open resolvers.
2. User privacy against the third party and its commercial pertners, not against the operator of the authoritative nameserver.
3. Whether it is "mandatory" (cf. optional) for CDNs is debatable. Cloudflare, a large CDN and third party DNS provider, has said they do not send it. Unless the RFCs have changed, IETF recommends that it be disabled unless it provides a clear benefit to clients.