Don’t most DoH resolversl settings have you enter the IP (for the actual lookup connection) along with the hostname of the DoH server (for cert validation for HTTPS)? Wouldn’t this avoid the first lookup problem because there would be a certificate mismatch if they tried to intercept it?
Well, that’s the thing. I’ve seen many instances where the DoH field is required to be a FQDN, not an IP. This always struck me as strange, but I didn’t think much on it until recently.
You’re not wrong, but you can bootstrap that request, too. It makes it more complicated, but I know NextDNS has taken steps to prevent that type of hijack with their mobile apps.
The HTTPS certs are designed to prevent MITMing, but if it’s still a worry or the domain is blocked by DNS, you can manually find the IP and add it to your hosts file instead.
All you need to do is enable DoH or DoT to prevent the DNS hijacking and spying.
Or just roll your own recursive DNS server.
With DoH, the first request to find the https DNS resolver itself is unencrypted rendering it subject to hijacking.
Correct me if I’m wrong, but that’s how I understand it.
Don’t most DoH resolversl settings have you enter the IP (for the actual lookup connection) along with the hostname of the DoH server (for cert validation for HTTPS)? Wouldn’t this avoid the first lookup problem because there would be a certificate mismatch if they tried to intercept it?
Well, that’s the thing. I’ve seen many instances where the DoH field is required to be a FQDN, not an IP. This always struck me as strange, but I didn’t think much on it until recently.
You’re not wrong, but you can bootstrap that request, too. It makes it more complicated, but I know NextDNS has taken steps to prevent that type of hijack with their mobile apps.
The HTTPS certs are designed to prevent MITMing, but if it’s still a worry or the domain is blocked by DNS, you can manually find the IP and add it to your hosts file instead.
a vpn is still better