An increasing number of them also rely on hard coded DoH servers which is harder to block/redirect. You will need to will Pi-Hole/Adguard Home on router to block them based on some curtailed lists (i.e [1])
In this arms race you are saying a current "move" is a curated list of IPs that correspond to known DoH servers ... and that's fine ..
However, if the adversary decides to just query - and answer - DoH requests on the same hostname that you are trying to talk to ... isn't that a winning move ?
For instance:
If one had an application - or an appliance - that spoke https to endpoint.samsung.com, how would one block DoH requests addressed to the same endpoint.samsung.com ?
That might work but if your Samsung example is behind cloudflare, you're basically going to have to block any and all access to cloudflare's Network.
And if telemetry.example-iot.com belongs to an AWS IP, it could change to another IP in their space at any time so your only recourse would be to limit connectivity to all of AWS which would effectively prevent you from accessing most things on the internet
If you're really serious about DNS interception, you'd setup something where
a) you stop accepting A lookups, because it's 2025 and IPv4 only is dead (let's pretend anyway)
b) for each AAAA lookup, return a new IPv6 address that you'll NAT to the real address (you can use this for NAT64 if you want to let clients connect to IPv4 hosts). Then only let clients connect to these IPv6 addresses you setup.
If someone smuggles address resolution through, outside of DNS, their clients can't connect.
(this is going to be a big PITA, but that's how these things go)
> for each AAAA lookup, return a new IPv6 address that you'll NAT to the real address (you can use this for NAT64 if you want to let clients connect to IPv4 hosts)
We employ exactly this technique for our Android firewall app. It can do IPv4 (by mapping hash(domain) name onto RFC6598 reserved subnet [0]) as number of unique AAAA/A requests on a client seldom exceeds 35k/mo!
Another (simpler) control we offer users is, to drop all connections made to IPs that the user-set resolver did not do name resolution for.
> (this is going to be a big PITA, but that's how these things go)
> Another (simpler) control we offer users is, to drop all connections made to IPs that the user-set resolver did not do name resolution for.
This sounds good, and I've wondered how I could implement such a thing.
However, with the clearly hostile approach all IoT appliances are taking, I wonder if they'll actually fall back to a "degraded" (for them) config with the network-provided DNS, or whether they'll just fail and complain the network is broken or something.
I run Zenarmor in addition to Adguard at home, which can detect DoH traffic and intercept it. You have to pay for this enterprise level tool, but if you are worried about DoH, Zenarmor is so far the easiest tool to block it.
In our house the only device that tries to use DoH is my partner's iPhone. It tries a few times, fails, then uses the Adguard DNS, which blocks the trackers.
And before DoH was a thing, several Chinese apps I've used also used to do plain HTTP for DNS resolution (I only caught them by chanbecause they were doing HTTP). PiHoles only work for apps that stick to the standards and don't mind being caught.
I use these settings on all my browsers to prevent DoH and make sure traffic goes through my Pi (I run unbound directly on the Pi though, not Pi-Hole: in my experience unbound is a bit harder to set up initially but it's also more powerful than Pi-Hole... For example unbound accepts wildcards in blocklists).
It's not incompatible with also blocking, at the firewall level, all known DoH servers of course.
Nor is it incompatible with forcing your router to also use your Pi as a DNS.
[1] https://github.com/dibdot/DoH-IP-blocklists