On macOS 26.5.2 (Tahoe, build 25F84), the command that clears DNS-related caches is two commands run back to back:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderBoth binaries exist on this machine at /usr/bin/dscacheutil and /usr/sbin/mDNSResponder, and mDNSResponder is running as a live process, confirmed with pgrep -x mDNSResponder. Neither prints a success message when it works — the absence of an error is the only feedback you get, which is also why this page exists: people run the command, see nothing, and assume it failed.
This exact two-part command has not always been the answer. Apple has changed it at least four times since Mac OS X shipped a DNS cache at all, and copying a command written for the wrong release is the most common reason it “doesn’t work.”
A flush only clears whatever is already sitting in these two local caches. It doesn’t reach a domain’s authoritative DNS records anywhere else, and it can’t override a TTL that hasn’t expired yet on a resolver upstream of your Mac. It does help in a narrower set of cases:
- A domain’s IP address changed recently and your Mac keeps answering with the old one.
- A site you just moved to new hosting isn’t resolving to the new server, specifically on your machine.
- A record was fixed after a typo, and the wrong value is still what your Mac serves locally.
- You changed DNS servers in Network settings and want that change to apply immediately instead of whenever the old entries would have expired on their own.
Which command for which macOS version
The table below is built from documentation written at the time each release shipped, not from testing every version on one machine today — that isn’t possible on a single Mac running a single OS. Where sources genuinely disagree, that’s noted rather than papered over.
| macOS version | Command |
|---|---|
| Tahoe 26, Sequoia 15, Sonoma 14, Ventura 13, Monterey 12, Big Sur 11 (current) — same command back through Catalina and Yosemite 10.10.4 | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder |
| Yosemite 10.10 through 10.10.3 | sudo discoveryutil mdnsflushcache; sudo discoveryutil udnsflushcaches |
| Lion, Mountain Lion, Mavericks (10.7–10.9) | sudo killall -HUP mDNSResponder |
| Snow Leopard (10.6) | sudo dscacheutil -flushcache |
| Jaguar through Leopard (10.2–10.5)* | sudo lookupd -flushcache |
*Exactly when lookupd stopped being the right tool is the one boundary where accounts diverge — some place the cutover at Leopard (10.5), others push it to Snow Leopard (10.6). The dscacheutil man page on this machine only says it “replaces most of the functionality of the lookupd tool previously available in the OS,” without a version number attached, so that ambiguity is inherited from Apple’s own documentation, not invented here.
The Yosemite row is the sharpest edge in the whole history. OSXDaily’s original Yosemite guide, published November 20, 2014, describes discoveryutil replacing mDNSResponder entirely in 10.10 through 10.10.3 — then Apple reversed that decision in 10.10.4, reinstating mDNSResponder and, with it, the dscacheutil combination that’s still current more than a decade later. A follow-up on El Capitan, published November 16, 2015, confirms the same two-part command carried straight through to 10.11.
Why two commands instead of one
dscacheutil and mDNSResponder aren’t doing the same job. dscacheutil talks to the Directory Service cache — the layer that also resolves usernames, groups, and mount info, not just hostnames. mDNSResponder is the daemon that actually performs DNS lookups and holds its own separate in-memory cache of the answers. Flushing one and not the other leaves half the stale data in place, which is why guides that only run one command sometimes “half work.”
There’s a wrinkle worth calling out: the local dscacheutil man page describes -flushcache as something that “should only be used in extreme cases,” not as routine maintenance. Everyday troubleshooting treats it as exactly that anyway — Apple’s own framing and how the command actually gets used day to day don’t match.
The sudo in front of killall isn’t optional flavor, either. The killall man page states plainly that it signals “processes with a real UID identical to the caller” by default, and that “the super-user is allowed to kill any process.” mDNSResponder runs as root, so an unprivileged killall -HUP mDNSResponder is filtered out by that UID check before it ever reaches the daemon — no error, no confirmation, nothing to flush.
How to confirm it actually happened
The mDNSResponder man page documents one built-in way to check the daemon is alive and listening for signals — it just isn’t the one most guides mention. A SIGINFO signal makes mDNSResponder write a snapshot of its internal state to the system log:
sudo killall -INFO mDNSResponder- Run the command above right after flushing.
- Open Console.app, or run
log show --last 1m --predicate 'process == "mDNSResponder"'in Terminal. - Look for the state-dump entry timestamped seconds after you ran the signal — that’s the daemon acknowledging it, not a message confirming every stale record is gone.
That distinction matters: this confirms mDNSResponder received and processed the signal, not that a specific hostname’s cached record was the thing sitting in there. Oddly, the documented signals for mDNSResponder are SIGUSR1 (extra logging), SIGUSR2 (packet logging), and SIGINFO — the man page on this build never mentions SIGHUP at all, despite -HUP being the signal at the center of the standard flush command. It’s undocumented behavior that’s been stable for years, not something spelled out in the daemon’s own manual.
Common mistakes that make it look like it didn’t work
- Dropping sudo from the killall half. As above, the UID filter means it silently signals nothing rather than failing loudly.
- Running today’s combined command on Yosemite 10.10–10.10.3. dscacheutil/mDNSResponder weren’t the active tools on that specific point-release range — discoveryutil was.
- Mistyping dscacheutil. It’s a real binary at /usr/bin/dscacheutil on every supported release, not a tool that got removed — “command not found” almost always means a typo or the command being pasted somewhere that isn’t a Mac’s Terminal.
Where the old version of this page got it wrong
The version of this page that ran before this rewrite made two mistakes worth naming directly, since fixing them is most of the reason this exists.
First, it grouped El Capitan through Catalina (10.11–10.15) into one row using sudo killall -HUP mDNSResponder alone, calling it “the simpler command.” OSXDaily’s El Capitan guide, written days after that release shipped in 2015, gives the two-part dscacheutil-plus-killall command instead — the same one this page lists for Yosemite 10.10.4 onward. The old row wasn’t simpler, it was incomplete.
Second, it framed its own coverage as running from Catalina (10.15) through Sequoia (15), described with a relative word standing in for “current release” instead of a version number. Once Tahoe (26) shipped, that sentence read as false — the exact failure mode a version table is supposed to avoid. That’s why every version above is written as a number, not a relative word.
If the two-command flush above doesn’t change the behavior you’re troubleshooting, the cache probably wasn’t the cause — a single stale record rarely survives an app restart or a network toggle on its own, so a problem that persists past both is more likely sitting in the site’s own DNS records, in a resolver upstream of your Mac, or in the browser’s separate connection cache rather than in mDNSResponder.