How to Flush DNS on Mac (macOS Tahoe 26 Command)

To flush DNS on a Mac running macOS Tahoe 26, open Terminal and run this one line. It asks for your admin password and prints nothing when it works.

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

The first part clears the Directory Services cache. The second part sends a “hang up” signal to mDNSResponder, the process that handles DNS on macOS, which makes it drop its cached answers. It does not quit the process. It is the same command Apple has used for years, and on Tahoe 26.6.2 both tools are still where it expects them.

I did not run the flush on my test Mac because it needs sudo. Everything else below (checking the DNS process, querying the cache, confirming new answers) was run on a MacBook Air with macOS Tahoe 26.6.2.

Step 1: Check that mDNSResponder is the DNS process

Before you flush, it’s worth seeing what you are about to signal. pgrep lists the process by name:

pgrep -l mDNSResponder

649 mDNSResponder
666 mDNSResponderHe

There are two processes. The second one is mDNSResponderHelper. Its name is cut off at 15 characters because pgrep -l shows the short kernel process name. Add -f to see the full path:

pgrep -lf mDNSResponder

649 /usr/sbin/mDNSResponder
666 /usr/sbin/mDNSResponderHelper

You can also see who owns them:

ps -o pid,user,comm -p $(pgrep -d, mDNSResponder)

  PID USER           COMM
  649 _mdnsresponder /usr/sbin/mDNSResponder
  666 root           /usr/sbin/mDNSResponderHelper

This is why the command needs sudo. The resolver runs as the system user _mdnsresponder, not as you. macOS does not let a regular user send signals to another user’s process, so killall needs sudo here. Both binaries live in /usr/sbin/, and dscacheutil lives in /usr/bin/. Both are part of the sealed system volume, so you will not find them missing on a normal Mac.

Step 2: Flush the DNS cache

Run the command from the top of this post:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

A few notes:

Type your Mac login password when asked. Nothing shows while you type. That is normal.
No output means success. There is no “cache flushed” message.
The ; runs the second command even if the first one prints a warning.
You do not need to restart the Mac or turn Wi-Fi off and on.

The dscacheutil man page on Tahoe still describes -flushcache with a warning:

     -flushcache
	     Flushes the entire cache.	This should only be used in extreme
	     cases.

In practice it is harmless. Your Mac just looks names up again the next time an app asks.

Step 3: Confirm the flush worked (and pick the right tool)

Here is the gotcha most guides miss. dig and nslookup do not use the macOS DNS cache. They send their query straight to a DNS server. So they show you what the server says, not what Safari or your apps see.

You can see this in the SERVER line. dig talks to the network’s DNS server directly:

dig example.com | grep -E 'IN[[:space:]]+A|SERVER|Query time'

;example.com.			IN	A
example.com.		261	IN	A	104.20.23.154
example.com.		261	IN	A	172.66.147.243
;; Query time: 31 msec
;; SERVER: 2001:db8::1#53(2001:db8::1)

nslookup does the same:

Server:		2001:db8::1
Address:	2001:db8::1#53

Non-authoritative answer:
Name:	example.com
Address: 172.66.147.243
Name:	example.com
Address: 104.20.23.154

To see what the system resolver returns (the path that apps use, cache included), use dscacheutil -q:

dscacheutil -q host -a name example.com

name: example.com
ipv6_address: 2606:4700:10::ac42:93f3
ipv6_address: 2606:4700:10::6814:179a

name: example.com
ip_address: 172.66.147.243
ip_address: 104.20.23.154

The proof that this goes through the system path: ask it for localhost. The answer comes from /etc/hosts, which dig never reads.

dscacheutil -q host -a name localhost

name: localhost
ipv6_address: ::1

name: localhost
ip_address: 127.0.0.1

So a good check after changing DNS records is:

dig +short example.com shows what the DNS server now says.
dscacheutil -q host -a name example.com shows what your Mac will actually use.

If the two match the new address, the flush worked. If dig already shows the new address but dscacheutil still shows the old one, flush again.

dig +short is the quick version:

dig +short example.com

172.66.147.243
104.20.23.154

Check which DNS servers your Mac uses

If the answers look wrong even after a flush, check which servers your Mac asks. scutil --dns lists them:

scutil --dns | head -8

DNS configuration

resolver #1
  nameserver[0] : 2001:db8::1
  nameserver[1] : 192.168.1.1
  if_index : 11 (en0)
  flags    : Request A records, Request AAAA records
  reach    : 0x00020002 (Reachable,Directly Reachable Address)

On my test Mac the first server was an IPv6 address handed out by the network, and the second was the router. scutil --dns listed eight resolvers in total. The rest are for .local names and reverse lookups, and you can ignore them. If nameserver[0] is not what you expect, change it in System Settings > Network > Wi-Fi > Details > DNS. Need your router’s address? See how to find your IP address in Mac Terminal.

Flush the browser’s DNS cache too

Chrome, Edge, Brave and other Chromium browsers keep their own DNS cache, separate from macOS. If Terminal shows the new address but the browser still loads the old site:

Open chrome://net-internals/#dns and click Clear host cache.
Open chrome://net-internals/#sockets and click Flush socket pools. This closes connections that are still open to the old server.

Firefox has a similar page at about:networking#dns with a Clear DNS Cache button. Safari has no DNS cache page of its own, so the Terminal flush plus a Safari restart is the usual fix there. Quitting and reopening the browser also clears its in-memory cache. I did not test the browser pages for this post. They are listed here as the usual next step.

When flushing DNS doesn’t help

Flushing only clears your Mac’s cache. It does nothing in these cases:

Problem	Why the flush doesn’t fix it	What to do
Router or ISP cache	They keep their own copy until the record’s TTL runs out	Wait for the TTL, or switch DNS servers
Entry in `/etc/hosts`	The hosts file wins over DNS, every time	Remove the line
VPN or “Private Relay”	Another resolver answers for you	Turn it off and test again
DNS record not updated	The server itself still has the old value	Check with `dig +short`

The TTL is the number in the second column of the dig output (261 above). It is in seconds. When I ran dig a few minutes earlier, the TTL for the same name was only 18. Short TTLs mean many changes clear up on their own within minutes.

To check the hosts file, just read it:

cat /etc/hosts

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1	localhost
255.255.255.255	broadcasthost
::1             localhost

That is the default file on Tahoe. If you see extra lines, such as a domain pointed at 127.0.0.1 by an old dev setup or an ad blocker, that line is your problem. No flush will override it. If a local dev server is stuck on a port after you change hosts entries, see how to kill a process on a port on Mac.

Common questions

Is the flush DNS command different on macOS Tahoe?

No. sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder is the command on Tahoe 26. On 26.6.2 the binaries are still at /usr/bin/dscacheutil and /usr/sbin/mDNSResponder, and the dscacheutil man page still documents -flushcache.

Why is there no “success” message?

Neither command prints anything when it works. If you typed the wrong password, sudo says “Sorry, try again.” If you see no error, the flush ran.

Can I flush DNS without sudo?

No. mDNSResponder runs as the _mdnsresponder user, so a regular user cannot signal it. If you can’t use an admin account, quitting the browser and waiting for the TTL to expire is the fallback.

Does `killall -HUP` stop my internet?

No. -HUP is a “hang up” signal that mDNSResponder treats as “drop your cache,” not as “quit.” The next lookup simply goes out to the DNS server again.

Why does `dig` show the new IP but my browser still loads the old site?

Because dig skips your Mac’s cache and the browser’s cache. Run the flush, clear the browser’s host cache, and then compare with dscacheutil -q host -a name yourdomain.com.

Does flushing DNS affect SSH or Git?

Only by making new lookups fresh. Hosts you already trust in ~/.ssh/known_hosts are not touched. If you’re setting up a new Git host, see how to generate an SSH key on Mac for GitHub.