DNS Cache Flushing: Architecture, Mechanics, and OS Implementations

When website migrations occur, IP addresses change, or domain routing records are updated, users frequently report that their workstations continue to reach obsolete server IP addresses or display NXDOMAIN (domain not found) errors [1, 2]. Meanwhile, external diagnostic tools verify that the new DNS records have propagated globally [1].

This discrepancy is caused by local DNS caching layers [1]. To minimize network latency and reduce load on authoritative nameservers, client operating systems, recursive resolvers, and web browsers maintain internal DNS caches governed by Time-To-Live (TTL) timers [1, 2]. In this technical guide, we examine the mechanics of DNS caching, explain the nuances of Negative Caching (RFC 2308), and provide exact, verified administrative commands to flush DNS caches across Windows, macOS, and Linux systems [1, 2, 3].

1. How DNS Caching Works: TTL and Multi-Tier Caching

When a client application (e.g., a web browser) initiates a connection to deprogit.com, the resolution traverses multiple caching tiers before querying external nameservers [1]:

+-------------------------------------------------------------+
|                     DNS Resolution Chain                    |
|                                                             |
|  1. Browser Internal DNS Cache (Chrome / Firefox / Edge)    |
|       | (Miss)                                              |
|  2. Operating System Stub Resolver Cache (Windows / macOS)  |
|       | (Miss)                                              |
|  3. Local Router / Gateway DNS Proxy (dnsmasq)              |
|       | (Miss)                                              |
|  4. Upstream Recursive Resolver (ISP / Cloudflare / Google) |
|       | (Miss)                                              |
|  5. Authoritative Nameserver (Returns Record + TTL)         |
+-------------------------------------------------------------+

Time-To-Live (TTL) Mechanics

Every DNS record published by an authoritative nameserver contains a TTL value expressed in seconds (e.g., 300 for 5 minutes, or 86400 for 24 hours) [1]:

• When a caching resolver stores the record, it starts a decrementing countdown timer.
• Until the timer reaches zero, all queries for that domain return the cached IP immediately without contacting the authoritative nameserver [1].

Negative Caching (RFC 2308)

A common source of confusion is Negative Caching [2]:

• If a user attempts to visit a newly registered domain before the DNS records are active, the authoritative server returns an NXDOMAIN response.
• Under RFC 2308, recursive resolvers and OS clients cache this negative result for the duration specified in the SOA record's MINIMUM field (often up to 3600 seconds) [2].
• Even if the administrator creates the valid A record five seconds later, the client workstation continues to fail until its negative cache entry expires or is flushed [2].

2. Flushing DNS Caches Across Operating Systems

Flushing the local resolver cache purges all cached resource records, forcing the operating system to query upstream nameservers for fresh records [1, 2].

Microsoft Windows (Windows 10, Windows 11, Windows Server)

Windows manages DNS resolution through the native DNS Client service (Dnscache):

1. Open Command Prompt or PowerShell as an Administrator.
2. View current cached records (optional):

ipconfig /displaydns

3. Purge the cache:

ipconfig /flushdns

Expected Output:

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Apple macOS (macOS Monterey, Ventura, Sonoma, Sequoia)

macOS handles DNS resolution through the mDNSResponder daemon. Flushing the cache requires signaling the daemon to restart:

1. Open Terminal.
2. Run the administrative command:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

(Enter your administrator password when prompted. The command completes silently without error if successful).

Linux Distributions

Modern Linux distributions employ different resolver daemons depending on the environment:

1. systemd-resolved (Ubuntu 20.04+, Debian, Fedora, Red Hat)

Most modern Linux distributions utilize systemd-resolved:

# Check current cache statistics
resolvectl statistics

# Flush the local cache
sudo resolvectl flush-caches

2. Dnsmasq

If the system operates a local dnsmasq caching proxy:

sudo systemctl restart dnsmasq

3. BIND / Named Resolvers

If running a local BIND caching resolver:

sudo rndc flush

3. The Browser Caching Layer: DoH and Application Caches

Modern web browsers implement independent DNS caches and frequently enable DNS-over-HTTPS (DoH), bypassing the host operating system's resolver entirely [3]:

• Google Chrome & Brave: Navigate to chrome://net-internals/#dns and click "Clear host cache".
• Mozilla Firefox: Navigate to about:networking#dns and click "Clear DNS Cache".
• Microsoft Edge: Navigate to edge://net-internals/#dns and click "Clear host cache".

If a user flushes their Windows or macOS system cache but fails to clear their browser cache, the browser will continue serving the stale IP address [3].

OS DNS Cache Mechanics Comparison

Practical Implementation Steps for Administrators

When executing critical domain or infrastructure cutovers:

1. Lower TTL Values Prior to Migration: Reduce record TTLs to 300 seconds (5 minutes) at least 48 to 72 hours before the scheduled migration to ensure records expire rapidly from global resolver caches [1].
2. Verify Negative Caching Parameters: Review the SOA record MINIMUM field to prevent long negative caching periods during setup [2].
3. Audit Host Files: Ensure internal users do not have obsolete static overrides in C:\Windows\System32\drivers\etc\hosts or /etc/hosts that take precedence over DNS queries [1].

For enterprise web platform management, infrastructure migrations, and domain security, explore our capabilities on our Web & Software Development page.

Key Takeaways

• DNS caching exists across multiple layers: browsers, operating systems, local routers, and recursive resolvers.
• Negative caching (RFC 2308) caches NXDOMAIN failures, causing workstations to fail even after valid records are created.
• Purging local OS resolver caches forces workstations to request fresh authoritative records immediately.
• Modern web browsers maintaining independent DoH caches must be cleared separately from the host operating system.

Need help with this? Contact us.

Sources

[1] IETF, "RFC 1034: Domain Names - Concepts and Facilities", 1987. URL: https://www.rfc-editor.org/rfc/rfc1034.html (Foundational standard establishing DNS resolver architecture, hierarchy, and resource record caching principles).

[2] IETF, "RFC 2308: Negative Caching of DNS Queries (DNS NCACHE)", 1998. URL: https://www.rfc-editor.org/rfc/rfc2308.html (Standards-track specification for caching negative DNS responses such as NXDOMAIN and NODATA).

[3] IETF, "RFC 8484: DNS Queries over HTTPS (DoH)", 2018. URL: https://www.rfc-editor.org/rfc/rfc8484.html (Standard defining DNS encapsulation over HTTPS and application-level resolver architectures).

Last reviewed: October 2026