I use Chromium and have problems with the DNS not being cached for the time that I would expect. Take the example.com domain. According to the DNS settings, this domain should be cached for another 26151 seconds:

$ dig example.com

example.com.        26151   IN  A

However, when I open example.com in Chromium and I open chrome://net-internals/#dns then the IP is forgotten within a minute!

enter image description here

Why does Chromium not adhere to the TTL of the DNS setting of the domain? How can I force it to cache the DNS data until they expire?

  • 5
    "... this domain should be cached for another 26151 seconds..." - No, the domain may be cached for 26151 seconds. DNS caching is not mandatory.
    – marcelm
    Commented May 7, 2017 at 22:28

1 Answer 1


Chromium/Chrome does not cache DNS requests more than a minute indeed.

Interestingly enough, from bugs-chromium - Issue 164026 - DNS TTL not honored from Apr 21 2011

The only DNS cache in the system is in chrome and it does not honor TTL. We need to either fix chrome and/or add an intermediate cache that does handle TTL correctly.

Answer in the Dec 4 2012 ticket:

The HostCache currently assumes TTL=60s for all positive results. With asynchronous DNS resolver, we plan to use TTL=max(60s, server_reported_ttl), i.e., at least 60s. The rationale is to improve the cache performance. (When a CDN NS provides TTL=10-20s, and it takes 30s+ to fetch all subresources, we often have to re-query for the same hostname during one page load.)

Ticket closed on Oct 10 2013 as:

Chrome on CrOS uses asynchronous DNS resolver which honors TTL = max(60s, > server_reported_ttl)

I'm closing this as WontFix (obsolete/works as intended).

This has been a known issue for years; their internal DNS resolver ignores the TTL of DNS records, and only caches DNS requests for 1 minute.

Users have been requesting for years, a feature to change that default behavior, and Google never created one.

In the past, you could disable the internal DNS resolver in chrome://flags, nowadays that functionally is not exposed anymore.

So summing it up, it is a feature, e.g. it does that by design.

(I initially wrote it could never be changed, which is not obviously not true. A really determined person can either recompile Chromium or hack Chrome binaries. ).

So, as an adenda: there is plenty of documented evidence Google engineers do not intend to respect the default TTL in received DNS answers in Chrome/ium.

From Negative Caching of DNS Queries (DNS NCACHE)

As with caching positive responses it is sensible for a resolver to limit for how long it will cache a negative response...

While it is implied a resolver may/should impose a maximum limit on caching DNS answer, the 1-min limit on Google Chrome may be too low.

P.S. I actually discovered the answer for something that has been bugging me for years while retrieving Chrome stats to answer this question: Chrome: DNS requests with random DNS names: malware?

PPS From the code bellow, it is apparent negative answers are not cached (TTL=0).

From https://chromium.googlesource.com/chromium/src/net/dns/host_resolver_impl.cc

  99 // Default TTL for successful resolutions with ProcTask.
 100 const unsigned kCacheEntryTTLSeconds = 60;
 102 // Default TTL for unsuccessful resolutions with ProcTask.
 103 const unsigned kNegativeCacheEntryTTLSeconds = 0;
 105 // Minimum TTL for successful resolutions with DnsTask.
 106 const unsigned kMinimumTTLSeconds = kCacheEntryTTLSeconds;
1518   // Called by ProcTask when it completes.
1519   void OnProcTaskComplete(base::TimeTicks start_time,
1520                           int net_error,
1521                           const AddressList& addr_list) {
1522     DCHECK(is_proc_running());
1524     if (dns_task_error_ != OK) {
1525       base::TimeDelta duration = base::TimeTicks::Now() - start_time;
1526       if (net_error == OK) {
1527         UMA_HISTOGRAM_LONG_TIMES_100("AsyncDNS.FallbackSuccess", duration);
1528         if ((dns_task_error_ == ERR_NAME_NOT_RESOLVED) &&
1529             ResemblesNetBIOSName(key_.hostname)) {
1530           UmaAsyncDnsResolveStatus(RESOLVE_STATUS_SUSPECT_NETBIOS);
1531         } else {
1532           UmaAsyncDnsResolveStatus(RESOLVE_STATUS_PROC_SUCCESS);
1533         }
1534         base::UmaHistogramSparse("Net.DNS.DnsTask.Errors",
1535                                  std::abs(dns_task_error_));
1536         resolver_->OnDnsTaskResolve(dns_task_error_);
1537       } else {
1538         UMA_HISTOGRAM_LONG_TIMES_100("AsyncDNS.FallbackFail", duration);
1539         UmaAsyncDnsResolveStatus(RESOLVE_STATUS_FAIL);
1540       }
1541     }
1543     if (ContainsIcannNameCollisionIp(addr_list))
1544       net_error = ERR_ICANN_NAME_COLLISION;
1546     base::TimeDelta ttl =
                                              # always  0 seconds
1547         base::TimeDelta::FromSeconds(kNegativeCacheEntryTTLSeconds);
1548     if (net_error == OK)
                                              # always 60 seconds 
1549       ttl = base::TimeDelta::FromSeconds(kCacheEntryTTLSeconds);  
1551     // Source unknown because the system resolver could have gotten it from a
1552     // hosts file, its own cache, a DNS lookup or somewhere else.
1553     // Don't store the |ttl| in cache since it's not obtained from the server.
1554     CompleteRequests(
1555         MakeCacheEntry(net_error, addr_list, HostCache::Entry::SOURCE_UNKNOWN),
1556         ttl);
1557   }
  • 4
    Interestingly for me, chrome is caching DNS lookups based on the TTL for some domains, e.g. this domain dougblack.io so maybe the full rules are a bit more complicated. but 99 out of a hundred domains behave as you have described. Commented May 7, 2017 at 9:57
  • 2
    Chrome makes random-looking DNS requests to determine whether it's on a network that hijacks all DNS requests (like some paid wireless access points). Also, I imagine the "timeout" value you're looking at in the configuration is a 1-second timeout for DNS servers to respond, not a 1-minute TTL.
    – user130738
    Commented May 7, 2017 at 16:01
  • 5
    It's sad that chromium does a dns cache at all. Whenever I do quick changes on my NS and flush the dns cache I always have to keep in mind chrome does it by its own as well.
    – Ole K
    Commented May 8, 2017 at 5:38
  • 1
    @OleK: Yeah, I had no idea Chrome even has its own DNS cache. Thanks to this page for pointing this out...
    – user541686
    Commented May 8, 2017 at 7:13
  • 2
    @OleK - I kinda agree, but at the same time I can see where a short... say, 60 seconds or so :) , cache is a good idea (to save a little network traffic) and still allows things like round robin dns, etc. to work
    – ivanivan
    Commented May 11, 2017 at 2:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .