iPhone VPN DNS: Who Owns the Setting Decides Where It Applies

Type a private resolver address into the Wi-Fi settings of an iPhone and it will work until the phone leaves that network, which is exactly when a VPN is supposed to take over. That is the first trap in mobile DNS: the place you entered the setting defines its scope, and the scope is narrower than most people assume. Before editing anything, answer three questions about the deployment, because the answers decide which control you should be touching. Treat the sequence as a design review rather than a settings hunt.

Three questions before you type a resolver address

First, which names actually need special handling? A private zone such as corp.example is a namespace, not a single host, and the answer should be a domain rather than one record. Second, which resolver is authoritative for it, and who owns that service? Third, what path makes that resolver reachable from the phone: the tunnel, a routed Wi-Fi network, or something else entirely.

If any of those three has no owner, stop. A DNS change made without a namespace, an authoritative source and a reachable path is a guess that will fail differently on cellular than it does in the office.

A Wi-Fi DNS entry belongs to that Wi-Fi network

The manual DNS configuration on iOS is stored per network. It applies while the phone is associated with that SSID and stops applying when it is not, which means it cannot govern cellular traffic or describe what a VPN client does. Editing it to fix an app that fails on cellular is a change to a setting the failing path never reads.

That does not make per-network DNS useless. For a home lab or a single office SSID, it is the simplest way to reach an internal resolver, and it is honest about its boundary.

The VPN's DNS mechanism follows the protocol and the client

A packet tunnel provider on iOS can configure DNS through Apple's DNS settings API, which exposes resolver addresses and domain matching to the tunnel that owns the connection. A native IKEv2 configuration can receive DNS through the IKE configuration payload when the gateway pushes it, but whether a given client applies what it receives is an implementation detail you have to verify. An app-based client may implement its own resolution path entirely.

Those are different integration points, and a result from one of them does not become a rule for all iPhones. The supported mechanism is whatever the profile or provider documents for the protocol in use.

Decide by ownership, not by convenience

If the device is managed, the profile owner should deliver the DNS setting with the VPN configuration, so a re-enrollment restores it without a user remembering anything. If a provider app owns the tunnel, its settings screen is the place to look, and its documentation is the authority on what it can split. If the phone is personal and the need is one internal name on one network, the per-network setting is proportionate.

The decision rule is short: the setting belongs wherever the connection is provisioned. Anywhere else, it is a local exception that the next network change will erase.

Verify on the paths the phone actually uses

Test a fresh request from the app that needs the private name, on Wi-Fi in the office, on cellular, and across a transition between them. An app with its own resolver integration may take a different path from the system, so test the actual application rather than a browser tab that happens to work.

When the private name fails, keep the exact error and the profile state. A public resolver answering that the name does not exist is a correct answer to the wrong question, and adding it beside the company resolver is not a namespace design.

Finally, store the verified policy with the provisioning source. The next reconnection or enrollment should restore the same name service because the profile said so, not because someone remembered an edit made to one hotspot two years ago.