An investigation, not a verdict
You bought a television. It appears to have accepted a second job. Before accusing it of anything, collect evidence.
Pi-hole filters DNS: the lookups devices use to find services by name. A query can reveal a requested domain, but it does not show the encrypted contents of a connection or establish why the request happened. A domain name alone does not prove spying.
Choose a small, reversible trial
You need a spare host running a currently supported Linux distribution, a stable LAN address, administrator access, and one test device whose DNS settings you can change. A Raspberry Pi is optional. Check Pi-hole’s current operating-system, memory, storage, and port requirements. Keep another way to read the instructions if the host loses connectivity.
Start with your own laptop, then a TV if it exposes suitable settings. Record the device’s existing DNS configuration, including whether it is automatic. Use a DHCP reservation or another correctly configured stable address for the Pi-hole host. An example address in this article is not an address assignment for your network.
Leave the household router and DHCP service unchanged for this first trial. Keep the resolver and administration interface inside your trusted LAN; do not add internet port forwards. A shared network also means shared browsing metadata: tell other users before collecting their queries.
Install on the spare host
Use the official installation instructions on that Linux host. They offer an automated installer, a download-and-review alternative, and a separate Docker route. Read what you are going to run before granting it administrator privileges. This guide does not install anything on the computer you are reading it from.
During setup, note the host’s address and your chosen upstream DNS provider. Pi-hole forwards permitted lookups upstream, so running it does not remove the upstream provider’s role. Protect the admin login, complete the installation, and confirm the dashboard opens from your trusted LAN. Record the Pi-hole version and the date.
For the trial, manually point only the test device’s DNS at your host’s real LAN address. The post-install documentation covers per-device and router-based arrangements. Do not add a public secondary resolver expecting it to act only as an emergency backup; clients can use it and bypass your filter.
Prove the query path before counting blocks
From a Windows test laptop, query the host directly. Replace the example address with your Pi-hole address:
nslookup example.com 192.168.1.50Find the corresponding request in the dashboard’s query log. This establishes that the explicit query reached Pi-hole. It does not prove every browser request uses that resolver. Browser encrypted-DNS settings, VPNs, device-specific resolvers, IPv6 DNS configuration, and cached answers can produce different paths.
For a repeatable blocking test, add example.com as an exact deny entry in the dashboard, repeat the lookup, and check the log’s blocking status. It is a reserved example domain, not a suspected tracker. In Pi-hole’s default NULL blocking mode, a blocked A lookup normally returns 0.0.0.0; other configured modes behave differently. See the blocking-mode reference. Remove the temporary deny entry afterward and verify ordinary resolution returns.
Observe one device and record breakage
Now use the chosen device for an ordinary session. Note the time window, the feature you used, requested domains, blocked decisions, and whether the feature worked. A short idle baseline followed by the same duration of active use makes a useful comparison, though caching and background tasks limit what it proves.
If the log shows only your router as the client, you may not have enough attribution to call a request a TV request. Mark it unattributed. Keep query logs private: even domain-only records can describe someone’s habits.
Do not assume a larger block percentage is better. If a feature fails, compare the time of failure with the query log, undo the latest change, and retry. Allow a specific domain only when you understand why it is needed. If restoring the old DNS settings does not fix the issue, the filter may not be the cause.
Restore the settings before expanding
Return the test device to its recorded DNS settings, then verify ordinary browsing or playback still works. Remove your temporary test entry and keep a private record of any exceptions. Only after a successful trial should you consider a documented router change, household notice, and an outage/recovery plan.
DNS filtering does not inspect page paths, remove every advertisement, encrypt traffic, or block requests that bypass the resolver. Blocking a domain shared by useful content and advertising can break both. It is one control with a specific boundary, not a replacement for browser permissions, updates, or account security.