Filtering Ads on Mobile Data with Android Private DNS

A weather app that behaves impeccably on the home Wi-Fi turns into a billboard on mobile data. A full-screen advert on every open, and the sort of data usage that has you checking the remaining balance while you wait for a delayed train. Nothing about the app changed. What changed is that the phone left the network where a filtering resolver was answering its lookups, and picked up whatever resolver Jio or Airtel or Vi supplies instead. That is the real shape of home DNS filtering: everything you built covers a bubble roughly the size of your flat, and the device that spends the least time inside that bubble is the one with the most screen time and a metered connection attached to it. Android has a built-in answer, buried in the network settings, and it takes about ten minutes to turn on.

your filtering stops at the front door

A resolver on your LAN can only answer queries that reach it. On Wi-Fi, your router hands out its address by DHCP and every device asks it for everything. Step onto mobile data and the phone takes whatever resolver Jio or Airtel or Vi supplies, which does no filtering and never asked your opinion.

For most of us the phone is the device with the most screen time and the least protection, and it is also the device on a metered plan. Ad creatives and tracking calls are bytes you paid for. So this gap is worth closing even if you care nothing about tracking.

what private dns actually is

Android’s Private DNS setting is encrypted DNS: DNS-over-TLS on port 853 for most resolvers, and on Android 11 and newer, DNS-over-HTTP/3 for a few well-known providers such as Google and Cloudflare. Rather than firing plain DNS at whatever resolver the network suggests, the phone opens an encrypted connection to a resolver you name by hostname, and uses it for every network the phone joins, mobile data included. Two things fall out of that: the network operator no longer sees your lookups in the clear, and your choice of resolver travels with you.

Transport	Port	Set where	Applies to
Plain DNS	53	DHCP from the network	Whole device, easy for the network to redirect
DNS-over-TLS	853	Android Private DNS	Whole device, every network
DNS-over-HTTPS	443	Inside a browser or app	That app only, invisible to the rest of the phone

The third row explains a confusion that comes up constantly. Chrome can use its own encrypted DNS regardless of the system setting, so a site can look unfiltered in the browser while everything else on the phone is filtered correctly. If your results seem inconsistent, check the browser’s own DNS setting before you blame Android.

turning it on

The path moves slightly between manufacturers, but the setting is always there on Android 9 and newer. On a stock build, Settings, then Network and internet, then Private DNS. On many Xiaomi, Samsung and Realme phones sold here it sits under Connections or More connection settings. Search the settings for “Private DNS” and you will find it in one go.

1. Open the Private DNS screen. You will see Off, Automatic, and “Private DNS provider hostname”.
2. Choose the hostname option. Automatic only upgrades to encryption if the network’s own resolver happens to support it, and you cannot count on that on mobile networks.
3. Enter the hostname of your chosen filtering resolver. It is a hostname, not an IP address, and it will refuse anything that is not a valid name.
4. Save. If the phone cannot reach that resolver over TLS it will tell you immediately, which is a useful sanity check.
5. Turn Wi-Fi off, open the app that was annoying you, and see whether it behaves differently.

If you have adb handy you can confirm the state without hunting through menus:

adb shell settings get global private_dns_mode
# hostname

adb shell settings get global private_dns_specifier
# dns.example.com

someone else’s filtering resolver, or your own

The easy route is a public filtering resolver that publishes a DNS-over-TLS hostname. AdGuard DNS is the one most people here settle on. Filtering everywhere, nothing to maintain, and a real trade: that operator handles every lookup your phone makes, and their list decisions are not yours to adjust.

The other route is your own resolver, reachable from outside. Your lists, your allowlist, your log, and a service facing the internet that you are now responsible for.

pointing private dns at your own server

Android accepts only a hostname, and insists on a certificate that validates against it. That rules out the shortcuts people try first: no home IP address, no self-signed certificate. A dynamic DNS name with a real Let’s Encrypt certificate works, and so does a subdomain of a domain you own pointed at your address.

So the checklist is: a hostname that resolves to your address, a certificate for that hostname, a filter that speaks DNS-over-TLS on port 853, and port 853 reachable from outside. AdGuard Home handles the TLS side itself in its encryption settings; Pi-hole needs something in front of it to terminate TLS, which is a fiddlier build. The comparison I wrote in AdGuard Home versus Pi-hole goes into why this particular feature tips the choice for a lot of people.

# Does your resolver present a valid certificate on 853?
openssl s_client -connect dns.example.com:853 -servername dns.example.com </dev/null 2>/dev/null | grep -E 'subject=|issuer='

# Does it answer over TLS at all? (kdig ships with knot-dnsutils)
kdig +tls @dns.example.com technobabu.com

two cautions before you open that port

First, a resolver exposed to the internet must not answer strangers. Restrict which clients it serves, because an open resolver becomes somebody else’s amplifier within days. AdGuard Home has an allowed-clients setting; use it, then read the logs to see who has been knocking.

Second, many Indian home connections sit behind carrier-grade NAT, so you cannot forward a port at all. Do not fight that. Run a mesh VPN such as Tailscale, which is built on WireGuard and reaches your home network even behind carrier-grade NAT, and route DNS home through the tunnel instead, which gives the same result with nothing exposed. The Tailscale home access guide covers that setup; a plain WireGuard server works too if your connection has a reachable public address. For a phone, the mesh VPN is what I would try first.

how iphones compare

iOS has no equivalent text box. It supports encrypted DNS, but system-wide settings arrive as a configuration profile, so you install a small app or a profile from your resolver provider and enable it under Settings › General › VPN & Device Management › DNS.

Two differences matter. The profile can be removed by anyone who can unlock the phone, so it is a preference rather than a control. And pointing an iPhone at your own home resolver means generating that profile yourself, which is more work than typing a hostname.

battery, reliability and public wi-fi

Battery impact is not something you will be able to notice. The TLS connection is reused across lookups, and DNS traffic is tiny next to everything else the radio does.

Reliability is the real consideration, because hostname mode is strict by design. If your resolver is unreachable the phone does not quietly fall back to the network’s; it fails. That is correct behaviour, and it means pointing Private DNS at something you trust to stay up. If you run your own and the Pi is down, the phone has no DNS until you change the setting, so keep a fallback hostname written somewhere offline.

captive portals

This is the friction you will actually hit. Railway station Wi-Fi, hotel networks, café logins and many college networks all work by hijacking your first DNS lookup to push you at a sign-in page. With Private DNS locked to a hostname, that hijack cannot happen, so the portal never appears and the connection looks broken.

The workaround is dull but quick: set Private DNS to Automatic, complete the portal login, then set it back to your hostname. Do it in that order and you will not spend fifteen minutes wondering why airport Wi-Fi hates you. Station and hotel networks catch people in exactly the same way, repeatedly.

what this cannot do for you

Name-based filtering has a hard limit, worth stating plainly rather than discovering and assuming something is misconfigured. When an app or site serves its adverts from the same domain as its content, DNS cannot separate the two, and refusing that domain takes the content with it. No cleverer list fixes that.

Nor is this per-app. Private DNS is device-wide, so you cannot filter one app and leave another alone, and an app that ships its own encrypted DNS can ignore the setting entirely. Filtering names also says nothing about permissions an app already holds.

Which lists sit behind that hostname matters more than the transport, so my notes on choosing and tuning blocklists apply here too, with the wrinkle that a broken payment on mobile data is harder to debug than one at home.

FAQ

is this better than running a blocker app?

It is cleaner. Most Android blocker apps hold the device’s VPN slot, so you cannot use a real VPN at the same time and the app must keep running. Private DNS is an operating system setting with nothing to maintain. If you need per-app rules you still want an app; for whole-device filtering the built-in setting wins.

will it filter youtube or instagram ads?

No, and nothing at the DNS layer will. Those platforms serve advertising from the same infrastructure as the content, so there is no name to refuse without losing the app. Treat DNS filtering as protection against trackers and malicious hosts across the whole device, not as a way to strip advertising out of services that are funded by it.

can i use this alongside my home setup?

Yes. Private DNS applies on every network, so at home your phone uses the hostname you set rather than the router’s resolver. Point it at your own resolver if you want your home lists everywhere, or accept the public one. Which devices get which treatment becomes a more interesting question once there are children in the house, which the guide to filtering for a family home covers.

Ten minutes in the settings closes the biggest gap in a home filtering setup, and the phone keeps that protection on the train, at work and in the queue at the bank. Just remember the captive-portal dance before you shout at a café’s Wi-Fi.

Update history: noted DNS-over-HTTP/3 on Android 11 and newer, corrected the iPhone settings path, clarified remote access from behind carrier-grade NAT, and removed sections that repeated the guide.

Sources

• DNS over TLS support in Android — the Private DNS modes Android offers, and what happens when a strict-mode hostname cannot be reached.
• RFC 7858 — DNS over TLS — the transport behind the setting, including the use of port 853 and certificate validation.
• AdGuard Home encryption wiki — certificate and DNS-over-TLS configuration for a self-hosted filter.