On macOS Sonoma 14 and newer, you can flush the local DNS cache by running sudo killall -HUP mDNSResponder in Terminal with administrator permission. Check the macOS version first, because some older releases need different commands. After the flush, repeat the affected hostname lookup and compare the result with the answer recorded beforehand.

Clearing the cache can help when a Mac keeps using an older DNS answer after a record has changed. It does not change the published DNS zone, clear an upstream resolver's cache or force an application to close an existing connection. A successful command therefore does not guarantee that a website will immediately use a new address.

Identify the macOS Version and the Failing Name

Open the Apple menu and choose About This Mac to find the full version number. Include the last number on older systems: Yosemite 10.10.3 and 10.10.4 use different cache services. On a managed Mac, check whether your administrator has a procedure for its DNS or VPN software before making a change.

Note the hostname that fails, the network in use and whether you are investigating an IPv4 A answer or an IPv6 AAAA answer. Use the same details for the later comparison. If the Mac already resolves the expected address but the site returns an HTTP or certificate error, investigate that later failure instead of assuming the DNS cache is wrong.

Open Terminal from Applications > Utilities, or find it with Spotlight. For a system lookup of both address families, run dns-sd -G v4v6 www.example.com., replacing the example hostname with the affected name and retaining the final dot for a fully qualified name. The command uses the Mac's system resolution service; note the addresses or error it reports, then press Control-C to stop the ongoing lookup.

If you only need IPv4 results, use v4 instead of v4v6; for IPv6, use v6. Keep that choice unchanged for the comparison after flushing. A browser can use a separate DNS cache or encrypted DNS service, so this system lookup and a browser test answer different questions.

Run the Command for Your macOS Version

For Sonoma 14 and newer, enter sudo killall -HUP mDNSResponder in Terminal and press Return. The command requests a cache reset from the system's mDNSResponder service. Use it only on a Mac you administer or with permission from its administrator.

If Terminal requests a password, enter the password for your administrator account on the Mac and press Return. Password characters are not displayed as you type, so a stationary cursor does not mean that Terminal has stopped accepting input. If your account lacks the required permission, ask the administrator to perform the operation.

The same mDNSResponder command applies to OS X 10.10.4 and later releases, including the versions between Yosemite and Sonoma. It also applies to Lion 10.7, Mountain Lion 10.8 and Mavericks 10.9. Early Yosemite is the exception: on 10.10 through 10.10.3, the corresponding commands are sudo discoveryutil mdnsflushcache and sudo discoveryutil udnsflushcaches, run separately. Snow Leopard 10.6 through 10.6.8 uses sudo dscacheutil -flushcache.

Choose the command for the version you actually have; do not run every historical command in sequence. Read any error before continuing, especially if a command is missing or permission is denied. A silent return to the prompt is not proof that the affected name now resolves correctly, and adding a spoken confirmation cannot establish that either.

Verify with the Same Lookup

Run the same dns-sd -G lookup again with the same hostname, address-family option and network connection. Compare the returned addresses or error with your earlier record, then stop the lookup with Control-C. Retry the affected application as well, because a correct system result does not establish what that application used.

If you manage the DNS zone, also compare the expected authoritative answer with the answer from the configured recursive resolver. Those are separate checks of the published records and the resolver's response. A public DNS checker may be useful for a public hostname, but it cannot by itself establish which answer your Mac received.

If the system lookup changes from the old address to the expected address after flushing, local cached data may have contributed to the problem. The timing alone does not prove the cause, since upstream records or cache entries can also change during the test. If the old address returns immediately, the recursive resolver or authoritative zone may still provide it; another local flush will not change that upstream data.

A newly created hostname can also be affected by a cached negative answer from a previous lookup. Clearing a local negative entry does not remove an independent negative entry at the recursive resolver. An unchanged failure can therefore require investigation beyond the Mac even when the local command completed.

Get Help When the Problem Persists

If the command reports a permission or service error, record the message and confirm the full macOS version with the administrator. Avoid changing unrelated network settings while comparing results, because that makes the effect of the flush harder to assess. If the system lookup returns the expected answer but the problem persists in just one browser, investigate that browser's DNS settings and existing connections.

For support, provide the macOS version, hostname, address family, active network, exact command and before-and-after results. Include any Terminal error and whether the failure also occurs in the affected application. Remove private names or addresses before sharing outside your organization; the remaining diagnostic details can help support narrow down which part of the lookup needs attention.