Set up a port 53 redirect in pfSense. The amount of hardcoded DNS traffic sneaking past the Pi-hole in just an hour is crazy.
Decided to finally drop an outbound port 53 redirect rule on my firewall to catch devices trying to sneak past my Pi-hole. This list is from about an hour of logs right after turning it on, and the amount of stealth traffic that immediately lit up the dashboard is crazy.
If you aren't doing this at the firewall level, your smart gear and applications are almost definitely talking right past your setup using hardcoded public servers like 8.8.8.8 or 1.1.1.1.
I used an inverted match NAT port forward rule in pfSense paired with Hybrid Outbound NAT. If a device sends a DNS query to an IP that isn't my Pi-hole or my gateway, the firewall transparently hijacks the packet and forces it to the Pi-hole anyway. Because of the NAT rewrite, they all show up in the log under the router's IP (192.168.1.1).
Here is the wall of shame from just the first 60 minutes:
- Eero Mesh Nodes (
node.e2ro.com,eeroup.com,edge.e2ro.com): Unbelievably aggressive. Even when forced into bridge mode as dumb access points, their firmware ignores DHCP DNS configurations completely and spams public servers every few minutes for cloud heartbeats and connectivity checks. - TP-Link / Tapo Gear (
tplinknbu.com,tplinkcloud.com): Caught a bunch of my Tapo cameras phoning home. They don't just hit generic domains; they bypass local resolution to match up to hyper-specific AWS instance IDs and dump data analytics to endpoints liken-use1-da.tplinkcloud.com. - Tencent IoT Video (
ap-singapore.gateway.iotvideo.tencentcs.com): Caught a budget smart camera mapping its video infrastructure all the way back to a Tencent server cluster in Singapore. Completely hardcoded straight into the firmware. - NordVPN (
napps-1.com,pdp.napps-1.com): Even commercial privacy tools do it. The Windows app completely bypasses system DNS parameters to hit their background update platform and Product Data Platform (pdp) servers. - Plex (
plex.tv,v4.plex.tv,plex.direct): Caught streaming clients using hardcoded public paths to resolve the local secure HTTPS connection strings (192-168-1-100...plex.direct) back to my own internal server IP, along with fast telemetry calls toscrobbles.plex.tv. - Amazon Smart Gear (
api.amazon.com): Fast, constant background chatter refreshing session tokens and profile preferences. - Even local scripts (
oisd.nl,githubusercontent.com): Caught a backup ad-block script running on a local box that was hardcoded to bypass local DNS entirely just to download its updated blocklists.
It seems pretty clear (at least in my case) If you aren't actively trapping outbound port 53, you're missing a massive chunk of telemetry and tracking traffic.