Re: Good & Bad
Not all of that is as concerning as you imply.
"2nd i can block normal DNS at my fw, i can't block https unless i wan to break the internet for my household, or install a proxy."
You can do a pretty good job if you want to. CloudFlare's resolvers on IPV4 are in the range 220.127.116.11-3. So you can set up a firewall rule: Source: [local_addresses] Destination: 18.104.22.168-3, Port: 443, Packets: drop. Do that for a couple providers and DoH becomes difficult.
"I really don't want my local systems being name checked against the internets dns servers,"
If you do enter a local address into something that sends it to an external resolver, that resolver won't be able to find the address, so you'll instantly know you have to fix DNS for the affected application to point it at the server that will work and will protect your addresses. While I understand that you might not want to send your internal requests by accident because you're concerned that a resolver will leak them, knowing your internal DNS names really shouldn't be very relevant to an attacker without additional access, and with that additional access the attacker can find them out anyway. In addition, the likelihood of an attacker also running a default DoH server is unlikely, and the encryption on that protocol makes it unlikely that someone could steal them from the traffic to that provider.
"i also don't want any random IoT crap on my net or apps i install on my laptop/phone being able to do dns look ups to stuff i can't block & without me knowing!"
I agree wholeheartedly. The problem is that any app sufficiently malicious can already do this. We block the most straightforward way of loading unwanted content. Here are some others, and DoH is not needed for any of them:
1. Hard-code an address into the code. Contact it directly. No DNS request sent at all.
2. Hard-code the address of a DNS server, then use normal DNS to retrieve it, ignoring the network-supplied resolvers. This is the easiest to block if you have set up your network to send all requests on port 53 to your local resolver, but most networks aren't set up that way.
3. Hard-code the address of a resolver which is willing to take requests on a different port. Not hard to set up by the attacker and finding out that it's happening requires inspection of packet payloads.
4. Hard-code an address and use it to find additional addresses via some encrypted and difficult to track mechanism.
5. Use the standard resolver to resolve something that's likely to get through, and host a resource there to allow resolution of other addresses. For example, hosting an encrypted database of addresses on Github.
None of these ways will stand up to a manual analysis with Wireshark, but all will completely bypass the local DNS system without requiring DoH to be operating. In only one of the cases can a simple firewall rule help.
"This is good for privacy but terrible for securing your home systems against unfettered outbound comms."
I really don't think so. If some device on your local network starts contacting a random external IP, will your network allow it or not? If it would allow it, then the only restriction on your outbound comms is trying to prevent the local device from getting the right address. Given how many ways there are of getting an address, that's not a guarantee of anything. If it would not allow it, then it doesn't much matter if the device knows the address to use.
"will be migrating to pfsense soon & will need to build a Man In the middle capable proxy to inspect outbound traffic."
This seems like an overreaction. Unless you are confident that you can create something capable of parsing all that traffic and determining whether you would like it or not, the effort will only create an extra bottleneck for your network.