DNS Cache Capacity Calculator

Resolver profile:

Choose the resolver family you are planning so the output names the right cache controls.

Client query rate:

Use peak or busy-hour QPS after any filtering that bypasses this cache.

QPS

Cache hit rate:

Use measured hit rate when available; otherwise model the target hit rate for this cache tier.

Distinct cache inserts:

Estimate from cache fill logs, miss logs, or a sampled unique QNAME/RRtype rate.

Positive TTL:

Use the observed average TTL or the resolver max TTL you plan to enforce.

sec

Average cached footprint:

Include owner name, RR data, metadata, and allocator overhead if you have measured samples.

bytes

Cache memory budget:

Model the per-resolver, per-view, or per-pod cache limit you intend to enforce.

MiB

Miss path latency:

Use recursive or forwarder latency for cache misses.

Hit path latency:

Use measured resolver response time for cache hits.

Check DNS cache inputs

{{ error }}

Review model assumptions

{{ warning }}

Negative answer share: {{ negative_response_pct }}%

Negative TTL:

Used only for the negative-cache memory slice.

sec

DNSSEC overhead multiplier:

Set 1.00 for unsigned zones; raise it when DNSSEC material dominates the cache.

Cache layer multiplier:

Keep above 1.00 so the raw RRset footprint becomes an operational memory target.

Reserve headroom: {{ reserve_pct }}%

Applied after cache and DNSSEC multipliers to create the recommended limit.

Prefetch refresh overhead: {{ prefetch_refresh_pct }}%

Adds to upstream QPS after ordinary cache misses.

Metric	Value	Readout	Copy
{{ row.metric }}	{{ row.value }}	{{ row.readout }}

Sizing item	Target	Decision	Next step	Copy
{{ row.item }}	{{ row.target }}	{{ row.decision }}	{{ row.nextStep }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Recursive DNS resolvers sit between clients and authoritative name servers, so their caches decide how often the same questions are answered locally instead of being asked again across the Internet. A busy resolver can handle thousands of queries per second, but the memory question is not simply how many queries arrive. The cache grows from distinct answers that are inserted, how long those answers remain valid, and how much space each resource record set, message, signature, and metadata entry consumes.

Time to live, usually shortened to TTL, is the main clock on a DNS cache entry. An answer with a longer TTL can be reused for longer, which improves repeat-query performance and reduces upstream load. The same longer window also means more unique answers remain resident at once. That tradeoff is why cache capacity planning belongs next to TTL policy, recursive-worker sizing, and memory limits rather than being treated as a one-time daemon setting.

DNS cache capacity diagram with client queries, cache hits, misses, TTL window, and memory budget.

Two DNS traffic patterns often look similar in a headline QPS graph but size very differently. A university campus may send many repeated queries for the same learning platforms, mail servers, and software-update hosts; a cache absorbs much of that repeat traffic after the first miss. A resolver serving malware analysis, public Wi-Fi, or typo-heavy search traffic may see far more unique names, so the cache must hold many short-lived entries even when the hit rate is lower.

Negative answers need separate attention. Responses such as NXDOMAIN and NODATA are cacheable too, and DNS standards define how their lifetime is derived from the negative-response data. They are usually smaller than positive answers, but a high share of nonexistent names can still crowd the cache and hide a problem in client behavior, split-horizon routing, or abusive traffic.

A capacity estimate is strongest when query rate, hit rate, distinct insert rate, TTL, answer footprint, and memory budget all come from the same busy period. It is only a planning model when those numbers are borrowed from different days, collected before a policy change, or averaged across traffic that has very different name churn.

How to Use This Tool:

Model one cache boundary at a time, such as a BIND recursive view, an Unbound node, a PowerDNS Recursor tier, a Knot Resolver instance, a dnsmasq forwarder, or a generic recursive cache.

Select Resolver profile. The core math stays the same, while Resolver Sizing Ledger changes the recommended target names and follow-up checks for the chosen resolver family.
Enter Client query rate, Cache hit rate, and Distinct cache inserts from the same peak or busy-hour sample. The summary should show upstream QPS and active entries once these values are valid.
If Distinct cache inserts is higher than miss QPS, check whether the sample counts RRsets per answer rather than client misses.
Set Positive TTL, Average cached footprint, and Cache memory budget. These fields drive Recommended cache limit and Memory budget fit.
Add Miss path latency and Hit path latency when you want the Latency payoff readout. Use hit and miss measurements from the same resolver path so the weighted average is meaningful.
Open Advanced when negative answers, DNSSEC, resolver overhead, reserve headroom, or prefetch refresh materially affect your cache. Keep DNSSEC overhead multiplier and Cache layer multiplier at least 1.00.
Use Cache Capacity Snapshot for the short answer, then compare TTL Memory Curve and Hit Rate Relief Curve when you are choosing between more memory, shorter TTLs, higher hit-rate goals, or more resolver capacity.
If Check DNS cache inputs appears, fix the listed field before reading the result. Hit rate must be from 0% to below 100%, memory budget and average footprint must be positive, and hit latency should not exceed miss latency.
Do not use Recommended cache limit until the input warning clears; the curves and ledger are only meaningful after the model accepts the fields.

Interpreting Results:

Recommended cache limit is the main sizing number. It starts with the modeled working cache, applies DNSSEC and resolver-overhead multipliers, then adds reserve headroom. Memory budget fit says whether that target is comfortably inside the entered budget, close to the budget, or above it.

Do not treat a strong hit rate as proof that the cache is large enough. Hit rate mostly reduces upstream work and latency. Distinct inserts, TTL, average answer size, and overhead decide how many bytes must stay resident. When the result is near the memory budget, compare it with live resolver counters after the cache has warmed under similar traffic.

DNS cache capacity result interpretation
Result cue	What it means	What to verify
`ample headroom`	The required cache is at or below `70%` of the entered budget.	Confirm process memory still leaves room for resolver threads, sockets, and the OS.
`fits budget`	The required cache is above `70%` but no more than `100%` of budget.	Watch cache counters and resident memory during the next warm peak before raising TTL.
`budget short`	The required cache exceeds the memory budget after reserve.	Raise the limit, reduce TTL, split load, lower churn, or revisit overhead assumptions.
`Upstream load after cache`	Miss QPS plus prefetch refresh overhead.	Size forwarders, recursive workers, and upstream links for this post-cache rate.
`Negative cache slice`	Modeled memory consumed by NXDOMAIN or NODATA-style entries.	Investigate typo storms or invalid-name traffic when this slice is unexpectedly large.

Technical Details:

DNS caching combines two separate capacity problems. The request path is governed by hit rate: client QPS is split into local answers and misses that still need recursive or forwarded lookup work. The memory path is governed by insert churn: unique cacheable answers remain in memory for their effective TTL, so the hot set grows when insert rate or TTL grows.

Positive and negative answers are counted separately because they can have different TTLs and different average sizes. The model treats negative answers as 45% of the positive average cached footprint before DNSSEC, cache-structure, and reserve multipliers are applied. DNSSEC-heavy traffic can raise the average footprint because signatures, validation material, and larger answer sets occupy additional memory.

Formula Core:

The core calculation estimates cache entries first, converts them to bytes, then applies overhead and reserve headroom.

\begin{array}{lll} Q_{miss} & = & Q_{client} \times (1 - H) \\ Q_{upstream} & = & Q_{miss} + (Q_{miss} \times P) \\ E_{positive} & = & I \times (1 - N) \times T_{positive} \\ E_{negative} & = & I \times N \times T_{negative} \\ B_{required} & = & [(E_{positive} \times S) + (E_{negative} \times 0.45 \times S)] \times M_{dnssec} \times M_{cache} \times (1 + R) \end{array}

DNS cache capacity formula symbols
Symbol	Tool field or output	Unit
`Qclient`	`Client query rate`	queries per second
`H`	`Cache hit rate`	fraction from `0` to `0.999`
`P`	`Prefetch refresh overhead`	fraction added to miss QPS
`I`	`Distinct cache inserts`	entries per second
`N`	`Negative answer share`	fraction of inserts
`S`	`Average cached footprint`	bytes per positive entry
`R`	`Reserve headroom`	fraction added after overhead

With the default sample values, 12,000 QPS at a 72% hit rate leaves 3,360 QPS misses. A 5% prefetch refresh overhead adds 168 QPS, so Upstream load after cache is 3,528 QPS. On the memory path, 180 inserts per second with an 8% negative share and a 1,800 second positive TTL creates about 298,080 positive entries plus 12,960 negative entries. After the configured average footprint, overhead multipliers, and 25% reserve, the recommended cache limit is about 336 MiB.

Resolver Profile Map:

DNS resolver profile sizing targets
Profile	Sizing target shown in the ledger	Operational check
`BIND recursive view`	`max-cache-size`, positive TTL runway, and negative TTL allowance.	Apply per view when views do not share a cache.
`Unbound resolver`	`rrset-cache-size`, `msg-cache-size`, and key or infrastructure cache allowance.	Compare RRset, message, and key cache counters after warm-up.
`PowerDNS Recursor`	Packet cache, record cache, and negative cache allowance.	Check cache counters before raising TTL or shard count.
`Knot Resolver`	`cache.size`, positive TTL, and negative TTL planning values.	Watch cache garbage collection and memory pressure under a warm workload.
`dnsmasq forwarder cache`	Entry-count target plus an estimated memory guard.	Validate resident memory with DHCP, leases, and hosts-file data included.

Validation and Warning Rules:

DNS cache capacity validation and warning rules
Condition	Boundary	Reason
Input blocked	`Client query rate` must be greater than `0`; footprint and budget must be positive.	Zero or negative values cannot produce a useful capacity target.
Input blocked	`Cache hit rate` must be `>= 0%` and `< 100%`.	The miss path must remain finite for upstream and prefetch modeling.
Input blocked	`Hit path latency` should not exceed `Miss path latency`.	A slower hit path usually means the samples came from different paths or labels.
Warning	Required memory above `85%` of budget, or above `100%` of budget.	The cache may fit on paper while leaving too little room for daemon and OS memory.
Warning	Positive TTL above `86,400` seconds or negative share above `40%`.	Long TTLs and high negative-answer churn can hide freshness or traffic-quality issues.

Accuracy Notes:

The calculation is deterministic, but the inputs are estimates. DNS caches are affected by resolver eviction policy, stale-answer behavior, minimum and maximum TTL settings, DNSSEC validation behavior, allocator overhead, and traffic skew. Treat the result as a planning target, then verify it against resolver telemetry and process memory under a warmed cache.

Use RRset or answer-footprint samples from the same resolver family when possible.
Keep cache hit rate and distinct insert rate from the same traffic window.
The calculator does not run live DNS lookups; it models the values you provide.

Advanced Tips:

Sample Client query rate, Cache hit rate, and Distinct cache inserts from the same busy period. Mixing a weekday hit rate with a weekend insert rate can hide cache churn.
Use TTL Memory Curve before raising positive TTLs. More retention can reduce misses while pushing Recommended cache limit beyond the memory budget.
Raise Reserve headroom when average footprint is estimated from a small sample, DNSSEC-signed answers dominate, or allocator overhead is not measured.
Treat a high Negative answer share as a traffic-quality clue. Shortening Negative TTL may be better than letting nonexistent-name churn occupy cache space.
Use the resolver-specific rows as configuration targets, then compare them with warm-cache counters and resident memory before changing production limits.

Worked Examples:

Use these cases to connect the sizing number to traffic samples, TTL changes, and validation recovery.

Warm recursive tier

A medium recursive tier at 12,000 QPS, 72% hit rate, 180 distinct inserts per second, 1,800 second positive TTL, and 512 MiB budget produces a Recommended cache limit of about 336 MiB. Memory budget fit shows spare space, while Upstream load after cache is about 3,528 QPS. That result supports the current memory budget if the measured insert rate and footprint are credible.

TTL increase pressure

A TTL experiment with the same traffic but a 3,600 second positive TTL pushes TTL Memory Curve upward because twice as many positive inserts remain live. The recommended target rises to roughly 666 MiB, so Memory budget fit becomes a shortfall against a 512 MiB budget. Shortening TTL, adding resolver memory, or splitting load would be safer than relying on the current limit.

Latency sample mismatch

A troubleshooting pass starts with an impossible latency pair: Hit path latency at 45 ms and Miss path latency at 25 ms. The page blocks the result with Hit path latency should not exceed miss path latency. Recheck the measurement labels, then enter hit and miss samples from the same resolver tier before using Latency payoff.

FAQ:

Why does TTL change memory so much?

TTL controls how long inserted answers stay eligible for reuse. At the same distinct insert rate and footprint, doubling Positive TTL roughly doubles the positive-entry working set before overhead and reserve are added.

Why can hit rate improve while cache memory still grows?

Hit rate measures repeat use, while memory is driven by distinct inserts, TTL, answer size, DNSSEC overhead, and reserve headroom. Hit Rate Relief Curve can improve at the same time that TTL Memory Curve shows a larger cache target.

What should I enter for average cached footprint?

Use measured samples when available. Include owner name, RR data, cached message or RRset metadata, signatures, and allocator overhead if your sample method captures them.

What does a high negative-answer share mean?

A high Negative answer share means NXDOMAIN or NODATA responses make up a large part of new cache entries. Review typo traffic, malware noise, split-horizon changes, and negative TTL before increasing cache size alone.

Does the calculator query my DNS resolvers?

No. It calculates from the values entered in the form and does not perform live resolver lookups. Use your resolver logs, statistics, or monitoring system to collect QPS, hit rate, inserts, footprint, and latency inputs.

Glossary:

TTL: Time to live, the number of seconds a DNS answer may be cached before it expires.
RRset: A set of resource records with the same owner name, class, and type, such as the A records for one host name.
Cache hit rate: The share of client DNS queries answered from cache instead of going to the recursive or forwarded miss path.
Distinct cache inserts: The estimated number of unique cacheable answers or RRsets added per second.
Negative answer: A response such as NXDOMAIN or NODATA that says the requested name or record type does not exist.
Reserve headroom: Extra memory added above the calculated working cache for bursts, allocator spread, and measurement error.

References:

Domain Names - Implementation and Specification, RFC Editor, November 1987.
Negative Caching of DNS Queries, RFC Editor, March 1998.
BIND 9 Configuration Reference, Internet Systems Consortium.
unbound.conf(5), NLnet Labs.
PowerDNS Recursor Settings, PowerDNS.
Knot Resolver Cache, CZ.NIC.
dnsmasq man page, dnsmasq project.