
The Big DNS Privacy Debate at FOSDEM - detaro
https://blog.powerdns.com/2019/02/07/the-big-dns-privacy-debate-at-fosdem/
======
rnhmjoj
DNSCrypt has been around for a decade and works really well. Did everyone
forget about it?

It's objectively better than running DNS queries over HTTPS: still UDP based,
no need to trust a CA but only the DNS server public key, can be cached
locally or network-wise, perfect forward secrecy.

There are clients[1] for Windows, Android, BSD, Linux, macOS and lots of
providers[2]. It's really a shame it hasn't been made into a standard.

[1]: [https://github.com/jedisct1/dnscrypt-
proxy](https://github.com/jedisct1/dnscrypt-proxy)

[2]: [https://dnscrypt.info/public-servers](https://dnscrypt.info/public-
servers)

~~~
detaro
Some would argue "still UDP based" is objectively worse, since it can be
blocked.

I don't think DNSCrypt is better for caching, doesn't it just protect one
"leg" from a client (which can be a local cache) to a resolver (which also can
be a cache) just like DoH? Similarly for pinning keys (although I think
DNSCrypt made exchanging keys easier).

~~~
michaelt
In the internet of the future, DNS will move from UDP to TCP because it's
better, and HTTP/3 will move from TCP to UDP because it's better.

Web 4.0 will consolidate these improvements, producing DNS over HTTP over QUIC
over UDP.

~~~
detaro
Probably, yes. The key from that perspective is to have it in the same format
as the content traffic.

------
davb
On a related note, I recently found out that Chrome uses its own DNS resolver,
ostensibly to improve performance. On some Android devices, this ignores the
nameserver precedence set against network connections on the device. The
result is that it will often send DNS queries to the nameserver attached to
the physical network adapter and not the one attached to the VPN interface. It
breaks queries for intranet servers and it breaks loopback-VPN-based ad
blockers (a common workaround to manage your own hosts file on Android without
rooting your device and breaking many root-hostile apps). There's a flag
(async dns) in Android Chrome to disable the internal resolver and use the
system resolver instead, but this flag is no longer present on desktop (where
a startup parameter must be used).

My point is that, as alluded to in the article, changing how DNS works can
have serious side effects. The fact that, as unintentional as it may have
been, one of the world's biggest ad networks broke ad-blocking on a number of
devices by changing how they handle DNS queries is worrying. I'm concerned
that as DoH (or DoC as the article refers to it) proliferates, it'll be used
less to circumvent censorship and more to take away control from end users and
enterprise network administrators. Every app, the browser included, could
creep towards using their own internal DNS query handler, using nameservers
they trust to delivery their analytics and advertising queries.

Additionally, giving DoH/DoC choice through the browser suggests that the
browser might return different results from other software on the device. This
sounds disastrous.

And I suspect that the oppressive regimes that always come up in discussions
about DoH would simply block the IPs of those cloud resolvers, which seem to
rely on having a well-known IP or domain name.

------
wtmt
In India, several websites get blocked by different ISPs based on some highly
unsubstantiated petitions to some court that doesn’t understand what the right
move is and just sends the list of domains to be blocked to some ISPs, who
gladly comply without any checks or questions. Users see a message saying that
the site has been blocked because of some order from the Department of
Telecommunications.

There is no grievance management process, no way for legitimate sites to get a
quick reprieve when they get blocked either due to operator error or issues
with the petitions not being vetted and investigated for malicious intent (a
competitor could easily knock you off in some states or regions and you
wouldn’t even know).

While there are activists working on policies and campaigning for better laws,
we really need stronger technological solutions against these (usually
ridiculous) blocks that insult “due process” and harm people.

India is also very quick to rap on large multinational companies whenever they
seem to provide something that those in power (or their supporters) frown
upon. So centralized providers like Google DNS or Cloudflare DNS would have
some tough times with the governments, since both have physical presence in
the country with their servers/data centers.

 _A decentralized and yet secure /private DNS may be more resilient than these
DoC (DNS over Cloud) providers if we have to deal with government censorship
effectively._

~~~
petronio
One of the options I've thought of (and I'm sure many others have as well) is
to have all zones distributed in a P2P manner via ICANN. To not put too much
burden on ICANN and keep things decentralized, have ICANN at the root of the
DNS PKI and have all zones signed by the responsible party.

This would solve a few of the big problems we have:

* All sorts of MITM and evil resolver attacks would be prevented.

* Since DNS queries are local, there would no longer be a privacy concern with resolving a name.

* Even if the P2P network mechanism were to be blocked, since every host connected keeps a full record (though not necessarily with history) it can still be distributed via sneakernet.

* DNS updates are as fast as the network is, no longer depending on turtles caching all the way down.

* DNS amplification? That's gone, as resolvers no longer need to query external sources.

As many will quickly notice, we would likely still need remote resolvers for
battery constrained devices as this would keep the network interfaces busy.

The one big political issue that would put a stop to this is that this would
cause all zones to be world readable. Many people treat zones as something
private and to them exposing the zone file is the same as exposing their
network. My view is that if it has a publically routable IP then it is already
exposed, but not everyone shares my view.

~~~
wtmt
> The one big political issue that would put a stop to this is that this would
> cause all zones to be world readable. Many people treat zones as something
> private and to them exposing the zone file is the same as exposing their
> network. My view is that if it has a publically routable IP then it is
> already exposed, but not everyone shares my view.

I really don’t get this view either. There may be more cases supporting zone
files being world readable than not (I can’t think of any cases for the latter
except for censorship and control).

------
mook
I'm disappointed that the fact it will break things only got a mention, and
yet the browsers are pushing for using DoH via cloud providers.

My NAS isn't externally resolvable; after all, it's not externally reachable
either. And now I have to refer to it by IP address because the Chromecast
insists on using Google's DNS servers.

People seem to be unwilling to address known issues before switching defaults
:(

------
Tepix
I attended the DoH talk by Daniel Stenberg at FOSDEM. When talking about
alternatives he didn't mention Dan Bernstein's DNScurve (
[https://dnscurve.org/](https://dnscurve.org/) ).

It has low adoption and is not on a standards track (as far as I know) but I
think it's the best proposal for DNS privacy and security so far.

~~~
tptacek
DNSCurve is over; DoTLS and DoH provide essentially the same value in
essentially the same deployment mode, but with mainstream support.

~~~
dsl
DoH failed to keep the important part of DNS, which was statelessness.

Running a stock or DNSCrypt resolver for 10k QPS requires a small to medium
sized box that is within the technical realm of most people to operate. Adding
stateful connection tracking now creates an operational burden that most IT
folks would say "screw it, send it to the cloud."

This centralizes the DNS in to the hands of a half dozen organizations that
can operate at that scale, and they also happen to be the ones driving the
policy forward.

~~~
tptacek
I don't honestly know whether, if I had the choice, I'd take DoHT or DNSCurve.
But that's not really my point. No matter how much I might like DNSCurve, it's
not going to happen at this point: DoH will be the mainstream secure resolver
going forward, because it's firewall-friendly and will have mainstream browser
support. With DoH widely deployed, the argument for DNSCurve is cut back
drastically.

It's a very positive thing, to my mind; it's equally fatal, I think, to the
arguments (such as they were) for DNSSEC --- which not only centralized DNS
but also TLS security, and handed them to world governments.

I also think:

1\. No matter what the protocol, centralization of "off-net" DNS services
inevitable, for reasons having little to do with performance.

2\. People with concerns about Google and Cloud Flare (it me!) can easily run
their own off-net resolvers, and people will inevitably start privacy-
preserving DoH resolvers that are open to the public.

3\. Over time, the performance implications of TLS for DNS lookups will become
less and less a factor.

------
scame
As they say, if it's free, then you're the product. I (as a European) have
much more confidence in my ISP to guarantee my privacy than in a company which
mostly makes money out of advertisement.

~~~
criddell
Your ISP doesn't sell user data?

I'm in the US and feel the exact opposite. I trust Google and CloudFlare far
more than AT&T or Verizon.

~~~
zzzcpan
With these proposals you still have to trust your ISP in addition to trusting
Google and Cloudflare. You can avoid trusting all three, your ISP, Google,
Cloudflare by trusting instead a single VPN provider of your choice (or a
hosting provider where you can run your own VPN server).

~~~
dagenix
A VPN provider has a much better source of data to mine than just about anyone
else. On top of that, figuring out which ones deserve to be trusted is near
impossible.

~~~
zzzcpan
It doesn't have more data to mine than your ISP. It's not harder to figure out
who to trust than with any other company. But unlike with any other company
there is so much competition across the globe, that you can strategically pick
specific jurisdictions and providers known to fight for your interests.

~~~
dagenix
> It doesn't have more data to mine than your ISP.

Let's say you are behind a NAT and then you sign on to your VPN. You've
helpfully disambiguated yourself from everyone else behind the NAT. Let's say
you head out to a coffee shop and sign in to you VPN. Your ISP can't monitor
you, but your VPN provider could.

> It's not harder to figure out who to trust than with any other company.

Have you ever looked for VPN reviews? There are many sites that seem to do
nothing except review VPNs. One example: [https://www.trusted-
vpn.com/](https://www.trusted-vpn.com/). And its "reviews" are basically all
advertising copy. So, maybe you check out a bigger name site:
[https://www.pcmag.com/article2/0,2817,2403388,00.asp](https://www.pcmag.com/article2/0,2817,2403388,00.asp).
And ... it's more advertising copy. The third sentence in the article:
"Everyone ought to be using a virtual private network, or VPN, as often as
possible" \- which again, sounds more like an article trying to push VPN sales
(with helpful affiliate links!) than to provide actual reviews.

And the thing is, let's say you do find some site that is both trustworthy and
doesn't seem to be trying to push you to click an affiliate link. What can a
reviewer actually tell you about how you should trust the VPN company?
Basically all they can do is read the privacy policy and rate that - which is
absolutely no better than believing Google or Cloudflare when they say they
won't track you with their DNS servers.

So, by all means use a VPN - but don't trust it.

------
js2
I'm disappointed by this situation where we have to shove encryption in at the
application layer one application at a time because we couldn't get our act
together with ipsec. I understand how it's come to be, but from an engineering
perspective, it's absurd to move dns into https.

Oh well, this is the nature of evolution, like the recurrent laryngeal nerve
in a giraff.

~~~
mbrumlow
I am not sure you need to do it at the application layer. All you need is a
local caching resolver that your apps query over local host using standard
methods. Then the local service can do all the fancy you want.

Today, I have this setup for work. I don't like them spying on me while at
work. So I have setup a local resolver that forwards some request to the
companies resolver, and others over a secure line to a set of public resolver.
I did not need to change any software.

~~~
js2
My use of "application" is ambiguous. I was referring to the fact that DoH
moves DNS from on top of udp/tcp to on top of https, itself on top of tcp,
primarily to benefit from the 's' in https.

I actually also run a DoH proxy on my home router and point dnsmasq (also on
the router) at it, so all my home network DNS goes out over https.

------
belorn
Through the two major DNS privacy talks on FOSDEM I felt a bit at odd that so
much effort is being put into the idea that giving all information to google
will give best privacy. In basic security theory we talk about assets that
need to be defended, and attackers we need to defend against. Why give
everything to a company which revenue is based on breaking privacy? It sound
completely incompatible with the idea of privacy.

Running your own resolver will give the authoritative servers the ip address
of the request, but does this leak any assets to any potential attacker? The
owner behind the authoritative servers already get the web logs so what
additional information is being leaked. It seems to me that in order to get
higher level of privacy you would need to run a VPN or Tor, in which case the
DNS traffic can just go through the same path.

~~~
_null_
>Running your own resolver will give the authoritative servers the ip address
of the request, but does this leak any assets to any potential attacker? The
owner behind the authoritative servers already get the web logs so what
additional information is being leaked.

This is addressed in the panel. The argument is that there is some "privacy
mixing" because owner of the authoritative server only sees a highly-
trafficked resolver as the source, and not your home network resolver.

~~~
belorn
Yes, the authoritative server get less data from the DNS server but the owner
of the domain already get the information from web server logs and similar
sources. I do not see how dns mixing provide any privacy in any common threat
model.

In the first case a client that request a webpage contact company X
authoritative server with private information [IP ADDRESS], creating a record
on the DNS server, and then visit company X web server creating a second
record at the same company with the same [IP ADDRESS].

In the second case a client request a webpage of company X by contacting
google, creating a record on google DNS server with [IP ADDRESS], and then
visits company X and create a record there with [IP ADDRESS].

In one case one company has the data, and in the second case two companies has
the data. It does not make any sense.

------
kardos
Potential workarounds:

1\. Round Robin your DoH requests across several providers. Eg, if CloudFlare
sees one quarter of your DNS requests it's less revealing then if they see all
of them.

2\. DNS proxies. Sort of like a VPN for the DNS requests such that they're
aggregated to one source IP before being passed to the DoH provider. Done at
the ISP level? Or some other arrangement. The VPN here would not be privy to
the requests due to TLS.

These ideas may require more work to be practical.

~~~
dsl
Round robin won't work because a 25% sample is just as useful as a full feed.
All they need is enough users to provide a statistically significant
representation of traffic.

For you personally, if you send a query for www.example.com to one provider,
and a query for images.example.net to another, you've outed yourself as
browsing example.com to both.

~~~
kardos
Agreed, see reply to your sibling comment for a less-broken idea

------
throw2016
There is a lot of misinformation and false choices. The ISP scaremongering
seen here is not real and only serves to further entrench SV based global
surveillance data collection unimpeded.

An ISP is local, accountable to its customers and more important subject to
local laws that can be enforced. An added benefit is ISPs cannot collect,
collate and correlate vast amounts of global user data. This is a huge win for
wider society.

Compare that to unaccountable global organizations built on stalking and
hoovering up every single piece of user data with zero regulation and subject
to and support of their own home governments.

With this already in play 'concern' with localized ISPs cannot be justified
without first offering more immediacy and potent solutions to the larger
global surveillance problem.

~~~
candiodari
Here's the thing, right. SV global surveillance gets us better ads.

Meanwhile, governments ("An ISP is local" \- you've GOT to be joking) actually
systematically damage people based on surveillance data. Try visiting Pakistan
and then see how governments react to that country's stamp being in your
passport.

But it's hardly just that. Credit reports (are government mandated, and a
monopoly, they _are_ therefore government) really damage people. Police
actions, "random" searches, ...

And of course, heavy handed copyright enforcement.

So we would be transfering DNS authority from entities, the SV companies, that
have a VERY long history of not abusing that data, to entities, the
governments that not only have a long history of abusing this data, but
haven't even stopped doing so when caught with their hands in some cases
literally torturing people.

Governments' accountability is a JOKE, a sad, distasteful joke. I will not be
counting on that, sorry. And there is nothing local about those local ISPs in
any of the countries I use them.

So: no thanks, given those choices, I'll take the Google/Cloudflare option,
thank you very much.

------
rini17
Is the research of homomorphic encryption far enough that it's practical to
implement for DNS? The server would accept DNS queries using such
cryptographic algorithms on encrypted database, that he nor anybody else can't
say which record was queried. Only the client.

~~~
effie
I think the science is there and the technology exists as a proof of concept
[1]. The hard part, as is often the case, is getting the providers to adopt it
and users to use it.

[1] Cristofaro, Lu, Tsudik: _Efficient Techniques for Privacy-Preserving
Sharing of Sensitive Information_
[https://eprint.iacr.org/2011/113.pdf](https://eprint.iacr.org/2011/113.pdf)

------
teddyh
Encryption usually solves _three_ problems:

1\. Authenticity of data; i.e. fixing DNS spoofing.

2\. Privacy

3\. Censorship

Problem 1 is fixed _today_ by DNSSEC.

The best solution for problem 1, 2 and 3 would be if IPsec had a working and
deployed PKI, so IPsec could be used for all IP-based traffic, and nobody had
to worry about encryption on _any_ layer above that.

Lacking that, the next best thing for problem 2 would be for DNS to use TLS
and/or DTLS, and there is a standard for DNS over TLS (DoT), which makes
perfect sense to use today between resolvers and authoritative servers, and
between master servers and slave servers. However, this does not solve problem
3, since DoT uses a separate port and can be trivially downgraded by a MITM to
use old non-TLS DNS. In theory, this could be fixed by something similar to
how DANE solves the same problem for SMTP, in that a separate channel can be
used to indicate not to allow protocol downgrades.

But, this problem of censorship is in practice, today, _primarily_ an issue
between the client and the resolver. If that traffic can use DNS-over-HTTPS,
this would avoid problem 3 as well.

Note that none of this requires any centralization of resolvers, and is
technically completely tangential. The problem of centralized resolvers
existed since centralized resolvers first appeared; witness the prevalence of
using Google’s 8.8.8.8, etc. This is a huge problem independent of DNS-over-
HTTPS.

The connection, as far as I can tell, between DoH and centralization is that
_browsers_ want to fix as many as possible of problems 1-3, and using a
centralized provider of DNS-over-HTTPS does that, at the expense of
centralization and a single point of failure for problem 1-3. This is of
course a terrible idea. But I can certainly see why browser vendors are
attracted to the idea, bad though it may be.

~~~
wahern
DoC doesn't actually address 2 or 3.

I trust Sonic to not data mine or game my DNS queries much more than I trust
Google or Cloudflare. I actually run my own recursive resolver locally, but if
Firefox or Chrome default to DoC then the effect will be to _lessen_ the
privacy of Sonic Internet users, and users of similarly trustworthy ISPs.
Worse, the techniques employed by browsers to select between a DoC resolver
and a local resolver will inevitably on occasion break anonymizing VPN setups.
When the browser becomes the OS, you lose interoperability with third-party
software as browsers aren't built as platforms for _local_ interfacing.

And centralization makes censorship easier. A U.S. court may not be able to
block resolution of a domain under co.uk, but it definitely can force Google
or Cloudflare to block it. And it's much easier to execute an injunction
against a small handful of service providers that reach 90% of users than
trying to execute one to hundreds or thousands of smaller providers. Here's a
recent injunction ordering Cloudflare to block a DNS name:
[https://torrentfreak.com/us-court-lists-dns-and-routing-
serv...](https://torrentfreak.com/us-court-lists-dns-and-routing-services-in-
broad-anti-piracy-order-181116/)

~~~
teddyh
> _DoC_

Surely you mean DoH?

> _I actually run my own recursive resolver locally_

As do I.

> _I trust Sonic to not data mine or game my DNS queries much more than I
> trust Google or Cloudflare._ […] _And centralization makes censorship
> easier._

Oh, I agree. When you can't trust the single point of failure to not actually
fail or not to be already fundamentally failed, then everything about
centralization is bad.

~~~
wahern
> > DoC

> Surely you mean DoH?

DNS over Cloud (DoC) is the term coined in the article to differentiate the
underlying transport (DoT, DoH) from it's deployment (centralization).

