DNS over HTTPS is a trojan horse to allow application developers to subvert the system administrator's DNS policy. Specifically, so that companies like Google, Microsoft, Amazon can ensure that you cannot prevent ads being displayed in their little black boxes (hardware or software).

This is dangerous, anti-user, and should be avoided at all costs.

DNS over TLS is the correct and appropriate solution here.

You can ensure your (Firefox) browser does not use DNS over HTTPS by configuring a canary domain: https://support.mozilla.org/en-US/kb/canary-domain-use-appli... but let's be clear here, nobody besides Firefox is going to respect user choice about using DoH.

This is FUD. This possibility has nothing to do with HTTP vs. [some other DNS-like protocol] sitting on top of an encrypted connection.

This possibility is, however, enabled by having the application package its own DNS resolution. It's unfortunate that more and more software is doing this with no way to opt out (Chromecast and Nintendo Switch are the worst offenders) -- but the way firefox does it, it is opt-out. I think it's a double edged sword; having in-application DNS as an option has an important advantage of subverting malware as well as public wifi networks configured for surveillance. In an ideal world, we don't have to "subvert malware", but we live in a world where a big chunk of users have some sort of malware installed or in their general proximity.

If you want to use DNS over HTTPS as a system-wide daemon, you can use DNSCrypt 2 (https://dnscrypt.info/ ) and disable DoH within Firefox/Chrome.

I have one specific problem but I'm not sure if this is connected. I have a home assistant on a raspberry pi at my parents house. From outside of the network there is no problem, they have a dynamic DNS pointing to their IP address and then port forwarding so that they can access the home assistant UI from the internet.

But they also need to access it from home when they're on the WiFi. Because their router doesn't do this NAT Loopback so that they need to access it via the IP address which is very cumbersome. What I did was that I set up a DNS server which would resolve the dynamic DNS domain to the raspberry pi and pointed the router to use this DNS server. This way they were able to use the same domain in and outside of the network.

I understand that Firefox falls back on the old way of DNS, but I have to assume that Chromecast and Google Assistant will not and therefor it will fail to play local media or show the home assistant UI?

Somehow this fucks up local networks and assumes everything is on the Internet, doesn't it?

In this case using an IPv6 address might work (if your ISPs aren't behind on rolling out IPv6). Alternatively you could tunnel the connection through something intended to break through problematic NAT setups like ngrok (or its alternatives: https://github.com/anderspitman/awesome-tunneling).

I've run a split horizon DNS configuration for years and I've got to say that it caused more problems for me than it solves.

Luckily, you can just turn off DoH if it causes problems for you.

In my experience, the Chromecast and Google Assistant functionality isn't related to your DNS setup. Chromecast should work through broadcast or through an active request from HASS itself, and the Google integration has always gone through the cloud as far as I know.

Perhaps your setup is different than mine, but I don't think these issues are necessarily DNS related, unless Google's servers are getting your local IP when they query for the HASS domain.