Hacker News Reader

Comment by mikestew | Hacker News Reader

In case you’re like a lot of folks in HN, read the title, and say to yourself “already have one”, read TFA for the iptables config that fixes those apps and devices that bypass local DNS. For example, the New York Times app seems to now use its own hard-coded DNS servers. Without having tried it, it looks like TFA has the fix for that.

EDIT: replies indicate that I, a person who is barely competent at many network tasks, might be off-base on this one. Grain of salt, and all.

View on HN

An increasing number of them also rely on hard coded DoH servers which is harder to block/redirect. You will need to will Pi-Hole/Adguard Home on router to block them based on some curtailed lists (i.e [1])

[1] https://github.com/dibdot/DoH-IP-blocklists

In this arms race you are saying a current "move" is a curated list of IPs that correspond to known DoH servers ... and that's fine ..

However, if the adversary decides to just query - and answer - DoH requests on the same hostname that you are trying to talk to ... isn't that a winning move ?

For instance:

If one had an application - or an appliance - that spoke https to endpoint.samsung.com, how would one block DoH requests addressed to the same endpoint.samsung.com ?

That might work but if your Samsung example is behind cloudflare, you're basically going to have to block any and all access to cloudflare's Network.

And if telemetry.example-iot.com belongs to an AWS IP, it could change to another IP in their space at any time so your only recourse would be to limit connectivity to all of AWS which would effectively prevent you from accessing most things on the internet

If you're really serious about DNS interception, you'd setup something where

a) you stop accepting A lookups, because it's 2025 and IPv4 only is dead (let's pretend anyway)

b) for each AAAA lookup, return a new IPv6 address that you'll NAT to the real address (you can use this for NAT64 if you want to let clients connect to IPv4 hosts). Then only let clients connect to these IPv6 addresses you setup.

If someone smuggles address resolution through, outside of DNS, their clients can't connect.

(this is going to be a big PITA, but that's how these things go)

> for each AAAA lookup, return a new IPv6 address that you'll NAT to the real address (you can use this for NAT64 if you want to let clients connect to IPv4 hosts)

We employ exactly this technique for our Android firewall app. It can do IPv4 (by mapping hash(domain) name onto RFC6598 reserved subnet [0]) as number of unique AAAA/A requests on a client seldom exceeds 35k/mo!

Another (simpler) control we offer users is, to drop all connections made to IPs that the user-set resolver did not do name resolution for.

> (this is going to be a big PITA, but that's how these things go)

You don't say.

[0] https://github.com/celzero/firestack/blob/2191381f/intra/dns...

> Another (simpler) control we offer users is, to drop all connections made to IPs that the user-set resolver did not do name resolution for.

This sounds good, and I've wondered how I could implement such a thing.

However, with the clearly hostile approach all IoT appliances are taking, I wonder if they'll actually fall back to a "degraded" (for them) config with the network-provided DNS, or whether they'll just fail and complain the network is broken or something.

I guess at that point they’d have to establish a tunnel and route ads through the same HTTPS connection as legitimate traffic.

I run Zenarmor in addition to Adguard at home, which can detect DoH traffic and intercept it. You have to pay for this enterprise level tool, but if you are worried about DoH, Zenarmor is so far the easiest tool to block it.

In our house the only device that tries to use DoH is my partner's iPhone. It tries a few times, fails, then uses the Adguard DNS, which blocks the trackers.

Do you have documentation of this? My understanding was always that Zenarmor simply maintains a list of known DoH servers.

And before DoH was a thing, several Chinese apps I've used also used to do plain HTTP for DNS resolution (I only caught them by chanbecause they were doing HTTP). PiHoles only work for apps that stick to the standards and don't mind being caught.

Browsers allows corporations to prevent DoH and force DNS through company-owned DNS servers:

https://support.mozilla.org/en-US/kb/dns-over-https

I use these settings on all my browsers to prevent DoH and make sure traffic goes through my Pi (I run unbound directly on the Pi though, not Pi-Hole: in my experience unbound is a bit harder to set up initially but it's also more powerful than Pi-Hole... For example unbound accepts wildcards in blocklists).

It's not incompatible with also blocking, at the firewall level, all known DoH servers of course.

Nor is it incompatible with forcing your router to also use your Pi as a DNS.

> read TFA for the iptables config that fixes those apps and devices that bypass local DNS. For example,

Don't worry. All the browsers and stuff are bypassing this level of control by moving to DNS-over-HTTPS. You'll either have to deploy a TLS terminating proxy on your network, or give up on this arms race.

Would certificate pinning also remove the first option? I wonder if we are moving to a system where inspecting your own traffic isn't a viable option anymore, am I missing a workaround?

If you control the machine you can always defeat pinning, given enough effort. But for an IoT device, yeah, we're already there.

To be fair, if you are geeky enough to run a PiHole you will have no trouble finding the config option to turn off DoH in your browser.

Don't turn it off in your browser. If you have control of that setting just install an ad blocker. The point of DNS block lists is to get rid of ads on phones, TVs, and other non configurable things.

>Don't turn it off in your browser. If you have control of that setting just install an ad blocker. The point of DNS block lists is to get rid of ads on phones, TVs, and other non configurable things.

Yes, and...It's not just to block ads. It's also to block various trackers and unwanted/surreptitious "telemetry" and "updates" to those devices you can't control/configure.

Except, now you don't really control your web browser either, and ad blockers are getting crippled. It is an uphill battle.

AdBlockers are not crippled on Firefox

And then there is amazon sidewalk, which can only be evaded by unplugging the wifi board on your tv

True, but I want all the devices on my home network to have DoH disabled too. Most of them I can't change directly.

The arms race will continue. I think the next gen will be a self hosted archive.ph style host that lets all the garbage load and distills it into a PDF or Web 1.0 style file ready for consumption. I would be fine with a browser extension that learns what I watch the most and preloads it for me, and/or an on demand service that shares prerendered sites bundled into torrents that group together common interests.

Edit: as much as I dislike AI, I concede it would be lovely to tell it to replace all ads with pictures of flowers.

That's what The Internet Junkbusters Proxy / Privoxy excelled so good at.

Yeah DoH was a solution to a really niche US-only problem where their laws provided the ability for providers to sell their users' DNS logs. In normal countries with privacy protections this isn't a thing anyway.

In this model, DoH is only a bad thing because it evades local DNS control.

I know that apps can always roll their own or even hardcode servers, but I hate the way that DoH was seen as some kind of saviour even though it adds zero benefit to European users and only adds negatives.

Your comment makes no sense. The DoH providers can still log requests and sell them.

DoH protects against intermediaries spying on your requests and potentially forging responses. Exactly the same as HTTPS.

Sending anything in clear text over the internet in 2025 is criminally negligent.

HTTPS is not necessary to encrypt DNS traffic. DNS-over-TLS exists, but it has much less traction compared to DNS-over-HTTPS. I am guessing the reason is that HTTPS traffic all goes through port 443, so "censorship" of DNS becomes tricky, since DNS traffic becomes a bit harder to distinguish from ordinary web traffic.

Encapsulating DNS packets in HTTP payloads still feels a bit strange to me. Reminds me a bit of DOCSIS, which encapsulates ethernet frames in MPEG-2 Transport Stream packets (this is not a joke).

Everything other than 80 and 443 is blocked by default, anything-over-https is just a matter of time. With a properly configured TLS MITM proxy only certificate pinning will prevent snooping, but it’ll also prevent connectivity, so you might call it a win for security/privacy, or a loss for the open internet if it’s you who needs to VPN to a safe network from within such an environment…

A port number does not force a certain protocol. You can run everything you want over port 443.

And yeah I also think it's a really bad idea to run everything over https. But I don't think it'll happen.

You can. The client side enterprise proxy/firewall really doesn’t want you to, though. Just a fact of life.

Yeah I wasn't really thinking of enterprise in this whole discussion though. After all, it's about pi-hole.

Yes but in the US the ISPs are the intermediary. And the big DoH providers like Cloudflare have better privacy protection.

Here the ISPs are intermediairs too, but we have laws to prevent them from using our data using DPI etc. And even if you use their DNS.

I agree encryption is important but DoT is much better then. DoH mainly took off because of this in the US.

Jokes on you, I do have a fortinet which does this.... Oh wait, only up to TLS 1.1 or something and it's slow.

I forgot the name of the software but there used to be a few tools to terminate and reencrypt. But yeah dnssec is it's own challenge

You need to get an F5 box instead. :)

No, that's not a fix and those iptables settings are on the router. It will only catch DNS requests on port 53. Doesn't catch DoH which you can't do on a router, you need a firewall for that.

Also, doesn't that break the network if the pihole is offline? Before I'd just override DNS on my workstation, but that iptables config would block any "unsanctioned" DNS traffic

It would, yes

> For example, the New York Times app seems to now use its own hard-coded DNS servers. Without having tried it, it looks like TFA has the fix for that.

Those commands in TFA simply reroute traffic on port 53 to Pi-Hole, which isn't enough to prevent apps from doing their own name resolution. For instance, the Telegram app has built-in DNS-over-HTTPS, which those iptables chains could do nothing about.

You can block known DoH servers.

I was going to say, as a person who used pihole pretty extensively at one point, it may not be enough anymore. I am by no means a network expert, but I do recognize those shortcomings and try to compensate for them. Blanket pihole recommendation may be disservice at this point.

I've seen Windows 11 ignoring DNS settings too, for Microsoft telemetry, ads and updates.

Apps that open arbritrary UDP/TCP ports? Isn't that something the app store policies should reject?

They're not opening listening ports on the local system, they're just ignoring the system's DNS and saying "Take me to this IP and this port" and then doing a DNS lookup themselves

What is an arbitrary TCP port? Ports in isolation from an IP address aren't inherently arbitrary, they're nothing, and the IP:port pair is arbitrary. Once you allow connections to any host on the internet the port doesn't really matter - you can do whatever nefarious shit over port 80. And not allowing apps to connect to external internet servers seems pretty limiting.

Reply on news.ycombinator.com