
A cartoon intro to DNS over HTTPS - johannh
https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/
======
barbegal
As a cynic I would say this is an attempt by Google and Cloudflare to collect
DNS data. Why else would they provide this service for free?

Both Google's [1] and Cloudflare's [2] DNS privacy policy prohibits them from
storing personally identifiable information or from correlating DNS
information with other Google data coming from the same IP/account but it does
allow them to store information about which domains are popular, from which
locations and from which type of device.

TLS (and therefore HTTPS) provides a very useful fingerprint based on accepted
cipher suites, extensions, compression methods...

[1] [https://developers.google.com/speed/public-
dns/privacy](https://developers.google.com/speed/public-dns/privacy)

[2] [https://developers.cloudflare.com/1.1.1.1/commitment-to-
priv...](https://developers.cloudflare.com/1.1.1.1/commitment-to-
privacy/privacy-policy/firefox/)

[3] [https://devcentral.f5.com/articles/tls-fingerprinting-a-
meth...](https://devcentral.f5.com/articles/tls-fingerprinting-a-method-for-
identifying-a-tls-client-without-decrypting-24598)

~~~
cremp
Cloudflare itself never made sense to me. What possible incentive do they have
to stop their primary purpose (DDoS protection) - They have value in
_promoting_ the behavior.

Whats worse, is everyone and their dog is using them. What happens when they
push a bad config to their core routers, or foobar their anycast?

~~~
txcwpalpha
It probably doesn't make sense because you misunderstand their primary
purpose. It's not DDoS protection. Cloudflare has a pretty wide-spanning
platform of products and services, but if you had to pick one out as their
"primary", it would be their CDN product. The DDoS protection is just more
visible because of the nature of the product (a good CDN will never make you
aware it even exists), and because mitigating DDoS attacks makes for good news
headlines.

Even if DDoS _was_ their main business driver, what you're saying is similar
to "doctors don't make any sense to me. what possible incentive do they have
for keeping people healthy? they have incentive for _promoting_ bad health."

As someone who works in security, believe me, there are _plenty_ of cyber
attackers out there that will easily keep companies like Cloudflare in
business, no "promotion" of bad behavior required.

~~~
yosito
> what you're saying is similar to "doctors don't make any sense to me. what
> possible incentive do they have for keeping people healthy

People do say this, all the time!

------
nykolasz
There are 3 major protocols available for DNS privacy:

* DNSCrypt

* DNS over TLS

* DNS over HTTPS

DNSCrypt is the one with better client support and a long list of providers
available. If you pick DNS over TLS or DNS over HTTPS you will be restricted
to 3 or 4 major players (google, quad9, cloudflare and cleanbrowsing). If you
trust them, you are good.

For example, this is the list of providers with DNSCrypt support:
[https://download.dnscrypt.info/dnscrypt-
resolvers/v2/public-...](https://download.dnscrypt.info/dnscrypt-
resolvers/v2/public-resolvers.md)

For DNS over (HTTPS|TLS), there is very little client tools available for
troubleshooting. The best one I found was these 2 in PHP:

[https://github.com/dcid/dns-over-tls-php-client](https://github.com/dcid/dns-
over-tls-php-client) [https://github.com/dcid/doh-php-
client](https://github.com/dcid/doh-php-client)

~~~
jedisct1
DNSCrypt is also the fastest and most secure.

It doesn't require sessions (uses UDP by default, like regular DNS, but
prevents amplification), enforces safe cryptography and pinned certificates,
is trivial to implement, doesn't need OpenSSL, implements padding without
inventing yet another DNS extension, and can use unique keys for each question
(so that DNS providers can't fingerprint clients, unlike other options due to
TCP sessions and TLS tickets).

~~~
eridius
If it's the fastest and most secure, why are people throwing their weight
behind DNS-over-HTTPS? There must be a reason for it.

~~~
bluejekyll
Because it's much more complicated to implement, where-as DNS-over-TLS and
DNS-over-HTTPS are far simpler to integrate into existing software and
operations.

~~~
gsich
How?

Both HTTPS and TLS implementations require custom software in order to work,
as no OS supports this natively (yet).

It boils down to install a stub that your local resolver will use instead of
the upstream directly.

~~~
bluejekyll
Well, basically because there are TLS libraries available in nearly every
language. DNSCrypt is a custom protocol.

For example here is my implementation over rustls in TRust-DNS:
[https://github.com/bluejekyll/trust-
dns/blob/master/rustls/s...](https://github.com/bluejekyll/trust-
dns/blob/master/rustls/src/tls_stream.rs)

Basically that’s a thin wrapper over the TLS library, and I was able to do
three different libraries. DNSCrypt on the other hand was a much larger
project, and I gave up on implementing it when I saw the DNS-over-TLS RFC
complete.

------
mike-cardwell
I kind of hate this. Taking a decentralised service, and replacing it with a
service provided by a small handful of tech giants.

"But this doesn’t mean you have to use Cloudflare. Users can configure Firefox
to use whichever DoH-supporting recursive resolver they want. As more
offerings crop up, we plan to make it easy to discover and switch to them."

Only defaults matter. Your average web user wont be interested in knowing
about or configuring this, no matter how simple the explanation/choice is
made.

~~~
marzell
If only defaults matter, then it's already a dead horse, as the majority of
users don't know what DNS even is, and are using their ISP's servers by
default.

~~~
gsich
Why does the amount of people knowing about DNS matter? Especially in the
context of decentralization?

~~~
tracker1
Depending on your ISP and/or country of origin, it can matter a lot.

------
Klathmon
There was a good chunk of time where my ISP (Verizon FIOS at the time) was
having some kind of DNS hijacking attack happening where many CDN IPs were
being replaced with an IP of a server that was adding some ad-injecting
javascript into many pages (and god knows what else, I still have the payload
laying around somewhere as I saved it for future curiosity).

At the time my only real recourse was to pump my whole house through a VPN, as
even Google's DNS (8.8.8.8) was being hijacked, but ONLY when it was coming
from my home IP. (Full disclosure, i'm not very well versed in the networking
stack. I know enough to get myself in trouble, but not much more. This was
what I understood to be happening, but I could be way off base. However it was
happening on multiple devices, multiple OSs, multiple verizon IPs, multiple
DNS servers, both with and without a router, and would stop instantly if any
of those machines were pointed at a wireless hotspot, or a VPN was turned on.
At one point I even sent my router's WAN connection through my phone's hotspot
and the problem went away)

After talking with verizon many times and each time having to spend an hour or
so trying to get through to someone that knew even remotely what I was talking
about, all they were able to do was reset my IP, which fixed nothing.

Now that DNS-over-HTTPS is becoming more common, i'm going to use it
everywhere I can. Yes, DNSSEC might be a "better" solution, but I can use DoH
right now to protect myself on all sites and (hopefully soon) all devices.

Just the other day I discovered Intra [0] a (still unreleased) app by Google
for android which has your whole android phone use DNS-over-HTTPS.

I've been running it the last few days and i'm quite pleased with it. Does
anyone know of a way to force all DNS queries in windows to use DoH?

[0]
[https://play.google.com/store/apps/details?id=app.intra&hl=e...](https://play.google.com/store/apps/details?id=app.intra&hl=en_US)

~~~
mcone
> Does anyone know of a way to force all DNS queries in windows to use DoH?

I think you could use pi-hole to do this. [https://docs.pi-
hole.net/guides/dns-over-https/](https://docs.pi-hole.net/guides/dns-over-
https/)

~~~
Klathmon
Thanks a ton, this looks fantastic! Do you know if it's possible to setup
Pihole to use this (and possibly other features) but not do any adblocking?

~~~
moderation
I'm using cloudflared [0] for this. Allows me to have system level DoH and
everything uses it (unless explicitly configured not to). Working on Linux
machines (amd64 and aarch64) and MacOS.

The documentation is not great / accurate but with a bit of fiddling I have it
running as a systemd service (launchctl on MacOS). I'm using the /metrics
endpoint to get details in Prometheus on the stats.

0\.
[https://github.com/cloudflare/cloudflared](https://github.com/cloudflare/cloudflared)

------
bluejekyll
I am very conflicted about DNS-over-HTTPS vs. DNS-over-TLS.

Most of DNS-over-HTTPS' interesting use-cases start coming into play when
you're using the same HTTPS session as the one being used to serve the site
you're visiting. Otherwise, DNS-over-TLS is sufficient for the same level of
privacy.

At that point though, DNS-over-HTTPS has a provenance issue that I don't fully
grok how we're going to avoid. What I mean by that: if the site you're
visiting supports DNS-over-HTTPS, where requests to that site for DNS records
are requested, what happens when they decide to issue custom responses to DNS
requests that ignore or supplement actual data in a zone? Won't that lead to a
bifurcation of the DNS network, where web-sites can start issuing custom
response to DNS queries?

Cloudflare, and Quad9, both offer DNS-over-TLS, this will be preferable for
non-HTTP use-cases. Some of the points in the article imply that DNS when
using DNS-over-HTTPS can't be used for tracking you, but really that just
means you're passing that trust to Cloudflare, Quad9, or Google. I suppose the
choice is open to you at that point.

~~~
jchw
I'm not sure I understand.

I was under the impression that DNS-over-HTTPS was nothing more than just an
alternative DNS protocol just like DNS-over-TLS, where you perform an HTTPS
request in order to query for a DNS name, and that DNS-over-TLS was just plain
old DNS wrapped in TLS.

You seem to be implying that DNS-over-HTTPS would enable sites themselves to
deliver DNS records. I don't see how that is possible, because connecting to
HTTPS with a hostname requires resolving a DNS record. Am I misunderstanding?

~~~
bluejekyll
You are correct for the initial request. I've seen many arguing for taking
this to another level of actually sending DNS requests over the same HTTPS
session being used with a site the browser is currently connected to.

~~~
jchw
Is this standardized/drafted? I am curious how one might implement this.

~~~
bluejekyll
See this thread with one of the authors of the RFC:
[https://news.ycombinator.com/item?id=16728600](https://news.ycombinator.com/item?id=16728600)

~~~
patrickmcmanus
Everybody is right in this thread :)

First, just to avoid confusion, the post linked to this HN article is just
about the classic recursive resolver model. That's the scope of what is being
experimented with actively.

Second, the notion of resolverless dns (where dns records are obtained from
somewhere other than your recursive resolver) is indeed something DoH
contemplates but does not yet allow. That's because issues around tracking,
correctness, and attacks haven't been fully explored. So unsolicited DNS is
interesting but its not something any browser would accept yet.

There are some other opinions on how HTTPS matches the needs of DNS here:
[https://bitsup.blogspot.com/2018/05/the-benefits-of-https-
fo...](https://bitsup.blogspot.com/2018/05/the-benefits-of-https-for-dns.html)

~~~
Lennie
Also notice how the plan is to push not only DNS entries but also TLS
certificates:

"Right now, people are really keen to get HTTP/2 “out the door,” so a few more
advanced (and experimental) features have been left out, such as pushing TLS
certificates and DNS entries to the client — both to improve performance.
HTTP/3 might include these, if experiments go well."

[https://www.mnot.net/blog/2014/01/30/http2_expectations](https://www.mnot.net/blog/2014/01/30/http2_expectations)

Some of those things could be used for bootstrapping SNI encryption as well:

[https://www.ietf.org/mail-
archive/web/tls/current/msg17474.h...](https://www.ietf.org/mail-
archive/web/tls/current/msg17474.html)

------
textmode
"Threats to users' privacy and security are growing."

s/privacy/&, autonomy/'

Case in point about autonomy is on HN front page at present:
[https://news.ycombinator.com/item?id=17196888](https://news.ycombinator.com/item?id=17196888)

The author cites a hypothetical example where a user shopping at Megastore is
blocked from accessing her preferred source of DNS data in order to prevent
her from checking a price.

Extending this hypothetical, imagine if in response to her request for an
unbiased price quote the user was shown unwanted ads with inflated, customised
pricing (informed by data gathered about her through tracking).

Choice of DNS data is an effective way for users to block advertising and
tracking.

The issue with user control over DNS also arises with mobile and other devices
(e.g. Chromecast/Google Cast/Google Home) that discourage or prevent a user
from using her preferred source of DNS data, forcing her to use a
commercially-oriented source which may block certain lookups.

This is relevant with any computer that connects to the internet.

It is an issue of _autonomy_.

There is a long tradition of HOSTS files and later non-commercial DNS where
users can autonomously determine where on the network they want to "go". They
have the final control over the source of DNS data the computer will use. They
can delegate DNS service to someone else, _however_ , following that long
tradition, they still retain the autonomy to choose the source of the DNS
data, whether it is another third party, their own DNS servers or perhaps
/etc/hosts in place of DNS.

When an organization (e.g. running an "app store") seeks to circumvent the
ability of the user to choose her own DNS data source on her own computer,
that is an attack on _autonomy_.

The author mentions that Firefox will allow users to choose their own "DOH
DNS" servers. If so, this respects users' autonomy.

(No one seems to be mentioning one obvious advantange of DOH DNS for browsers:
bulk DNS "prefetch" lookups. One can use HTTP/1.1 pipelining to retrieve the
IP addresses for every hostname contained in an HTML page, with _a single HTTP
request_ , instead of numerous, simultaneous DNS requests. As for privacy
problems with TLS fingerprints, HTTP requests can be secured by CurveCP as an
alternative to TLS - example is in my profile.)

~~~
vetinari
I see additional problem with this, which actually endangers autonomy.

The resolving is not only done for user-initiated action, but is being done by
many programs, even which you might not want to do it. For the same reason,
many users use a local firewall to block outcoming connections, like Little
Snitch.

(Sidenote: if you are using MS Office 2016 for Mac, and are not satisfied with
the choice of telemetry that Microsoft offered you in the last update, and you
are interested in third option, "None", the hostnames to block are
nexusrules.officeapps.live.com and nexus.officeapps.live.com)

With apps using DoH and ignoring the local resolver, that firewall will now
have a problem, especially if multiple, separate hostnames resolve to the same
IP. Until now, Little Snitch used a guess (last resolved hostname that matches
the IP); now it won't have that chance.

That's why, if the user wants to have a chance to who their local processes
talk to, they must be forced to use a local resolver under user's control, not
implement their private resolver. And of course, on non-public networks, it
should be supplie-able by DHCP or RA.

~~~
tracker1
As long as you can configure DoH, you can setup your own resolver and do what
you want. In the end DoH will probably eventually be an option in the OS
level, or not for lighter OSes. I think having it at the application layer is
to add a nudge in the OS developer direction.

------
gsich
I tried DNS over TLS (somewhat similar) and it has some potential. But not
with those strict timeouts. 1.1.1.1 closes the TCP connection almost instantly
after the query response, 9.9.9.9 waits a bit longer, about 10 seconds (need
to check again).

So everytime you want to make a query, you have to wait several RTTs before
getting a response.

The connection need to be open for as long as possible, at least 5 minutes.

I used stubby as forwarder with idle_timeout: 6500000, the idle timeout in ms.
The connection gets closed by the remote party, not by stubby.

~~~
jedisct1
Because DNS servers were never designed to keep many open TCP connections.

~~~
gsich
Doesn't matter what they were designed for. With TCP they need to behave that
way. Otherwise this is a solution for people with latency <10 ms to the
server. So not a whole lot.

I'll argue that the TCP and TLS handshake take more processing power then
keeping the connection open.

~~~
caf
The limiting resource with large numbers of idle sockets on the server side is
memory, not processing power.

~~~
gsich
Which I doubt is a problem for Cloudflare or Quad9. Anyway, a TCP based DNS
service needs to consider those things. Otherwise it is becoming unusable due
to very high response times.

A standard 8 GB system with Debian 9 gives me 1048576 max file descriptors. I
am sure this can be optimized still.

~~~
caf
The default socket receive and send buffers are ~200KB, so you would actually
need 400 GB of memory in order to have each of those 1048576 file descriptors
connected to a unique socket.

And if you were keeping them open for 5 minutes as suggested, that would still
limit you to only 3400 clients / second.

I do actually agree that they need a longer idle timeout on these connections,
but I just wanted to point out that comparisons with the processing power
required to set up a TLS connection aren't apt.

~~~
tracker1
I'm pretty sure that they don't _HAVE_ to use the defaults, and for something
like DNS, they probably shouldn't be... The buffer should probably be limited
to what the largest request segment would be for creating the TLS/HTTPS
connection in the first place, which just guessing would be closer to 1K.

------
herghost
> "Threats to users’ privacy and security are growing."

Website won't load without allowing a call out to googleadapis.l.google.com

Yeah, you're right they are growing.

------
mholt
Was just wondering... what value will DNS over HTTPS provide if/when we all
move to IPv6 and presumably everything could potentially be identified by IP
address directly? Will datacenters/ISPs be incentivized to do NAT with IPv6 or
have some other way of introducing indirection into the routing?

~~~
zackbloom
Think about Cloudflare itself. Millions of websites hosted behind a handful of
IP addresses.

~~~
mholt
So we go back to re-centralizing for privacy? I love Cloudflare, but... if
that's really the answer to this... sigh.

~~~
tracker1
Well, about 8M websites are already behind Cloudflare... if you add the top 50
hosting providers, that's probably 95% of the internet. Traffic is already
relatively centralized.

------
PappaPatat
Now just wait for your browser (or any other random application) to stop using
your OS's resolve completely (at least Chrome does at times already by simply
accessing DNS services via port 53 when it considers the configured OS DNS
'not good'. I have no idea about the exact criteria) by accessing its desired
DNS-over-HTTPS server and bypass your carefully setup DNS filtering /
monitoring.

Notes 1: I have NO idea if Chrome (or any other random application) accesses
DNS-over-HTTPS already since I have not paid too much attention to it.

2: At least Chrome (on OSX) likes to access 8.8.8.8 & 8.8.4.4 & your
configured DNS server on port 53 (happy eyeball protocol). This might only be
on flaky networks like mine, where I tend to make all sorts of configuration
experiments.

------
iampims
I applaud the efforts to increase privacy,reduce data collection and hardened
security. Do we really want a SPOF in Cloudflare for this though? A single
outage (or AT&T snafu) and many millions of users would be affected.

~~~
dogecoinbase
In fact, it already happened between this Mozilla announcement and now:
[https://www.cloudflarestatus.com/incidents/2mz3wly2g7dy](https://www.cloudflarestatus.com/incidents/2mz3wly2g7dy)

I think encrypting DNS transport is as important as the next guy (though DoH
is bad), but am super unhappy about Mozilla apparently signing on with
Cloudflare's ongoing fairly successful attempts to centralize the internet.
Sure, they say they'll delete your data "within 24 hours" (they shouldn't be
keeping it at all), but pretty soon they'll get a Nat'l Security Letter like
everyone else does.

~~~
tracker1
Which begs the question, do they have a canary page?

In any case, it would be unreasonable to require logging for more than that...
even a week would be too much data for many ISPs. Also, they have to have some
logging to be able to even try and troubleshoot a problem.

------
codedokode
Encrypted DNS is an awesome idea. But routing all of your DNS requests to a
private US company should not be enabled by default.

And what about SNI that shows domain name in clear text for HTTPS connection?
Please do something with it too.

------
h1d
Why is DNS taking so long to have security patched in as if governments are
pressuring to make sure they can snoop on things easily. Same goes for email.

Having an opt in security mechanism is easy to deploy as in keeping the http
version of a site available while running https on a new port for clients that
want to use it.

------
Skunkleton
Doesn't TCP, TLS, HTTP, and finally DNS seem like overkill? Why not DTLS +
plain DNS requests?

~~~
gsich
Standard HN response: Because my corporate firewall does not allow me to use
UDP! Which is the nowadays excuse to use 80/443 for everything. Customers at
home don't have this problem.

But there are alternatives, DNS over TLS (essentially the same without HTTP)
and dnscrypt which uses UDP.

~~~
walrus01
This is why I run an openvpn server on port 443 in tcp mode, not UDP, for
places like shitty airport captive portal wifi.

------
64kbisalluneed
As a good and responsible parent DNS over HTTPS will never be an option. I run
a DNS server on my local network.

~~~
tracker1
You _could_ still have that DNS server use an upstream DNS over HTTPS or other
encrypted channel that unifies traffic, which has the effect of anonymizing.

------
philip1209
DNS over HTTPS uses DNS in the protocol. Does that make it extra-recursive
DNS?

~~~
jedisct1
Not necessarily.

You can connect using an IP address. At least to bootstrap the process. This
is where DNS Stamps come in handy [https://github.com/jedisct1/dnscrypt-
proxy/wiki/stamps](https://github.com/jedisct1/dnscrypt-proxy/wiki/stamps)

------
bobajeff
>That means that your ISP can still figure out which sites you’re visiting,
because it’s right there in the server name indication. Plus, the routers that
pass that initial request from your browser to the web server can see that
info too.

Well there goes the interest I had in this.

~~~
patrickmcmanus
we're coming after SNI too. One step at a time.

(also, 1] dns leaks are worse than sni leaks as typically more people are
exposed to the dns query and 2] HTTP/2 can carry more than one hostname on a
connection so some hostnames that appear in dns are never leaked through sni.)

~~~
tialaramex
The TLS WG currently has only a problem statement for Encrypted SNI. Even the
weak selection of two possible ways forward didn't achieve consensus as I
understand it.

I don't see any way to have encrypted SNI without paying a price of one
additional round trip. That's a fair price for something you must have, but
for anybody to benefit we must insist everyone use it always, or adversaries
will simply block it. And a round trip is a high price for users who don't
(believe they) need this.

