If nslookup resolves a host fine but curl, pip, and Python (requests/httpx) fail with "Could not resolve host," your mDNSResponder daemon has almost certainly entered a non-responsive "zombie" state — and the fix is to restart it (sudo killall -9 mDNSResponder), not to touch your API keys, SDK versions, or code.
This failure is maddening because every signal points the wrong way. nslookup example.com returns a clean IP, so DNS "works." Your network is up. Your code didn't change. Yet curl, pip install, and every Python HTTP call die with "Could not resolve host." People burn hours rotating API keys, downgrading SDKs, and editing config files. None of that is the problem.
macOS resolves DNS over two independent paths, and the asymmetry is the diagnosis:
| Path | Who uses it | Goes through mDNSResponder? |
|---|---|---|
| Direct | nslookup, dig | No — queries DNS servers directly |
| System resolver | curl, Python, pip, most apps (getaddrinfo()) | Yes — routes to the daemon |
The daemon can keep its PID alive while silently refusing to answer. So the direct path (nslookup) succeeds and the system-resolver path (curl) fails on the exact same host. When one path works and the other fails, you are not looking at a network, key, or code problem — you are looking at a sick daemon.
Use the daemon path directly so you're testing the same route curl uses:
# Uses the mDNSResponder path (same as curl/Python). Empty result = zombie.
dscacheutil -q host -a name example.com
# ...while the direct path still returns a valid IP:
nslookup example.comIf dscacheutil comes back empty but nslookup returns an IP, the daemon is confirmed as the culprit. One more sanity check proves routing and TLS are fine and isolates the daemon as the sole cause:
# Bypass resolution entirely with the IP nslookup gave you:
curl --resolve example.com:443:<IP-from-nslookup> https://example.com
# Succeeds? Then DNS resolution is the only broken thing.Start gentle and escalate only as needed:
# 1) flush + reload (least disruptive)
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# 2) kickstart the service
sudo launchctl kickstart -k system/com.apple.mDNSResponder
# 3) universal hammer (if kickstart prints "Could not find service" —
# the service path differs across macOS versions)
sudo killall -9 mDNSResponder mDNSResponderHelper
# launchd's KeepAlive immediately restarts it with a fresh PID.
# verify
pgrep -l mDNSResponder && dscacheutil -q host -a name example.comThe zombie is usually triggered by connection-pool exhaustion. Many concurrent outbound long-poll connections — say several MCP servers, a local inference/LLM server, and an ingest or daily-report job all holding sockets open at once — push mDNSResponder into high CPU until it stops answering.
mDNSResponder to 77% CPU and into the non-responsive state. The recovery (restarting the daemon) alone doesn't stop recurrence — you have to find and cut the connection source. Watch for the active connection count climbing (lsof -i -P -n | wc -l in the 80+ range) and mDNSResponder CPU above ~30%.A subtle trap when hunting the connection source: a server can be flagged off at the code or config level (an ENABLED=False switch) while its OS process keeps running and keeps holding its long-poll connections. The flag stopped new work from being dispatched but never killed the process, so it kept feeding the pile-up. When auditing, check ps/pgrep for the actual process and its elapsed time (etime) — not just the config flag.
# the flag says off; the process says otherwise
pgrep -lf <server-name> # still there?
ps -o pid,etime,%cpu,command -p <pid>Two durable fixes: reduce concurrent long-poll load (trim always-on servers/MCP endpoints, kill stale inference servers, and on a box that runs for many days, restart mDNSResponder on a schedule), or install a watchdog LaunchDaemon that kickstarts the daemon when its CPU crosses a threshold.
mDNSResponder/getaddrinfo behavior, not Linux's nsswitch/resolv.conf. And a watchdog that calls launchctl kickstart needs root: implement it as a LaunchDaemon running as root with a narrowly scoped script, not a broad sudo NOPASSWD rule. The watchdog is a band-aid — the real fix is capping concurrent connections.Q. Why does nslookup work but curl says "Could not resolve host" on the same Mac?
Different DNS paths. nslookup/dig query DNS servers directly; curl/Python/pip use getaddrinfo() → the mDNSResponder daemon. A zombie daemon (PID alive, not answering) breaks the second path only.
Q. How do I confirm it's mDNSResponder, not my code or key?
dscacheutil -q host -a name <host> uses the daemon path — empty result while nslookup returns an IP confirms the daemon. curl --resolve with that IP succeeding proves routing/TLS are fine.
Q. How do I fix it?
Weakest-first: flushcache + killall -HUP → launchctl kickstart -k system/com.apple.mDNSResponder → sudo killall -9 mDNSResponder mDNSResponderHelper (launchd restarts it).
Q. Why does my agent/MCP box keep hitting this?
Connection-pool exhaustion from many concurrent long-poll connections (measured: 30+ → 77% CPU → zombie). Cut the connection source; restarting alone doesn't prevent recurrence.
Q. Edit /etc/resolv.conf or reinstall the SDK?
No — macOS ignores /etc/resolv.conf for its system resolver, and the SDK isn't involved. Restart the daemon and cap concurrent connections.