Then people need to decide what their limit of bullshit is. If you are willing to accept blackboxes being attached to your network, to have all of your traffic flow through a device you have no say or control over, nor any real idea if it's sending everything that flows through it to an adversary you don't want, well all bets are off. Ad blocking won't be a concern anymore, you'll only be allowed to visit "approved" sites, speak the approved newspeak, read the approved blogs and sites, etc...
I wear tin foil regularly, but if you accept to have uncontrollable devices as Big Brother's Helper then you're screwed hard.
2 Likes
If your router doesn't allow to redirect traffic, it might worth looking if it has some kind of firewall settings. It might allow you to block outgoing traffic on port 53 except for your pihole. I have good experience with blocking outgoing DNS traffic for all devices except from my pihole - it forced Googles IoT devices to honor my DHCP settings and fall back to my pihole as DNS server instead of the hard coded google DNS servers.
Of course it is not guaranteed to work like that with all devices or still work after any kind of software/firmware update. But still might be worth a try.
1 Like
(very late to the game...)
Here is how I hacked it...
- Created a router iptables entry to redirect outgoing DNS request going to 8.8.8.8 (dns.google) to a local container/port.
- The container (Alpine based) is running a simple Python script, listening on the redirected-to UDP port, for those redirected requests.
- The script issues a request to my local DNS server (Pi-Hole...) for the requested fqdn.
- Response is returned to the requesting entity (known as the DNS request packet's source IP is unchanged) by creating a DNS response packet with dst ip set to that of the original request issuer. The response packet's source IP is set to 8.8.8.8 .
A hack, but it works for me...
The reason this is required is the client must receive the response from 8.8.8.8 - not the local DNS server. Thus, the response packet had to be modified, or re-created with 8.8.8.8 as source IP (i.e., spoofed)
Note each spoofed DNS server will require a different UDP port for the script to listed on - there is not was to tell where the original DNS request packet was originally destined for (AFAIK, that is)
(A day later) Well, my Nest-Mini stopped working ("unable to connect to the internet" or something similar). Clearly, my spoofing server/iptables setup does not work (although it did seem to work for a day...). Not sure what is going on.. anyway, I'm attaching the script.
dns_proxy.py (2.0 KB)