DNSecure: the missing UI for encrypted DNS on iOS and macOS

The gap in the platform, not a new DNS implementation

DNSecure is a configuration tool of DoT and DoH for iOS and iPadOS, and the reason it exists is stated as a missing piece in the operating system rather than as a missing feature in the network.

iOS 14+, iPadOS 14+ and macOS 11+ have supported encrypted DNS, for example DNS-over-TLS and DNS-over-HTTPS, but they do not have a native user interface for enabling it. The system can do the thing and you cannot ask it to. DNSecure is the piece that asks it.

That framing matters for how you judge the app. It is not a resolver, a VPN client or a filtering tool. It does not sit in the path of your traffic in the way a content blocker does. It writes a configuration that the operating system then enforces, which is why the app can work on iOS at all, since an iOS app cannot install a system-wide VPN configuration without entitlements that require a developer account and a distribution profile.

The implementation detail that makes it work is the DNS Settings API from NetworkExtension. The app uses that API, and the requirement of iOS 14+, iPadOS 14+ or macOS 11+ is a direct consequence of it, since the API only exists from those versions. The repository links the Apple documentation for DNS Settings and a WWDC20 session on encrypted DNS as its two references, which is what you would expect from a project that is essentially a front end for one system API.

The project is Swift, MIT licensed, and the top level carries a Package.swift, a DNSecure.xcodeproj directory, the DNSecure/ source directory, DNSecureTests/ and DNSecureUITests/, a .swift-format configuration and a .yamllint.yml, plus a privacy_policy.md.

Three platform paths, and macOS 12 is the awkward one

The usage instructions differ by platform and by version, and the difference is large enough that picking the wrong one leaves you stuck.

On iOS and iPadOS the sequence is: select a DNS server you like, or add another one, enable Use This Server, open the Settings, go to General, then VPN & Network, then DNS, and finally select DNSecure, because Automatic is selected by default.

On macOS 13 and later it is shorter. Select a DNS server or add one, enable Use This Server, open the System Settings, go to Network settings and click Filters, then enable DNSecure. The Filters pane is the modern location for this.

On macOS 12 it is a different shape again, and this is the one worth reading carefully. You select a DNS server or add one, enable Use This Server, open the System Preferences, go to Network settings, select DNSecure and click the ... button on the bottom, click Make Service Active, and then click Apply.

The macOS 12 path is longer because the system presents the DNS configuration as a network service with an order in a list, and a filter has to be enabled and moved into place rather than switched on. Make Service Active is the step that actually turns the filter on, and Apply is what commits the change to the network configuration.

So the three paths differ in where the control lives, in the terminology, and in the number of steps. On iOS it is a picker in a settings list, on macOS 13 a toggle in Filters, and on macOS 12 an ordered service list with an explicit activation.

What you do inside the app before the system settings step

Whatever the platform, the first two actions are the same and happen inside DNSecure itself. You select a DNS server you like, or add another one, and you enable Use This Server.

The wording of the second step is worth noting. Use This Server is a switch inside the app, and the sequence then moves to the operating system settings, where a separate action is needed to point the system at DNSecure. The app does not simply take over; it registers a configuration and the user has to select it.

That two-step arrangement is a consequence of how the platform treats these settings. A network extension configuration for DNS is a system-level object, and on macOS in particular it lives in a list where several filters can be active at once, ordered by priority. The app's own Use This Server switch is about which resolver definition it offers, and the system-level selection is about which of the registered filters the system actually applies.

Adding your own server is the other half of the app's job. The app is not limited to a curated list, so a resolver you run yourself, or one with a protocol your ISP does not offer, can be configured with the same Use This Server switch. For a DoH or DoT endpoint that is not in the app's list, that distinction between offering a server and having the system adopt it is the part that matters.

Where this sits against the alternative of a configuration profile

The obvious question for an iOS or macOS administrator is why you would use an app at all, when a configuration profile can push a DNS configuration to managed devices.

The answer is about who the tool is for. A configuration profile is the right mechanism for an organisation that manages the device and can push settings to it, and it can set an encrypted DNS resolver without any user interaction or any third party app installed. For a managed fleet, the profile wins, and an app in the App Store is the wrong tool.

DNSecure is for the other case. It is for a person who owns the device, who wants encrypted DNS on a platform that supports it but does not expose it, and who would rather pick a resolver and switch it on than hand-edit a profile and install it by hand. The steps it asks for, enabling Use This Server in the app and then selecting DNSecure in the system settings, are the steps of a person acting on their own machine rather than a fleet being configured.

There is a second reason the app exists at all rather than a profile being the only answer, and it is the App Store distribution. A configuration profile with a DoH or DoT payload has to be obtained, signed and installed, which for an individual user means either an MDM server or a self signed profile and a trust prompt. An app from the store, with TestFlight for the beta channel, is a two tap path for the same outcome.

What neither approach settles is the trust question. Encrypted DNS moves the resolution of your names away from whatever resolver your network would otherwise use, and the resolver you pick then sees every name your device looks up. The README does not describe the resolver list the app ships with, does not say whether the app itself is involved in the queries once the system is pointed at DNSecure, and does not say what the Use This Server switch does beyond enabling the configuration entry. The privacy policy in the repository and the App Store listing are where that is answered, and they are worth reading before you switch it on for a device that holds your mail and your messages.

Distribution, maintenance and what the repository contains

The app is distributed through the App Store, and there is a TestFlight beta channel for people who want to test before a release reaches the store. That distribution choice is a design decision with a practical consequence, which is that you are running a binary you did not build.

The repository is an Xcode project rather than a package, with a Package.swift at the top level alongside the DNSecure.xcodeproj directory. The source lives in DNSecure/, with DNSecureTests/ and DNSecureUITests/ as the test targets. A .swift-format file and a .yamllint.yml suggest the formatting and linting configuration is committed rather than left to each contributor's editor, and a privacy_policy.md is present, which is consistent with an App Store submission.

The maintenance picture is modest but not dormant. The recent releases are 1.6.0 on 2025-09-11, 1.6.1 on 2025-10-14 and 1.6.2 on 2025-12-28, and the last push to the repository was on 2026-10-18. So the version line is 1.6.x and the source is being worked on more recently than the last tagged release.

What the repository does not contain is as informative as what it does. There is no resolver list to inspect, no configuration schema, and no documentation of the DNS servers the app ships with, and the README does not say whether the app filters, logs or otherwise inspects the queries it configures. For an app whose entire job is to point your device at a name server, that is the question to settle before you install it, and the answer belongs in the app store listing and the privacy policy rather than in the README.

The licence is MIT, with a LICENSE.txt at the root, and the default branch is main.

Editorial conclusion

DNSecure suits an Apple user who wants a third-party encrypted DNS resolver configured on a device where the system offers the capability but no way to reach it, and the whole app exists to close that one gap. It does not suit you if you only need to set encrypted DNS on a single Mac, because macOS has a DNS settings pane for that, and it does not suit a fleet of managed devices, where a configuration profile is the appropriate mechanism. Before you install it, check which of the three platform paths applies to you, because macOS 12 needs a different sequence from macOS 13 and later, and note that the app is distributed through the App Store and TestFlight rather than as a build you compile.

Frequently asked questions

Official sources

1. Issues
2. kkebo/DNSecure on GitHub
3. License: MIT
4. README
5. Releases