←back to thread

1.1.1.1: Fast, privacy-first consumer DNS service

(blog.cloudflare.com)
1895 points _l4jh | 1 comments | 01 Apr 18 12:14 UTC | HN request time: 0s | source
Show context
bluejekyll ◴[01 Apr 18 14:17 UTC] No.16728385[source]▶
DNS-over-HTTPS doesn’t make as much sense to me as DNS-over-TLS. They are effectively the same thing, but HTTPS has the added overhead of the HTTP headers per request. If you look at the currently in progress RFC, https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-04, this is quite literally the only difference. The DNS request is encoded as a standard serialized DNS packet.

The article mentions QUIC as being something that might make HTTPS faster than standard TLS. I guess over time DNS servers can start encoding HTTPS requests into JSON, like google’s impl, though there is no spec that I’ve seen yet that actually defines that format.

Can someone explain what the excitement around DNS-over-HTTPS is all about, and why DNS-over-TLS isn’t enough?

EDIT: I should mention that I started implementing this in trust-dns, but after reading the spec became less enthusiastic about it and more interested in finalizing my DNS-over-TLS support in the trust-dns-resolver. The client and server already support TLS, I couldn't bring myself to raise the priority enough to actually complete the HTTPS impl (granted it's not a lot of work, but still, the tests etc, take time).

replies(9): >>16728460 #>>16728600 #>>16728618 #>>16728709 #>>16728748 #>>16728753 #>>16728813 #>>16729267 #>>16729468 #
Twirrim ◴[01 Apr 18 15:04 UTC] No.16728618[source]▶
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.

replies(2): >>16728809 #>>16729885 #
bluejekyll ◴[01 Apr 18 15:38 UTC] No.16728809[source]▶
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?

replies(1): >>16729088 #
gsnedders ◴[01 Apr 18 16:30 UTC] No.16729088[source]▶
> When we add TLS on top of the protocol, ISPs can only filter based on port at that point.

And SNI… :(

replies(3): >>16729197 #>>16729570 #>>16729589 #
Operyl ◴[01 Apr 18 16:49 UTC] No.16729197[source]▶
If this were to become an issue, I guess Cloudflare could try to disable SNI.
replies(1): >>16729300 #
hsivonen ◴[01 Apr 18 17:08 UTC] No.16729300[source]▶
The client sends SNI, so how could the server opt out?
replies(2): >>16729342 #>>16729731 #
Operyl ◴[01 Apr 18 17:17 UTC] No.16729342{4}[source]▶
You just solved your own question. Cloudflare creates an opensource client that users install locally.
replies(2): >>16729538 #>>16733066 #
majewsky ◴[01 Apr 18 17:55 UTC] No.16729538{5}[source]▶
Where's the button to install your own DNS resolver on iOS? Or non-rooted Android, for that matter.
replies(3): >>16729659 #>>16733164 #>>16733592 #
1. MertsA ◴[02 Apr 18 11:03 UTC] No.16733592{6}[source]▶
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.