DNS-over-TLS vs. DNS-over-HTTPS | Hacker News Reader

DNS-over-TLS vs. DNS-over-HTTPS

dnsfilter.com

49 pointsserenadns24 comments

Sorry to say this out loud, but this article is poorly written and has many misconceptions about DoH, DoT and browsers. Feel free to chide and correct my comments below.

> DNS-over-HTTPS isn’t used by Firefox and Google because it’s superior to DoT. It’s used because browsers operate at the HTTPS layer by default, so DNS-over-TLS doesn’t make sense (as things stand now) for a browser to implement.

Umm, browsers need to handle TLS in order to support HTTPS. I don’t know where this idea popped up that browsers only know about HTTPS and don’t care for or don’t handle TLS. They actually care so much about TLS that they can warn users about deprecated versions of TLS (like TLS 1.0) used by websites and also push web servers and server operators to plan and move to TLS 1.2.

> Google can’t use DNS-over-TLS in their browser because they can’t modify the code on Windows or MacOS operating systems (which only support DoT at the moment) in order to encrypt DNS requests done outside of the browser. And that works for Google and Firefox, because they only need to encrypt DNS requests inside of their browsers.

The latter part is true, that browsers care primarily about their web related DNS requests, but the former part is a big misunderstanding. They could’ve adopted DoT within the browser, but they chose not to for a few reasons that are explained in their FAQs. I’ve seen at least Firefox’s FAQ on why Mozilla chose DoH and not DoT, and that has nothing to do with OS support.

> Meanwhile at DNSFilter, we need to operate DNS encryption not just in the browser, but at the operating system level. That’s why we use DNS-over-TLS:

Well, there are others who provide DoH (yes, DNS Over HTTPS) at the OS level. NextDNS is one example.

Why does it show that DNS-over-HTTPS is app layer?

Isn't HTTPS HTTP-over-TLS? (transport layer)

Therefore DNS-over-HTTPS is (DNS-over-HTTP)-over-TLS? (transport layer)

HTTP and DNS are all app layer. In fact, so is TLS but is sometimes said to belong to a session layer between the app and transport layer (there is no session layer in the internet protocols suite, this is an OSI layer: TLS is session layer in OSI, application layer in TCP/IP).

I agree, I upvoted it because it's better technically than some of the others I've seen recently. But having DNS and HTTP conceptually jammed sideways into the networking stack makes my head hurt. You're also correct about this: DoT and HTTPS both use TLS (you can use nginx to terminate TLS in front of a DNS server and feed it TCP, just like you can put it in front of a web server).

> > DNS-over-HTTPS isn’t used by Firefox and Google because it’s superior to DoT. It’s used because browsers operate at the HTTPS layer by default, so DNS-over-TLS doesn’t make sense (as things stand now) for a browser to implement.

> Umm, browsers need to handle TLS in order to support HTTPS. I don’t know where this idea popped up that browsers only know about HTTPS and don’t care for or don’t handle TLS.

The author didn't refer to TLS, they referred to HTTPS which is HTTP+(TLS|SSL). The TLS part is common to both DNS-over-HTTPS and DNS-over-TLS. Browsers speak HTTP natively, but they don't speak the DNS protocol. That's the argument the author of the article is making.

Do we really want to give more control to google over DNS, not just on the internet but now your home network too? Google Home being a perfect example where they build a product assuming they have free reign over your home network, leaving it broken if you try and get in the way.

Just the other day, and many times before, there were articles and commenters on here complaining about Google's uncompetitive behaviours relating to established email procotols and the standards for blacklisting offending domains.

It seems the same disincentives to behave responsibly by default will be at play in the DNS/DoH situation as the self-hosted email situation except now they have free reign inside your network.

IMO DoH is slithy better since it can more easily traverse proxies, NATs, firewalls.

HTTP and HTTPS are probably the only two well implemented protocols that are universally supported among all routers, proxies, firewalls including the very cheap routes that we often find out there.

Interesting that "slithy" passes spellcheck but "toves" doesn't.

I don't know, I'd say that's precisely the reason DoH isn't so great - because it bypasses proxies, NATs, firewalls.

If you're the admin that needs to configure DNS a certain way for any reason (corporate policies, parental controls, intranet configurations, malware protection) then having the user be able to work around by default is a massive pain.

DoH seems like a great idea at first, until you're in a situation when it's not, and then it gets messy, because it's a moving target and everything has different workarounds.

If you’re the admin that needs to configure DNS a certain way, you need to do it by controlling and modifying endpoints. Otherwise, even if you implement network-level DoT, a user can defeat your controls by running DoH on their own, or by just adding an /etc/hosts file.

Author and CTO of DNSFilter here; for any questions.

I'm unable to understand from your documentation how your "roaming client" works, or if it is applicable to desktop systems for example. Are you replacing the stub resolver?

Correct. We have agents for desktops (Windows, MacOS, Linux) as well as Mobile (Android, iOS) We basically run a service that listens for dns requests on port 53 loop back IP, and then we change system DNS to point to that loopback IP.

Now we can do a bunch of things with the traffic between your machine and us: like inject edns0 data to authenticate requests, shift traffic between our anycast networks, and encrypt you’re traffic using DNS over TLS!

I'm trying to use DoT at home to protect my privacy and I'm using my own resolver hosted externally. The external resolver is Unbound 1.9 and my LAN resolver is Unbound 1.7.

With this combo random domains will fail a DS lookup even though they don't have DNSSEC. Causing them to fail the query from my home LAN. So direct queries to the external resolver always work, with or without dnssec. But internally on my LAN I get a failed query for some domains, seemingly at random.

I've seen one other post on the Cloudflare boards with someone having the exact same issue, otherwise nothing. And no replies on that post.

Only way to get rid of the intermittent issue is to disable upstream TLS.

Really sucks, anyone know more about this? My idea was maybe to run 1.9 in my LAN using containers, just to match up versions and exclude any such issues.

Random sites won't load for me like Netflix for some reason. It works with my wired connection for some odd reason though.

DoT is easier for network admins to block. I prefer it, but that is a downside to DoT IMPO.

as I network administrator, I prefer it for that reason :)

DoH has caused several problems for enterprise networks and will likely continue to as I do not want nor desire my endpoints to be getting their DNS from CloudFlare, they need to use my servers that I configured at the network level

I should not have to manage and apply group policies for every browser so DNS works like expected

Theoretically, it’s true that DoT can be easily blocked by the network through port blocking and that blocking DoH is a lot more difficult because it’s over the same port (443) as web traffic.

But in reality, the main browser makers embracing DoH have provided very easy mechanisms for network operators to tell browsers not to use DoH. So it’s not like DoH, at least as implemented by the main browsers, is against enterprises and network management.

I don't really agree here. It's much harder to implement different mechanisms for each browser individually, and now that it's coming on the OS level (iOS 14, MacOS 11, Windows 10), there'll be a whole new set of ways to disable it.

Firefox's canary domain method is a bit clunky but at least it can be set up at the DNS server level.

I prefer DoT because I already supply DNS to all the machines in my network; I have a dozen upstream DoT resolvers that happily do the transcoding, and I still get to run internal domains.

ODNS (Oblivious DNS) is another one: https://odns.cs.princeton.edu/

Still in the “academic research” phase, but it looks promising.

No, they are not doing dns over https because they can’t do raw tls (wtf?).

The reason for dns over https is that it doesn’t look different from any other https traffic so can’t be blocked to force use of the ISPs monetizing dns.

It should be plainly obvious to anyone that application level software is able to perform raw tls connections.

This isn’t a DoT is better/worse than DoH comment, it’s merely saying that the states reason for chrome and Firefox doing DoH is blatantly wrong, and the rest of the argument is predicated on that incorrect reason.

Obligatory post when this comes up of a presentation by Paul Vixie, who was responsible for BIND from 1989 to 1999 and very involved in forming dns protocols since then.

Paul Vixie talks about DNS over HTTPS (EuroBSDCon, Oct 27, 2019) https://www.youtube.com/watch?v=ZxTdEEuyxHU

The way he approaches this I think is fundamentally correct, it is both a technical and political subject.

Paul Vixie is deeply wrong about DoH, and the logic he uses to describe the control he demands over his local network (which he runs with apparently the same rigor that Allstate runs their corp net) isn't coherent: he's required to concede that he doesn't have control over all his machines (else he could just do what serious security teams do and manage his machines centrally, and wouldn't have control problems with DoH), but he's giving them all access to his network anyways (else DoH wouldn't matter to begin with).

Consider carefully why you think his approach is fundamentally correct. His talk opens with multiple slides talking about how improved performance is relevant only for serving advertisements. That's an alarming thing for an influential standards person to say out loud.

Reply on news.ycombinator.com