dnsetter

Two settings that are each correct and cannot both be on. This one decides, automatically.

Android's Private DNS encrypts your name lookups. A VPN carries names only its own tunnel knows. Turn both on and things stop resolving — so you switch Private DNS off, and forget to switch it back. dnsetter turns it off the moment a tunnel comes up, and puts exactly what you had back the moment it goes away.

dnsetter is being built, and there is a beta you can install today. The code is private while it is written; what follows is what the app does now, not what it will do.

The problem, in plain terms

Android has a setting called Private DNS: you give it a resolver’s hostname — dns.adguard-dns.com, one.one.one.one, your own — and from then on the phone looks names up over an encrypted connection to that resolver, on every network you join. It is a good setting and most people who turn it on should leave it on.

A VPN does something that overlaps. It routes your traffic through a tunnel, and a tunnel very often carries names that only exist inside it: a work machine, a home server, a Tailscale address ending in .ts.net.

Both are correct and they collide. With Private DNS pointed at a public resolver, the phone keeps asking that resolver for names — including the ones that only exist inside the tunnel, which it has never heard of and cannot answer. Depending on the tunnel, the result is anywhere from “the office intranet does not load” to “nothing resolves at all”.

The fix everybody arrives at is manual: open Settings, find Private DNS, turn it off, use the VPN. The half people forget is turning it back on. And a phone whose Private DNS you switched off three days ago is a phone that is looking names up in the clear on café Wi-Fi today, with nothing on screen to say so.

dnsetter does the remembering.

How it works

1. It watches for a tunnel. Android publishes no broadcast for “a VPN came up”, so the only way to hear about one is to keep a small process alive. That is the permanent notification the app keeps — at minimum importance, so it stays folded at the bottom of the shade and puts no icon in the status bar.
2. When a VPN appears, it writes down exactly what you had — the mode, and the hostname if there is one — and then turns Private DNS off. The order matters: recorded first, changed second, so a phone that kills the app between the two loses nothing.
3. When the tunnel goes away, it puts back exactly what it wrote down, hostname included. Losing that is the one unforgivable bug in an app like this, and it is the thing most of the testing goes into.
4. If you change Private DNS yourself while a VPN is up, that is the new answer. dnsetter notices within the second, stops holding anything, and leaves it alone until the next tunnel. An app that argues with you about a setting you just changed by hand gets uninstalled.

Three more things it does, because “it worked” and “it says it worked” are different claims:

• Every change is read back from the system before it is reported. Some manufacturer skins keep Private DNS somewhere else, or put their own value back a second later. Where that happens dnsetter says the change is not taking, rather than claiming a switch it did not make.
• It never creates a VPN of its own. Android allows one at a time, and an app that took that slot would be standing between you and the tunnel you actually wanted.
• Nothing about your DNS, your VPN or your settings leaves the phone. There is no account and no server. The only thing the app ever sends is a message you type yourself on the Info tab, and only when you press send.

You decide the rest: whether a given VPN app gets switched for at all — some tunnels bring their own resolver and are perfectly happy beside Private DNS — and, if you would rather not simply go unencrypted while the tunnel is up, which resolver to write instead.

The one permission, and why it is awkward

Changing Private DNS needs WRITE_SECURE_SETTINGS, and no dialog can grant it. Android reserves it for the system, and the only ways in are a one-line command from a computer over ADB, or Shizuku on the phone alone. You do it once, and the app holds it from then on.

The app’s first screen is that setup, with the command to copy and each route spelled out. Until the permission arrives, dnsetter shows you exactly what is true — whether a tunnel is up, what Private DNS is set to, what is actually resolving — and changes nothing. There is no setup wall: you can see whether the app is worth setting up before you set it up.

What is free, and what Pro is

The part dnsetter exists for is free and stays free: Private DNS goes off when a VPN comes up, your setting comes back exactly when it goes away, on every tunnel, with a rule of your own for one VPN app, the manual override on the Status tab, and the whole of what that tab shows. A utility whose one job is behind a paywall does not get installed twice.

dnsetter Pro is the Quick Settings tile, a rule per VPN app beyond the first, a resolver of your own while the tunnel is up instead of Private DNS simply off, several saved resolvers to move between, switching only on Wi-Fi or only on mobile data, the history of every switch with a copy you can keep, the home-screen widget, and a broadcast an automation app can send.

The tile is the one thing here that was free and is not: it shipped free in the betas up to 2026.8.7 and moved behind the paywall on 2026.8.8. Anyone who was already using it keeps it. Nothing else has moved or will — a feature an install was already using stays with it for good.

The build in the F-Droid repository has no paywall in it at all — there is no way to buy anything in a build distributed outside a store, so nothing is withheld there. What it asks instead is a donation, once a week, on a notification you can silence in two taps; silencing it takes nothing away, because nothing was held back.

Who paid for it, and how to be on that list, is its own page.