4 ms·
The TLDs are only queried for the NS records of the second-level domain, and the A (or AAAA) records of the those NS names. This is cached, often for longer tha
by pdkl95 8y ago
The TLDs are only queried for the NS records of the second-level domain, and the A (or AAAA) records of the those NS names. This is cached, often for longer than the record's specified TTL. The rest of the traffic is with the 0delegated nameserver,
- Dylan16807 8y agoThe second level domain under com is the important part 95% of the time.
- pdkl95 8y ago> This is cached, often for longer than the record's specified TTL. 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]. [1] https://en.wikipedia.org/wiki/Pattern-of-life_analysis https://en.wikipedia.org/wiki/Pattern-of-life_analysis
- Dylan16807 8y agoSo what I get out of this is that your system protects your privacy because it uses a custom TTL, and not really because you run a recursive resolver. It helps reduce errors, but you could get almost the same effect with a pure cache.
- pdkl95 8y agoNo, I'm still requesting the A/AAAA records at the normal TTL rate. This doesn't expose useful information, because those queries are sent directly to the domain's nameserver. The domain learns that data point anyway from the TCP SYN packet I'm probably sending immediately after I learn the A/AAAA record. 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.
- Dylan16807 8y agoI'm not sure why you lead with "No" because you didn't disagree with anything I said.
- pdkl95 8y ago> and not really because you run a recursive resolver. "No", because the system depends on running a recursive resolver locally to separate queries onto different nameservers.
- Dylan16807 8y agoIt depends on doing so to work better. But a similar not-quite-as-good system could do without that feature. It's not integral.
- pdkl95 8y agoWhat is this system that prevents pattern-of-life analysis while still sending all DNS queries to one nameserver? I'm still sending frequent short-TTL (normal caching) DNS lookups for most hosts that would betray my pattern-of-life in aggregate. The vast majority of the security is from sending those requests to the domain-specific nameservers instead of aggregating it all through a single upstream nameserver. 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.