> 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.
> 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.
Isn't HTTPS HTTP-over-TLS? (transport layer)
Therefore DNS-over-HTTPS is (DNS-over-HTTP)-over-TLS? (transport layer)
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.
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.
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.
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!
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.
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.
Firefox's canary domain method is a bit clunky but at least it can be set up at the DNS server level.
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
Still in the “academic research” phase, but it looks promising.
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.
Paul Vixie talks about DNS over HTTPS (EuroBSDCon, Oct 27, 2019)
The way he approaches this I think is fundamentally correct, it is both a technical and political subject.
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.