DNS Cache Size Calculator
Estimate DNS resolver cache entry count and memory footprint from query rate and average TTL.
Inputs
Estimated Steady-State Cache Entries
12,000
Estimated Cache Memory (KB)
2,343.75
Estimated Cache Memory (MB)
2.2888
Step by step
Values used
Unique DNS Queries per Second = 40; Average Record TTL (seconds) = 300; Memory per Cache Entry (bytes) = 200
Steady-state cache entries
entries = queries_per_sec × avg_TTL
Estimated Steady-State Cache Entries
= 12,000
Estimated Cache Memory (KB)
= 2,343.75
Estimated Cache Memory (MB)
= 2.2888
How it works
A DNS resolver cache (systemd-resolved, nscd, dnsmasq, or an application-level cache) reaches a steady-state entry count determined by how many unique queries arrive per second multiplied by how long each answer stays valid — a query rate of 40/sec with a 300-second average TTL settles around 12,000 cached entries, since older entries expire at roughly the same rate new unique queries arrive. Each cached record consumes a modest but nonzero amount of memory for the name, record type, TTL countdown, and answer data, which this calculator totals for basic capacity planning.
Formula
Steady-state cache entries
entries = queries_per_sec × avg_TTL
- q
- unique queries per second
- TTL_{avg}
- average record TTL in seconds
Frequently Asked Questions
How do I check systemd-resolved's current DNS cache statistics?
`resolvectl statistics` shows cache hits, misses, and current cache size for systemd-resolved; `sudo systemd-resolve --statistics` is the equivalent on older systemd versions.
Why does average TTL matter more than raw query volume for cache sizing?
A high query rate with very short TTLs (e.g. some cloud load balancer DNS records use 5-60 second TTLs) can still result in a small steady-state cache, since entries expire almost as fast as they're added — it's the product of rate and duration, not rate alone, that determines how many entries coexist at once.
Does a larger DNS cache always reduce query latency?
Only up to the point where the cache actually holds the records being requested — for workloads querying a huge number of distinct, rarely-repeated names (low cache hit rate), increasing cache size has diminishing returns, and the bottleneck is upstream resolution latency rather than cache capacity.