Skip to content

Latest commit

 

History

5 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 

Repository files navigation

smart-home-telemetry-blocklists

Validate License Last update

Multi-vendor DNS blocklists for smart-home/IoT devices that phone home more than they need to. Block the telemetry, keep the device working.

Philosophy

Most consumer IoT vendors route local device control through their cloud. Turning on a lightbulb on your own LAN can still trigger a DNS lookup and a round-trip to a vendor's servers. That's not always avoidable, but a lot of what these devices call home for is diagnostics, analytics, and marketing telemetry that has nothing to do with the device working.

This project's rule for every domain added here:

  1. Block telemetry, not function. If blocking a domain breaks core device operation (pairing, local control, firmware updates), it goes in the vendor's whitelist as a documented exception, not silently omitted.
  2. Evidence over guessing. Every domain is backed by a cited source (packet capture writeups, vendor forums, community integrations). No domain is added because it "sounds like telemetry."
  3. Reversible by default. Each vendor ships three files: block-only, whitelist-only, and combined, so you can pick your own risk tolerance instead of taking an all-or-nothing list.

Supported vendors

Vendor Status Devices covered
TP-Link ✅ Available Tapo (cameras, plugs), Kasa, Deco, routers/Omada
Google ✅ Available gstatic.com telemetry/metrics CDN (Android, ChromeOS, Chrome)
Samsung Smart TV ✅ Available Tizen ACR/telemetry, Smart Hub ads
LG Smart TV ✅ Available webOS ACR/telemetry, Content Store ads
Roku ✅ Available Roku streaming devices + Roku-OS TVs, ACR/ad telemetry
Vizio ✅ Available SmartCast TV, Inscape ACR (thin list, see vendor README)
Xiaomi / MIUI 🔜 Coming soon -
Reolink 🔜 Coming soon -
Govee 🔜 Coming soon -

Each vendor directory follows the same structure:

vendors/<vendor>/
├── README.md                          # what's blocked, what breaks, sources
├── <vendor>_block.txt                 # block-only list
├── <vendor>_whitelist.txt             # exceptions only
└── <vendor>_block_with_whitelist.txt  # combined, ready to import

Installation

All lists use standard AdGuard Home / Pi-hole domain syntax (||domain^ for blocks, @@||domain^$important for exceptions), so the combined file for each vendor can be imported directly.

AdGuard Home

Settings → DNS blocklists → Add blocklist → Add a custom list, then paste the raw URL of a vendor's *_block_with_whitelist.txt, e.g.:

https://raw.githubusercontent.com/sappafrancesco/dns-blocklists/main/vendors/tplink/tplink_block_with_whitelist.txt

Pi-hole

Group Management → Adlists → Add, paste the same raw URL, then Tools → Update Gravity.

NextDNS

Settings → Denylist → Add a URL and paste the same raw *_block.txt URL. NextDNS doesn't process @@ exceptions from custom denylists, so add the vendor's *_whitelist.txt domains individually to your NextDNS Allowlist if you need the documented exceptions.

Contributing

PRs adding a new vendor or expanding an existing list are welcome.

  1. Follow the 3-file structure above for any new vendor.
  2. Cite a source for every domain you add (packet capture, vendor forum thread, community integration repo, etc.) in the vendor's README.
  3. If a domain is required for core device function, don't just omit it: add it to that vendor's whitelist with a comment explaining why.
  4. Run scripts/validate.sh before opening the PR; the same check runs in CI on every push/PR.

Methodology

Domains are only added after being observed or reported via at least one of:

  • Packet captures / DNS query logs from real devices (own testing or published writeups)
  • Vendor community forums where users report specific hostnames
  • Existing open-source integrations for the device (e.g. Home Assistant custom components) that reference vendor API hostnames
  • Cross-referencing with other public blocklists (e.g. hagezi/dns-blocklists) for corroboration, never copied without independent verification

Every domain's source is cited in that vendor's README.md. Anything whose blocking impact is uncertain gets called out explicitly rather than silently included.

Disclaimer

These lists are provided as-is, with no warranty of any kind. Blocking a domain can break device functionality in ways not yet documented here. Vendors change their infrastructure without notice. Test in your own environment before relying on this for anything you can't afford to have break. You are responsible for what you block.

License

GPL-3.0, chosen so that forks and derivative blocklists must stay open and freely redistributable, matching how most established DNS blocklist projects (hagezi, oisd) license their work.

About

Multi-vendor DNS blocklists for smart-home/IoT telemetry

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages