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.
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 ?