Remember- there is no reason you can’t serve DoH from the www host (the web server).

So you won’t necessarily even get to play this cat and mouse game - the dns requests are indistinguishable from your web requests.

I guess you could mitm your own ssl traffic and strip out dns answers there?

But then … how soon until we see DoHoH?

> how soon until we see DoHoH?

DoH over Tor already exists, but more importantly, Oblivious DoH (kind of like DoHoH) is being standardized by the IETF: https://datatracker.ietf.org/doc/draft-pauly-dprive-obliviou...

Unless I understand incorrectly, this doesn't seem to make the problem any worse. You'd just have to block the proxy rather than the DNS server. Like DoH, only a problem if that's also the web server.

You're correct but you are viewing the comment out of context. GP said: "I guess you could mitm your own ssl traffic and strip out dns answers there?"

ODoH isn't going to be defeated by TLS MitM afaik.

In order for this to be true the device manufacturer would have to send both DNS and web requests through the proxy. They'd also have to "obliviously" encrypt web traffic as well. Otherwise, a MITM could determine which are DoH requests or determine which server is the proxy server and which are web requests.

This means that the DNS response for the web server would always be the proxy itself, or some set of proxies (and it would have to be the same IP for both wanted and unwanted traffic). What does DNS even add at that point? You'd be better off just making your "wanted" and "unwanted" servers the same server.

I believe there was a proposal for something like this a while back, before the DoH we see now. IIRC, the idea was that DNS information could be contained inside the web page, maybe enclosed in a tag. Addresses for ad servers perhaps.

Few of these ideas can be expected to work unless Evil, LLC controls the program the end user chooses to read the web. When an advertsing services company is also the majority share "web browser" vendor, then ideas like this become feasible. Whereas if web users can choose any client to access the web,[FN1] then these ideas would be non-starters. The open source text-only browser I am using is not going to read the IP address of an ad server embedded in a web page and connect to it automatically. Even if it did, I would simply edit the source code to disable that behaviour and re-compile.

1. In theory they can but in practice they generally don't.

Surely you can have firewall redirect rule that bounces all outgoing dns to your Pi hole?

This doesn’t work with DNS over https of course.

I can see people MITM their own https traffic in the near future!

Actually no. By blocking 53 at your router to anything except your pihole, even a hard-coded IP like 8888 is blocked.

You'd have to do packet inspection. Otherwise a hostile hardware manufacturer could just run their DNS on a non-standard port.

I guess if the relationship we have with our devices is full-on adversarial and yet still need them, they should be put on a dedicated subnet with a default deny rule in place.

I guess, at this point, the other commenter's solution of "just stop using those things" may be the best.

Even a dedicated subnet won't be enough, because these devices could be made to connect to any open wifi until they can phone home or even use the cell network, without the user even knowing about it.

> I guess, at this point, the other commenter's solution of "just stop using those things" may be the best.

Yeah. Assuming this doesn't change, this is the end result for me, at least.

Perhaps, but blocking 53 is better than not, IMHO. I've seen devices fall back once blocked to a hard-coded dns, so it works today. DoH is another that devices will eventually employ, so that's another whack-a-mole situation.