macOS Resolver File for a Local Domain Beside a VPN

Your work VPN resolves company names perfectly while the printer at home stays unreachable by name, and the usual fix people reach for is to point the whole Mac at the home router. That is a much larger change than the problem requires. macOS can send a single DNS suffix to its own server through a small resolver file, leaving every other lookup exactly where it was.

The permission boundary comes first: this is for a domain you administer or have been authorized to configure. It is not a route around an organization's enforced DNS policy or its local-network restrictions.

One file with a narrow job

Suppose the local zone is lab.example.org and its server answers on 192.168.55.1. On a Mac where you are allowed to make the change, an administrator creates a plain-text file whose name is the domain itself, /etc/resolver/lab.example.org, containing a single nameserver 192.168.55.1 line. The directory may not exist on a fresh system, so create it with administrator rights, and look before you write in case management software already owns a file there.

Apple's resolver configuration documents the convention that the filename supplies the domain when no separate domain setting appears inside the file. That naming rule is the whole trick, and it is why the file has to be named for the zone rather than for the server.

How macOS chooses among resolvers

More than one resolver client can be active, and the most specific matching domain wins. A resolver for lab.example.org therefore has a different scope from the default resolver, and a more specific subdomain with its own file can take precedence again. That is what lets a work VPN keep its own suffix while your lab zone goes elsewhere. Nothing about the arrangement is global, which is the point worth remembering.

Leave /etc/resolv.conf alone. macOS writes that file itself, and it never held the full picture of domain-specific resolution. Configuration can also arrive from the system configuration database rather than from files in this directory, which is why a management profile can override what you wrote.

Three things the file cannot supply

The server must be reachable. If the VPN blocks local networking, or a corporate route captures the server's address range, a perfectly correct suffix file still cannot deliver a query. Take that to the network owner rather than widening local exceptions on your own.

The zone must hold the right answer, and that is best tested with a fully qualified name such as printer.lab.example.org. A short name can invoke search-domain behaviour and end up asking a different question than the one you meant to ask.

Finally, the application has to be able to use the answer. Resolving a printer's name does not grant access to its address, and it does not open the service behind it. The returned address still needs an allowed route and an access policy that permits the connection. A resolver file changes where a name is looked up; it does not reserve a path for the result.

Verify selection instead of replacing DNS

Check what macOS is actually using right now, and query the fully qualified name from inside the application itself or from a tool that resolves the way applications do. A direct query at 192.168.55.1 proves the server answers; it does not prove macOS selected that server for ordinary lookups. Those are different facts, and only the second one describes what your browser will experience.

If another resolver already claims the same suffix, find out who owns it before adding priority hints. The documented search_order setting orders clients that share a domain; it is not a global preference switch that makes a general resolver win every query.

Confirm that company names still resolve with the VPN connected, then record the file and its purpose in your local notes. When the arrangement is retired, delete only that file and recheck both name spaces rather than resetting all network DNS settings.