What’s the maximum size of a DNS response?
<p><pre><code>   Why EDNS0
   Because DNSSEC
   Why DNSSEC
   Because cache poisoning
   Why cache poisioning
   Because remote, shared caches
   Why remote, shared caches
</code></pre>
Was the idea for remote, shared caches suggested in RFC 1035.<p>RFC 1035 suggests that the resolver and the cache are part of the user&#x27;s operating system.<p>&quot;User queries will typically be operating system calls, and the resolver and its cache will be part of the host operating system.&quot;<p>The expectation is that the cache is local, not remote.<p>&quot;Resolvers answer user queries with information they acquire via queries to foreign name servers and the local cache.&quot;<p>Mockpatris&#x27; DNS does not direct anyone to make use of remote, shared caches.  It is entirely optional.<p>&quot;Foreign nameservers&quot; refers to authoritative servers, not third party caches.<p>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.<p>IMO, a general historical principle that applies to computer software is that &quot;features&quot; can carry risks.  In a non-DNS context, Apple&#x27;s latest &quot;Lockdown Mode&quot; has now provided a popular contemporary illustration.  Not every &quot;feature&quot; makes sense for every user in every situation.  EDNS0 is an optional feature.  Some computer owners may choose not to use it.<p>There are risks in DNS &quot;extensions&quot;.^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.<p>NB. I am not against extensions, per se.  RFC 1035 contemplated them.  I remain keen to to learn what the &quot;Z&quot; bits will be eventually be used for.  However using remote caches &quot;safely&quot; and facilitating someone else&#x27;s DNS-based load balancing are not &quot;features&quot; that interest me.<p>1.  EDNS0&#x2F;DNSSEC becoming a DoS vector and user privacy leakage via ECS.<p>Notes<p>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.<p>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.<p>Remote, shared caches are sometimes referred to as &quot;open resolvers&quot;.  Problems have been associated with open resolvers.<p>2.  User privacy against the third party and its commercial pertners, not against the operator of the authoritative nameserver.<p>3.  Whether it is &quot;mandatory&quot; (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.