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.
They can hijack the DNS answer to the DoH server, which have to happen if the system doesn’t know where to look for, and create a DoS. However, that’s how far they can go AFAIK. They can’t pretend they are the real server, nor downgrade the connection. And, it can be sidesteped by using a direct IP connection.
We use DNS just because lemmy.ml is easier to remember than 54.36.178.108 or 2001:41d0:303:486c::1. DoH can still works by direct IP connection.
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.
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.
Aint all of peasant level ISPs bootstrapping unencrypted DNS requests?
Get you a fucking VPN and a good router, flash openwrt and put vpn on the router. Deny these parasites the data.
or at leas get a good VPN for your main PC and cellphone. they monitor your traffic, they sell it. you know this, act on it.
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.
They can hijack the DNS answer to the DoH server, which have to happen if the system doesn’t know where to look for, and create a DoS. However, that’s how far they can go AFAIK. They can’t pretend they are the real server, nor downgrade the connection. And, it can be sidesteped by using a direct IP connection.
We use DNS just because
lemmy.ml
is easier to remember than54.36.178.108
or2001:41d0:303:486c::1
. DoH can still works by direct IP connection.Aren’t they a MITM here? Can’t they easily forge certs for the domain name of their fake resolvers since they intercept and resolve your DNS requests?
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.
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.
a vpn is still better