
DNS-over-TLS vs. DNS-over-HTTPS - serenadns
https://www.dnsfilter.com/blog/dns-over-tls/
======
AnonHP
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.

~~~
RyanGoosling
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)

~~~
mytailorisrich
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).

------
darwingr
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.

------
rafaelturk
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.

~~~
pgl
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.

~~~
akerl_
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.

------
LogicX
Author and CTO of DNSFilter here; for any questions.

~~~
m3047
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?

~~~
LogicX
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!

------
INTPenis
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.

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

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

~~~
AnonHP
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.

~~~
pgl
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.

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

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

------
olliej
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.

------
darwingr
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](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.

~~~
tptacek
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.

