NS records don't change very often. They can see that I looked up the delegation data about "example.com" once every $CACHE_TTL (~months). They do not get repeated queries at the beginning of every session I have with a website.
A lot of security is about being in the habit of minimizing attack surface. The only thing a TLD (or ISP) nameserver needs to know if I want to use the Doomain Name System is "pdkl95 asked for example.com's nameserver once last month" Instead of giving Google (or whomever) an update e.g.:
;; ANSWER SECTION:
news.ycombinator.com. 300 IN A 209.216.230.240
...every 5 minutes. This is not trying to stop someone discovering that I have ever been a domain; I'm limiting the ability to model my pattern of life[1].Separating the requests allows for different cache policies. If you simply delegate the entire recursive resolution work to Google (or whomever), they get to record that you needed "www.example.com" every TTL (5min?). You don't even need to see the domain's NS records in that case, so there isn't an opportunity to choose a cache policy.
"No", because the system depends on running a recursive resolver locally to separate queries onto different nameservers.
Aggressive caching of NS records for TLDs doesn't do anything to prevent a single upstream nameserver from leaning your pattern of life from the frequent DNS lookups for A records that are not cached longer than normal.
Setting $CACHE_TTL to "months" on everything, and doing nothing else.
> I'm still sending frequent short-TTL (normal caching) DNS lookups for most hosts that would betray my pattern-of-life in aggregate.
Your system does that. This theoretical mildly-inferior system would not have frequent DNS lookups for any record type.
That will break a lot.
DNS isn't static; IPs regularly change as servers move, CDNs are introduced/changed. Long-term caching only works on NS records because changing DNS delegations is relatively rare. NS record caching does cause problems, but they are infrequent. Caching the addresses of the actual servers will break some things within days, and most of the internet the next time each server is updated/moved/etc.
You presupposing that it is necessary to send all DNS traffic to one entity. I run a local recursive nameserver (unbound) instead of sending all of my queries to a different nameserver.
Combined with aggressive caching, any particular DNS server (from .ROOT-SERVERS.NET down to the specific authoritative nameservers for a specific domain) is only able to view a tiny subset of my browsing behavior. Most of the time the query to the final authoritative nameserver is to be followed quickly by a TCP SYN packet that reveals roughly the same information.
Yes, running the full recursive resolver locally can be very slightly* slower than asking e.g. the local ISP's server that probably has the query cached. Fortunately, local caching limits this (very minor) problem to only the first request for a domain.