
Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims - shreyasonline
https://blog.technitium.com/2019/09/analyzing-dns-over-https-and-dns-over.html
======
jchw
Part of Paul Vixie’s argument is that DNS is part of the control plane, and
that DoH will bypass security policy. Let’s at least address this with some
skepticism.

1\. Is security policy via DNS really a good way to go? There are other, imo
more effective, ways of handling this. If your security policy can be defeated
by using a DoH resolver, it’s evidently not very hard to bypass.

2\. While this can be true, it’s not actually anything to do with the way DoH
works. You could just as easily choose to only upgrade to DoH when the DNS
provider of your choosing happens to support it.

3\. Home internet is not new or uncommon. 76% of the US has internet access
according to a cursory Google search. A vast, vast majority of these users are
casual users. The control plane is not under their control necessarily. The
control plane is not something that can just absolutely be trusted.

With much respect, I simply must disagree. The notion that DoH is dangerous
feels like it comes from a dated view of internet security, and it only
reflects the mode of rollout where application software indiscriminately uses
a DoH server in place of the user’s default DNS server.

Further, this article has a lot of interesting claims. It claims that many
websites are still not running over TLS even though it’s free. Of course, this
is undoubtedly true and reflected in statistics. However, is it true in a
realistic sense? How many non-HTTPS pages do you browse?

Thanks to Cloudflare and other actors, I suspect ESNI will have no trouble
gaining meaningful marketshare. Not full proliferation. We don’t need full
proliferation for it to be useful, though.

~~~
zrm
> Is security policy via DNS really a good way to go? There are other, imo
> more effective, ways of handling this. If your security policy can be
> defeated by using a DoH resolver, it’s evidently not very hard to bypass.

That's assuming the clients and the network are adversarial to each other.
Consider that the local DNS resolver may be blocking domains associated with
malware or ads, which the client wants for it to do, and then changing the
default DNS from the one configured via DHCP results in clients getting
malware and ads they didn't want.

> While this can be true, it’s not actually anything to do with the way DoH
> works. You could just as easily choose to only upgrade to DoH when the DNS
> provider of your choosing happens to support it.

The major criticism of DoH is Firefox enabling it by default and overriding
the existing system DNS configuration, requiring manual reconfiguration of
arbitrarily many client devices to change it back to the way it was. There can
obviously be no legitimate objection to it if it is disabled by default and
only used when explicitly enabled by the user.

> Home internet is not new or uncommon. 76% of the US has internet access
> according to a cursory Google search. A vast, vast majority of these users
> are casual users. The control plane is not under their control necessarily.
> The control plane is not something that can just absolutely be trusted.

This is a great argument for making DoH/DoT/DNSCurve/etc. the default
configuration for the builtin resolver in home internet routers. Which thereby
solves the problem without introducing a new one where if you want to change
the default it requires reconfiguring arbitrarily many separate applications
on every individual client device, because in that case you can still
configure the DNS for the local network in one location.

~~~
tptacek
Adversarial networks are the common case.

In the other cases, where DNS is being used as a legitimate policy vector, the
entity enforcing that policy should also have endpoint control, which they can
use either to re-establish network policy (by disabling DoH) or to enforce
policy more reliably at the endpoint layer.

~~~
zrm
Adversarial networks are not the common case. On the majority of networks you
can send a plaintext UDP DNS query to 8.8.8.8 or 1.1.1.1 and nothing will
actually interfere with it in practice.

Adversarial networks _exist_ , which is why something like DoH or DNSCurve
should be used in favor of unauthenticated DNS over the internet, but the real
issue here is independent of which DNS protocol is used -- it's how the
recursive resolver is chosen.

The canonical answer to that is to use DHCP or similar to distribute the
resolver that should be used for the local network, and allow the user to
manually configure a different one in any case where that one is
untrustworthy. DHCP _is_ the ordinary method of endpoint control for
configuring the endpoint's DNS server.

The endpoint shouldn't have to be exposed to manual configuration or give up
even more control over other unrelated settings by adding their device to
something like a third party Active Directory domain just to be able to plug
into a local network and have local name resolution work.

~~~
tptacek
Your threat model isn't the set of actors _currently attacking you_ , but
rather those actors who _can and might_ attack you in the future. Your ISP is
certainly adversarial in any sane threat model.

~~~
zrm
Aren't you the one usually telling everyone that DNSSEC is useless even though
it solves the same problem, e.g. because the server can be verified with TLS
instead? If the DNS attack is nothing more than a denial of service then it
seems completely reasonable to wait until the attack is actually observed
before applying a mitigation (third party DNS) that can have problematic side
effects. Especially when the mitigation can be made as simple as a single
checkbox in the browser.

And what makes Cloudflare any more trustworthy than the average ISP? Isn't
that just switching the user's resolver from the network they explicitly chose
to connect to, to a centralized third party that they didn't?

~~~
tptacek
DNSSEC doesn't solve any practical problem, but does have the effect of
escrowing TLS keys to world governments. DoH solves an immediate problem,
which is that ISPs (and other entities) passively monitor DNS traffic to
collect intelligence on network users. DNSSEC does nothing about this problem.

You don't have to use Cloud Flare for DoH, and I wouldn't.

~~~
zrm
> DoH solves an immediate problem, which is that ISPs (and other entities)
> passively monitor DNS traffic to collect intelligence on network users.
> DNSSEC does nothing about this problem.

That's assuming the DoH provider isn't monitoring queries either. Doesn't
Cloudflare have a deal with APNIC to do exactly that?

> You don't have to use Cloud Flare for DoH, and I wouldn't.

That's the point -- the problem isn't that DoH exists, it's when an
application changes your DNS provider to Cloudflare by default instead of
using the one you have in your system configuration.

~~~
tptacek
You can trivially boot up your own DoH provider if you don't trust any of the
existing ones. It's hard to imagine a protocol that would improve this
situation: "supported by major vendors, and free to use for everyone".

I won't use Firefox to begin with (I'll reconsider when it's mostly Rust!),
and so don't care so much about how Mozilla is handling this. Personally, I
wouldn't touch Cloud Flare with a 10 foot pole. But that's not what I'm
commenting about; I'm talking about DoH itself, which is an unalloyed good
thing, which you can tell in part by the fact that the knives are out for it.

------
Santosh83
The claim that DoH will interfere with internal DNS of enterprises can be
solved with a local deployment of a recursive DoH server right? That also
addresses the concern of centralisation. Imagine every ISP offering a DoH
sever... so now Cloudflare will not be in a position to scoop up the entire
DNS data of the Internet.

I'm still waiting to see a genuinely technical disadvantage of DoH. All that
I've read so far are social and implementation related issues that can be
ironed out over time.

~~~
vetinari
The thing that is _still_ being ignored is the configuration mechanism for the
DoH resolver.

Currently, the only way to configure it is manual and application-specific;
there's no way to configure it for all apps and automatically, like DHCP for
the normal, 53/udp DNS. Nobody is going to manually reconfigure their DNS
every time they switch network (e.g. home -> office -> customer).

~~~
chupasaurus
Currently, the only way to configure DoH for everything is one-time setting
local dnscrypt-proxy as the only resolver. Easy on Android 9+ and Linux with
systemd, on Windows you have to override DNS settings for _all_ NICs because
it has a weird process of resolving. Don't know about macOS, iOS is definitely
out.

edit P.S: I'd never trust ISP's DNS servers, because it's the easiest way to
track what customers does.

~~~
fragmede
I may trust Comcast as far as I can throw them. I still prefer that they get
my data, rather than even more of my browsing data go straight to Google.

~~~
tptacek
The point of DoH is that you don't have to send your DNS queries to either of
those entities.

------
asveikau
I do sometimes use firefox and I found the canary hostname, linked in the
article, to be a good tip:

[https://support.mozilla.org/en-US/kb/canary-domain-use-
appli...](https://support.mozilla.org/en-US/kb/canary-domain-use-application-
dnsnet)

My home network has a DNS server that already talks to the outside DNS servers
with TLS, so having browsers reach out to cloudflare would prevent cross-
device caching and only protect against snooping on my LAN or wifi, which I
don't find to be very necessary. So I just made this domain return NXDOMAIN.

------
shawnz
> DNS is one important control planes in a network. It essentially allows
> network administrators to block content based on domain names making it
> quite useful tool in the arsenal. It is being widely used to provide content
> filtering services, parental controls, and to block known malware command
> and control. Its so popular that a lot of people install a locally running
> DNS server on their home networks to block Internet Ads using block lists.

This is a totally wrong usage of DNS and I wish we would focus more effort
into making IP-based blocking easy and accessible rather than wasting time
trying to make DNS fit this niche. DNS is not the right tool for this job and
maintaining this functionality is not a valid reason to block progress on more
private technologies like DoH. And it's totally possible to run a PiHole-style
system using DoH anyway.

~~~
jdsnape
I'm not convinced IP-based blocking can be more effective than DNS blocking.
Very often many different sites are hosted on one IP address (e.g. a CDN in
the 'worst' case), and IP blocking would mean lots of things become
inaccessible.

Users access services by DNS name, so if you want to control access it has to
be at that level. Whether DNS can be effectively blocked while maintaining
privacy is another issue, but I can't see IP-based blocking helping here.

~~~
comex
In my opinion, _both_ DNS- and IP-based blocking are a hack because they
fundamentally have to work based on limited information. After all, ad
services could pretty easily start doing any of the following:

\- proxying ad requests through the server of the website you're visiting;

\- accessing ads by IP address directly; or

\- using randomly generated domain names.

With a browser-based ad blocker, those measures would still be an obstacle,
but at least you'd have a chance - you could switch to more heuristic ways of
detecting ads based on, say, the scripts involved, or the content of the media
being downloaded, or its size and placement on the page. None of that
information is available to network-based blockers, at least not when HTTPS is
in use.

Admittedly, those things probably won't happen anytime soon, at least not for
regular website ads. (Though as one example, Twitch has already started using
fairly sophisticated measures to bypass ad blockers for their video ads...)
But I'm an idealist, and I like to fight on favorable territory. When it comes
to cat and mouse games, I don't want to be the mouse.

------
Ayesh
I like Chrome's approach to DoH. If the local DNS server is capable of DoH,
then, and only then, Chrome switches to DoH. It is the safest choice to make,
since if you are querying that name server, they have your data anyway, so you
might as well encrypt it in transit.

~~~
techslave
i am very avidly opposes to DoH because it doesn’t solve the problem people
think it does. and it further entrenches cloudflare, who imho are vile but
that aside the concentration isn’t a good thing.

however, your statement is wrong.

i won’t go further into detail because my comments on this subject universally
attract all the downvotes so there’s no point. but in general the problem is
you need to qualify “safest”. safest for what and for whom, and in what
scenarios? you’ve left too much unsaid, so what you say is not generally true.

~~~
icebraining
This comment says very little; you don't explain what problem people think DoH
solves, won't go into detail on why the statement is wrong, nor why not
qualifying "safest" makes it not generally true.

At least a comment that attracts downvotes may be useful to someone.

------
alibert
My fear is that platforms start using DoH, bypassing local dns privacy
resolver such as pihole, for tracking purpose. I have a nVidia Shield and I
can see how many requests to tracking domains it does and if nVidia or Google
uses DoH, I will not be able to block those requests.

------
bjoli
Can anyone explain why DoH was invented? To me it seems like another one of
the "let's solve this using web technologies!" Whereas DoT has a great ietf
process behind it.

~~~
tptacek
_Two primary use cases were considered during this protocol 's development.
These use cases are preventing on-path devices from interfering with DNS
operations, and also allowing web applications to access DNS information via
existing browser APIs in a safe way consistent with Cross Origin Resource
Sharing (CORS)._

Virtually all the opposition to DoH is rooted in two complaints:

1\. It centralizes DNS at Cloudflare (obviously, you can point DoH elsewhere).

2\. It's hard for network operators to block it (which is the point).

~~~
kchamplewski
The biggest complaint I have regarding DoH is that it's extremely painful to
configure because every application does it individually.

If I could configure DoH at the system level, as I do normal DNS, I'd be
perfectly happy. As it stands, DoH could trivially be co-opted by browser
vendors to ignore system DNS settings, and even if it isn't, it still makes
DNS configuration a worse experience.

~~~
tptacek
This seems a lot more like a complaint about your libc than about DoH. But the
response to that complaint would likely be "give it time".

------
seanhunter
For people concerned with Firefox's use of cloudflare, it's very easy to
configure an alternative DoH if you have one you prefer. You can do so via
network prefs or about:config (the key is "network.trr.resolvers")

------
cbsmith
I haven't though much about this problem, but I'm curious why none of the
solutions employ DTLS. Is UDP just pointless in this context?

------
collsni
DOH has the possibility to leverage the wrong parties against encryption.
There needs to be a barrier of control.

