Why not? DHCP is supposed to be authoritative for the network you're connected to. If you don't trust that network, you should probably also not be using its advertised gateway. Where does that leave you?
Why not? Just make sure to use a VPN/etc to access services over the gateway.
I mean, this is the default case for everything going over the internet. Do you trust every router in the path?
Personally when my laptop is connected to a network on a high latency link to the internet, I'd rather it used the local caching server rather than one half a continent away. Clearly if I don't trust that network provided DNS server I'll tunnel everything out to a trusted network, or I could specify a DOH.
I have no practical issue with DOH if it were implemented at the OS level and had standards around how to distribute recommended settings (just like my dhcp server distributes a recommended gateway, recommended ntp server, recommended tftp boot server, etc).
If you're worried that your network upstream is intercepting your DNS requests (and if you're in the US on a mainstream ISP, you should be), this is the problem DoH is designed to solve, and it does so quite effectively.
The fact is that there's nothing you can do to authenticate DNS records, and turning some silly "DNSSEC" feature on in your own stack won't do anything but make you feel better, because DNSSEC simply doesn't have meaningful adoption. However, enabling DoH does in fact immediately protect you from attacks that really do happen, like ISPs monetizing your DNS.
Exactly. That's what I said.
The problem is that DoH is not the solution, as you just change trust from resolver A to resolver B. With no indication that B is better than A.
If you fear that your ISP is selling your data you need to change your ISP. The ISP always know what sites you are accessing, regardless of DNS. DNS might be easier than SNI or IP lookups but the danger is still the same. Right now it might actually help but once encrypted DNS gets enough traction those methods will also adapt. (Assuming that ISPs still do that practice)
While I have strong normative beliefs here, I'm mostly just posting descriptively. DNSSEC isn't happening. Enabling DNSSEC in your local configuration won't meaningfully protect you, because you depend on the security teams of large companies to also participate in the system, and DNSSEC has been more or less rejected by the market. Meanwhile: there are specific problems that DoH does protect against, it's easy to roll out, and doesn't depend on the Stripe security team changing their mind about DNSSEC --- so DoH is on a path to become universal, even as DNSSEC whithers.
(I invite the curious to test my reporting out with the `host -t ds foo.com` command, for arbitrary values of "foo").
I know I sound like a sore winner about this, and I guess I sort of am, but it is a little alarming that there are still currents of sysadmin wisdom telling people to go out of their way to opt into DNSSEC, in the belief that it will somehow protect them from any kind of real attack. In reality: corrupted DNS records overwhelmingly come from phished registrar accounts, not the elaborate, geographically-specific DNS cache corruption attacks DNSSEC was envisaged to deal with. I think it's worth being plain with people about this stuff.
Of course. If you know that your ISP is doing that, you change to one that is not doing it. It's not ubiquitous. Besides that, what makes you think that your DoH provider (if not your ISP) is also not selling that data?
You think that DoH/DoT is somewhat a replacement for DNSSEC but it's not. Both are independent. Doesn't matter how much domains have it.
Seems more plausible to just run DoH for my DNS and then not worry about my ISP snooping on my DNS requests.
Shame that I have 20 applications on several different users on two dozen different machines to configure
The same applies for your "home" environment. Since you usually don't want to run multiple DHCP servers, this would also work there.
option wpad-url code 252 = text;
option wpad-url "http://10.10.10.10/proxy.pac\n";
There is some work regarding this.
If you don't trust the network, then the OS should be tunneling to a trusted one. If you do trust it then it can go ahead and use the DHCP/etc provided name servers.
After all it can decide to enable/disable access to services (windows filesharing for example) based on this, there isn't any reason it can't decide to trust the local nameserver too.
I’m sure others do too I just can’t say for certain.
macOS: same as iOS (a dedicated window pinging www.apple.com).
Firefox: Detects detectportal.firefox.com and asks the user if the want to access the captive portal.
Android: Detects connectivitycheck.android.com on Android 5 and connectivitycheck.gstatic.com on Android 6+. I don't know if it applies to all phones, but I'm sure (that except for phones on Android One or Nexus/Pixel) Samsung also does this for phones outside of China.
Windows has support
https://techcommunity.microsoft.com/t5/networking-blog/windo...
You can put the proxy anywhere on the network and set up DHCP to point the clients to this proxy.
I see a comment like this basically every time something about DoH comes up.
What I haven't seen: A plan how this should be implemented, a proposal to OS vendors and developers, ideally with patches.
This raises a few questions. How should the OS decide which server to use? It obviously can't be DHCP, because that's not a secure thing to begin with. How does this interact with things like captive portals if you have a disconnect between the DNS functionality and the gui application? Do you have good answers for these?