It’s a double edged sword. DoH will enable unblock-able ads.
DNS filters might be very easy to set up but if they become more major they can be outsmarted very easily - what if Google starts serving ads from www.google.com, would you block that domain name too? Browser extensions can block content far more precisely.
And smart TVs and such stuff could easily switch resolvers and just not use your Pihole's DNS resolver - that would work even without DoH as long as you don't intercept traffic on your router. E.g. Fire TV already adds Google DNS as an additional DNS server (you can't change that). Chromecast only uses Google DNS (AFAIK you can't change that either). I guess the only viable option here is just not to buy those products.
And devices are handed DNS servers (with the option to opt out) via DHCP when they connect to the LAN.
If Cloudflare starts serving DNS traffic from HTTPS on its CDN, the malware can use Cloudflare for DNS. Am I supposed to block all of Cloudflare's IPs because they can be used to circumvent DNS query monitoring?
If it needs to phone home or otherwise contact an outside address (excluding hard-coded IP addresses), then presumably it needs it needs to do a DNS look-up at some point.
Many botnets use pseudo-random DNS domains, and when the generation algorithm was figured out, people were able to get control of it:
One DNSmasq already addresses in part through various asblock and malware-blocking DNS blacklists. I'm using one such that updates hourly or better. Requests to or for specific domains my be blocked (and are).
Keep in mind that by using DNSmasq at a centralised LAN server, you now have a single point of control to defend against such threats, rather than relying on multiple device- and application-specific points of control. Though software (such as browsers) offerring its own defences against such threats is in no way hindered.
You can further, and more appropriately IMO, defend against such threats at the firewall level, by blocking network space (rather than domains) and ports associated with malware. At the OS level, firewalls such as Little Snitch monitor and block traffic at the application / process and user level, and may detect, alert on, and/or block such malware.
As does DNS-over-TLS. Though since it has an official IANA port, this can be blocked.
> You can further, and more appropriately IMO, defend against such threats at the firewall level, by blocking network space (rather than domains) and ports associated with malware.
And if malware leverages Cloudflare, am I supposed to block that? The ports associated with malware may be HTTPS.
You seem to be manufacturing a hypothetical threat that isn't actually impacted by DoH, to no clear end.
Malware already exploits specific IP spaces (DUL, datacentres, AWS), and ports (20, 22, 25, 53, 80, 443, ...), as well as vectors such as adtech networks, IFRAME, and XHR. Those are blocked as best as possible, leveraging numerous signature, to varying degrees of effectiveness.
Methods are not perfect. But if they on net reduce or manage risks more effectively, they're a net win.
Again, DoH, either in the browser or at the LAN level, addresses a specific set of known risks. And I'm not seeing the caveats you're suggesting as either more severe or non-mitigable.
DNS over HTTPS means that you can make a tv that resolves dns using https://8.8.8.8 and looks at fancy.ads. But I can't mitm it because I don't have a suitable trusted certificate to respond to that request. So either the request to fancy.ads gets dropped and the request to online.movies.example.com gets dropped so I can't use my smart tv for its intended purpose. Or both get through.
Obviously things are different if the service uses standard OS level configuration so I can tell it to resolve dns using https://my.adblocked.dns or /etc/hosts. But nothing obliges any particular system to do that.
If my logic is faulty, please, do inform.
Uponcoffee suggests inspecting the SNI header to drop the TLS handshake. So the DNS resolves fine, but when they try to connect to https://fancy.ads, that request is tampered with and fails. As far as I know, that depends on a bug in TLS which will be fixed in some future version, so that inspecting such a request becomes impossible.
NegativeLatency suggests installing an alternative certificate. This would presumably work if I have root access to my smart device. Maybe I can get access to root on my smart tv, I'm not sure, I don't use smart tvs.
But random people can't get access to root on their phone. It will break their banking apps. I can install an adblocker on my phone and accept the consequences of my actions. I'm not sure what the tradeoff between adblocking and banking apps is, even for me. I would probably want to write my own browser based app to let me log into my bank from an separated web browser - if I'm trying to log into my bank when I'm standing in the queue I don't want to piss fart around with stupid browser tabs.
I certainly can't tell my coworker "yeah I'll just install this ad blocker on your phone, it'll block some analytics too so your privacy will be a little more respected" if the only way to do it is to break their banking apps.
I mean, okay, the ads aren't unblockable. But we are at the point where I have to make a trade off between letting you run whatever code you want on my phone, and letting you not run any code at all on my phone. Capitalism depends on negotiation to work. If it's just "I'm a big company, use my service or don't", capitalism stops working.
Then there's the option to reverse lookup the dns record associated with a given ip.
So ad blocking/censorship will still be viable for a while yet.
Suggesting that we should weaken encryption/privacy because some people plan to use it in ways that we don't like is just not a viable option. It's exactly the argument that governments are trying to use to mandate backdoors in our chat services. With encryption, it's all or nothing.
I would presume that, like with DNS over DNS¹, a resolver could check /etc/hosts first prior to attempting to resolve over the network; do proposed DoH resolvers not do that?
Worse comes to worse, you could always run your own local resolver.
¹or whatever we're calling the original protocol now
How do you like them ads?
Update: https://www.flatpanelshd.com/news.php?id=1416894724&subactio...
You have no evidence that the devices would be more expensive. Your only evidence is that the companies would receive less income all else being equal. But what is the evidence that the trade off is your eyeballs instead of your dollars? And if the tv is perfect except for the ads, where do you get the more expensive, ad free version?