ADNS: an Android Private DNS controller that avoids the VPN tax

Android's own Private DNS engine, driven from an app

Android has had a Private DNS setting for years, a system-wide DNS-over-TLS slot that any app can point at a hostname. What it has never had is a good controller for it. ADNS is that controller: it is described as a feature-rich Private DNS client for Android with a native NextDNS integration, giving control over the device's DNS settings and over a NextDNS account. The feature list is the honest description of what a DNS controller does well. Private DNS can be switched on or off with a single tap, automatic Wi-Fi rules can apply specific settings to specific networks, state notifications show at a glance whether DNS is actually active, and a Quick Settings tile gives instant toggling without opening the app. Provider and filtering choices include ads, trackers, malware, adult content and safe search, with supported providers listed as AdGuard, Cloudflare, Google, Quad9, OpenDNS, NextDNS and custom hostnames. For the user, the point is that the toggle is one tap and the state is visible, which is exactly what the stock settings screen does not give you.

Three ways to use it, with different setup costs

The README splits the app into three distinct uses, and the difference between them is the setup cost rather than the feature set. As a Private DNS client, ADNS controls system DNS directly without using a VPN, and it requires a one-time Shizuku or ADB setup. As a native NextDNS dashboard, it replaces the NextDNS web dashboard inside an app, and it requires a NextDNS account but no Shizuku or ADB, which makes it the mode with the lowest barrier. The third mode links a NextDNS account to the device's DNS settings and keeps both sides in sync, again needing the one-time Shizuku or ADB setup, and it brings the Wi-Fi rules, the state notifications and the Quick Settings tile along with it. The third mode also handles NextDNS setup automatically and supports a custom device name that shows up in the NextDNS dashboard, statistics and logs, plus one-click profile switching that updates the system DNS settings. That last detail is the one that matters for anyone with several NextDNS profiles, for example separate ones for home and travel.

Shizuku or ADB is a one-time cost, and then it is out of the picture

The privilege model is where an app like this is usually criticised, so it is worth being precise about what ADNS asks for and when. Changing the system Private DNS setting is a privileged operation, and ADNS performs it through Shizuku, the service that lets an app use system privileges without root, or through ADB. The README says this is a one-time setup, and the FAQ answers the obvious follow-up directly: no, Shizuku does not need to run in the background all the time, because after onboarding the app does not use Shizuku at all. That is a meaningfully different design from tools that keep a privileged service alive continuously, and it also means that if you reboot or restart Shizuku you may have to repeat the setup step. The project declines native root support as well, explaining that it manages system settings cleanly through Shizuku or ADB, and that a rooted user can start Shizuku in root mode with a single tap.

NextDNS credentials are used once and the key is stored encrypted

The NextDNS side of the app has a security story that is spelled out rather than implied. If you log in with your NextDNS username and password, they are used a single time to generate an API key, and the password is never stored. That API key is stored encrypted on the device and is only ever transmitted to official NextDNS API endpoints. No personal data or credentials are collected or sent to third-party servers, and the app is built with zero telemetry or tracking. The NextDNS mode is genuinely native, with no WebViews involved, which means profile settings, logs, detailed statistics and the per-device setup guides are rendered by the app itself rather than by an embedded browser loading the dashboard. For someone who wants to check what their resolver saw, that difference between a native screen and a WebView is the whole point.

Two build flavors and a reproducible build check

The distribution story has two parts. First, there are two build flavors with different network behaviour. The FOSS flavor has a completely clean network profile, containing no update checker and making zero external requests other than direct communication with your configured DNS provider and NextDNS. The normal flavor makes a single background API request to GitHub on app launch to check for new releases. Second, and more unusually for a small Android app, ADNS supports reproducible builds. An independent server compiles the open source code from the repository and compares the resulting binary against the published release APKs, and a passing status is presented as proof that the APK you downloaded from GitHub or IzzyOnDroid was generated directly from that source code, with no hidden code, backdoors or credential-stealing modifications injected during compilation. For an app that handles DNS credentials and an API key, that is a stronger claim than a code review of the repository alone, and it is checkable by anyone.

Building from source with the Gradle wrapper

The repository is an ordinary Gradle project with a wrapper checked in, and the README gives the two build commands per platform:

- Windows: `gradlew.bat assembleDebug`
- macOS/Linux: `./gradlew assembleDebug`

Both variants call the wrapper from the project root and assemble a debug APK, and the top-level entries include the app module, build.gradle.kts, settings.gradle.kts, gradle.properties, a fastlane directory for the store listing and an assets directory for the banner. The README does not document how to reproduce the signed release APK locally, so anyone who wants to check the reproducible build claim should compare against the published binaries rather than expect a local release build to match. The license file and the readme.md and latest.md files at the root are where the licence text and the current release notes live.

What the project refuses to build, and where it points you instead

The FAQ is where this project is most honest, because it names three features it will not implement and explains the reasoning. There will be no DNS-over-HTTPS and no VPN mode, because ADNS is specifically built to leverage Android's native Private DNS engine without running a background VPN service, and a local VPN engine consumes extra battery, takes up system memory and prevents you from using other VPN apps. There will be no native root support, for the reasons described above. For local VPN based filtering the README recommends AdAway or BlockAds as better and more customizable, and for NextDNS users who want DoH it points to RethinkDNS. That is a useful boundary to understand before installing, because a DNS app that runs a local VPN is solving a different problem, and ADNS is explicitly not that. The trade-off of the Private DNS path is that filtering is limited to what the upstream provider can do, rather than what a local ad blocker can do on the device.

MIT licensed, Weblate translations, and a fast release line

The project is MIT licensed with the LICENSE file in the repository, and it is distributed as an APK from GitHub Releases or from IzzyOnDroid, with the package identifier com.eyalm.adns. The website adns.eyalm.dev carries the user guide under its docs section. Localisation is handled through Weblate, and the README splits the translation work into two components so contributors do not drown in strings. The adns-xml-strings component holds the main interface strings and is the one to work on first. The nextdns-strings component is imported from NextDNS for the app settings, and the README notes that most languages are already complete because official translations were imported, but that it is a very large set including web dashboard text the app does not use. The release history is busy: v2.1.6 on 2026-09-23, v2.1.7 on 2026-09-24 and v2.1.8 on 2026-10-03, with the last push on 2026-10-16. The disclaimer is short and worth repeating: ADNS is an independent project and is not affiliated with NextDNS in any way.

Editorial conclusion

ADNS fits an Android user who wants system-level DNS filtering with the Private DNS engine, a Quick Settings toggle and per-network rules, and who would rather not keep a VPN service running, or who wants a native NextDNS client instead of a web dashboard in a WebView. It does not fit someone who needs DNS-over-HTTPS, hosts file patching, or a root-based workflow, since the project answers all three with a flat no. Before installing, decide between the FOSS flavor and the normal one, check whether you are willing to grant Shizuku or ADB once during setup, and confirm that the provider you want supports the filtering options ADNS exposes.

Frequently asked questions

Official sources

1. eyalm2000/adns on GitHub
2. Issues
3. License: MIT
4. README
5. Releases