Recommended strategy for clients with hard-coded DNS?

I see one year ago there was a Reddit discussion about clients with hard-coded DNS to avoid DNS based adblocking. Supposedly these devices have hard-coded DNS:

  • Google Cast
  • Google Home (including Mini)
  • Netflix on Android (presuming iOS as well)
  • Roku
  • Ring Doorbell Pro

Is there a recommended strategy for dealing with this? I know it isn’t pi-hole specific, necessarily, but any software, service, client, or app with hard-coded DNS is kinda bypassing the ad blocking service that pi-hole provides entirely which isn’t … great.

I guess it would be best if there was a service you could run on the pi-hole that would forcefully redirect all DNS through the pi-hole? :thinking:

2 Likes

The best way to handle those devices would be to use some rules on the router or firewall to intercept all traffic to port 53 and give it to the Pi-hole DNS. I think there is a FAQ or two that covers some of the examples for iptables, and there is a blog post about using Ubiquity gear and their configurations.

https://scotthelme.co.uk/catching-naughty-devices-on-my-home-network/

2 Likes

Right but the problem there is that it’s 100% router device dependent, so it varies dramatically by vendor, OS, and all that. On some routers it may not even be possible! It would be nice if there was a generic way the pi-hole could handle this with a standardized software solution, somehow.

Maybe that’s not possible? :cold_sweat:

Pi-hole would need to see all traffic on the network to be able to intercept and redirect DNS queries. If an IoT device doesn’t use the Pi-hole IP for DNS then the Pi-hole will never be aware of the devices DNS queries. You would need some kind of network appliance that sits on the edge of the network and can see all of the traffic outbound through the WAN interface. Or IoT devices that don’t intentionally disregard DHCP assigned DNS servers.

Edit: Even if we proxied all the traffic on the network, we’d still be in the situation where the IoT device would just ignore the proxy and go direct for their traffic and requests. We ask that the devices use our supplied DNS address and they intentionally ignore that, so why would they honour the proxy? The problem is that the device manufacturers do not want their traffic blocked or filtered.

2 Likes

If you want to redirect all DNS queries to Pi-Hole and your router does not support this, I recommend changing to a router that can do this (or flashing new firmware if your router supports that). The router is the single device on your network that sees all outbound traffic.

1 Like

I managed to capture those sneaky DNS requests in my network, using NAT rules on my EdgeRouter:

150 requests tried to bypass PiHole in the last 12 hours.

That only works for IPv4, so I have to come up with a solution for IPv6 yet…

2 Likes

IPv6 should be similar, same ports (UDP/TCP 53). I have an ER-X-SFP and the GUI is horribad for IPv6 rules, you have to do most of that via the CLI tools.

2 Likes

Make sure that you are catching both TCP and UDP, most queries go though UDP for speed and only when the response is larger than a UDP packet can handle does it go via TCP.

I think what the main idea of the discussion is for an idea or a solution that could be abstracted out for use in varying network configurations.

One of the biggest barriers to adoption of Pi-hole is the vast difference in networking. Originally we just did DNS but then we found a lot of small network routers and routers from ISPs locked out users from what I would consider to be basic functionality. That lack of flexibility cuts down on the support requirement for the ISPs as they don’t have to allow users to configure their networks but its “not right”. So we evolved to use DHCP, but now we’re seeing devices locking out users from configuring things.

The problem is that you need to be on the WAN interface to detect attempts to bypass and to intervene but RasPi devices are absolute crap when it comes to routing. I think the tone of my comments here are a bit harsh and I don’t want to leave the impression that it’s not something we would investigate but instead it’s something that I would be very interested in if there were a way to do it. I just don’t think there is something that would work from my networking background and experience but I’m happy to be wrong.

2 Likes

Is anything better with the Raspberry Pi 4 in this regard?

I haven’t tested that as I don’t have one to check (I don’t use Raspberry Pi boards anymore) but from the design changes made it looks like the bottleneck is gone. But it would still require that the Raspi be the WAN interface and that you would have to configure the network to use the Raspi in that way to be sure that the IoT devices did not try to circumvent the proxy as they are circumventing the DNS configuration.

But my IPv6 doesn’t go through the NAT (I get a prefix from the ISP) so I think I need a different strategy there.

Yes all rules where created for both protocols.

I think the pi-hole development team should really start planning for a world where more and more clients and devices are hard-coding DNS IPs, and the pi-hole must become a router for all network traffic to work.

Because in my opinion this outcome is inevitable… I can’t say if it will be a significant problem in 4 years, or 10 years, but it is definitely coming.

The good news is the hardware is getting there… a 1GB or 2GB Pi 4 can definitely handle monitoring all in/out internet traffic on the average home network no problem. We just need pi-hole to keep pace :wink:

Routers already can do this, so there is little point in turning Pi-Hole into a router.