Setting Up DNS-Level Filtering at Home: A Practical Walkthrough

Last updated: October 29, 2026 · Based on published project documentation

The previous guide in this section covered what DNS-level filtering does and does not accomplish. This one is the practical companion: how to set it up, what order to do things in, and how to avoid the two-hour debugging session that most first attempts turn into. It is deliberately conservative. There is nothing here that requires editing a dozen files at once, and nothing that leaves you without a working network if you stop halfway.

Table of contents

• Before you start: what you need and what to check
• Choosing where the filtering runs
• Step one: get the resolver running and reachable
• Step two: point the network at it
• Step three: add lists and watch what breaks
• Building a deliberate exception list
• Devices that will not use it, and what to do
• FAQ
• Bottom line

Before you start: what you need and what to check

• What you will need. A machine that stays on and can be reached on the local network — a small dedicated device, a spare computer, or a server you already run. [VERIFY the current hardware requirements and supported platforms against the project's own documentation, as this changes.]
• Your router's DNS setting, and where it is documented. You will change it, and you will want to put it back. Note the current values before you touch anything.
• Access to your router's administration interface. Usually a local address, often with credentials printed on the device.
• Ten minutes of not needing the network. Changing the resolver affects everything on the network at once, and the steps below assume you can recover if something goes wrong.
• A way back. Know how to set the router's DNS back to automatic before you start. This is the single most important preparation, because a misconfigured resolver that you cannot undo is a bad afternoon.

Choosing where the filtering runs

There are three practical arrangements, and the choice determines how much work the project is.

• A dedicated small device on the network. The cleanest arrangement: a low-power machine that runs the resolver permanently, serving the whole network. It does one job, it is easy to inspect, and when it goes down you change one setting on the router.
• A container or virtual machine on an existing server. Reasonable if you already run one and can accept that a host update can affect it. If the resolver shares a machine with many other services, an outage takes more with it.
• On the router itself. Some routers include filtering. This avoids a separate device, and it comes with the router's own limitations and configuration interface.

Whichever you choose, run the resolver first and test it directly before pointing the network at it. The order matters more than the choice.

Step one: get the resolver running and reachable

Install the filtering software and start it with no lists enabled at all. This is deliberate: it lets you confirm the resolver works before you introduce the thing most likely to break it.

• Confirm it is listening on the expected port, and bound to the address other devices will reach it on — not only to localhost.
• Query it directly from another machine on the network, using the address you assigned. A name should resolve to a normal address.
• Test a name you expect to be blocked later and confirm it currently resolves normally. This is your control.
• Give it a static address. A dynamic address that changes leaves you pointing the router at nothing after a reboot.
• Make sure it starts on boot. A resolver that stops when the machine reboots means the network loses DNS until you notice.

Do not proceed until a device on the network can resolve names through this resolver. Every later step depends on it, and the failures are much harder to diagnose once the whole network is pointed at it.

Step two: point the network at it

Now change the router's DNS setting to the resolver's address, and save.

• Change one setting and save. Most routers apply a DNS change immediately, which means every device on the network is affected at once. This is why step one matters.
• Immediately test on a device whether normal browsing works.
• If it does not, set the router's DNS back to automatic and confirm browsing returns. Do this before troubleshooting anything else, because a working network with no filtering beats a broken network with an interesting configuration.
• Once it works, test with a name you expect to be blocked. At this point nothing should be blocked, so this is still a control.

If the router will not accept a custom DNS, two alternatives exist: configure DNS per device, which is more work but more contained, or use DHCP to hand out the resolver's address automatically, which is convenient but depends on the router's DHCP options. [VERIFY the options your router supports.]

Step three: add lists and watch what breaks

Now enable a list, and enable only one to begin with.

• Start with a modest list. A small, well-maintained list that covers known advertising and tracking domains is a better starting point than the largest available one. You can expand it later; recovering from an overly broad list is harder than adding to a working one.
• Add the list, then browse normally for a while — your regular sites, your mail, your video calls, your banking.
• Note anything that breaks and add an exception for it. Do not disable the list; refine it.
• Only then consider a second list. Adding one at a time means you can attribute a problem to a specific list.
• Check the query log. Most resolvers keep a record of what was asked and what was answered. This is how you diagnose a specific site: look up what it requested and what happened to it.
• Keep the lists updated. A list that has stopped being updated stops blocking anything new, and you will not notice. Check the update status periodically.

Building a deliberate exception list

This is the part that determines whether the setup survives. The exception list should be short, and each entry should exist because something broke.

• Allow the specific domain that broke, not the whole site. Most resolvers support an exact domain or a wildcard. Start narrow.
• Note why. A comment saying which site and which symptom turns a list of exceptions into a record you can act on later.
• Watch for the pattern. If several services from one provider are breaking, allowing that provider's whole domain is simpler and less likely to break again.
• Watch for shared infrastructure. Blocking a shared domain can break every site hosted on it, because the block is by name and the name is shared. This is the most common cause of “one site broke and then three more did.”
• Review it every few months. Remove exceptions for services you no longer use.

Devices that will not use it, and what to do

• Devices with their own DNS setting. Some routers, printers and smart home devices are set to a specific resolver or ignore DHCP entirely. Check the ones that behave oddly.
• Private DNS on Android. The system setting for encrypted DNS takes precedence over the network resolver and bypasses your filtering entirely. This is worth knowing because it is easy to enable without realising, and the effect is that filtering silently stops working on that device.
• VPNs on the device. A VPN route usually takes its own DNS, which may bypass your resolver.
• Mobile data. None of this applies when the device is not on your network, which is expected.
• Guest networks. Frequently isolated, and often given their own DNS. Sometimes a good thing.

FAQ

How long does this take?

The initial setup — running the resolver, pointing the network at it, confirming both work — is usually an evening at most. The ongoing work is a few minutes a month maintaining exceptions. That is a fair account of it, and it is worth having in mind before you start.

Will this break my smart home devices?

Possibly, and it is the most common early problem. Many such devices expect to reach a specific name, and a blocked or unresolvable request stops them. It usually resolves with an exception for the affected domain. Setting up the resolver before changing the network, as above, makes this much easier to diagnose.

Can I run this on a Raspberry Pi?

It is a common choice for exactly this reason, and the project's own documentation covers supported hardware. Two practical points: give it a static address, and make sure it starts automatically after a power cut, because a home network without DNS is an outage. [VERIFY current hardware support before buying anything.]

Do I still need a tracker-blocking extension in the browser?

Yes, for the trackers that are not separate domains. This handles the network layer; an extension handles what the page does with the requests it makes itself. The two are complementary rather than alternatives, and the layering is set out in ad and tracker blocking layers.

What happens if the resolver machine dies?

DNS stops and browsing stops with it, until you either restore the service or put the router back to automatic. This is the strongest argument for a small dedicated device and for keeping the recovery steps written down somewhere you will find them under pressure — a photograph of the router administration page with the current values is enough.

Is there any downside for gaming or video calls?

Usually not, and sometimes an improvement, because blocked requests fail immediately rather than loading. The exception is when a service you use relies on a domain you have blocked, which shows up as the service failing rather than as slow browsing.

Bottom line

The order of operations is what makes this easy: run the resolver first and test it directly, point the network at it with no lists enabled and confirm everything still works, then add one list and refine it as things break. Most of the difficulty people report with this kind of setup comes from doing it in the reverse order — changing the network and adding a large list at the same time, so that when something breaks you cannot tell which change caused it. Budget an evening for the setup and a few minutes a month afterwards, keep the exception list short and deliberate, and write down the router's original DNS setting before you change it. The result is a network where a meaningful volume of third-party requests is never made, with no ongoing subscription and no new device to manage beyond the one doing the work.

If you want to see what browser-level filtering costs as a second layer, the link below goes to our own page for the category.

See current blocking tool plans →