DNS-Level Blocking at Home: What Pi-hole Does and Does Not Do
DNS-level blocking is the easiest privacy upgrade most people will ever install and the easiest to get wrong in interpretation. It sounds like a switch you flip for the whole house, and in practice it is a narrower instrument that solves a specific problem while leaving several large ones untouched. This guide explains what happens at the DNS layer, what a blocklist does and does not cover, and the failure modes that make people give up on it after a week.
Table of contents
- What actually happens when a device asks for an address
- What a DNS blocklist covers
- What it cannot reach
- Pi-hole in particular
- The failure modes, and how to diagnose them
- Deciding whether it is worth doing for you
- FAQ
- Bottom line
What actually happens when a device asks for an address
Every device on a network turns a name into a number before anything loads. When you open a site, the device asks a DNS resolver for the address of that name; the resolver answers; the device then connects to that address. A DNS-level blocker changes one thing: it sits between your devices and the resolver, and answers some of those questions itself.
When the answer comes from a blocklist, the request is answered with a null address or a local sinkhole address instead of the real one. The connection either fails immediately or lands on a page you control. That is the entire mechanism, and every strength and limitation follows from it.
Two consequences follow directly. First, the block works before any content is loaded, so it can stop things a content filter would have to load first to recognise. Second, the block is decided by name, not by what the page does — which is why it cannot stop a site that is not on a list.
What a DNS blocklist covers
DNS blocking is good at things that are announced by name, and the coverage depends entirely on the list.
- Known advertising networks. The large shared ad-serving domains are well catalogued, and a standard list blocks a substantial share of them. This is the clearest win and the reason most people notice a difference on the first day.
- Known telemetry endpoints. Many analytics and tracking domains are in the standard lists.
- Malicious hosts. Most blocklists also carry threat-intelligence feeds. These cover known-bad domains rather than bad behaviour.
- Some regional variants. A domain that is blocked may be served under country-specific names that a list may not cover consistently.
The useful frame is that a blocklist is a published set of names. It works well when an adversary uses one name from that set, and not at all when they use something else.
What it cannot reach
This is the part that matters, and it is worth being blunt about it.
- First-party trackers. Analytics embedded in the site you are already visiting is not a separate domain, so there is no DNS query to intercept. A large share of modern tracking works this way.
- Anything served from the same domain as the site. If the tracker is served from the site's own domain, the DNS answer is legitimate and the connection proceeds. The tracker runs; the block never fires.
- Encrypted traffic whose name is not blocked. If the domain is not in the list, the name resolves normally and the encrypted connection proceeds.
- Connections made directly to an IP address. No name means no query means no block.
- Anything on the device that does not use your network's DNS. Some apps ship their own resolver settings, and some operating systems offer per-network encrypted DNS. A device configured that way bypasses a network-level resolver entirely.
- The first-party relationship itself. You are still sending requests to the site. What changes is that some third parties are no longer contacted on your behalf.
None of this makes DNS blocking pointless. It removes a meaningful volume of third-party contact at essentially zero cost. It does not make a browser private, and it is not a substitute for a tracker-blocking browser extension or for browser-level controls.
Pi-hole in particular
Pi-hole is the most common way people set this up at home, and it is worth being specific about what it is. It is a DNS server that runs on your own hardware, queries upstream resolvers on your behalf, and applies blocklists to the answers. [VERIFY the current project status and supported configuration options against the project's own documentation, as this area moves quickly.]
The reason people choose it over a hosted resolver with a subscription attached is straightforward: the filtering happens on hardware they own, and the list membership is theirs to choose. The reason people often abandon it is that the default configuration applies a large list, and a large list breaks things — which is the next section.
The failure modes, and how to diagnose them
Almost every complaint about DNS blocking reduces to one of four causes, and each has a distinct signature.
- The site is genuinely broken by an over-broad list. Symptoms: a specific site fails to load, or loads without content, while everything else works. Cause: a shared or CDN domain was blocked because something else on it was tracked. Diagnosis: allow that single domain and see if the site returns. One exception is usually enough.
- DNS resolution itself is broken. Symptoms: nothing loads, including pages that have nothing to do with blocking. Cause: the resolver cannot reach its upstream, or the device is pointed at the wrong resolver address. Diagnosis: check that the blocking service is running and that the device's DNS setting points at it.
- A feature depends on a blocked domain. Symptoms: sign-in does not complete, a captcha never appears, a map or a payment widget does not render. Cause: the blocklist covers a domain the flow needs. Diagnosis: allow the domain, or allow the whole suffix for that service.
- The device is bypassing the resolver. Symptoms: blocking works on one device and not another, on the same network. Cause: that device uses its own DNS, encrypted DNS, or a VPN. Diagnosis: check the resolver the device is actually using, not the one the router advertises.
The habit that prevents most of this pain is to keep a small, deliberate exception list rather than a large one. Allow a domain when something breaks, and note why. Over time that list becomes a record of which parts of the web you actually rely on — which is more useful than any default configuration.
Deciding whether it is worth doing for you
DNS blocking is a strong first move for several reasons: it applies to every device at once without installing anything, it costs almost nothing in time, and it reduces a real volume of third-party contact. It is worth doing if you want a broad improvement with no per-device effort.
It is not enough if your concern is a specific tracker, if you need to see exactly what a given site loads, or if you want a guarantee rather than a reduction. And it is worth understanding that the two are complementary: DNS blocking removes requests that never needed to be made, while browser-level blocking sees what the page does with the ones that were.
The layered view — what the network does, what the browser does, what the site does — is covered in ad and tracker blocking layers, which works through where each layer sits and what each one is capable of stopping.
FAQ
Will DNS blocking slow my connection down?
Normally it makes it slightly faster, because blocked requests fail immediately instead of being attempted. There is a small overhead from the resolver having to do the filtering work. On a home connection you are unlikely to notice either way, and you will notice if a blocked request was previously loading a heavy third-party script.
Does it work on my phone?
Yes, if the phone uses the network's resolver, which most do by default. It stops working if the phone is set to use its own DNS, if it is on mobile data rather than your home network, or if an app ships with its own resolver configuration. Private DNS on Android is worth knowing about, because enabling it moves name resolution away from your network entirely.
Can a blocked site see that I blocked it?
Generally no. A null response looks like the site does not exist, which is the same signal a typo produces. Some setups resolve to a sinkhole address on your own network, which is also not distinguishable from a failed connection — although it is worth noting that the request for the name still reached your resolver.
Is a bigger blocklist always better?
No, and this is where most people go wrong. A larger list blocks more third parties and breaks more legitimate things, and the breakage is what drives people to disable it entirely. A smaller, well-chosen list with a handful of exceptions you added yourself tends to survive longer.
Does this protect me on mobile data?
No. DNS blocking runs on your network, and mobile data is someone else's network with a different resolver. To cover that you would need blocking on the device itself, which is a browser extension's job rather than your router's.
Bottom line
DNS-level blocking is worth doing for the reason it is usually dismissed: it is cheap, it applies everywhere at once, and it removes a real volume of third-party requests. What it is not is a complete answer, because it works by name and a growing share of tracking does not announce itself under a name worth blocking. Treat it as the bottom layer rather than the whole stack, keep your exception list short and deliberate, and expect to spend an afternoon on the first weekend adding back the things you actually use. If you are willing to do that, it is one of the better privacy-per-hour ratios available.
If you want to see what the browser-level options cost before deciding how far to take this, the link below goes to our own page for the category.