Hacker News Reader

Comment by lapser | Hacker News Reader

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.

View on HN

On my router I redirect all outbound port 53 traffic not coming from my local recursive DNS server to my local recursive DNS server.

The next step in the arms race is DoH. Afaik no one has a generic answer to that beyond "treat devices behaving hostilely as hostile".

This is what I do, too. Simple and effective.

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?

Sure, the setup becomes a bit more involved...

Surely you can have firewall redirect rule that bounces all outgoing dns to your Pi hole?

This doesn’t work with DNS over https of course.

I can see people MITM their own https traffic in the near future!

Remember- there is no reason you can’t serve DoH from the www host (the web server).

So you won’t necessarily even get to play this cat and mouse game - the dns requests are indistinguishable from your web requests.

I guess you could mitm your own ssl traffic and strip out dns answers there?

But then … how soon until we see DoHoH?

> how soon until we see DoHoH?

DoH over Tor already exists, but more importantly, Oblivious DoH (kind of like DoHoH) is being standardized by the IETF: https://datatracker.ietf.org/doc/draft-pauly-dprive-obliviou...

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.

You're correct but you are viewing the comment out of context. GP said: "I guess you could mitm your own ssl traffic and strip out dns answers there?"

ODoH isn't going to be defeated by TLS MitM afaik.

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.

Actually no. By blocking 53 at your router to anything except your pihole, even a hard-coded IP like 8888 is blocked.

You'd have to do packet inspection. Otherwise a hostile hardware manufacturer could just run their DNS on a non-standard port.

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.

Have you tried blocking them explicitly? That might cause them to fall back through the advertised ones.

Same on DoH.

I can’t filter it or redirect it like I can with plain old DNS.

Yes, really the only way would be to set up a MITM proxy on your network and enforce all traffic goes through that. Also means accepting a CA.

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.

" Similar to corporations, home users need a turnkey solution for monitoring their home networks."

You'd think thats thr job of the router companies - they sell you hex-core routers for $390 or whatecer, but no usefull functionality

Chromecast products, in particular, will not work with self-signed certificates, and you can't adjust their trust stores.

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.

What is a DoH server?

DNS over HTTP

DNS over HTTPS

Reply on news.ycombinator.com