3 ms·
Running your own recursive resolver at home isn't the solution, because it reveals to eavesdroppers what DNS servers you're talking to and it reveals to DNS ope
by akvadrako 7y ago
Running your own recursive resolver at home isn't the solution, because it reveals to eavesdroppers what DNS servers you're talking to and it reveals to DNS operators what your IP is.
Maybe it's the best current compromise, but it would be better to have a shared and trusted remote recursive resolver which many people talk to.
- penagwin 7y agoA Shared and trusted resolver is just centralization again though... I don’t know enough about DNS, but I’m wondering if we could somehow fit BitTorrent into the mix for the home resolver?
- pdkl95 7y ago> it reveals to eavesdroppers what DNS servers you're talking to Yes, they (probably the ISP) can do traffic analysis - which is a significant risk - but they are prevented from learning the contents fo the query which puts a limit on what they can learn. Also, the same eavesdroppers can see the TCP connection to the HTTPS server that follows he DNS request. Also, I should have mentioned that while performing recursive resolution locally does provide some actual privacy protections, it is not perfect. Name resolution as a distributed database fundamentally requires leaking some information to the servers that have the information. As long as we resolve names with anything similar to existing DNS, the best we can do is try to limit the damage to privacy. In a perfect world, we would probably use something similar to TOR to perform name resolution. Lots of inputs that onion-route queries to the actual nameservers. > it reveals to DNS operators what your IP is. Revealing my IP to ns.example.com is redundant when I'm almost certainly following the DNS request with a connection to www.example.com; the authoritative server for a domain is controlled (directly or indirectly) by the same org that controls the domain's HTTPS/etc servers.
- blattimwind 7y agoFor almost every service this genuinely doesn't matter, becasue the authorative DNS server for a given domain will most likely be run by the same entity that runs the server you want to talk to. I wanna point out that a recursive resolver normally caches everything it is allowed to cache, so visting the same site a few times will not, in general, produce any extra DNS requests.
- akvadrako 7y agoNot really. You first have to talk to the root server, then .xxx, then the server for the domain.
- blattimwind 7y agoThe first steps of the chain are so generic there will be no useful data in there and the TTL is normally high (~a day). The last one or two steps are pretty directly connected to the service you are connecting to anyway. I don't really see an argument how caching RR is worse than centralized DNS at Google or Cloudflare or whomever, from a privacy perspective.
- akvadrako 7y agoThey do contain useful data. You are telling the root servers what tlds you are talking to and telling the tld operator what 2nd level domain you are talking to.
- pdkl95 7y agoYes, you hae to ask the tld's server for the NS record - the delegated domain's authoritative server. That's one request that usually has a much longer TTL. I've seen TTLs of multiple days or even weeks for NS records, compared to 5 minute TTLs (or less!) for A records. Every few days/weeks the tld gets a single query that tells them you were making some sort of request so an unknown domain anywhere in queried delegation. That query only includes the 2nd level domain and a request for that domain's nameserver(s). The rest of the recursive resolution and most future queries only need to involve the domain's nameserver. Yes, some information is leaked. This is unfortunate, but there is a huge difference between leaking that you occasionally visit something at exsmple.com and leaking your pattern of life (the exact subdomains you visit with ~minute-ish granularity).