Gabe Stanton via Dng <dng@lists.dyne.org> wrote: > Of course using a local (or controlled by you) caching dns resolver > ENHANCES privacy. That's not even a question and doesn't represent a > real argument against the likelihood that, in the case of everyone > running their own caching resolver, that second level nameservers would > end up being a very good source of info to match dns requests to ip > addresses, to be exploited just as any other big dns provider is likely > to do.
I think you missed that if you use an external service for resolution, then **ALL** your queries go via one point - so there's a single point someone can slurp that information from. Obviously, the inclination to slurp that data and use it in ways we aren't happy with will vary between providers. Once you run your own local resolver then important things happen. The queries are now not concentrated at one point. Yes, you are correct that if you visit (e.g.) www.amazon.com, then your local resolver will go to the .com tld servers to find the NS records for amazon.com - but it will only do that once every 2 days and so the .com tld servers will only see ONE query every two days regardless of how often you visit anything in the amazon.com domain. The fact that the frequency information is vastly diluted significantly reduces the value of that information. Also, the .com tld servers will have ZERO visibility of you visiting www.amazon.ch (or in my case, amazon.co.uk) because no query for that will go near them. Similarly, once your resolver has the amazon.<something> ns records cached, nothing other than those nameservers will see whether you switch from (say) www.amazon.whatever to smile.amazon.whatever. So to gather even a fraction of what you can get from clients using one source for a resolver, someone would need to get information from multiple different sources - run by different entities. Once anyone tried that, then it's a lot harder for them to hide what they are doing - if some commercial entity were to go round asking various tld server operators for data, then it's highly likely that at least one of them would go public with this information. Because different domains use different servers, without getting data from many sources, no-one can correlate your DNS lookups to work out your path around the internet. They may be able to get snippets of it, but not the detail they'd get by seeing all your queries and being able to time correlate them. As already mentioned, what information you do leak is limited in volume. Once your resolver has cached information, it will not go upstream to request it again until it's TTL expires. So regardless of how frequently you go somewhere, upstream will only see a small volume of that. I've never looked into it, but I suspect that at least some packages might offer a config option to not send the full query string upstream. The default is that if you lookup (say) www.amazon.com and nothing is currently cached, then I know that BIND will send that query string to the root servers - which will replay with the NS records for the .com zone. BIND will then send the full name to the .com servers which will respond with the NS records for amazon.com domain. In principle (though there are some complications that would need to be worked around), it would be possible to only ask the root servers for the NS records for .com, and then only ask the .com servers for the NS records for amazon.com - whcih would significantly mask your activity. As I say, there are some complications, and I don't know if any package actually offers that ability. Simon _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
