An ad blocker installed in the browser protects only that browser. The smart TV, smartphone apps, the console and connected appliances keep contacting advertising and telemetry servers. A local DNS filter works one level lower and covers the whole home with a single device.
The basic idea
Before connecting to a server, every device asks DNS to translate a name, for example that of an ad server, into an IP address. A DNS filter sits in the middle of this request: if the name appears on a blocklist, it replies with a null address and the device cannot connect. If the name is legitimate, it forwards the question to an external DNS server and returns the answer.
The device does not know it is being filtered: it simply receives an answer. That is why the system also works on devices where nothing can be installed.
Pi-hole and AdGuard Home
The two most popular projects are free software and run well even on modest hardware, such as a mini PC, a Raspberry Pi or a container on a home server.
| Feature | Pi-hole | AdGuard Home |
|---|---|---|
| Installation | Script on Linux, also container | Single binary, also container |
| Interface | Web, with detailed statistics | Web, with statistics and per-client rules |
| Encrypted DNS upstream | Via add-on components | Built in |
| Per-device rules | Client groups | Per-client settings |
| DHCP server | Available | Available |
Both do the main job well. AdGuard Home is more straightforward if you want encrypted upstream DNS without extra configuration; Pi-hole has a large community and many guides.
Network installation, step by step
- Fixed address: give the filter a static IP or a DHCP reservation on the router. If the address changes, nobody resolves names any more.
- Install the software and choose the external DNS servers to forward requests to.
- Test on a single device: manually point a PC's DNS at the filter and browse for a few days.
- Roll out to the whole home: in the router's DHCP settings, set the filter as the DNS server. Devices will receive it when their lease renews.
Avoid listing a public "backup" secondary DNS in DHCP: many devices use both at random and ads would reappear intermittently. If you want redundancy, use two instances of the filter.
Blocklists: less is more
It is easy to overdo it by adding dozens of lists found online. More lists mean more unwanted blocks: shopping sites that do not load, links in emails that do not open, apps that stop working. A sensible approach:
- start with one or two reliable general-purpose lists;
- add specific lists only for precise needs, such as the telemetry of a particular device;
- keep an allowlist for the domains you really need.
When something goes wrong, the query log shows in real time what was blocked and for which device. It is the most useful tool in the filter, and also an interesting window into how much household devices talk.
Limits to be aware of
A DNS filter is not a magic solution:
- Ads served from the same domain as the content: if ads and videos come from the same name, blocking one means blocking the other. Some video platforms cannot be filtered well at DNS level.
- Encrypted DNS on devices: browsers and operating systems can use DNS over HTTPS towards external servers, bypassing the filter. It has to be disabled in the device settings or handled with rules on the router.
- Hard-coded DNS in firmware: some devices ignore the DNS received via DHCP. A router rule that redirects all requests on port 53 to the filter solves many of these cases.
Redundancy and reliability
If the filter goes down, at home "the internet stops working", even though the connection is fine. In my work I always recommend at least one of these precautions:
- two instances on different devices, kept in sync, both listed in DHCP;
- an uninterruptible power supply for the device hosting the filter;
- a written procedure to switch back to the router's DNS within seconds in case of failure.
In short
- A local DNS filter blocks ads and tracking on every device at home.
- Pi-hole and AdGuard Home are free, lightweight and well documented.
- Give the filter a fixed IP and distribute it through the router's DHCP.
- Use a few reliable lists and an allowlist.
- Plan a second instance or a quick fallback in case of failure.
