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.
DoH and DoT both hide DNS requests from the sysadmins. If the sysadmins want to capture DNS for some reason, they can just provision their own DoH server (I do that with my Pihole) or disable the feature all together with a simple canary domain (https://support.mozilla.org/en-US/kb/configuring-networks-di...) in the local DNS resolver.
Although I hate the idea that everything must now be layered on top of HTTPS because shitty middleboxes can't deal with internet protocols, I think Oblivious DOH is superior to simple DoT. It not only provides security, but also anonymity in DNS requests. I'm not sure if that's what Firefox actually implements by default, though.
Chromecast doesn't respect any settings and only communicates over TLS (and some local broadcast protocols for compatibility). If you don't like that, don't buy a Chromecast.
I've managed to get it to use my PiHole by forwarding all outbound traffic to UDP/53 that's not coming from my PiHole to the PiHole itself through a DNAT rule in Firehol:
ipv4 dnat to "${pihole4}" proto udp dport 53 src not "${pihole4}" dst not "${pihole4}" inface not "${world}"
ipv6 dnat to "${pihole6}" proto udp dport 53 src not "${pihole6}" dst not "${pihole6}" inface not "${world}"
So far, I haven't seen any weird traffic that's trying to bypass this rule, but honestly, I don't really care. Whenever I block any of its domains I just get weird error messages about connectivity problems, or a non-working Chromecast. The real meat is inside the TLS connection anyway, and I can't block that.
You can't buy a closed-source, always-online Google product and expect it to let you block it. If I wanted that, I would've disconnected it from the internet or just used a Kodi box instead. We've lost to ability to introspect and filter connections the moment we started switching to TLS. If you don't trust a device, don't install it in your network, that's my take.
The chromecast is proprietary anti user software/hardware. Stallman has been warning about this for decades. DoH has very little to do with this. The Chromecast could hardcode the Google dns server already.
> The Chromecast could hardcode the Google dns server already.
Could nothing; Chromecasts have always hardcoded Google DNS AFAIK. This is a right pain when you want them to stream something from an internal site that has a perfectly good DNS entry but not a public DNS record, and we ended up casting things that used raw IPs because of it. I've also seen some people end up having their router rewrite packets from 8.8.8.8 to their own DNS, but that might actually be more icky IMO.
> I've also seen some people end up having their router rewrite packets from 8.8.8.8 to their own DNS, but that might actually be more icky IMO.
It is actually very simple, just dst-nat everything destined for any ip, 53/udp, 53/tcp, to your resolver, except traffic originated by the resolver itself. Works very well.
> The Chromecast could hardcode the Google dns server already.
This wouldn't work, because routers/firewalls can easily rewrite the destination of insecure DNS queries. But what it could do is to hardcode all of the IPs of the servers it really wanted to talk to, instead of using DNS at all.
It doesn't need to use DNS at all. As long as it can rendezvous through some IP, it can just tunnel all of it's discovery stuff through TLS, or anything else it wants. This is a particularly silly cat-and-mouse game that network pentesters have been winning for decades; it's only because DNS people had a strange heyday as botnet hunters, and botnet authors are really dumb, that this folk wisdom about the importance of DNS policy set in so firmly.
Which is a big downside of DoT and reason to prefer DoH. The people that have an easier time blocking DoT are the very people who are the reason that you'd want to use it in the first place.
This is sort of like claiming that the spread of encryption is bad and dangerous because it provides tools to terrorists. The problem with the claim is that even if every person or organization producing end-user software stopped developing or supporting DoH, the cat is fully out of the bag. It's just technology at the end of the day, and any company making hardware that wants to hide their DNS requests is completely able to do so already. Some are even building VPNs into their IOT devices. This can't be stopped; ending development on uses of the technology that do benefit the end user is not just pointless but actively a bad idea.
There's also a weird conflation that happens between the claim that DoH is "anti-user" and that DoH is "anti-sysadmin". These are two completely different things. If you're a sysadmin who wants to provide a useful DNS service with some additional features on your domain / network, DoH makes it harder for you to do that. I fully agree with this point, and in fact it's a pain point for me because I run Unbound on my router myself! However, this is completely different from the claim that it's "anti-user". Most people do not have friendly local competent admins setting up DNS for them. Those who do are given the choice to opt out of DoH by changing their settings in e.g. Firefox. For other users, DoH is a massive security win. It absolutely makes sense for it to be the default. Anti-admin != anti-user.
The hacker news hysteria over DoH is quite absurd and disappointing. Seeing comments massively exaggerate to downright lie about the situation because they are angry their pihole setup no longer works.
Imo Firefox is representing the users best interests here. The router, and ISP dns servers can not be trusted. The user wants their browsing session to be as private as possible. Cutting out one more source of data leakage is what the user wants.
DoH gives us two things as end users in our homes:
* Privacy from the router and ISP, which is good, and the reason you should use it on your personal computing devices (PC, laptop, phone, RPi, whatever)
* The inability to inspect/redirect/selectively block traffic from anti-user devices we own (Samsung spyware TVs/Chromecasts/Smart ovens/Smart vacuums)
That being said, while I generally trust Cloudflare, it's not the optimal provider for me, and I don't like a random american company being hoisted on me.
Go ahead and give us evidence about how Cloudflare can be trusted. At least we have legally binding contracts with our ISPs.
Also, are you trying to suggest that people who know enough to run Piholes don't know enough to run their own DNS servers (or at least select good ones) and their own routers? That's pretty rich.
> Also, are you trying to suggest that people who know enough to run Piholes don't know enough to run their own DNS servers (or at least select good ones) and their own routers?
If your upstream network is trying to censor or surveil you, you can't run your own DNS server, because it will intercept your queries to the root servers.
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.
Sadly Google Assistant does need to use the DNS setup because I play local media for announcements on it and every time the DNS is broken it stops working and doesn't play any local media anymore. Basically home assistant media player plays a mp3 which is stored on the raspberry pi on the Google Assistant, for example when someone opens the out door it plays a chime on all Google Assistants in the whole house so that my parents know that someone opened the door downstairs. The url will be https://myparentshouse.duckdns.org/local/open-door.mp3 so if the Google Assistant doesn't use the local DNS it can't resolve the domain to the local raspberry pi, and instead resolves it to the public IP address which then without the Loopback NAT doesn't go anywhere.
I understand that I should then instead of using Google Assistant for that to use something else, but I haven't found any free hardware which would have the functionality of good microphones and working speech to text yet.
In that case I'd find a way to put the file universally accessible on the internet somehow (the proxies I mentioned, or IPv6, through HE Tunnelbroker if necessary, or on a random HTTP host you might control?). Debugging split DNS issues can take hours and luckily there are free and cheap tools to avoid this mess! They require some setup, but in my opinion the lack of maintenance they require is much easier to live with than the split-DNS-mess.
I haven't seen much evidence of Google hardware actually using DoH, but they will definitely use 8.8.8.8. If your router has the ability, you could try forcing traffic intended towards 8.8.8.8:53/udp to your router's DNS server.
Organizations that use split-horizon DNS should just add their own domain to network.trr.excluded-domains via enterprise policies rather than disabling DoH completely.
Software that does its own resolution will not run on my network, and we have banned it by policy at work. Of course it becomes another game of whack-a-mole.
My house, my rules; you don't get to subvert my network security and continue to use my network.
That's a perfectly acceptable policy to have, but you'll have to check and monitor that policy like you always have. You can add an A/AAAA record for use-application-dns.net and Firefox won't turn on DoH on your network unless the user overrides it. Chrome's DoH model will use your existing DNS server: if it supports DoH, Chrome switches to DoH, otherwise it'll stick to normal DNS.
Do note that malware and even legitimate software (some Android apps, some Windows applications) have been using HTTP(S) based domain lookups for years, though, years before DoH was even proposed. I've used free HTTP proxies over fifteen years ago to bypass school filters, for one, and that's without any infrastructure of my own!
You'll have to configure an intercepting proxy to exclusively allow traffic through if you want to catch problematic software in the act, and add some pretty sophisticated filtering. With the modern take on inserting your own certificate authority (certificate pinning, unrooted Android, NodeJS, etc. all avoiding your user certificate store) you'll have to go through great lengths to get that working, though.
Truth be told, DNS was never really much of a security measure if you don't have control over what applications do or do not use it.
So far, Firefox is the only browser that has announced support for this. Chrome takes another approach, which is to test the system DNS server for DoH capabilities and to switch to DoH when the resolver supports it. Chrome does have a fallback to Google's DNS if it determines that your DNS server is broken, but you should be able to disable that. That means you can secure your network by picking an existing DNS server that also provides a DoH server and Chrome should pick it up by default!
I believe Microsoft announced a similar approach to Google, but from what I can find you still need to enable DoH manually anyway.
In all cases, the end user can override your domain settings unless your group policies (or similar) lock these settings.
That's the Firefox approach, yes: provide a list of trusted DoH servers and use that to avoid scummy ISP servers that might monitor, intercept, or mess with DNS records.
Chrome has a separate list of DNS servers that it knows can also do DoH. It doesn't change the DNS server, it just changes the mechanism in which the server is queried:
I believe their intent was to auto upgrade existing all DNS servers if they support DoH, but I'm not so sure anymore; perhaps some other product was doing that instead. In theory it shouldn't be too difficult: send a TLS request to dns.server:443, extract the hostname from the TLS handshake, and do a lookup through https://hostname/dns-query (with the IP address hardcoded for the socket to prevent redirect attacks).
Yes, it shouldn't be difficult, but if Chrome isn't doing it, my point is that that would put DNS servers not on that internal list, such as Pi-hole, at a disadvantage.
> I've used free HTTP proxies over fifteen years ago to bypass school filters, for one, and that's without any infrastructure of my own!
I did the same, back in the early-mid 2000s. My favourite were the ones that used ROT13 to get around school filtering of domain names (and banned words in them). Was very cute.
Of course not. That's why you can disable DoH on the software you install, and have the choice (in the EU) to return a product you bought online within 14 days if it doesn't live up to your expectations, or not buy the product at all.
However, it should be clear that we're not ceding control, per se, as we have never had control over these closed source devices in the first place! We should instead be working to gain control over our devices through open source efforts so that we can control what our hardware can and cannot do.
For what it's worth, there is a thread on XDA about customising Chromecast firmware that should allow you to hack the device to disable any unwanted behaviour, but I can't say if that method still works.
Right, and the feature is not designed for you. It's designed for the billions of users who are not on your network, and are sitting in their own home or in a coffee shop where there is no such security policy or skilled network administrator in sight.
Aside: If you are using Firefox in an enterprise environment, you should be locking the settings to begin with. If I remember correctly, the Firefox ESR downloads don't even prompt about enabling DoH.
This is simple: people like you are best served by a policy that manages this kind of policy at the system or network layer. But most people aren't. For most people, the managers of their networks are adversaries. Firefox should, by default, serve most people --- not just nerds like us with strong opinions about the "system resolver".
There is no moral authority to the system resolver. It's a convenience, not a contract.
You should not get to censor people's view of the Internet just because you're providing the connection, just like the gas/electric company doesn't get to decide what you can and can't cook on your stove even though they provide the energy it uses to work.
And if you really only mean your own devices, then enforce your policy on the endpoints instead.
Yes and no. The problem is different - the problem is application vs OS DNS resolvers.
It's not an application job to be a DNS client, this is what actually subverts system administrator policies. Just as if some application has a hardcoded DNS (over UDP) address, but worse because there's encryption and authentication involved, so the system administrator cannot enforce the policy (sans patching the binary or hooking it at runtime).
But if DNS over HTTPS is implemented at the system resolver level there is no issue (and the actual transport doesn't matter).
> DNS over HTTPS is a trojan horse to allow application developers to subvert the system administrator's DNS policy.
No, it's a very important tool to help users bypass censorship and surveillance performed by hostile network operators.
> 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).
They don't need DoH to do this. They can do this by either hardcoding the IPs of their ad servers, or by serving their ads from the same hosts as the content you want.
> This is dangerous, anti-user, and should be avoided at all costs.
No, it's very pro-user and should be used at all costs.
> DNS over TLS is the correct and appropriate solution here.
No, because that's too easy for the aforementioned hostile network operators to block.
This is a misfeature that needs to go away. Thankfully, Firefox has an override that lets you manually enable DoH even if a hostile network operator configures that.
> but let's be clear here, nobody besides Firefox is going to respect user choice about using DoH.
Correct, but not in the way you meant. Most operating systems and programs will never use DoH even if the user does want it.
I'm running https://crates.io/crates/doh-proxy on my Pihole for DoH access (with an nginx frontend for TLS, though that's not necessary of course). You can just plug it into Firefox and it'll work.
With nginx in front you can put a stream {} block to proxy pi.hole:853/tcp to pi.hole:53 to enable DoT at the same time:
This setup worked great for me with Android, though it doesn't log the requesting device separately anymore (which is why I switched to a DNS server over a WireGuard VPN instead).
Doesn't this only give you DoH and DoT on the local half of the connection? Don't you need to also using cloudflared or unbound to send the remote half over DoH (which is where basically all of the security and privacy benefit comes from) as well?
You're right, but I made the assumption that people want to play around with DNS resolution.
For even better privacy, you'll need something like dnscrypt or enable DoH in your local bind/unbound/knot/powerdns server. Preferably ODoH to have complete privacy, but I don't know how commonly that's implemented yet.
It's not exactly difficult to block 8.8.8.8:443 and 1.1.1.1:443 if ISPs want to block it. There's also no technical reason why DoT should use port 853 even if it's the default; using 443 will work with most clients I've tested, although shitty middleboxes might get confused about the protocol not being HTTPS.
Strange. Those networks must be using a protocol whitelist or something. Luckily, I haven't encountered any networks that will drop 853/tcp outright. All I have is anecdata, but I can't ignore that I haven't seen any reliable statistics about this topic at all. I suspect some businesses or sketchy ISPs will likely block any type of traffic that isn't either DNS or HTTP(S), I haven't seen anyone else use DoT, let alone seen any network care about it.
If I were to encounter such networks regularly (and would not have the option to change network provider), I'd probably switch the DoT port around to 443 or just go directly for DoH.
The idea is that eventually ECH will roll out, and then Google and Cloudflare can start offering this from the same IPs that they do the rest of their services, which there will be way too much collateral damage for the censors to block.
State-level censors will at first ask nicely to block specific entries for their ip ranges; either the provider cooperates (then DoH won't help at all) or not.
If not, they won't have problem blocking entirety of Google or Cloudflare, collateral damage be damned. It would be as much Google's or Cloudflare's problem as it would be user's, so they won't do it. They don't allow domain fronting either.
This is one of my concerns with DoQ (DNS-over-QUIC). Currently DoQ is designated to be on port 853, like DoT, but DoH is great because it's not easily distinguished from other traffic on 443. But, DoQ is a much better protocol so I hope that there is a resolution here, which I'm guessing will be the same as HTTP/3, so we'll see. Maybe in the end it will be the same as DoH.
The DoQ RFC is working on and explicitly setting aside provisions for automatic discovery of alternative ports for the port 443 "blend-in" use case. The designated port is just there for having a standard number to use when admins don't want to have to multiplex everything over UDP 443.
I don't know for sure how the Fx stack presently behaves, but I would expect that eventually it would do DoH/3 if the server provided the appropriate indications (e.g., Alt-Svc).
DNS over HTTPS is useful tool that gives users agency instead of being subjected to the system administrator's DNS policy. It means that in many cases I don't need to use Tor or a VPN to get around network blocks, except on networks with Fortinet. Fortinet even tries to block Tor, but I made a little tool[1] that tunnels BridgeDB requests over docs.google.com so I don't need to worry about that anymore.
As a user it's pretty easy to ignore the DNS settings in DHCP and use whatever you want. An aggressive network admin can identify packets headed to outbound 53 on tcp/udp and block them (or reroute them to the preferred DNS) but they could also block known DoH endpoints. As soon as enterprises realize that DoH is happening, they will definitely do that.
But sometimes you're on a device where you can run binaries but don't have admin access. Firefox lets you use a custom DoH server regardless of the DNS settings set by the admin.
If your admin has set up the necessary policies, you won't be able to configure a custom DoH server in Firefox either! That doesn't work for personal devices, of course, but DoH is explicitly not intended to work around system administrators' configuration.
I'm lucky in that my admins are VERY hands-off (I've had a local admin account for months now that they haven't noticed) so that wasn't an issue. Worst case scenario I could probably build or patch Firefox to ignore Group Policy.
For example, my school laptop had Cisco Umbrella forcing DNS connections to itself, but half the time it never responded. Firefox DoH still worked because it didn't rely on the system DNS setting, which needs admin perms to change. Eventually I fixed the problem entirely by escalating to admin with PrintNightmare and deleting Cisco Umbrella altogether.
If you know how to manage your DNS policy, you know how to turn off DoH or at least how to learn about it. Especially if you're an administrator. I may want to run my own DoH endpoint, which is very much pro-user in that case.
@denkmoon Thank you for speaking up. There are many things about DOH/DOT that many don’t understand. There are protocol issues, privacy issues, security issues. DNS over TLS should be the natural progression.
The reality is that DNS over TLS is a rarity and most users are stuck with poorly operated, unencrypted DNS servers both at work and at home. That's not secure and the lack of privacy is often intentional or even local policy. A lot of operators actually earn some money on the side selling data to advertisers. And they are also more than happy to give local authorities access to that data. Same in companies where your boss likes to know what his minions are looking at in their browsers. These issues are not hypothetical, they are real and the vast majority of users is exposed to this poor status quo.
DNS over HTTPS solves that problem right now by simply bypassing all those poorly configured DNS services. Nothing wrong with that. Why wait for something that might never happen and that is dependent on the cooperation of companies that are clearly not in a hurry to do so when you can go straight to a secure and private by default situation right now? If you have a nice trusted TLS DNS server, use it of course. If not, consider using DOH.
I recently had to figure out why my browser was so slow and then I realized I had not turned DNS over HTTPS on yet (new laptop) and all the DNS requests were taking hundreds of milliseconds. Enough for me to notice and be annoyed by it. That's how bad things are for real users right now. O2's DNS server is not great and they are definitely doing everything they legally can to monetize whatever happens on their servers. They probably also hand over server logs to anyone who asks nicely. So thanks, but no thanks.
So, I turned on DNS over HTTPS and problem solved. And I feel a lot better not broadcasting my browsing behavior to O2 and the various companies they sell my data to. And that's when I'm at home. I also use my laptop and phone in coffee shops, hotels, and via public wifi's, different operators in different countries, companies/customers I visit, etc. DNS over TLS is not an option there. DOH is.
What advantage do you see of DoT over DoH other than that it's easier to block at the network level? If you want to block other people's computers from using DoT or DoH, then you're the adversary that they're meant to protect us from.
>What advantage do you see of DoT over DoH other than that it's easier to block at the network level? If you want to block other people's computers from using DoT or DoH, then you're the adversary that they're meant to protect us from.
Not GP, but I don't want to block other people's computers. I'm only concerned with my computers. And when one of them gets uppity and tries to bypass the policies on my network, it needs to be smacked down. Hard.
As for anyone else's devices? Have at it. Do whatever you want. But my devices on my network will abide by my policies.
That may make you wonder if I'm going to try and steal your DNS requests. But don't worry, I won't invite you into my home.
> That may make you wonder if I'm going to try and steal your DNS requests. But don't worry, I won't invite you into my home.
The problem isn't guests using your house's network. The problem is that if there's a way for you to network-level block DoH at your own house, then nothing is stopping Comcast or China from implementing the same network-level block.
>The problem isn't guests using your house's network. The problem is that if there's a way for you to network-level block DoH at your own house, then nothing is stopping Comcast or China from implementing the same network-level block.
Fair enough.
But I'd posit that you can't prevent a bad actor who controls your network access from doing whatever the hell they please with/on your traffic, whether you use DoH or not[0].
Running a TLS termination proxy would break everything unless they convinced the users to accept their root certificate, so even the most evil ISPs generally don't do that.
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.