The block happens at the lookup. A name on the list gets a dead-end answer, so your device never even tries to connect to it. Everything else resolves as normal.
Every page you open starts with a name to look up. DNS blocking steps in right there, deciding which names get a real answer and which get a dead end, before a single byte of an ad is fetched.
The idea in one picture
- A blocklist — a list of domains to refuse
- A long, regularly updated list of domain names known to serve ads, track you, or host malware. Things like ads.example-network.com. People maintain these lists so you do not have to.
- The block — a dead-end answer
- When a name on the list comes in, the resolver does not return its real address. It returns nothing useful (an empty answer, or 0.0.0.0), so your device has nowhere to connect. The ad or tracker is never contacted. Names that are not on the list resolve completely normally.
Why one setting covers everything
Almost every app on your device, the browser, the games, the smart TV, the phone that will not let you install an ad-blocker, has to do DNS lookups to reach the internet. They all go through the same resolver. So when the resolver filters, the filtering applies to all of them at once. There is no extension to install per browser and no app to keep updated. Point a device, or a whole home network, at a filtering resolver, and that is the configuration done.
That is the real strength of blocking at the DNS layer: it is network-wide and app-agnostic. It is also why it pairs naturally with encrypted DNS. The same resolver that hides your lookups from the network can filter out the bad names while it is at it.
The lists doing the work
A filtering resolver is only as good as its lists. These are the four open, well-maintained sources behind our own filtering, each aimed at a different problem. You can see the live counts on our server info page.
| List | What it targets | In short |
|---|---|---|
| AdGuard DNS filter | Ads and trackers | A broad, curated list of advertising and analytics domains |
| OISD | Ads, trackers, malware, phishing | A large aggregated list tuned to keep false positives low |
| PhishTank + OpenPhish | Phishing sites | Community-reported pages that impersonate real services |
| URLHaus (abuse.ch) | Malware distribution | Live domains caught handing out malware |
Lists update constantly as new ad and threat domains appear and old ones go quiet, which is why filtering is a moving service rather than a one-time setting.
DNS blocking vs a browser ad-blocker
They are not rivals. They work at different points and miss different things, so the strongest setup runs both. Here is who does what.
| DNS-level blocking | Browser extension | |
|---|---|---|
| What it covers | Every app and device on the resolver | Only that one browser |
| Blocks by | Whole domain name | Page elements and domains |
| First-party ads (same domain as the content) | Cannot block | Can block |
| Cosmetic cleanup (blank gaps, banners) | No | Yes |
| Setup | One resolver setting | Installed per browser |
What DNS blocking cannot do
DNS blocking only knows domain names. It decides yes or no for a whole name and nothing finer. The instant an ad is served from the same domain as the thing you actually came for, that bluntness becomes a wall: refusing the domain would break the content too, so the ad has to be let through. This is the single reason most of the ads people complain about still get past it. Here is where it shows up in real life.
Watch for one pattern running through all of it: every modern social platform serves its ads first-party, from the very same domain as the posts and videos you came to see, and flags them as ads only inside the app's own code, never at the domain level. That design is precisely what defeats domain-level blocking. Here is how it plays out platform by platform.
-
YouTube video ads
The ads stream from the googlevideo.com servers that also stream the video you want, spliced into the same playback. There is no separate ad domain to refuse. Block it and the video stops too, so DNS filtering simply cannot remove YouTube's in-stream ads. A browser blocker can, because it works inside the player and can tell an ad segment from the real video and skip past it.
-
TikTok "For You" ads
Sponsored clips are dropped in among the organic ones in your feed and delivered through the same content network, especially inside the app. To DNS the ad is just another video in the endless scroll, coming from the same place as everything else. Only TikTok's own app data marks which clip is paid, and DNS never sees that data.
-
X (Twitter) promoted posts
"Promoted" posts are slotted straight into your timeline from the same servers (twimg.com and the site's API) that serve ordinary posts. The only thing that says "Ad" is a label in the data the app draws on screen. Refuse the domain and the entire timeline disappears with the ad, so DNS has to let it through.
-
Instagram feed, Stories and Reels ads
Sponsored posts in the feed, and the ads slipped between Stories and between Reels, all come from the same Meta network (cdninstagram.com, fbcdn.net) that delivers your friends' photos and videos. Content and ads share the infrastructure completely, so there is no separate name for DNS to single out.
-
Facebook sponsored posts
The same Meta story from the other side: sponsored posts sit inline in the feed, served from facebook.com and fbcdn.net, indistinguishable at the domain level from every other post you scroll past. A browser blocker can read the page and hide the marked post; DNS has nothing to grab onto.
-
Twitch stream ads
Ads are stitched directly into the live video stream on the server, from the same servers as the broadcast, before it ever reaches you. To DNS it is one continuous stream from one domain, with no seam to cut at.
-
Spotify free-tier audio ads
The audio ads come down the same delivery network as the music. Block that domain and the songs go silent too, so DNS filtering leaves the ads untouched.
-
Ads baked into mobile apps
Beyond the big names, countless apps pull ads through their own first-party domain, or connect to a hardcoded IP address that never asks the resolver at all. Either way there is no separate name to refuse, and a browser extension cannot reach inside an app, which is the awkward gap where some ads survive both approaches.
There are two more limits worth naming. DNS blocking does no cosmetic cleanup: when it kills an ad slot, nothing tells the page to close the gap, so you can be left with a blank rectangle where the ad would have been. And anything that connects by raw IP address, skipping the lookup entirely, is never seen by the resolver and so is never filtered.
The honest summary: inside a browser, a dedicated content blocker like uBlock Origin blocks more, and more correctly. It can pick apart the page, hide the right element, reflow the layout cleanly, block an ad path on a domain while allowing the rest of it, and push back on anti-adblock scripts. DNS blocking can do none of that. On the web, in the browser, the extension wins.
So why block at DNS at all?
Because the browser is not the only thing on your network, and a browser extension only protects the browser it is installed in. DNS blocking works where extensions cannot reach, and it does a few things the extension structurally cannot.
- It covers every device and app at once. Smart TVs, consoles, phones, IoT gadgets, and the apps you cannot install an extension into, all of it filtered from one resolver setting. A TV that begs you to install nothing still obeys the resolver it was handed.
- It stops the connection before a single byte is fetched. A blocked tracker or malware domain is never contacted at all. The extension blocks the ad after the page has started reaching for it; DNS refuses the address up front, which also means the phone-home and the bandwidth never happen.
- It catches traffic the browser never sees. Background telemetry from the operating system, chatty apps, and connected devices all do DNS lookups. A browser extension has no visibility into any of that. The resolver does.
- It is one setting, with nothing to maintain. No per-browser install, no per-device upkeep. Point the network at the resolver once and new devices are covered the moment they join.
So they are not competing for the same job. DNS blocking is the baseline that protects everything, the floor under your whole network, especially strong against trackers and malware that never reach a browser. A content blocker is the precision tool for the browser, where it cleans up what DNS is too blunt to touch. The strongest setup is plainly both: DNS filtering for the network, uBlock Origin in the browser on top.
Filter and encrypt in one move
The resolver that blocks ad, tracker and malware domains for every device on your network can also encrypt your lookups so the network cannot read them. Point your device at it once.
Set up encrypted, filtered DNSNew to how a resolver fits in? Start with what a DNS resolver is, or check the live blocklist counts on the server info page.