This is already happening. The likes of Google Home et al already hardcode their own servers. I noticed that no DNS requests were being made through my Pi Hole, so when I looked, it turned out their DNS servers were hardcoded.
However, I'm more worried about when they start hardcoding DoH servers.
In the case of just using a PiHole, a hard-coded server would easily get around it.
But if the network outright blocks random DNS requests, that only leaves DoH, which would require fixed IPs, which should be able to be detected and blocked, right?
Unless I understand incorrectly, this doesn't seem to make the problem any worse. You'd just have to block the proxy rather than the DNS server. Like DoH, only a problem if that's also the web server.
In order for this to be true the device manufacturer would have to send both DNS and web requests through the proxy. They'd also have to "obliviously" encrypt web traffic as well. Otherwise, a MITM could determine which are DoH requests or determine which server is the proxy server and which are web requests.
This means that the DNS response for the web server would always be the proxy itself, or some set of proxies (and it would have to be the same IP for both wanted and unwanted traffic). What does DNS even add at that point? You'd be better off just making your "wanted" and "unwanted" servers the same server.
I believe there was a proposal for something like this a while back, before the DoH we see now. IIRC, the idea was that DNS information could be contained inside the web page, maybe enclosed in a tag. Addresses for ad servers perhaps.
Few of these ideas can be expected to work unless Evil, LLC controls the program the end user chooses to read the web. When an advertsing services company is also the majority share "web browser" vendor, then ideas like this become feasible. Whereas if web users can choose any client to access the web,[FN1] then these ideas would be non-starters. The open source text-only browser I am using is not going to read the IP address of an ad server embedded in a web page and connect to it automatically. Even if it did, I would simply edit the source code to disable that behaviour and re-compile.
1. In theory they can but in practice they generally don't.
I guess if the relationship we have with our devices is full-on adversarial and yet still need them, they should be put on a dedicated subnet with a default deny rule in place.
I guess, at this point, the other commenter's solution of "just stop using those things" may be the best.
Even a dedicated subnet won't be enough, because these devices could be made to connect to any open wifi until they can phone home or even use the cell network, without the user even knowing about it.
> I guess, at this point, the other commenter's solution of "just stop using those things" may be the best.
Yeah. Assuming this doesn't change, this is the end result for me, at least.
Perhaps, but blocking 53 is better than not, IMHO. I've seen devices fall back once blocked to a hard-coded dns, so it works today. DoH is another that devices will eventually employ, so that's another whack-a-mole situation.
Been using this solution myself for a number of years. Works remarkably well. I do not even use DNS recursion or any remote DNS requests because I can load bulk DNS data into the proxy's memory. There is only ever one nonrecursive request to a localhost authoritative DNS server and the answer is always the same: the address of the proxy. Ironically perhaps, DoH outside the browser can be used to gather the bulk DNS data, thanks to HTTP/1.1 pipelining.
Many years ago I anticipated that "developers" would no longer allow end users to choose DNS servers. The developers' work, i.e., software, was dropping in market value and they began to adopt a Trojan Horse "business model". End users could use the software for free with the expectation that few would notice/complain about increased surveillance and data collection, or injected advertising.
The so-called "MITM proxy" is neither a new nor radical idea. Corporations routinely "MITM" TLS traffic from their networks. Enterprise hardware/software companies have provided turnkey solutions.
The issue is not limited to addresses for DNS servers. For example, WhatsApp hardcodes IP addresses in their mobile app. For that problem I use an application firewall.
The PiHole is essentially a slightly modified version of dnsmasq running on a RPi. It is funny that no one has tried using other DNS software. Given a choice of DNS software, I would not choose dnsmasq. It also still seems that no one has presented a "PiHole" that uses a forward proxy instead of a DHCP/DNS server. Similar to corporations, home users need a turnkey solution for monitoring their home networks.
I have an early one someone gave me and there was a custom ROM that one could flash that let one choose their own DNS servers.[FN1] I actually bought a Teensy 2.0 in order to install the custom ROM, but I never got around to doing it. So now I have an old Chromecast and a Teensy 2.0 I am looking to make use of.
TBH, I always found the Chromecast proposition to be unreasonable: "Look at this neat form factor single board computer you just paid for. Too bad only Google is allowed to have control over it. Sorry, you cannot use this for your own projects because [unspecified]. Google must be allowed to conduct surveilllance and gather data." By comparison, lack of complete control over the RPi GPU is rather easy to ignore. AFAIK, the RPi Foundation is not selling online ad services. Compare the number of cool projects people have done with the RPi versus the Chromecast.
1. I think it used to be possible to force use of different DNS servers via DHCP as well.
However, I'm more worried about when they start hardcoding DoH servers.