On Tue, 2021-03-09 at 22:26 -0800, Rick Moen wrote:
> Quoting Gabe Stanton via Dng (dng@???):
>
> > In the absence of a "community of dns server operators and users",
> > is
> > the optimal option to have everyone run their own recursive server?
> > But
> > then the upstream servers still get the birds-eye view and will
> > very
> > likely abuse that information like the big companies do now.
>
> Please pardon my being blunt, but I don't think you have a realistic
> understanding of how typical patterns of authoritative nameservice
> data
> and caching work. I rather suspect you haven't stopped to think
> about
> that.

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'm open to any information you have that suggests sld nameservers can
never be exploited the way that google dns or cloudflare dns or any
other big dns provider have been exploited.

> Let's say I run a local recursive DNS nameserver on my local LAN for
> use
> by my and all other local hosts. For the sake of discussion, let us
> assume that it has what is misleadingly called an 'ICANN' root hints
> file.
>
> At service startup time, the instance starts getting and caching TLD,
> SLD, etc. authoritative data and caching it for the duration of
> TTLs.
> Right, now, kindly tell me where on the planet is the network node
> that
> provides a "birds-eye view" of query traffic processed by my
> recursive
> server? The root nameservers? Nope, not hardly. All they have is
> the
> hits where my nameserver followed the RD-bit-marked queries to find
> various TLD nameservers. TLD zones' nameservers? Nope, not
> hardly.
> They have only analogous logfile data when my nameserver first
> located
> and then cached information about SLD nameservers.

Right here. The SLD nameservers. Sure you're caching it, but you have
to get that data at some point. SLD nameservers are the ones that can
match the public IP of your resolver to the domains you request. This
seems an obvious target if everyone starts cutting out the middle man.
Regardless of whether that data is abused right now, if everyone
started getting dns data directly from root servers, they would be the
target.

> In fact, the very fact that I am operating a recursive nameserver
> means
> that I have greatly impoverished every possible spying vantage point.

If everyone ran their own caching resolver, the same parties exploiting
dns now would go to the second and third level nameservers to get the
data on who visits what site. It's too valuable to be left alone. Do
you think the people seeking that data would just give up on everyone's
data at that point? I don't think so. You're only safe now taking that
approach because you're a minority, and the data of the majority is
easy to get.

> The best of the bad choices in places to spy on my network's port-53
> activity is thus right on the far side of my network uplink, at my
> local
> bandwidth provider. And, even there, because of pervasive caching,
> even
> my uplink has extremely poor data about what the machines on my local
> LAN are looking up.
>
> Ideally, one has a contractual relationship with a reputable good
> provider who looks after customer interests in accordance to local
> business practices and law, such as (to cite the USA local legal
> concept) the implied covenant of good faith and fair
> dealing. However,
> that contract concept is (naturally) not a shield for privacy but
> rather
> a cudgel to wield in civil litigation, so the best thing to do is to
> limit what your immediate uplink can learn about your network
> traffic.
> Various crypto schemes help limit that data, but -- my point -- so
> does
> operating a local recursive nameserver, rather than outsourcing to
> -anyone- on the other side of the uplink.


You made a case for another possibly good alternative for dns providers
as oppposed to opennic, but I didn't hear any rebuttal to any of my
arguments in their favor.
Your suggestion of a contractual relationship with a dns provider has
it's good points, but also it's bad points. You still have to trust the
provider, and you have to trust their security model to also ensure
your privacy. Hacking is also a convenient excuse for unethical
companies.

So, here are the good points about opennic.

1. they are a community of server operators and users that encourages
participtation and understanding of the dns system
2. they put privacy right up front by displaying flags indicating if a
dns server operator keeps logs. (of course you have to trust the server
operator, but that is the case any time you don't run the server
yourself)
3. it allows you to advertise your dns server to a pool of other poeple
to potentially pool your dns queries together, this can enhance
privacy, that's a good thing. Of course there are complexities of
scale, but right now that doesn't seem to be a problem for opennic as
they're still a small commmunity.


Gabe