# Block ads across your home network with AdGuard DNS

**Author:** Ivan Misic  
**Published:** 2026-01-05  
**URL:** https://ivanmisic.net/blog/tech/block-ads-every-device-adguard-dns

**TL;DR**

Test AdGuard's public DNS on one device before changing the router. It can block requests to known advertising and tracking domains, but the result depends on the device, app, resolver mode, and filter list.

- Android Private DNS can use `dns.adguard-dns.com`; current iOS guidance uses AdGuard's profile or supported app
- A compatible router can cover devices that accept its DNS settings, while VPNs, private DNS, hardcoded resolvers, cellular data, and IPv6 can bypass it
- It cannot remove ads served from the same domain as normal content, including many YouTube and social-media ads
- A blocked-query percentage is not the percentage of ads removed
- Read the provider's privacy policy, use encrypted DNS where available, and restore the previous DNS setting first if something breaks

Start with one phone. If something breaks, changing one setting back is easier than debugging the whole house. A compatible router can cover most devices later, with some exceptions.

![Before/after comparison showing ad-heavy webpage vs clean version](/images/blog/ad-blocker-comparison.png)

## What DNS blocking does

A DNS resolver translates a domain name into an address. AdGuard DNS checks requested domains against its filtering rules and refuses or redirects matches, depending on the service and rule.

If an app requests a separate advertising or tracking domain, that connection can be blocked before the content downloads. For me, this is the reason to use DNS blocking: it also catches separate ad and tracking domains used by apps.

## Why AdGuard DNS does not block every ad

A DNS filter decides one thing: whether to answer a request for a domain. That is enough to stop an ad loading from a separate advertising domain, and it does nothing about an ad that arrives from the same domain as the content you asked for.

YouTube is the clearest case. The video and the ad in front of it come from the same serving infrastructure, so there is no advertising domain to refuse without also refusing the video. The same holds inside Facebook, Instagram, TikTok, and most large streaming apps. If a filter list claims to solve this at the DNS layer, check what it actually blocks before you trust the claim.

Three other limits are worth knowing before you decide the setup is broken:

- An ad written directly into the page HTML arrives with the page. Nothing was requested separately, so there is nothing to refuse.
- Sponsored posts and in-feed promotions are content on the platform's own domain, not calls to an ad network.
- A device or app can ignore your DNS setting through a VPN, its own encrypted DNS, a hardcoded resolver, cellular data, or IPv6 settings supplied elsewhere.

So your result depends on the device, app, site, resolver mode, and filter list. A blocked-query percentage counts refused lookups, not the share of ads you stopped seeing.

If you want a cleaner page rather than a cleaner network, a browser content blocker works on a different layer and can remove elements after they arrive. Running both is normal, as they solve different halves of the problem.

## Test it on Android

Android supports encrypted private DNS on current versions:

1. Open **Settings**.
2. Search for **Private DNS**.
3. Select **Private DNS provider hostname**.
4. Enter `dns.adguard-dns.com`.
5. Save.

Menu names vary by manufacturer. If the option is missing, use [AdGuard's current public DNS instructions](https://adguard-dns.io/en/public-dns.html) for your Android version.

I would leave it on for a day and use the phone normally. If one app stops working, switch Private DNS back first.

## Set it up on iPhone or iPad

For coverage beyond one Wi-Fi network, follow AdGuard's [current iOS instructions](https://adguard-dns.io/en/public-dns.html) and use its configuration profile or supported app.

You can enter DNS addresses manually under a Wi-Fi network, but that setting applies only to that network. It does not cover cellular data, and you need to repeat it for every Wi-Fi network.

That is why I would use the documented profile for a device-wide setup. Before installing any profile, check that the download comes from AdGuard's official domain and read what the profile changes.

## Apply it through your router

A router change can cover phones, laptops, TVs, consoles, and smart-home devices that accept DNS settings from the network.

Write down the current DNS values first. Then:

1. Open your router's administration page.
2. Find the WAN, Internet, DHCP, or DNS settings.
3. Enter AdGuard's default public IPv4 servers:
   - Primary: `94.140.14.14`
   - Secondary: `94.140.15.15`
4. Check whether the router has separate IPv6 DNS settings.
5. Save the change and reconnect one test device.

Router menus differ, so use the manual for your model. Some internet-provider routers do not allow custom DNS at all.

Most devices that accept DNS from the router will now use AdGuard DNS on that network. A device or app can still bypass it through hardcoded DNS, private encrypted DNS, a VPN, cellular data, or IPv6 settings supplied elsewhere.

Network-wide does not mean impossible to bypass. It means one network setting covers the devices that follow it.

## What the default service blocks

AdGuard's default public servers focus on ads and trackers. Its family-protection servers use different addresses and add adult-content blocking and safe search.

Check the [current server list](https://adguard-dns.io/en/public-dns.html) before choosing a mode. Do not mix addresses from different modes, as the result becomes harder to understand.

DNS filtering can block:

- advertising domains used by apps and websites
- tracking and telemetry domains included in the service's rules
- connections to domains covered by the selected protection mode

It cannot inspect encrypted page content or remove an element served from an allowed domain. A browser content blocker can still help inside the browser.

## Privacy and encrypted DNS

A public DNS provider can process the domain lookups sent to it. You are moving that part of the connection from the resolver chosen by your network to AdGuard.

Read the [AdGuard DNS privacy policy](https://adguard-dns.io/en/privacy.html) before making that choice. Use an encrypted method such as Android Private DNS or the supported iOS profile where available. Encryption protects DNS transport, but it does not make browsing anonymous.

Plain DNS addresses entered on a router usually travel without that encryption unless the router explicitly supports DNS over HTTPS or DNS over TLS.

## Other public resolvers

These services solve different problems, so choosing one from a generic “fastest DNS” list makes little sense.

| Provider | Main purpose | Blocks ads by default |
|---|---|---|
| AdGuard default public DNS | Advertising and tracker filtering | Yes, at DNS level |
| Quad9 | Malicious-domain protection | No general ad blocking |
| Cloudflare `1.1.1.1` | General public DNS with a privacy focus | No |
| NextDNS | Account-based filtering and rules | Configurable |

Quad9 and Cloudflare are not ad-blocking replacements.

## Public AdGuard DNS or AdGuard Home

Public AdGuard DNS is enough for the quick setup. I would move to AdGuard Home only for local logs, custom lists, or per-device rules, as you own the maintenance too.

I would create an AdGuard DNS account only if I needed hosted statistics, device configuration, or custom rules. At the time of this update, the Starter plan lists 300,000 monthly requests, 5 devices, 2 servers, and 100 user rules. Check the [current plan limits](https://adguard-dns.io/en/license.html), as they can change.

[AdGuard Home](/blog/tech/adguard-home-network-wide-ad-blocking) runs the resolver on your own system and adds those controls. DNS-level blocking still has the same-domain limits described above.

## Revert before debugging everything else

Some sites and apps depend on domains a filter may block. If something breaks, restore the previous DNS value on the test device first.

If that fixes the problem, you know where to investigate. If it does not, the DNS change was probably not the cause. Small test, clear answer.
