:: Re: [DNG] Opennic
Página Inicial
Delete this message
Reply to this message
Autor: Gabe Stanton
Data:  
Para: dng
Assunto: Re: [DNG] Opennic
On Thu, 2021-03-11 at 13:14 +0000, Simon Hobson wrote:
> Gabe Stanton via Dng <dng@???> 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.


You're right that I didn't address the fact that queries to root
servers don't all go to one server. My understanding of that wasn't
firm when I was writing so I said 'upstream server'. But that would be
a small hurdle to overcome if everyone started protecting their dns
queries by running a caching resolver, because of the financial
incentive for doing so. The collusion it would take to exploit all
exploitable data would be minimal. I'm reminded of cloudflare and
mozilla working together to send dns queries to cloudflare, of course
it came with a media campaign about their using doh or dot to increase
privacy, all the while ignoring the fact that they're sending your dns
queries to cloudflare. That type of collusion would just move upstream
if you cut out the middlemen, the big dns providers of today.


> 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.


But if everyone in the world was using a caching resolver, would not
the value of that little information increase and be a target for
people with the same leanings as google, cisco, cloudflare etc? That
was my original point, the game changes significantly when the behavior
of the masses changes, and I think another good strategy to rely on is
the decentralized community model to help us fight data aggregaters,
and the implementation of that model with regards to dns in opennic is
pretty good.

> 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.


Those are great arguments for runnning a caching resolver, and of
course that's a good thing, but there are a couple cases I outlined
that potentially offer better privacy.
1. Running your own recursive server where your dns requests are pooled
with others.
2. Pointing at a single resolver that doesn't keep logs and where your
dns requests are pooled. Of course you never know what logs are being
kept for sure, but if operators are honest and don't keep logs, and if
they run doh, dot, or dnscrypt, then you have potentially better
privacy because of no logs and pooled requests.

> 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.


That would be a nice upstream privacy feature in any scenario.


Gabe