Skip to content
macOSHow-To Published Updated 5 min readViews unavailable

macOS Scoped DNS Resolvers: Diagnose Per-Domain and VPN Routing

Use scutil and a resolver query to diagnose macOS supplemental DNS, VPN match domains, search domains, and interface scope without changing settings.

On macOS, a single list of DNS servers is not enough to explain every lookup. The system can maintain a default resolver and supplemental configurations associated with a domain, a VPN, or a network interface. A lookup for printer.corp.example can therefore follow a different path from www.example.net even while both programs run on the same Mac.

The first diagnostic is read-only: inspect the resolver configuration the system currently exposes, then test a fully qualified name through the system resolver. Do not start by replacing a DNS server or editing a managed profile; first establish which resolver scope is relevant to the failing name.

Capture the effective configuration

Run:

sw_vers
scutil --dns

scutil --dns reports the current DNS configuration. Apple’s scutil implementation obtains a snapshot through dns_configuration_copy() and formats that configuration; it is not a packet capture and does not show which answer a past application query received. The scutil(8) documentation describes the first listed resolver as the default and subsequent supplemental resolvers as additional configurations. A supplemental resolver with a domain is used for matching-domain queries; one without a domain acts as another default configuration.

Read each resolver block as a group. Fields such as domain, nameserver, search domain, if_index, and flags describe different properties. A search domain can help expand a short hostname such as printer; a domain-scoped resolver determines which DNS configuration is relevant for a fully qualified name. The roles differ, but the lists need not be disjoint: Network Extension appends matchDomains to the search-domain list by default unless matchDomainsNoSearch is enabled. Do not treat those fields as synonyms or assume resolver number alone is a universal preference ranking.

Resolver output can expose internal DNS addresses, VPN names, search suffixes, and organization-specific domains. Keep captures local and redact those details before sharing them in a ticket or public forum.

Test a fully qualified name through macOS host resolution

Choose a hostname and address that the network owner says should resolve, and query it with macOS’s host-resolution utility:

dscacheutil -q host -a name api.corp.example

Replace the example name with a real test record. A short name can introduce search-domain expansion and obscure which suffix was tested. Record the exact name, time, active VPN state, and returned address or error.

dscacheutil reports the host lookup result available through macOS’s directory and cache layer; it is not a packet capture and does not guarantee that a DNS packet was sent. Local host data or a cached result can affect the outcome. Use it to compare the system lookup result, and use a separately labeled direct-server query when you need to test a specific DNS server.

For a split-DNS VPN, Apple’s Network Extension API describes NEDNSSettings.matchDomains as the domains whose queries use that DNS settings object; other names use the system default resolver. An empty string in that list makes the VPN DNS settings the default domain, so it is not a narrow suffix match. Apple also documents a significant exception: if the VPN tunnel becomes the network’s default route, the VPN DNS servers become the default resolver and the match-domain list is ignored. Thus, a resolver block containing a VPN interface or supplemental domain is evidence to investigate, not proof that a particular query used it.

Compare snapshots only across an approved, controlled state change - for example, before and after connecting a test VPN on a lab Mac. If the problem appears only after a VPN connects, compare the added or changed resolver blocks and interface index, then ask the VPN or MDM owner to verify the intended match domains and tunnel route. Do not disconnect a production VPN or remove a profile merely to see what happens.

Separate system resolution from direct-server tests

dig @192.0.2.53 api.corp.example sends a query to the explicit server. That can test server reachability or its answer, but it bypasses the question “which resolver would macOS choose for this name?” A direct-server success alongside a system-resolver failure narrows the issue; it does not prove that the system selected that server.

Likewise, /etc/resolv.conf is not a complete representation of all supplemental macOS resolver configuration. Use scutil --dns for the exposed resolver set, and use a system-resolver API or tool for the application-style lookup. If an application still behaves differently, compare the exact hostname, process, cache state, VPN state, and API it uses; applications may have their own DNS-over-HTTPS or proxy configuration.

Avoid testing with ping alone. It combines name resolution with ICMP reachability, which may be filtered even when DNS works. A failed ping does not identify the resolver, and a successful one does not prove that a browser or application uses the same DNS path.

A practical triage sequence

  1. Record macOS version, the exact fully qualified test name, and whether the relevant VPN or managed network configuration is active.
  2. Capture scutil --dns locally. Identify the default resolver, domain-scoped entries, nameservers, and interface scope relevant to the suffix being tested.
  3. Run dscacheutil against the same fully qualified name. Record the result and repeat only after an approved network-state transition.
  4. If needed, query the expected DNS server directly as a separate test. Label it as a server test, not as proof of system resolver selection.
  5. If the system resolver and direct-server results disagree, provide the redacted snapshots and exact name to the network/VPN administrator. Ask them to verify domain matching, server availability, and whether the VPN is a default route.

This workflow isolates configuration selection before changing it. DNS settings may be delivered through DHCP, VPN software, Network Extension providers, or device management; making a local change can hide the actual owner of the configuration or be overwritten at the next reconnect.

Related:

Sources:

Comments