A colleague adds a nameserver line to /etc/resolv.conf on a Mac and reports that DNS resolution is unchanged for their apps. Why does that happen on macOS, and how do you actually change and inspect the system's DNS configuration?

## The Linux habit that fails here On a Linux host you can reason about resolution by reading `/etc/nsswitch.conf` and `/etc/resolv.conf`. Bringing that habit to macOS produces this bug report every time. macOS does have a `/etc/resolv.conf`, and it does contain `nameserver` lines, and it is nevertheless not where the system's DNS configuration lives. ## Where it does live `configd` maintains the **dynamic store**: a live, in-memory database of network state assembled from DHCP leases, manually configured network services, VPN connections and configuration profiles. DNS settings are one branch of it, and they are *per network service* — Wi-Fi can have one set of resolvers while an active VPN supplies another, plus resolvers scoped to particular domains. `mDNSResponder` — the unified responder that handles both unicast DNS and multicast/Bonjour names — consumes that configuration and answers on behalf of applications, which reach it through the system resolver APIs. It also owns the DNS cache. `/etc/resolv.conf` is a symlink to a file `configd` writes out as a courtesy for software that links the classic BIND resolver directly instead of using the system APIs. Because it is generated, editing it is pointless twice over: the programs you care about never read it, and the next network change regenerates it. ## Changing DNS properly `networksetup` is the supported command-line front end to network service configuration: ```bash networksetup -listallnetworkservices networksetup -getdnsservers Wi-Fi sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 8.8.8.8 sudo networksetup -setdnsservers Wi-Fi Empty # revert to DHCP-supplied networksetup -getsearchdomains Wi-Fi ``` Note the argument is a **network service name** ("Wi-Fi", "Ethernet", "USB 10/100/1000 LAN"), not a BSD interface name like `en0`; listing the services first is how you get the exact string, which is case- and spelling-sensitive. The literal `Empty` clears the manual override rather than setting a server named Empty. On a managed Mac, DNS may be set by a configuration profile instead, in which case it is enforced centrally and a local `networksetup` change is the wrong lever. ## Inspecting what is really in effect `scutil --dns` is the answer to "what will this machine actually do with a lookup": ``` resolver #1 search domain[0] : corp.example.com nameserver[0] : 10.0.0.53 if_index : 14 (en0) flags : Request A records reach : 0x00020002 (Reachable,Directly Reachable Address) resolver #2 domain : internal.example.com nameserver[0] : 10.9.9.9 ``` The ordering and the scoping are the point. Resolver #1 is the default; later entries with a `domain` line are **split DNS** — queries for that suffix go to that server only. This is how a VPN routes internal names to internal resolvers while everything else stays on the local network, and it is invisible from `/etc/resolv.conf`. `scutil` more generally is the client for the dynamic store; interactively, `scutil` then `show State:/Network/Global/DNS` prints the global DNS dictionary. ## Why dig and the browser disagree This is the classic follow-on symptom. `dig` and `nslookup` are BIND tools: they build queries themselves and read `/etc/resolv.conf` for a server, bypassing `mDNSResponder` entirely. So `dig` ignores the DNS cache, ignores split-DNS scoping, and ignores `/etc/hosts`. A name can resolve in `dig` and fail in Safari, or vice versa, purely because the two took different paths. To query through the same path an application uses, use `dscacheutil -q host -a name www.example.com`, which goes through Directory Service and the system resolver. Comparing the two answers is a fast way to tell a *server* problem from a *client configuration or cache* problem. ## Cache and hosts file `mDNSResponder` caches positive and negative answers. The standard flush is: ```bash sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder ``` Both halves are conventional: the first clears the Directory Service cache, the second signals the responder to reload. `/etc/hosts` *is* honoured — it is consulted through the system resolver path, so a hosts entry affects applications but will not affect `dig`. ## What the interviewer is listening for That you know configuration is centralised in the dynamic store, that `/etc/resolv.conf` is generated output, that `networksetup` sets and `scutil --dns` inspects, and — the mark of someone who has actually debugged this — that `dig` takes a different path from the applications, which is why the two can disagree.