You install AdGuard Home on a Sunday afternoon. You pick a big blocklist — something aggressive, highly recommended. You point your router's DNS at it. Monday morning, your Google Analytics dashboard is blank, your spouse's banking app spins forever, and your kid's game can't connect to the server. You have just traded one kind of broken for another. That's the tension at the heart of what Daniel sent us. He wants to talk about how to run network-level DNS blocking that actually works — blocking nuisance ads, invasive telemetry, and tracking pixels — without nuking the services you need. And his real question is: what's the workflow for getting that balance right?
That broken dashboard is not a bug — it's a feature of how DNS blocking works. Let's unpack why.
Before we get into the fix, I want to name the three things people are actually trying to block, because they're not the same problem and treating them identically is where a lot of setups go wrong. Nuisance ads are the most visible — banner ads, pop-ups, video pre-rolls. They're annoying and they slow page loads, but they're primarily a revenue model. Invasive telemetry is different — that's your operating system phoning home, your smart TV reporting what you watch, your printer sending usage stats back to the manufacturer. And then there's tracking pixels and cross-site profiling — the invisible infrastructure that builds a dossier on you across every site you visit. Three different threat models. A blocklist that treats them all the same is going to break things.
And network-level blocking is uniquely powerful precisely because it catches all three. A browser extension only sees browser traffic. It can't stop your smart TV from calling home, or your IoT thermostat from beaconing out telemetry, or a locked-down corporate laptop from connecting to analytics endpoints. DNS blocking intercepts the query before it ever reaches the device. The device asks "where is ads dot samsungads dot com" and your AdGuard Home server says "nowhere." That's the whole mechanism. And AdGuard Home specifically — open-source, self-hosted, runs on a Raspberry Pi or an old laptop — supports per-client filtering, a live query log with search, and multiple blocklist formats. It's the reference implementation for this conversation.
Why AdGuard Home over Pi-hole? Because a lot of people start there.
Pi-hole is excellent software, but it uses a single global allowlist and blocklist. Every device on your network gets the same filtering. AdGuard Home does per-client filtering natively — you can block a domain on your smart TV but allow it on your work laptop. That's the differentiator that makes this whole workflow possible. Pi-hole can approximate it with group management, but it's bolted on. AdGuard Home was built for it.
So how does a well-intentioned blocklist turn your smart TV into a brick? It starts with the query log.
The query log is the single most underused tool in AdGuard Home, and it's where everything we're about to discuss lives. Let me walk through what you actually see. You open the AdGuard Home admin interface, go to Filters, then Query Log. At the top there's a search bar and a set of filter buttons — you can filter by blocked only, allowed only, by client IP, by domain. When a domain gets blocked, the log entry shows you the exact filtering rule that triggered it — the blocklist name, and the line number in that list. So you don't have to guess why something broke. You see "blocked by AdGuard DNS filter, line fourteen thousand two hundred seven." That's forensic-level detail.
Which matters because most blocklists are curated by aggregating domains observed in tracking contexts. But a huge number of those domains serve dual purposes. Google Analytics is the classic — block www dot google hyphen analytics dot com and you stop tracking pixels, but you also break every GA4 dashboard you need to log into for work. Connect dot facebook dot net is both the Like button embed and the Facebook Login SDK. Block it globally and federated login breaks everywhere.
And that's the collateral blocking problem in a nutshell. The blocklist curator sees a domain used for tracking and adds it. They don't know — can't know — that you personally need that domain to access your marketing dashboard or your ad account. So the tool does exactly what you told it to do, and your stuff breaks. The fix isn't to remove the blocklist. It's to get precise about what you allow, where, and for whom.
Let's get concrete. What's the actual triage workflow when something breaks?
Step one: someone in your house says "the internet is broken." Could be a blank dashboard, a spinning login screen, a video that won't play. Step two: you open the AdGuard Home query log and filter by blocked domains. Step three: you sort by time — the most recent blocked queries are at the top. Step four: you look for domains that were blocked right around when the problem started. Step five: you click the blocked entry and read the filtering rule. Now you know exactly which blocklist and which rule did it. Step six: you decide whether to allow that domain globally, allow it only for a specific client, or leave it blocked and find another way to access the service.
That decision — global versus per-client — is where the whole strategy lives.
And here's the three-tier approach that actually works in a household with mixed use cases. Tier one: per-client disallowed domains. You block telemetry on IoT devices but allow it on your work laptop. The smart thermostat doesn't need to talk to Google Analytics. Your browser might, if your job requires it. Tier two: per-client allowed domains. You whitelist analytics dot google dot com only for the specific browser or device you use for work dashboards. Every other device on the network still blocks it. Tier three: DNS rewrites. Instead of returning NXDOMAIN — which means "that domain doesn't exist" — you return a custom IP. For most clients you return zero dot zero dot zero dot zero, which is a black hole. For specific MAC addresses, you return the real IP. Same domain, different answers depending on who's asking.
So the smart TV gets told "ads dot samsungads dot com doesn't exist," but the marketing team's laptop gets the real IP. Same query log, same blocklist, different outcomes.
And AdGuard Home's filtering syntax gives you the tools to do this precisely. The dollar sign important modifier overrides allowlist rules — so if you've globally allowed a domain but want to make absolutely sure it stays blocked on a specific client, you mark the blocking rule as important and it wins. The dollar sign ctag equals modifier applies a rule only to clients with a specific tag. You tag your IoT devices as "iot" and your work devices as "work," and then rules only fire for the tagged clients. And dollar sign dnsrewrite lets you return a custom IP instead of NXDOMAIN. These three modifiers are the difference between a setup that works and one that gets turned off after a week.
Let's do a real case study, because this is where it stops being abstract. Someone's running AdGuard Home with a popular blocklist. Their marketing team can't access a dashboard that ingests data through pixel dot quantserve dot com. That domain is in the blocklist because QuantServe is a tracking and analytics company. But the dashboard needs it. What do you do?
First, you confirm it in the query log. You filter by blocked, search for quantserve, and you see it being blocked every time someone on the marketing team tries to load the dashboard. The log shows the exact rule and blocklist. Now you have a choice. Option A: globally allow pixel dot quantserve dot com. That fixes the dashboard but now every device on your network can connect to QuantServe tracking — including your smart TV, your phone, your kid's tablet. You've just re-enabled tracking for everyone. Option B: create a client tag called "marketing," apply it to the specific browser or device the marketing team uses, and add an allowlist rule with dollar sign ctag equals marketing. Now that domain resolves only for that one client. Every other device still blocks it. Option B is the correct answer.
And this is where most people go wrong. They hit the problem, they Google it, they find a forum post that says "just whitelist this domain," and they add a global allow rule. Problem solved. But now they've punched a hole in their blocklist that every device can walk through. Do that ten times and your blocklist is Swiss cheese.
Here's another case study that trips people up constantly. Smart TV stops streaming because it can't reach ads dot samsungads dot com. The TV's firmware is hardcoded to phone home to Samsung's ad server before it'll stream anything. Block that domain and the TV just sits there. The naive fix is to globally allow it. Now every device can reach Samsung's ad infrastructure. The correct fix: identify the TV's MAC address in the AdGuard Home client list, and add a per-client allow rule that only applies to that MAC. The TV gets its ad server. Nothing else does.
And you can verify this is working because the query log shows you the client IP or MAC for every query. You'll see the TV's requests being allowed and everyone else's still being blocked. That visibility is the whole game.
Once you know how to read the log, the next question is: what do you do with that information? This is where most people go wrong.
They add more blocklists.
They add every blocklist they can find. There's a GitHub repo with a curated list of blocklists, and people just subscribe to all of them. Thirty, forty blocklists. And then everything breaks and they can't figure out why, because now a blocked domain could be coming from any of forty sources. The query log still tells you which list and which rule, but the false positive rate goes through the roof.
Why? Aren't more blocklists just more coverage?
Blocklists overlap massively. The top five or six popular lists probably cover ninety-five percent of the same domains. But they also have edge-case differences — one list blocks a CDN domain that another list leaves alone. When you stack lists, you're not getting meaningfully better coverage. You're getting all the edge-case conflicts from every list simultaneously. The false positive rate increases exponentially, not linearly. And debugging becomes a nightmare because now you're managing exceptions across forty different rule sources.
So what's the actual starting point?
The AdGuard Home FAQ recommends starting with a single curated list. OISD Big is the one most commonly suggested — it's aggressive but well-maintained, and the maintainer actively removes false positives based on user reports. You install AdGuard Home, you add OISD Big as your only blocklist, and you run it for a week. You do not add a second list. You spend that week watching the query log, identifying false positives, and building your per-client allowlist. Only after the setup is stable — no more "the internet is broken" complaints — do you consider adding a second list. And when you do, you repeat the monitoring cycle.
A week of active monitoring sounds like a lot of work.
It's front-loaded. The first month of running network-level blocking is the hardest. After that, the maintenance drops to maybe fifteen minutes a month. But that first month requires attention, and most people aren't warned about that. They think it's set-and-forget. It's not. It's set, monitor, tune, monitor, tune — and then it's mostly forget.
There's a knock-on effect here that I think is worth naming. Aggressive blocking creates a false sense of security. Someone blocks all Google and Facebook domains, feels great about it, and then discovers they can't use Sign in with Google, can't load embedded maps, can't solve reCAPTCHA challenges. So they disable the blocklist entirely. They go from blocking everything to blocking nothing. A moderate, targeted approach that preserves functionality is actually more private in practice because people stick with it.
Sustainability is the metric that matters. A blocklist that gets turned off after three days provides zero privacy. A blocklist that blocks eighty percent of tracking but stays on for three years provides enormous privacy. The goal is not to block everything — it's to block the things that don't serve you while allowing the things that do.
Let's talk about the difference between blocked and rewritten in the query log, because it's a distinction that unlocks a lot of power.
When AdGuard Home blocks a domain, by default it returns NXDOMAIN. The client asks "where is this server" and gets back "it doesn't exist." The connection never happens. That's clean and fast. But sometimes you want more control. A DNS rewrite returns a custom IP instead. For ad servers, you might rewrite the domain to one twenty-seven dot zero dot zero dot one — localhost — so the request goes nowhere but doesn't throw an error that breaks page rendering. For analytics dashboards on specific clients, you rewrite to the real IP while everyone else gets the black hole. The query log shows both — blocked entries say "blocked" and show the rule, rewritten entries say "rewritten" and show the custom IP.
So you can have three different outcomes for the same domain across three different clients. The IoT camera gets NXDOMAIN. The family tablet gets rewritten to localhost so pages load cleanly. The work laptop gets rewritten to the real IP. Same domain, same blocklist, three different answers.
And that's what makes AdGuard Home's per-client architecture genuinely powerful. It's not just blocking or allowing. It's answering differently depending on who's asking.
There's a privacy trade-off in the query log itself that I think we should address. AdGuard Home stores every DNS query by default. Every domain your devices look up. That's itself a privacy concern — you've just built a perfect surveillance tool for your own network.
This is the paradox of DNS logging. The query log is essential for debugging and tuning, but it's also a complete record of every domain every device on your network has ever requested. If someone gets access to your AdGuard Home instance, they have a detailed picture of your household's internet activity. The fix is configuration. Set log retention to seven days — that's enough for debugging cycles without building a permanent record. You can disable logging entirely for specific clients — family members who opt out, guest devices. And you can enable anonymized client IPs in the log, so you see that some client queried a domain but not which specific device.
Seven days seems like the sweet spot. Long enough to catch patterns, short enough that you're not building a dossier on your own family.
And you should set a calendar reminder to review the query log monthly even after the initial tuning period. Blocklists change. Maintainers add and remove domains. New tracking services emerge. Old allowlist rules may become unnecessary — a domain you whitelisted for a service you no longer use. Monthly review keeps the setup tight.
Let's turn all of that into a repeatable workflow you can start using tonight. What's step one?
Step one: install AdGuard Home. It runs on Linux, Windows, macOS, or a Raspberry Pi. Point your router's DNS at it, or configure individual devices if you want to start gradually. Step two: add exactly one blocklist. OISD Big or the AdGuard DNS filter. Not both — one. Step three: monitor the query log for forty-eight hours. Filter by blocked domains. For each blocked domain, ask yourself: did anything break? If yes, identify which client and which service. Step four: for each false positive, decide whether the domain is needed by one client or all clients. Add a per-client allow rule if it's only one device. Add a global allow rule only if every device needs it. Step five: after one week of stability, add a second blocklist and repeat the monitoring cycle. Step six: set log retention to seven days, configure client anonymization if desired, and put a monthly calendar reminder to review the query log.
And the rule of thumb for domains you don't recognize?
If a domain is blocked and you don't know what it does, look it up before whitelisting. Services like urlscan dot io or whois dot domaintools dot com will show you what's hosted there and who owns it. Many tracking domains also host malware or phishing infrastructure. The fact that something broke doesn't automatically mean the domain is safe — it just means something you use depends on it. Do the lookup, then decide.
There's a misconception I want to head off directly. Some people think "if I block all tracking domains, I'm fully private." That's not true. Many tracking domains are also CDNs for legitimate services, and blocking them breaks functionality without eliminating all tracking. Browser fingerprinting via canvas, WebRTC, and browser headers doesn't touch DNS at all. DNS blocking is one layer. It's a powerful layer. It's not the only layer.
And the companion misconception: "I can add every blocklist I find and it will just work." We covered this, but it's worth repeating because it's the number one mistake new AdGuard Home users make. Blocklists overlap and conflict. Adding multiple aggressive lists increases false positives exponentially without meaningfully improving coverage. Start with one. Get it stable. Add a second only if you have a specific reason.
There's a third one that's more subtle. People treat the query log as just a debugging tool — something you look at when something's broken and ignore the rest of the time. But the query log is a privacy tool in its own right. It reveals which devices are phoning home to which services. That awareness — just knowing that your smart TV talks to six different analytics domains every time you turn it on — is itself a form of privacy. You can't make informed decisions about traffic you don't know exists.
The query log is the dashboard for your network's behavior. Most people have never seen what their devices actually do. The first time you open it and watch the queries scroll by in real time, it's eye-opening. Your printer is talking to HP's analytics. Your TV is talking to Samsung, Netflix, and three ad networks you've never heard of. Your phone is resolving tracking domains even when the screen is off. That visibility changes how you think about the devices you bring into your home.
One last thing to keep in mind as you build your setup. The landscape is shifting under our feet. More and more services are moving to encrypted DNS — DNS over HTTPS, DNS over TLS, DNS over QUIC. When every app uses its own DoH resolver, network-level blocking stops working because the queries bypass your AdGuard Home server entirely. AdGuard Home supports encrypted DNS itself — you can configure it as a DoH or DoT resolver — but the cat-and-mouse game continues. Browsers like Firefox and Chrome can be configured to use their own DoH resolver, and some apps hardcode their DNS. The future of network-level filtering is an arms race.
For now, the countermeasure is to block known DoH servers at the firewall level — if the app can't reach its hardcoded DoH resolver, it falls back to the system DNS. But that's a losing strategy long-term. The real question is whether DNS-level blocking remains viable when every application brings its own DNS. We're not there yet, but we're heading there.
Which is why the skill of reading your own traffic — understanding what your devices are doing and making informed decisions about what to allow — is the thing that outlasts any specific tool. AdGuard Home might not be the answer forever. But knowing how to look at a query log and say "that domain serves me, that one doesn't" — that's a permanent capability.
The goal is not to block everything. It's to block the things that don't serve you while allowing the things that do. That requires understanding your own traffic. And that understanding is a superpower in itself.
The single biggest misconception people hold about this topic is that DNS blocking is set-and-forget — you install it, add some blocklists, and walk away. The reality, as we've laid out, is that it's an ongoing practice. You monitor, you tune, you make per-client decisions, and you review monthly. The tool is powerful, but the power is in the workflow, not the install.
And the workflow is learnable. It's not arcane. It's just not obvious until someone walks you through it. Once you've spent a week with the query log, you'll never look at your home network the same way again.
Thanks as always to our producer Hilbert Flumingtop for keeping this show running. This has been My Weird Prompts. If you want to send us your own questions — maybe about a tool you're trying to configure, or a workflow you're trying to get right — email the show at show at my weird prompts dot com. We'll be back soon.
