Some ISPs block outbound DNS from customers to anywhere but their resolvers, filtering based on target port. This is a particularly common trick in countries that attempt to censor the internet.

It's a lot harder to do that with DNS-over-HTTPS because it looks like normal traffic.

That said, in this case ISPs can just null route the IP address of the obvious main resolvers such as 1.1.1.1. I imagine most of the benefit is surely to people who can spin up their own resolvers.

When we add TLS on top of the protocol, ISPs can only filter based on port at that point. We can run DNS on 443 if that helps, but as you said, static well-known IPs can then be blocked.

> I imagine most of the benefit is surely to people who can spin up their own resolvers.

There are already many easily run DNS resolvers available. Is there a benefit you see in operating them over HTTPS that improves on that?

> When we add TLS on top of the protocol, ISPs can only filter based on port at that point.

And SNI… :(

This is really the elephant in the room. For all we know, ISP bad-actors have never cared about DNS for data-collection purposes, and they're already using SNI to gather data to sell to marketers. I think it's absolutely crucial to find a way to (at least optionally) send SNI encrypted to the server.

There's domain fronting, which uses SNI to bypass censorship! :)

https://en.wikipedia.org/wiki/Domain_fronting

If this were to become an issue, I guess Cloudflare could try to disable SNI.

The client sends SNI, so how could the server opt out?

You just solved your own question. Cloudflare creates an opensource client that users install locally.

The client that sends SNI is, AFAIK, the browser or a similar piece of software. Some older browsers don't support SNI so they can only access single-vhost-per-ip over https.

This means you'll have a really hard time trying to get rid of SNI system-wide, what with a lot of minor apps making their own https connections (granted, on Android or iOS they probably use a common API, but not on a computer).

Where's the button to install your own DNS resolver on iOS? Or non-rooted Android, for that matter.

Someone shared this lovely iOS app yesterday:

DNSCloak • DNSCrypt DoH client by Sergey Smirnov https://itunes.apple.com/ca/app/dnscloak-dnscrypt-doh-client...

It supports DNSCrypt, DNSSEC and DNS-over-HTTPS, the IAP are for tips :)

It works via running a VPN server on your device.

To change your normal plaintext DNS resolver just tap the circle-i on your WiFi network.

Well with SNI the concern isn't DNS. Any TLS connection that supports SNI (basically everything that isn't ancient) would have to be fixed. Also, ANI is a pretty useful thing to have and getting rid of it doesn't exactly fix much. Without SNI the server only has the destination IP address to determine which site and thus which certificate to send to the client. Having https sites with multiple certificates hosted on one IP address only works because of SNI. You would break a large portion of the web by disabling it. Also, even if you do disable SNI, the server still sends back the certificate with the domain names in it. And even if you ignore all of that, there's still reverse DNS which will probably be accurate if they send mail from that server and you can always do a DNS lookup for every domain name there is to get a map of which domains point to a given IP. Due to DNS based geolocation that won't work for every site but the sites using that are going to be big enough to find their IP address ranges via another method.

In short, there's really no good solution here but an amendment to TLS could conceivably make it to where it wouldn't be possible to narrow it down to which site that an IP address hosts the user was visiting. That could actually be good enough for traffic to e.g. cloudflare.

Non-rooted android, you have to set a static IP for every network and then there will be an option to enter DNS names. They default to Google DNS Static IP settings are under advanced.

Server could advertise no need to use SNI in advance. Or we could do SNI after actually establishing an encrypted session...

I suppose there is also domain fronting [1], but it won't be fast or an easy-to-remember IP address anymore. And if you need that, you might need a VPN anyway?

[1] https://en.wikipedia.org/wiki/Domain_fronting

It's amazing that governments haven't shut down shared domains to prevent domain-frontong.

1.1.1.1 does support DNS-over-TLS as well: https://developers.cloudflare.com/1.1.1.1/dns-over-tls/

Yes! And I plan to actually build in a default setup to use that now that it exists. I should have mentioned up front that this is the most exciting thing to me in the announcement.

This is a very exciting development, thank you for posting this.

One of the use cases for DNS-over-HTTPS given in the draft was to allow web applications access to DNS directly via existing browser APIs.

I've implemented DNS before. Doing this saves an entire 300 lines of code. At the same time, it makes the DNS server much more complicated. On top of that, implementing a compliant posix libc will now either use a completely different code path, or pull in a huge amount of code to implement HTTP, HTTP/2, and QUIC. If the simpler, cleaner, and more performant route is taken, it willgbreak when someone screws up "legacy" dns without noticing, because it works in the browser.

It's not worth the complexity of multiple protocols that do the same thing. And it's not worth making the base system insanely complicated so that the magic 4 letters 'http' can show up.

TLS? Yeah, since the simpler secure DNSes failed, we might as well use that. But let's try to keep http complexity contained.

Ok that’s actually pretty cool.

Wonder if this will pave the way for other protocols over HTTPS.

Hopefully not. One needs to stop working around crappy setups from crappy networks. Which X-over-HTTPS really is all about.

It seems like crappy networks are the norm nowadays, and the preference of the ISPs is to offer the web only. You need a middle box just to access the internet at-large (e.g Tor). Masquerading traffic as web traffic appears to be a good tactic, though inefficient/sloppy.

Yeah, but once everything is tunneled over HTTP it will finally fix the network operator problem once and for all since you can't filter applications using ports.

Cloudflare addresses this in the blog post:

There are a couple of different approaches. One is DNS-over-TLS. That takes the existing DNS protocol and adds transport layer encryption. Another is DNS-over-HTTPS. It includes security but also all the modern enhancements like supporting other transport layers (e.g., QUIC) and new technologies like server HTTP/2 Server Push. Both DNS-over-TLS and DNS-over-HTTPS are open standards. And, at launch, we've ensured 1.1.1.1 supports both.

We think DNS-over-HTTPS is particularly promising — fast, easier to parse, and encrypted.

Dns over https would be harder for governments and other middleman to block or intercept, despite it being less efficient. It would look like any other https request. Especially if browsers agreed to universally support it.

No it wouldn't. They're both encrypted with the same method so they can't tell whether http is used or not.

tls isn't magic, you can still observe the encrypted stream and make assumptions based on bytes sent/received on the wire, protocol patterns and timing. See the crime and breach attack.

Sorry, confused. Https requests are prolific, while encrypted DNS requests aren't. Why isn't the former less hard to detect?

How would you tell that an encrypted chunk of data is HTTPS instead of DNS? The best you'd be able to do is guess based on behavior that it's DNS.

Destination port might be easy to differentiate dns over tls vs dns over https :)

Perhaps if the attacker filters traffic first by protocol, it's harder but not at all impossible. I'd guess that DNS-over-HTTPS packets won't be hard to identify by other means.

of course dns over https to cloudflare can be mixed on the same h2 connection with other https to the same host. It starts to get interesting.

(this is one of the advantages of https vs straight tls)

rfc 8336. h2 coalescing. h2 push. caching. it starts to add up to a very interesting story.

Thank you for responding, Patrick. As one of the authors of the RFC, your views on this are a great contribution to the conversation.

> rfc 8336

I'll have to read up on this, thanks for the link.

> h2 coalescing

DNS is already capable of using TCP/TLS (and by it's nature UDP) for multiple DNS requests at a time. Is there some additional benefit we get here?

> h2 push

This one is interesting, but DNS already has optimizations built in for things like CNAME and SRV record lookups, where the IP is implicitly resolved when available and sent back with the original request. Is this adding something additional to those optimizations?

> caching

DNS has caching built-in, TTLs on each record. Is there something this is providing over that innate caching built into the protocol?

> it starts to add up to a very interesting story.

I'd love to read about that story, if someone has written something, do you have a link?

Also, a question that occurred to me, are we talking about the actual website you're connecting to being capable of preemptively passing DNS resolution to web clients over the same connection?

Thanks!

this story will evolve as the http ecosystem evolves - but that's part of the point.

wrt coalescing/origin/secondary-certificates its a powerful notion to consider your recursive resolver's ability to serve other http traffic on the same connection. That has implications for anti-censorship and traffic analysis.

Additionally the ability to push DNS information that it anticipates you will need outside the real time moment of an additional record has some interesting properties.

DoH right now is limited to the recursive resolver case. But it does lay the groundwork for other http servers being able to publish some DNS information - that's something that needs some deep security based thinking before it can be allowed, but this is a step towards being compatible with that design.

wrt caching - some apps might want a custom dns cache (as firefox does), but some may simply use an existing http cache for that purpose without having to invent a dns cache. leveraging code is good. There are lots of other little things like that which http brings for free - media type negotiation, proxying, authentication, etc..

> There are lots of other little things like that which http brings for free - media type negotiation, proxying, authentication, etc..

Reading a little between the lines here, would you say that at some point we effectively replace the existing DNS resolution graph with something implemented entirely over http? Where features like forwarding and proxying would have more common off the shelf tooling?

I can start see a picture here that looks to be more about common/shared code, and less about actual features of the underlying protocols.

As a complete layperson, h2 push might be interesting because a DNS resolver could learn to detect patterns in DNS queries (e.g. someone who requests twitter.com usually requests pbs.twimg.com and abs.twimg.com right after) and start to push those automatically when they get the query for twitter.com.

How is any of this more secure against your ISP in any case given someone willing to do reverse lookup‘s on IP addresses?

If someone controls routers is it not nearly useless?

So for example all mobile 4g providers could laugh at this and build a nearly as good database of every site you visit?

Reverse DNS is a lot more difficult than just intercepting DNS requests. Especially with virtual hosts, caching proxies and so on.

How much overhead? Is the request or response larger than a single packet?

>The article mentions QUIC as being something that might make HTTPS faster than standard TLS.

Even with TLS 1.3 0-RTT?

yes, quic will make dns over https more resillient to packet loss than a tls based approach.

exactly...