I don’t, but it’s stupid simple:
- DoT uses a new, dedicated port for DNS queries that is different from the port traditionally used for DNS, so that the server knows to serve TLS-encrypted traffic.
- DoH just abuses HTTPS to do DNS instead of coming up with a new protocol/port, so it all goes over port 443.
The latter certainly feels wrong from a design perspective, we like labeling our traffic as the traffic it is, but not being explicitly marked as encrypted DNS is precisely the advantage: it looks like perfectly normal HTTPS traffic, which you can’t just blanket ban on your network since everything else also needs HTTPS to work, so it’s harder to block.
Since it’s TLS encrypted packet sniffing is also pretty hard, you need heuristics (e.g. IP/domain bans, or more complex and unstable things like blackbox traffic analysis) to try and prevent people from dodging your honeypot DNS server in your internet cafe.
You can tell whether you’re using DoT or DoH by the nameservers you set. The <address>#<domain> syntax is DoT, while DoH simply uses an https URL.
As for using it in practice...
There are more up-and downsides to both; I think ideally you set up a fallback nameserver with DoT (since DoH needs a bootstrap query, and DoT can gracefully fall back to unencrypted DNS when necessary), and otherwise use DoH. You’ll want a good caching resolver and keep copies of both the DoH and DoT server certificates so you don’t end up having to bootstrap that trust chain while under attack.
That said, I haven’t found a good, caching resolver that’d implement this yet. I think the best option is something like unbound + dnscrypt-proxy, but I’ve struggled making them play ball, so personally I still use unbound + DoT and just hope I never need to use a network that blocks DoT.
There’s also no good UI for this yet. None of these setups survive exposure to - gasp - a captive portal (which is usually implemented precisely by MITM-ing your DNS queries and serving the wifi owner’s login page instead of, say, google), so really you need a toggle that lets you make one or two queries with the dhcp-provided nameserver, and then switch back to DoT/H after login for any of this to be useful in practice.
I’ve tried, but it’s still very hard to make this a useful improvement to security!
The downside of encrypted DNS in general that critics will tell you about is that you need to trust the DNS servers you choose, since they can fully track your queries (there is ODoH, which uses a proxy to obfuscate your traffic, but it doesn’t really convince me since now you have to trust the proxy).
In the modern world, where computers travel between networks all the bloody time, I don’t think you’re getting around this, no matter how cleverly you design your intranet. IMO we should hence make encrypted DNS as standard and always-on as possible, so DoH is the way to go for default configs (ideally with e.g. cloudflare so ISPs can’t just block domains on account of cloudflare also being necessary for everything).
If you run a computer on precisely one private network with a carefully controlled, shared caching DNS resolver you probably know what you’re doing and don’t need others to set sensible defaults for you.
