WireGuard DNS on iPhone: the domain is a search suffix

You write one line with a resolver address and a company domain, expecting only names in that domain to use the tunnel resolver. On the Apple client, all names now go there, and short names in the domain resolve too. The line does two separate things, and only one of them is about which queries the tunnel handles. The other is a typing convenience that got promoted to a policy by wishful reading.

What the DNS line is parsed into

The client reads the entry as a list and classifies each item by shape. Anything that looks like an address becomes a DNS server; anything that looks like a domain becomes a search suffix. Both end up in the tunnel settings, but in different fields. An illustrative line for a tunnel that carries a private resolver and one internal domain looks like this.

DNS = 10.24.8.53, lab.internal.example

The address supplies the resolver. The domain supplies a suffix that lets a client type a short name and have the system append the rest before asking. Neither item says anything about confining the resolver to that domain, which is the part people expect and do not get. Only one field in the platform can express that restriction, and it is not this one.

Two Apple fields, two different jobs

Apple exposes the distinction in its DNS settings object. The search-domain list is documented as the list used to qualify single-label hostnames: type a bare hostname and the system may append each suffix in turn. That is a completion rule, not a routing rule. Nothing in that list decides which server is asked.

The match-domain list is a different property. It decides which namespaces use this set of DNS settings, and an empty entry means the default domain rather than one specific suffix. The packet-tunnel settings generator in the Apple client follows that model. It puts parsed search suffixes into the search list, and when servers are present it sets the match list to the empty string. The result is a tunnel resolver that answers everything the system sends it, plus a suffix that helps with short names.

So a domain on that line is not a namespace selector. Adding another one does not narrow which queries use the tunnel, and removing it does not widen them either. The only thing that changes is how many short names complete.

Why every name still reaches the tunnel resolver

With the empty match entry, the tunnel is a candidate resolver for ordinary names, not only for the company domain. On a full-tunnel configuration this usually matters little, because all traffic is in the tunnel anyway. On a split tunnel it matters a great deal. Public names may now be resolved by a resolver that only holds a private zone, and a failure looks like a broken VPN when it is actually a resolver that answers only part of the namespace. The tunnel is fine, the queries leave, and the answers come back empty.

Two repairs are available and they are different decisions. Make the tunnel resolver a complete resolver that forwards public names through the approved path, or stop sending public names to it by changing the client configuration rather than the domain list. The first keeps every query on the tunnel and trusts the upstream. The second keeps some queries local and accepts that private names may stop resolving while the tunnel is down.

What split DNS would actually need

A namespace-scoped resolver policy requires a client that lets you express it: match domains on Apple platforms, or an equivalent setting in the product you use. A configuration field that only accepts servers and suffixes cannot express it, no matter how it is punctuated. A profile can carry the policy because it describes a managed configuration rather than a connect-time hint. It can name the domain, the servers, and what should happen when that domain is unreachable. That is the difference between a setting and a contract.

On managed Apple devices this is normally delivered through a configuration profile that carries the domain-specific DNS settings. That is a different mechanism from a WireGuard configuration file, and the two can coexist only if the client respects the profile. Check what your client actually calls the field before assuming the two products behave alike. A wg-quick script on a Mac and the WireGuard app on an iPhone read similar lines and install them through different layers.

Read the installed settings, not the config

On a Mac you can inspect what the system ended up with, which is more informative than re-reading the file you wrote. The resolver list shows which servers are configured for which domains, and the scoped queries show which one won. A client that mangles the line shows it here rather than in the file you wrote. On iOS there is no equivalent command line, so the evidence there is an outcome: a private name that resolves through the tunnel, and a public name whose answer reveals which resolver replied.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

These two commands print the current resolver configuration and the DNS servers for the active service. If the tunnel resolver appears as a default resolver with no domain restriction, the configuration is doing exactly what the client asked for. Fix that by changing the mechanism, not by adding a second suffix and hoping the behaviour changes.