iOS DNS Profile vs VPN Profile: Which One Do You Have

Someone sends an iPhone profile with a reassuring name, it installs in two taps, and internal names start resolving. Whether traffic also travels through a tunnel is a separate question, and the display name does not answer it. One profile can carry several payloads, so the only reliable move is to open it and read what each payload configures. The list is short, the payload names are dull, and the answer is usually obvious once you have seen them. Guessing from the title is how people end up believing their traffic is tunnelled when only their lookups are.

Open the payload list, not the header

On iOS the profile list sits under Settings, General, VPN and Device Management, and each entry opens to a payload inventory rather than to a single switch. Read that inventory: a DNS settings payload, a VPN payload, a proxy payload, certificates, Wi-Fi. A profile carrying only DNS settings is not a tunnel, whatever its name suggests, and one carrying both is doing two different jobs at once. The inventory is the technical claim, and the header is marketing.

Three questions turn the inventory into a decision. Does name resolution change, does the public source address change, and which applications does each effect cover? A DNS payload answers the first, a VPN payload usually answers the second and third, and anything claiming both should show two payloads or a documented extension.

What a DNS payload actually changes

A DNS payload changes how names are resolved inside its configured scope, which can mean a specific resolver, an encrypted transport such as DNS over HTTPS, or a restricted set of domains. What it does not normally change is the public source address of your connections, so websites still see the network you are on. Resolution and routing are separate mechanisms, and only one of them moved. That is why an internal name can resolve correctly while the page behind it refuses to load.

A DNS payload also introduces a party that receives your queries, and if the resolver operator is not the network operator, that is a new participant in the path. Note it, because it changes who can see which names you ask for. It does not by itself hide the destination addresses you connect to afterwards.

What a VPN payload actually changes

A VPN payload establishes a tunnel and a route policy, and depending on how it is configured it may capture all traffic, only listed destinations, or only listed applications. Exclusions matter as much as inclusions, since a full-tunnel profile with two excluded domains behaves nothing like the name suggests. Per-app VPN can leave the browser entirely outside the tunnel while the badge in the status bar says connected. Read the included and excluded lists before you trust either word.

The source address does change here, at least for the traffic the tunnel captures, and that is the practical distinction most people are actually asking about. Everything else is detail about which traffic.

Where Network Extension apps blur the label

An app can install its own Network Extension whose behaviour the profile list does not obviously describe, so the marketing name and the status-bar indicator are not an inventory. Open the app's own configuration screen next to the profile payloads and compare the two. A toggle labelled protection may only switch resolution, and a toggle labelled private DNS may only change the resolver. Where the two sources disagree, believe the payload list and note the difference.

This is also why an app can pass a quick test on one network and fail on a captive portal, where resolution works and routing does not. The two mechanisms were never the same thing.

Removing the right object, and checking the names after

Remove a configuration through the app or the management service that installed it, using Apple's documented removal steps rather than deleting files you found. Deleting a profile can take associated settings and data with it, and a managed profile may refuse to leave until the management side releases it. Removing one DNS payload should never require destroying an unrelated VPN identity that the device still depends on. Separate the objects before you delete anything, then remove only the one that owns the behaviour you are trying to stop.

Afterwards, check the private names your work depends on, because an organisational app can rely on a resolver public DNS has never heard of. That failure usually surfaces as an application error rather than a DNS error, which is why it gets misdiagnosed. Test one internal name and one public name from the same app, and the answer will tell you which object you actually removed.