Types of DNS Cache, Cybersecurity Risks & How to Secure Your DNS

• Browser DNS cache: Stores recent domain lookups inside the browser to speed up repeated website visits.
• Operating system DNS cache: Stores DNS results at the device level so multiple applications can reuse resolved records.
• Router DNS cache: Caches DNS responses at the network gateway to reduce repeated lookups for connected devices.

• Recursive DNS resolver cache: Stores DNS records at ISP, enterprise, or public resolver level to serve many users faster.
• Application-level DNS cache: Allows specific applications to cache DNS results independently for performance and control.

• Forged DNS responses: Attackers send fake DNS replies that may be cached if accepted before the legitimate response.
• Resolver vulnerabilities: Weak or outdated resolver software can allow attackers to inject or manipulate cached DNS records.

• Man-in-the-middle attacks: Attackers intercept and alter DNS traffic in transit before it reaches the client or resolver.
• Compromised DNS infrastructure: Attackers modify DNS records at authoritative servers, resolvers, or DNS management systems.

• Windows: Open Command Prompt as admin and type ipconfig /flushdns.
• Mac: Open Terminal and type sudo killall -HUP mDNSResponder.

• Chrome: Go to chrome://net-internals/#dns and click clear host cache.

• Types of DNS Caches
• Technical Deep Dive: How Recursive DNS Caching Works
• What Is DNS Cache Poisoning?

• DNS Caching Cybersecurity Risks: How Attackers Exploit DNS Caches
• How to Clear an Operating System and Browser DNS Cache
• How to Secure DNS Caching in Your Organization

Browser DNS Cache

Web browsers maintain their own DNS caches to speed up the resolution of domain names for websites frequently visited by the user. When a domain is resolved, the browser stores the resulting IP address in its internal cache, allowing future requests for the same domain to bypass operating system and network-level DNS queries. This cache is managed independently from other system caches and is cleared when the browser is closed, restarted, or manually flushed.

Browser DNS caching is useful for users who visit the same websites repeatedly during a browsing session. By storing recent DNS records, browsers reduce page load times and improve responsiveness of web applications. Browser caches are generally short-lived, and their effectiveness depends on user behavior and browser-specific cache management policies.

Operating System DNS Cache

The operating system (OS) maintains its own DNS cache, storing query results obtained by any application running on the device. This system-level cache ensures that once a domain has been resolved, subsequent applications can use the cached record without initiating new queries. The OS cache persists across browser sessions and typically holds more DNS records than browser caches.

Managing the OS DNS cache is important for performance and troubleshooting. Cached entries are subject to TTL expiration, after which they are automatically removed. Users and administrators can manually clear the OS DNS cache using commands like ipconfig /flushdns on Windows or sudo dscacheutil -flushcache on macOS to resolve issues related to stale or incorrect DNS records. This helps maintain reliable domain resolution across the system.

Router DNS Cache

Routers can implement DNS caching, acting as intermediaries between client devices and external DNS servers. When a device on the network submits a DNS query, the router checks its local cache for a matching entry before forwarding the request upstream. This reduces redundant DNS traffic and speeds up domain resolution for connected devices, particularly in environments with many users or devices accessing similar resources.

Router-based DNS caches are useful in home or office settings where multiple clients visit the same websites. By centralizing DNS caching at the network gateway, routers can decrease average DNS lookup times and reduce bandwidth use. Like other caches, router DNS entries are subject to TTL expiration, and routers may provide options to manually flush their DNS cache.

Recursive DNS Resolver Cache

Recursive DNS resolvers, often operated by ISPs or third-party DNS providers, maintain large-scale caches for the domains they resolve on behalf of clients. These caches store DNS records obtained from authoritative servers and serve them to any client making the same request within the record's TTL. Because these resolvers handle queries from many users, their caches are extensive and reduce upstream DNS traffic.

The efficiency of recursive resolver caches affects the performance and reliability of DNS resolution across large user bases. By serving cached responses, recursive resolvers reduce query latency and help shield users from temporary outages or slowdowns in the broader DNS infrastructure. Maintaining secure and accurate caches at this level is critical, as poisoned resolver caches can affect many users at once.

Some applications implement their own DNS caching mechanisms, independent of browser or operating system caches. Examples include web servers, proxy servers, and custom networking tools that handle high volumes of DNS queries or require fine-grained control over caching behavior. Application-level caches can be configured with custom TTLs, cache sizes, and flushing policies.

Application-level DNS caches are useful in scenarios where rapid, repeated domain lookups are common or where the application needs consistent performance regardless of the underlying system cache state. However, managing multiple layers of caching increases complexity, and care must be taken to avoid stale or conflicting records. Developers should ensure that application caches respect DNS TTLs and provide mechanisms for cache invalidation.

1. DNS Query is Submitted

When a client needs to resolve a domain name, it sends a DNS query to a recursive DNS resolver. The recursive resolver may be operated by an ISP, an enterprise network, or a public DNS provider.

Before contacting other DNS servers, the recursive resolver checks its cache for a valid record that can answer the query. If the requested record is already cached and has not expired, the resolver can respond immediately. If no valid cached answer is available, it must perform a DNS lookup.

2. Recursive Resolver Checks Its Cache

The recursive resolver stores DNS records obtained from previous lookups. Each cached record is associated with a time-to-live (TTL) value that determines how long the resolver may continue using it.

When the resolver receives a query, it searches its cache for a matching record. If it finds an unexpired record, it returns the cached result to the client without contacting upstream DNS servers.

This reduces DNS resolution latency and decreases the number of queries sent to root, top-level domain (TLD), and authoritative DNS servers.

3. Cached DNS Record Is Returned

If the recursive resolver finds a valid cached record, it returns the DNS response directly to the client. The client can then use the returned information, such as an IP address from an A or AAAA record, to continue establishing a connection to the requested service.

Because the resolver does not need to perform a new lookup, a cache hit usually requires fewer network requests than a full DNS resolution.

The resolver also reports the remaining TTL for the cached record. As time passes, this value decreases until the cached entry expires.

4. Recursive DNS Lookup Occurs When Needed

If the requested record is not present in the cache or its TTL has expired, the recursive resolver must obtain a new answer.

For a typical uncached lookup, the resolver may query several DNS servers:

1. A root DNS server directs the resolver to the appropriate TLD servers.
2. A TLD server directs the resolver to the authoritative DNS servers for the domain.
3. An authoritative DNS server returns the requested DNS record or other information needed to complete the lookup.

The resolver follows these referrals until it obtains an answer that it can return to the client.

During this process, the resolver may also cache intermediate information, such as NS records and address records for authoritative name servers. These cached records can reduce the number of queries required for later lookups.

When the recursive resolver receives cacheable DNS records, it stores them according to their TTL values. The TTL is supplied in the DNS response and specifies how long the record may remain cached.

While the TTL remains valid, subsequent queries for the same information can be answered from the resolver's cache. When the TTL reaches zero, the cached record can no longer be used to answer new queries, and the resolver must obtain fresh DNS data when another request arrives.

Shorter TTLs cause resolvers to refresh records more frequently, which allows DNS changes to take effect sooner. Longer TTLs allow records to remain cached for longer periods, reducing repeated queries to authoritative DNS infrastructure.

Forged DNS Responses

Attackers may send forged DNS responses before the legitimate response arrives from an authoritative server. If the resolver accepts the fake response, it stores the malicious DNS record in its cache and returns it for future requests. This redirects users to attacker-controlled servers without changing the requested domain name.

Modern DNS resolvers make forged responses harder to inject by using randomized transaction IDs and source ports. These protections reduce the likelihood that an attacker can guess the values required for a spoofed response to be accepted. Outdated or improperly configured resolvers remain more vulnerable to this type of attack.

Resolver Vulnerabilities

DNS resolvers may contain software flaws or configuration weaknesses that attackers can exploit to poison or manipulate cached records. Examples include predictable query identifiers, insufficient response validation, or vulnerabilities in resolver implementations. Successful exploitation allows attackers to inject false DNS data or bypass verification mechanisms.

Keeping resolver software updated helps prevent these attacks. Security patches address known vulnerabilities, while secure configuration practices reduce the attack surface. Organizations should restrict access to recursive resolvers and enable features such as DNSSEC validation when possible.

Man-in-the-Middle Attacks

In a man-in-the-middle (MITM) attack, an attacker intercepts DNS traffic between a client and a resolver or between DNS servers. By modifying DNS responses in transit, the attacker can replace legitimate records with malicious ones before they are cached or delivered to the client. This can redirect users to fake websites or malicious services.

MITM attacks typically require the attacker to gain a position on the network path, such as through a compromised Wi-Fi network or a breached router. Encrypting DNS traffic with protocols such as DNS over HTTPS (DoH) or DNS over TLS (DoT) helps prevent unauthorized parties from reading or altering DNS queries and responses.

Compromised DNS Infrastructure

Attackers may target the DNS infrastructure rather than individual clients or resolvers. By compromising authoritative DNS servers, recursive resolvers, or DNS management accounts, they can modify legitimate DNS records at the source. These malicious records are then distributed and cached by resolvers across the internet according to their TTL values.

Protecting DNS infrastructure requires strong authentication, regular software updates, access controls, and continuous monitoring. Multi-factor authentication for DNS management accounts, DNSSEC deployment, and prompt detection of unauthorized record changes help reduce the risk of infrastructure compromise and the distribution of malicious DNS data.

When Do You Need to Clear the DNS Cache?

You may need to clear the DNS cache when cached records become outdated or incorrect. This can happen after a website changes its IP address, DNS records are updated, or a domain moves to a different server. Flushing the cache forces the operating system to request fresh DNS data, which can resolve errors such as websites failing to load or connections being directed to an old server.

Clearing the DNS cache can also be useful after a suspected security incident. If malicious or forged DNS records have entered the cache, they may redirect requests to attacker-controlled systems until they expire. Flushing the cache removes these local entries, but it does not fix the source of the compromise. If cache poisoning is suspected, administrators should also verify DNS settings, check the configured resolver, update affected systems, and investigate how the false records were introduced.

How to Clear DNS Cache in Windows

Windows stores DNS records in the operating system cache, which can be cleared from the Command Prompt.

1. Open Command Prompt as an administrator.
2. Run the following command: ipconfig /flushdns
3. Press Enter.

If successful, Windows displays: Successfully flushed the DNS Resolver Cache.

You can verify that the cache has been cleared by accessing the website again, which will trigger a new DNS lookup.

How to Clear DNS Cache on macOS

macOS caches DNS records through system services. The required command varies slightly between macOS versions, but the following works on current releases.

1. Open Terminal.
2. Run: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
3. Enter your administrator password when prompted.

The command completes without displaying a confirmation message.

The next DNS request will retrieve fresh records from the configured DNS resolver.

How to Clear DNS Cache in Google Chrome

Google Chrome maintains its own internal DNS cache in addition to the operating system's cache.

1. Open Chrome.
2. In the address bar, enter: chrome://net-internals/#dns
3. Click Clear host cache.
4. Reload the website.

Note: On current Chrome versions, chrome://net-internals/#dns may still be available for clearing Chrome's host cache. The chrome://net-export page is not an alternative DNS-cache clearing tool. It is used to capture network diagnostic logs. If the Clear host cache option is unavailable in your Chrome version, clear the operating system's DNS cache and restart Chrome instead.

If the problem persists, clear the operating system's DNS cache as well, since Chrome also relies on the system resolver for many DNS operations.

1. Enable DNSSEC Validation on Recursive Resolvers

Organizations should enable DNSSEC validation on their recursive DNS resolvers. DNSSEC uses cryptographic signatures to let a resolver verify that DNS data is authentic and has not been modified.

When validation is enabled, the resolver can reject forged or tampered responses for DNSSEC-signed zones instead of storing them in cache. This reduces the risk of DNS cache poisoning.

Administrators should verify that all organization-managed recursive resolvers perform DNSSEC validation and that validation failures are logged and monitored. DNSSEC does not encrypt DNS traffic, so it should be combined with other controls where confidentiality is required.

2. Centralize DNS Resolution Through Approved Resolvers

Organizations should configure endpoints and network devices to use approved recursive DNS resolvers rather than allowing users or applications to select arbitrary external resolvers.

Centralizing DNS resolution makes it easier to enforce security policies, monitor DNS activity, apply filtering, and investigate suspicious queries. Approved resolvers may be operated internally or provided by a managed DNS service.

Network controls should prevent unauthorized DNS traffic from bypassing these resolvers where practical. This can include restricting outbound DNS traffic on port 53 and defining policies for encrypted DNS protocols such as DNS over HTTPS (DoH) and DNS over TLS (DoT).

3. Keep Recursive Resolver Software and Infrastructure Updated

Recursive DNS servers and the infrastructure that supports them should be included in the organization's patch management process.

Administrators should apply security updates to DNS resolver software, operating systems, firewalls, and related network components. Outdated software may contain vulnerabilities that allow attackers to disrupt resolution, bypass protections, or manipulate cached data.

Organizations should also review resolver configurations after upgrades to ensure that security settings, logging, DNSSEC validation, and access controls remain enabled.

4. Restrict Access to Recursive Resolvers

Recursive DNS resolvers should accept queries only from authorized clients and networks.

An unrestricted recursive resolver can be abused by external attackers for DNS amplification attacks and may expose internal DNS infrastructure unnecessarily. Organizations should use firewall rules, access control lists, or resolver configuration settings to limit who can submit recursive queries.

Internal resolvers should generally be reachable only from corporate networks, approved remote-access infrastructure, and other explicitly authorized systems.

5. Verify Cache-Poisoning Protections

Modern recursive resolvers include protections such as randomized source ports and DNS transaction IDs, which make forged DNS responses more difficult to predict and inject.

Administrators should verify that these protections are enabled and that network devices such as firewalls, NAT gateways, or load balancers do not reduce their effectiveness by rewriting DNS traffic in predictable ways.

These protections should supplement DNSSEC validation rather than replace it.

6. Monitor Resolver Activity and Cache Anomalies

Organizations should monitor recursive DNS resolvers for signs of poisoning, abuse, or unusual resolution behavior.

Relevant indicators can include sudden changes in resolved IP addresses, repeated DNSSEC validation failures, unusually high query volumes, unexpected domains, and abnormal response patterns.

DNS logs should be forwarded to centralized monitoring or SIEM systems where possible. Alerts can help security teams identify compromised endpoints, malicious DNS activity, or resolver misconfigurations before they affect a large number of users.

Organizations should configure recursive resolvers to follow DNS TTL values correctly and avoid keeping stale records longer than intended unless a documented resiliency feature requires it.

Administrators should also review features such as serve-stale caching, negative caching, cache prefetching, and custom TTL overrides. These features can improve availability and performance, but incorrect settings may cause outdated or incorrect records to remain in use.

Any deviations from authoritative TTL values should be documented and applied consistently across organizational resolvers.

• Protection against any DNS DDoS attack: Real-time detection and mitigation of both known and zero-day DNS DDoS attacks, so networks and services remain accessible and resilient.
• Coverage of DNS-specific attack techniques: Defends against DNS amplification attacks, DNS flood attacks, DNS water torture / random sub-domain attacks, and phantom domain attacks.
• Automated machine-learning protection: A multi-layered, patented, and adaptive solution that accurately detects and mitigates attack campaigns while minimizing false positives.
• Shorter time to mitigate (TTM): Autonomous management of detection, characterization, and mitigation without human intervention, lowering overall time to mitigate.

• Lower total cost of ownership (TCO): Configuration management and handling of ongoing attacks is fully automated, leading to significantly lower costs.
• Flexible deployment: Cloud services, appliances, and hybrid solutions to match any customer use case, environment, or architecture.
• Fully managed security service: Real-time support from the 120 battle-proven security experts on Radware's Emergency Response Team (ERT).