This is a great summary of common misconceptions, nicely done!
If you want to test your own connection for this sort of interference, you can run OONI: https://ooni.org/install/. The project is building more capabilities, like improved middlebox detection, which should make it easier to identify who exactly is tampering with your network.
I'm currently using the platform to assess tampering in the email ecosystem (MTA-STS censorship) and I'm looking for volunteers to run a custom test list I maintain to detect tampering in the wild: https://run.ooni.org/v2/10371.
I hate that DNS, as a technology, is so frigged up. Off the top of my head:
As this article states, UDP DNS interception/rewriting is trivial. You don't even necessarily have to be a MitM if you have any visibility into the network, because UDP.
DNS is supposed to be scalable and redundant, but in practice, well, there's a reason why, "It's always DNS" is a meme among tech engineers. If DNS is not working perfectly on your network, you will find out about it in the most annoying ways possible.
DNSSEC is a good idea, but is complex, has poor adoption, and either goes too far or not far enough in terms of security, depending on who you talk to.
DoT seems like a good idea on paper, but it allows software (trusted AND malware!) to subvert local network security controls.
DoH has the same concern, but also requires clients to incorporate a whole full-featured HTTP stack.
Even tech people tend to have a poor understanding of how DNS actually works. I still hear people to this day say "DNS record propagation" as if that is a real thing.
plain UDP DNS is bad, because it can be easily intercepted by the local ISP (who is evil and implements censorship)
DoT/DoH is bad, because it cannot be easily intercepted by the local ISP (who is good and implements security controls)
I don't think it's possible to reconcile these two problems – you fix one, you break the other. I feel that current state of things isn't such a bad balance: your ISP can mess with your traffic (as they can mess with all traffic; if they couldn't rewrite DNS responses, they could simply route traffic to the resulting IP to their own box), but you as a LAN administrator can mess with it too. There's a hobby forum that has blocked access from my entire country – I can configure my home network's DNS to point it at a tun2proxy instance connected to a VPN.
If a service needs tamper resistance, it can be provided on the transport layer, which will protect not just from DNS tampering, but also from tampering on a routing level or (to some degree) OS level. TLS/https certificates provide a minimal level of protection here, most ISPs can't easily mint certs for any domain; depending on your threat model, you can add more mechanisms on top of that, all the way to mutually authenticated end–to–end encryption.
DNS is so complex because name resolution is a complex problem: it has to work on all levels, from localhost and VMs running on one physical host, through LAN and local services, intranet level, to worldwide Internet. If it malfunctions, everything breaks ("It's always DNS"). If it's slow, it slows everything down – hence multiple layers of caching. As we all know, "there are only two hard things in Computer Science: cache invalidation and naming things" – DNS is both.
I'd say DoH is what specifically subverts security protocols since DoT on port 853 is trivial to block and most clients are identifiable through the ALPN on the TLS handshake regardless
OP says they self-host unbound, but this still happened, then discusses why everything local isn't using self-hosted DNS. It's not clear whether self-hosted unbound resolved to the ISP's IP. If not, there's the solution there. If you're worried about your containers and whatever else not getting DNS, then it's a good opportunity to set up something more resilient.
If unbound was tricked in to also giving incorrect answers in spite of being a fully recursive resolver, then the ISP needs to be outed, the methods need to be examined, and a much bigger deal should be made about this.
I feel like I cleared that up in the first paragraph. But if not, YES, they tamper with that traffic too. They monitor and tamper with all DNS traffic over port 53.
I found that my ISP (Virgin Media in the UK) was tampering with port 53, blocked DoT entirely, and block DoH to some (not all) well known servers. It took me a while to work around this - also with unbound.
Mostly this doesn't bother me because at work I use a vpn; but that has drawbacks too. Recently I figured out why firefox would often fail to connect to our vercel sites, when chrome worked. It turned out that firefox will try to use DoH via mozilla/cloudflare's default server, making a TYPE65 request that returns (among other things) 'alpn=h3'. That causes firefox to try to use QUIC to reach vercel...which the vpn blocks!
It works when DoH is off, because then firefox uses a "happy eyeballs" approach, making both the http/2 and http/3 requests and just using the first response (always /2 because QUIC was blocked). I couldn't test exactly what was doing this off vpn because... Virgin were blocking DoH as above, so firefox always used the fallback behaviour and managed to connect.
Wow, this is just fucked up!! Have you tried tunneling your DNS traffic through WireGuard to a relay server and having that relay forward the queries to your DNS resolver? That should work around work but this is wild.
no, after looking around a bit I found a DoH server they hadn't blocked, set up a pihole with unbound as my dns server, and everything worked for me just fine (and not saying which, in case they read this. It wasn't that hard to find one). Or, I just use a vpn.
I wouldn't have spotted it but when I accessed some low TTL sites off vpn they didn't resolve, tho I could switch to my phone hotspot and everything worked. A plausible, and forgivable, reason for that would be caching - but then blocking DoT made it inexcusable.
I use Anonymized DNSCrypt, which works in a similar way to ODoH. I'm a little skeptical of ODoH, though. It was started by multi-billion-dollar companies like Apple and Cloudflare, and the privacy policies of some relay providers, like Surf, makes me more skeptical about it.
robalex | 21 hours ago
This is a great summary of common misconceptions, nicely done!
If you want to test your own connection for this sort of interference, you can run OONI: https://ooni.org/install/. The project is building more capabilities, like improved middlebox detection, which should make it easier to identify who exactly is tampering with your network.
I'm currently using the platform to assess tampering in the email ecosystem (MTA-STS censorship) and I'm looking for volunteers to run a custom test list I maintain to detect tampering in the wild: https://run.ooni.org/v2/10371.
Edit: thanks for running the test list! Anomalies are getting reported here: https://explorer.ooni.org/search?since=2026-10-28&until=2026-11-30&failure=false&ooni_run_link_id=10371&only=anomalies
bityard | 17 hours ago
I hate that DNS, as a technology, is so frigged up. Off the top of my head:
I could go on...
Psentee | 2 hours ago
Generalizing a bit, one could say that:
I don't think it's possible to reconcile these two problems – you fix one, you break the other. I feel that current state of things isn't such a bad balance: your ISP can mess with your traffic (as they can mess with all traffic; if they couldn't rewrite DNS responses, they could simply route traffic to the resulting IP to their own box), but you as a LAN administrator can mess with it too. There's a hobby forum that has blocked access from my entire country – I can configure my home network's DNS to point it at a tun2proxy instance connected to a VPN.
If a service needs tamper resistance, it can be provided on the transport layer, which will protect not just from DNS tampering, but also from tampering on a routing level or (to some degree) OS level. TLS/https certificates provide a minimal level of protection here, most ISPs can't easily mint certs for any domain; depending on your threat model, you can add more mechanisms on top of that, all the way to mutually authenticated end–to–end encryption.
DNS is so complex because name resolution is a complex problem: it has to work on all levels, from localhost and VMs running on one physical host, through LAN and local services, intranet level, to worldwide Internet. If it malfunctions, everything breaks ("It's always DNS"). If it's slow, it slows everything down – hence multiple layers of caching. As we all know, "there are only two hard things in Computer Science: cache invalidation and naming things" – DNS is both.
It's amazing that it works at all.
xetera | 10 hours ago
I'd say DoH is what specifically subverts security protocols since DoT on port 853 is trivial to block and most clients are identifiable through the ALPN on the TLS handshake regardless
johnklos | 19 hours ago
OP says they self-host unbound, but this still happened, then discusses why everything local isn't using self-hosted DNS. It's not clear whether self-hosted unbound resolved to the ISP's IP. If not, there's the solution there. If you're worried about your containers and whatever else not getting DNS, then it's a good opportunity to set up something more resilient.
If unbound was tricked in to also giving incorrect answers in spite of being a fully recursive resolver, then the ISP needs to be outed, the methods need to be examined, and a much bigger deal should be made about this.
[OP] dracarys_18 | 19 hours ago
I feel like I cleared that up in the first paragraph. But if not, YES, they tamper with that traffic too. They monitor and tamper with all DNS traffic over port 53.
bazzargh | 18 hours ago
I found that my ISP (Virgin Media in the UK) was tampering with port 53, blocked DoT entirely, and block DoH to some (not all) well known servers. It took me a while to work around this - also with unbound.
Mostly this doesn't bother me because at work I use a vpn; but that has drawbacks too. Recently I figured out why firefox would often fail to connect to our vercel sites, when chrome worked. It turned out that firefox will try to use DoH via mozilla/cloudflare's default server, making a TYPE65 request that returns (among other things) 'alpn=h3'. That causes firefox to try to use QUIC to reach vercel...which the vpn blocks!
It works when DoH is off, because then firefox uses a "happy eyeballs" approach, making both the http/2 and http/3 requests and just using the first response (always /2 because QUIC was blocked). I couldn't test exactly what was doing this off vpn because... Virgin were blocking DoH as above, so firefox always used the fallback behaviour and managed to connect.
[OP] dracarys_18 | 17 hours ago
Wow, this is just fucked up!! Have you tried tunneling your DNS traffic through WireGuard to a relay server and having that relay forward the queries to your DNS resolver? That should work around work but this is wild.
bazzargh | 12 hours ago
no, after looking around a bit I found a DoH server they hadn't blocked, set up a pihole with unbound as my dns server, and everything worked for me just fine (and not saying which, in case they read this. It wasn't that hard to find one). Or, I just use a vpn.
I wouldn't have spotted it but when I accessed some low TTL sites off vpn they didn't resolve, tho I could switch to my phone hotspot and everything worked. A plausible, and forgivable, reason for that would be caching - but then blocking DoT made it inexcusable.
riking | 8 hours ago
Overly restrictive work VPNs strike again. Should just allow UDP 443.
vpr | 7 hours ago
Not a single mention of ODoH [RFC 9230]?
I've been using it with dnscrypt-proxy on most boxes without any trouble for years.
[OP] dracarys_18 | 6 hours ago
I use Anonymized DNSCrypt, which works in a similar way to ODoH. I'm a little skeptical of ODoH, though. It was started by multi-billion-dollar companies like Apple and Cloudflare, and the privacy policies of some relay providers, like Surf, makes me more skeptical about it.
rfmoz | 4 hours ago
I've seen different behavior inside the same ISP between IPv6 and IPv4. It seems that they deploy their "solutions" only in one side.