A survey of DNS caching and TTL in end-user client software

How long do Domain Name System (DNS) client software like web browsers cache DNS query responses? It can be difficult to determine, so I’ve prepared an overview over the DNS caching behavior of the most popular client software. Clients vary by as much as anywhere from 2 seconds to infinity!

DNS records come with a time-to-live (TTL) hint in seconds that suggest how long a cache can consider the response to be fresh, and reuse it to answer subsequent queries before having to refresh it. Different DNS clients treat this hint differently: and either ignore it completely in favor of their own policies, or enforce minimum or maximum duration on the records.

The below table shows how long a positive DNS response containing an A or AAA record is cached in different common DNS client implementations. Negative responses (resolution failures) where not meassured.

Implementation TTL honored Min-TTL Max-TTL Entries
Android No 2 sec 2 sec 16
Chrome/-ium No 1 min 1 min 1000
dnsmasq Yes 0* 68 years 150*
Java No Session Session 150*
mDNSResponder Yes 15 sec 48 days 512+ KiB
Mozilla Necko No 2 min* 2 min* 400*
Necko (Win32) Yes* 1 min* 68 years 400*
systemd-resolved Yes 0 2 hours 4096
Trident No 30 min 30 min 128
WebKit No 1 min 1 min 400
Windows DNS Yes 0 2 days* 2 MiB*

* Configurable.

There’s a lot to unpack in this table, not at least what these clients are and where you may encounter them. I’ll quickly go through every one in turn.

Note that there may be multiple DNS caches involved. A single response could be cached in Firefox, the Windows DNS cache, and in dnsmasq on the end-users router in additional to their ISP’s DNS cache. Each step in the chain can reinforce their own policies and even rewrite the original DNS response accordingly.


The Android platform (excluding the Chromium WebView) version 4.1 and newer store up to 16 addresses for exactly 2 seconds at a time. The oldest address is discarded when the cache is full. Android 4.0 and older stored the same number of addresses for up to 10 minutes. The TTL value is ignored. Apps can override these values and maintain their own cache.


Chromium based web browsers, even on Android and including Chrome OS, store up to 1000 addresses for exactly 60 seconds. The oldest address is discarded when the cache is full.


dnsmasq is the first implementation to support the TTL field and it doesn’t enforce a minimum TTL value by default. It can be configured to enforce a minimum up to 1 hour, however.

You may find dnsmasq in Linux desktop setups, inside edge routers, and even running on some Android devices as a standard component of the Android Open Source Project. I’ve checked six different generation and brands of Android devices, and they all have it installed but not running.


The Java runtime running with a security policy, except on Android, will cache DNS responses for the duration of the session – potentially to infinity. Java running without a security policy doesn’t cache anything by default. The default cache duration is configurable regarding of runtime policy. Java always disregard the TTL.

mDNSResponder (also known as mdnsd)

You’ll find mDNSResponder responsible for DNS caching in iOS and MacOS devices, as well as some network equipment. It’s also distributed as part of the Android Open Source Project, but it’s not running as a cache on any of my test devices. Safari/WebKit doesn’t have an internal DNS cache and rely entirely on the system-wide mDNSResponder.

Update (): Safari/WebKit has now added its own DNS cache. It holds up to 400 addresses for 1 minute. This cache is used in addition to any operating-system level caches, such as mDNSResponder.

mDNSResponder is the second implementation to support the TTL. However, it enforces a minimum TTL of 15 seconds and can store an unlimited number of actively used DNS responses. It will begin asynchronously update records if requested if there’s less than 15 % left of their TTL. This is why other research suggest that mDNSResponder’s minimum TTL is 12,5 rather than 15 seconds.

Mozilla Necko

The Mozilla Gecko Networking Library (Necko), as used in Firefox and Thunderbird, will cache up to 400 DNS responses for at least 1 minute and up to 2 minutes. If a request is processed after the first minute, it will get a cached response while Necko asynchronously updates the cached record and extends the cache for another 2 minutes.

On Windows, Necko behaves quite differently to how it behaves on other operating system. It will cache entries for a minimum of 1 minute and up to the full duration specified by the TTL.

Mozilla experimented in 2018 with doubling the cache from 400 records to 800 records but only saw less than 1 % improvement in cache hit ratio. The experiment was concluded and Mozilla decided to stick with the existing 400 limit.

The DNS cache in Firefox is isolated betwen regular and private browsing modes. However, the whole DNS cache is reset after closing all private windows. The Tor Browser (built on Firefox and Necko) does neither resolve nor cache DNS locally.


systemd-resolved is enabled by default in Ubuntu 16.04 and later as well as in derivative Linux distributions. I’d not be surprised to learn that it will be shipping as the default DNS cache in many consumer grade edge routers in the future.

It can store up to 4096 DNS responses for up to two hours. It honors the TTL field and despite online claims to the contrary, systemd-resolved doesn’t enforce a minimum TTL except on negative responses.


Internet Explorer’s Trident engine is more of a historical curiosity than a real-world concern. However, Trident is still used inside some components of Windows and in third-party browsers and other programs.

Trident stores up to 128 addresses for 30 minutes. Older cache entries expire earlier if newer entries get added ot the cache. This is the longest enforced minimum TTL and 1400 % longer than the second longest minimum TTL.

Windows DNS Client

The Windows DNS Client, interchangeably called Microsoft DNS Client or simply DNSCache, stores up to 2 Megabytes of cache data for up to 2 days. (This cache is separate to the DNS cache in Trident.)

There’s virtually no information available on recent versions of the Windows DNS Client. It also behaved inconsistently even on the same computer when testing just seconds apart. Two days is my best guess at what the maximum TTL is, though it can be longer and shorter.

Trident and Windows DNS are the only two proprietary implementations in this list and the only two of any note. The other implementations have been confirmed by both testing and source code review. However, Microsoft’s two implementations is based primarily on testing – that notably returned inconsistent results. There seems to be a demand or memory based limiter involved that behaves unpredictably.

Bonus: Public DNS resolvers

Google products, including the Google Chrome web browser and Chromecast, will use the Google Public DNS resolver service by default instead of the system-configured DNS provider (often discovered via DHCP). Because of this, I thought it would be interesting to look at a few of the global free DNS resolvers that promote themselves as either being faster or more secure than traditional DNS providers.

Service Provider Min-TTL Max-TTL
Google Public DNS 0 6 hours
OpenDNS 0 7 days
Quad9 0 12 hours

Google has documented their 6 hour maximum TTL value for DNS caching. OpenDNS claims to support “full TTL”. However, it appars to be capped at one week. This is a sensible maximum for a public recursice DNS service.

I’ve tried to determine whether these services have a transparent minimum TTL and perform asynchronous updates to their caches. This could help explain how they manage to provide faster DNS responses than other services. However, testing results have been completely inconclusive for all services. Please let me know through the feedback link below if you do manage to get a more definitive answer to this question.