What Is DNS Cache? How TTL and Caching Speed Up DNS Resolution

DNS cache is a temporary store of DNS records held by a DNS server, resolver, or client. Instead of repeating the full DNS resolution process every time a domain is requested, the cache returns a stored answer immediately, cutting lookup time and reducing load on upstream name servers.

Without caching, every request for www.google.com would require a full recursion chain:

• Stub resolver
• Recursive resolver
• Root server
• TLD server
• Authoritative name server

With caching, most of that chain gets skipped entirely.

How DNS TTL Controls Caching

DNS implements a time-to-live (TTL) on every record. TTL specifies how many seconds a DNS server or client can cache that record. The cache counts the TTL down every second; when it hits zero, the record is removed, and the next query triggers a fresh resolution.

How DNS Caching Works at Each Layer

DNS caching happens at three layers in order:

1. Stub resolver (OS level)

When you request www.google.com, the OS stub resolver checks its local cache first. If the record is there and the TTL hasn’t expired, it returns the answer immediately without sending any query.

2. Recursive resolver (ISP/DNS server level)

If the stub resolver has no cached record, it queries the recursive resolver. The recursive resolver checks its own cache; if it has the A record, it returns it directly. If it has NS records but not A records, it skips the root and TLD servers and queries the authoritative name server directly. If it has nothing, it starts the full recursion from root servers down.

3. Root and TLD servers

Root server queries are rare in practice. TLD server records (like .com) have very high TTLs and are almost always cached. A full recursion from root only happens after a complete cache purge.

How TTL Adjusts as It Passes Through Resolvers

To prevent the propagation of expired DNS records, the DNS servers will pass the adjusted TTL to a query and not the original TTL value of the record.

For example, let’s assume that the TTL for an A record of www.google.com is four hours and it is stored in cache by the “Recursive Resolver” at 8 a.m. When a new user, on the same resolver, queries for the same domain at 9 a.m., the resolver will send an A record with a TTL of three hours.

How Browsers and Applications Cache DNS

Applications add a third caching layer on top of the OS and DNS server, but unlike DNS servers, they don’t follow the TTL specification.

Applications rely on an OS function called “getaddrinfo()” to resolve a domain (all OS have the same function name). This function returns the list of IP addresses for the domain, but it does not return DNS records; hence, there is no TTL information that the application can use.

As a result, different applications cache the data for a specific period of time. IE10+ stores up to 256 domains for 30 minutes, which sounds like a lot until you consider that many pages reference more than 50 domains through third-party tags and retargeting alone.

Chrome, on the other hand, will cache the DNS information for one minute and stores up to 1,000 records. You can view and clear the DNS cache of Chrome by visiting chrome://net-internals/#dns.

What Is the NS Cache Trap and Why Does It Matter?

One major trap that people fall into with DNS cache is the authoritative name server records.

The authoritative name servers are specified in the query response as NS records. NS records have a TTL, but do not provide the IP addresses of the name servers. The IP information is in the additional records of the response and is A or AAAA records.

So, a Recursive Resolver relies on both NS and A records to reach the name server. Ideally, the TTL on both types of records should be the same, but every once in a while someone will misconfigure their DNS zones, and they pass in DNS query responses for the domain’s new A or AAAA records for the name servers with lower or higher TTL than what was specified in the TLDs. These new records override the old records, causing a discrepancy.

There are three possible cache states for a Recursive Resolver trying to reach a name server:

1. Both NS and A/AAAA records cached: queries the name server IP directly, fastest path
2. Only NS records cached, no A/AAAA: must resolve ns1.google.com first to get the IP, adding latency
3. Only A/AAAA records cached, no NS: forced to do a full DNS lookup for www.google.com

Setting TTL: A Balancing Act

Neither a longer nor a shorter TTL is universally better. The right choice depends on how often the record changes and how quickly you need updates to propagate. Stable records benefit from longer TTLs; records tied to infrastructure that could fail or change need shorter ones.

DNS lacks authentication by default, so if an attacker ever manages to slip a false record into a resolver’s cache, a longer TTL means that bad record stays trusted for longer before it expires and gets re-verified.

A shorter TTL narrows that exposure window at the cost of more frequent lookups. This is one more reason the “just set it high for performance” instinct needs a second thought for anything security-sensitive.

Use DNS Caching to Your Advantage

Set your TTLs deliberately. For stable records like MX or root A records, use longer TTLs (hours or days) to maximize cache hits and reduce name server load.

For records tied to infrastructure you might need to change quickly such as load balancers, failover IPs, and CDN endpoints, use shorter TTLs so changes propagate fast when you need them to.

If you want to see DNS caching in action, open Chrome and visit chrome://net-internals/#dns to view and flush your local DNS cache. For deeper investigation, tools like dig with the +ttl flag show you exactly what TTL a record is being served with at any point in the resolution chain.

Where Monitoring Fits

Misconfigured TTLs and cache inconsistencies are often the first visible symptom of something worse.

A resolver serving a record it shouldn’t, or an unexpected drop in cache hit rate, can be an early signal of cache poisoning rather than a simple misconfiguration.

Monitoring DNS response codes, resolution latency, and record changes across multiple resolvers helps you catch that difference before it becomes an outage or a redirect users don’t notice until it’s too late.

FAQs