[gerdesj]

Its a trick one. Traditional DNS runs over port 53/udp and fails over to 53/tcp for large queries/results. That's easy to deal with on a packet filter firewall.

Then in the name of ... something, something, security ... DNS over http(s) was invented. Now you can balkanize DNS by requiring certain SSL certificates be involved. To my knowledge this hasn't been abused large scale yet but it could.

Let's go easy on the tinfoil and simply redirect outbound traffic to 53/udp and tcp to a PiHole or other DNS server under your control.

If you insist on the tin foil, you will probably need to look into a MitM proxy such as Squid - look into "bump" and "spice".

[esseph]

This falls apart when you realize DoH can (and does) just go out to 443/TCP.

It looks like a web request, which was literally the point of the specification.

"DoH ensures that attackers cannot forge or alter DNS traffic. DoH uses port 443, which is the standard HTTPS traffic port, to wrap the DNS query in an HTTPS request. DNS queries and responses are camouflaged within other HTTPS traffic, since it all comes and goes from the same port."

Now if you get into that territory, as you have suggested with your proxy comment, now you are breaking the security model for not just DNS requests but much of the overall traffic on the network.

[vladvasiliu]

> Now if you get into that territory, as you have suggested with your proxy comment, now you are breaking the security model for not just DNS requests but much of the overall traffic on the network.

You may be breaking things altogether, actually, since many of the devices for which this song and dance needs to exist don't actually offer a way to alter certificates. I don't know that my smart tv actually uses DoH (it's not physically connected to the network), but I have no idea how I'd add a trusted certificate to its chain, even for other purposes.

[gerdesj]

I know exactly (within reason) how TLS works. However that enforceable guarantee may not be in the end user's best interests.

Your browser could require via TLS certain CA only signed responses and even covertly do that and flatly refuse to use the system configured DNS and fib and lie. At least DNS over UDP/TCP can be easily manipulated locally through a packet filter and via NAT n that and it can be inspected by the end user easily.

No, I am not suggesting you break any security model - a MitM run by yourself is yours and yours alone. If you consider your browser might be hostile <tin foil crackling sound effect here> then you really have to look quite deeply into what security model you are dealing with and how it really works.

Proxies and so on are just tools for a job as are DNS servers (I have one just for my customer's Let's Encrypt challenges) and all the rest.

I like to forget the usual trite networking bollocks and think quite clearly about how it all really hangs together. I start with what I would like to be the source of "truth" with regards the thing I type into the browser and the IP address that is returned and connected to.