Its a good thing DoH is now in the stable version of RouterOS, I've just switched it on.
Here is the difference between using Virgin Media's resolving proxy DNS servers and using your own:
% # http://jdebp.uk./Softwares/djbwares/guide/commands/dnsqrx.xml
%
% dnsqrx a z398nvfsd0098u3qwtltnk. 194.168.4.100
1 z398nvfsd0098u3qwtltnk:
56 bytes, 1+1+0+0 records, response, noerror
query: 1 z398nvfsd0098u3qwtltnk
answer: z398nvfsd0098u3qwtltnk 0 A 92.242.132.24
%
%
% dnsqr a z398nvfsd0098u3qwtltnk.
1 z398nvfsd0098u3qwtltnk:
40 bytes, 1+0+0+0 records, response, authoritative, nxdomain
query: 1 z398nvfsd0098u3qwtltnk
%
That last query didn't even escape the machine in my case. I run a private root content DNS server on every machine if possible. The query here got answered by a tinydns instance listening on 127.53.0.1: % tail -n 1 /var/log/sv/tinydns/current | tai64nlocal
2020-08-26 09:37:44.305619726 7f000001:cfd9:f163 + 0001 z398nvfsd0098u3qwtltnk
%
No-one gets to complain about (minuscule) extra load on the root content DNS server except me. It's my server on my machine. (-:I did have my router setup to cache DNS requests to google and updated the DHCP config so everything would use my router for resolution, but virgin's DNS servers were still being pulled through as a "dynamic server" according to the RouterOS panel.
I thought Virgin was fiddling with my DNS requests even though I was sending them to a different provider.
Requiring HTTPS would absolutely protect against hijacking of top-level domains that aren't registered, as no SSL/TLS issuer that's trusted by browsers will issue certificates covering those domains.
A first step towards that eventual outcome would be to default to https:// for anything typed by a user that doesn't start explicitly with http:// so that they are protected from NXDOMAINs in that regard.
I hope that the various browsers implement at least that first step.
Amazon and Azure are still lagging behind, but those aren't going to ignore DNSSEC forever.
DoH solves nothing in this context unless we centralise DNS resolution to Google or Cloudflare. The Windows method submits the DNS requests to the same server as your regular DNS server by default, so the protocol doesn't give you any advantage there. Chrome does the same thing; if it detects that your name server does DoH, it'll switch to that, but it won't switch DNS servers.
Perhaps this does solve the problem for the few people with custom DNS servers getting their queries intercepted, but the vast majority of people (everyone not using Firefox inside the US) won't notice any difference.
DNSSEC will solve this problem by making the certification chain break for domains that haven't been signed by their TLD, but only if we start enforcing it (like we are enforcing HTTPS for certain features already). DNS over HTTPS will just encrypt the bad NXDOMAIN DNS query when it comes from the same malicious server, only protecting against traffic interception when using different DNS servers; the two protocols serve different purposes.
DoH breaks ISP DNS interception immediately, and for all zones, not just the rare DNSSEC-signed ones, by moving DNS resolution off-net to a more trusted provider.
The irony is, breaking NXDOMAIN interception is in fact a core use case of DNSSEC, and the protocol simply won't work for it, because the ocean needs to boil before every vector of the attack is closed. DoH went from the whiteboard to deployment in a tiny fraction of the time, and actually closes this hole decisively.
(That the firefox solution works is due to the root servers themselves being deemed trustworthy, and the ISP ones being tentatively not, but the DNSSEC solution is strictly better as now nothing needs to be trusted.)