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.

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.

Check DNS cache inputs

{{ error }}

Review model assumptions

{{ warning }}

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 }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

DNS cache capacity planning estimates how much recursive resolver cache memory is needed to hold the useful hot set of DNS answers while still reducing upstream lookup volume and client latency. The same resolver can look healthy by raw query rate and still run short if distinct names arrive quickly, TTL windows are long, DNSSEC answers are large, or negative responses churn through memory.

A recursive DNS cache usually stores positive resource record sets, negative answers such as NXDOMAIN or NODATA, and supporting data learned during resolution. Time to live, or TTL, controls how long a cached answer can be reused before it must be refreshed. Higher hit rates reduce recursive work, but the cache still needs enough memory to hold the entries kept alive by insert rate and TTL.

The useful estimate is not just "how many queries per second." It separates repeat queries answered from cache, misses that still reach upstream recursion or forwarders, distinct cache inserts that create memory pressure, and the reserve needed for allocator overhead, DNSSEC data, bursty churn, and measurement error.

A DNS cache model is a planning estimate, not a substitute for resolver telemetry. It is strongest when the query rate, hit rate, insert rate, TTLs, and memory samples come from the same busy period. It is weakest when traffic is dominated by one-off names, bot-driven NXDOMAIN noise, highly variable DNSSEC answers, or policy features that keep more state than the estimate represents.

Technical Details:

DNS cache size is governed by how quickly new cacheable objects arrive and how long they remain eligible for reuse. A positive answer consumes space for owner names, record data, metadata, signatures when DNSSEC is involved, and resolver bookkeeping. A negative answer also occupies cache space, but often with a smaller footprint and a separate TTL policy.

Hit rate affects upstream work and latency, while insert rate and TTL affect memory. Those quantities can move in different directions. A resolver may have a high hit rate from repeated popular names but still need a large cache if many distinct names are inserted every second and retained for long TTL windows.

Formula Core:

The model treats the cache as a working set of positive and negative entries, then applies DNSSEC, cache-structure, and reserve multipliers to turn raw answer bytes into an operating cache limit.

\begin{array}{lll} Q_{miss} & = & Q_{client} \times (1 - H) \\ Q_{upstream} & = & Q_{miss} \times (1 + P) \\ E_{pos} & = & I \times (1 - N) \times T_{pos} \\ E_{neg} & = & I \times N \times T_{neg} \\ B_{required} & = & (E_{pos} \times B + E_{neg} \times B \times 0.45) \times D \times L \times (1 + R) \end{array}

Variables used in the DNS cache capacity formulas
Symbol	Meaning	Field or result
`Qclient`	Cacheable DNS queries arriving each second	`Client query rate`
`H`	Share of client queries answered from cache	`Cache hit rate`
`P`	Extra refresh work after misses	`Prefetch refresh overhead`
`I`	Distinct cache inserts per second	`Distinct cache inserts`
`N`	Negative-answer share of inserted entries	`Negative answer share`
`Tpos`, `Tneg`	Positive and negative cache lifetimes in seconds	`Positive TTL`, `Negative TTL`
`B`, `D`, `L`, `R`	Average bytes, DNSSEC multiplier, cache-layer multiplier, and reserve rate	`Average cached footprint`, `DNSSEC overhead multiplier`, `Cache layer multiplier`, `Reserve headroom`

Latency is modeled separately from memory. Average latency is the hit-rate-weighted blend of the hit path and miss path. Aggregate latency saved is expressed as seconds saved per second of client traffic, which is useful for comparing resolver tiers with different query rates.

\begin{array}{lll} L_{avg} & = & H \times L_{hit} + (1 - H) \times L_{miss} \\ S_{aggregate} & = & \frac{Q_{client} \times H \times (L_{miss} - L_{hit})}{1000} \end{array}

DNS cache validation and interpretation boundaries
Boundary	Rule used by the model	Why it matters
Hit rate	`0` to `99.9%`	A full `100%` hit rate would remove misses entirely and is not accepted.
Memory budget	Must be greater than `0 MiB`	Budget fit and utilization require a positive denominator.
Hit and miss latency	`Hit path latency` should not exceed `Miss path latency`	A slower hit path means the cache is not reducing average latency in this model.
Multipliers	`DNSSEC overhead multiplier` and `Cache layer multiplier` must be at least `1.00`	The raw RRset footprint is treated as the minimum before signatures, metadata, indexes, and allocator overhead.
Warning threshold	Utilization above `85%` warns; above `100%` is short of budget	A cache that fits on paper can still need room for daemon memory, operating system memory, and bursts.

Everyday Use & Decision Guide:

Start with one resolver tier, view, pod, or cache population. Choose BIND recursive view, Unbound resolver, or Generic recursive cache from Resolver profile so the sizing ledger names the closest operational setting, then enter the busy-hour Client query rate for cacheable traffic that actually reaches that cache.

Cache hit rate and Distinct cache inserts deserve separate measurement. Hit rate tells you how much upstream work is avoided. Insert rate tells you how fast new entries are added to the hot set. A resolver with many repeated names can save upstream QPS with modest memory, while a resolver receiving many unique names can fill memory even when the hit rate looks acceptable.

Use measured resolver or cache statistics when available. If you only have logs, estimate distinct inserts from unique QNAME and RRtype combinations over the same peak window as QPS.
Set Positive TTL to the effective retained lifetime after resolver min or max TTL policy, not only the authoritative TTL printed for one record.
Use Average cached footprint from memory samples when possible. Include owner name, answer data, metadata, and allocator overhead if your sample already captures them.
Raise DNSSEC overhead multiplier when signed zones, RRSIG records, DNSKEY material, or authenticated denial data are common in the cache.
Use Negative answer share and Negative TTL when NXDOMAIN or NODATA traffic is a meaningful part of cache churn.
Keep Reserve headroom above zero unless the numbers come from a controlled lab and you have separate process memory outside the cache budget.

Cache Capacity Snapshot is the first readout for a single sizing pass. Resolver Sizing Ledger translates the same estimate into BIND, Unbound, or generic cache targets. TTL Memory Curve shows how a longer positive TTL changes required MiB, and Hit Rate Relief Curve shows the upstream QPS and latency payoff across hit-rate choices.

A low upstream QPS result does not prove the cache limit is safe. Check Recommended cache limit, Memory budget fit, warnings, and the sizing ledger before changing production resolver settings. If the result says the budget is short, reduce TTL, reduce insert churn, increase the cache budget, or measure the footprint again before treating the configuration as ready.

Step-by-Step Guide:

Build the sizing pass from traffic first, then tune memory and TTL after the hit, miss, and insert assumptions are credible.

Choose Resolver profile. The summary title and Resolver Sizing Ledger should switch between BIND, Unbound, and generic cache language.
Enter Client query rate and Cache hit rate. Upstream load after cache should change as the miss share changes.
Enter Distinct cache inserts, Positive TTL, and Average cached footprint. Watch Active cache entries and Recommended cache limit, because these fields carry the main memory signal.
Set Cache memory budget, Miss path latency, and Hit path latency. If hit latency is higher than miss latency, the input alert asks you to correct the latency pair before using the result.
Open Advanced when negative answers, DNSSEC material, cache overhead, reserve, or prefetch behavior materially changes the resolver. Adjust Negative answer share, Negative TTL, DNSSEC overhead multiplier, Cache layer multiplier, Reserve headroom, and Prefetch refresh overhead.
Read the summary badges, then check Cache Capacity Snapshot for Memory budget fit, Upstream load after cache, Latency payoff, Positive TTL window, and Negative cache slice.
Open Resolver Sizing Ledger for the operational target. BIND runs show max-cache-size target, max-cache-ttl runway, and max-ncache-ttl allowance; Unbound runs split the target across rrset-cache-size, msg-cache-size, and key or infrastructure allowance.
Use TTL Memory Curve, Hit Rate Relief Curve, and JSON only after the inputs describe the same resolver tier. Mixed peak windows or mixed cache populations can make the charts look precise while the sizing target is wrong.

Interpreting Results:

Recommended cache limit is the main memory answer. It includes the working cache, DNSSEC multiplier, cache-layer multiplier, and reserve headroom. Compare it with Cache memory budget and Memory budget fit, not with raw positive-answer bytes alone.

Upstream load after cache is the main resolver-load answer. It starts with miss QPS, then adds Prefetch refresh overhead. A 72% hit rate on 12,000 QPS still sends about 3,528 QPS upstream when 5% prefetch overhead is included.

Active cache entries is driven by distinct inserts and TTL windows. It is not the same as total names seen in logs.
Latency payoff depends on both hit rate and the gap between hit and miss latency. It is a planning average, not a tail-latency percentile.
Negative cache slice should be checked separately when NXDOMAIN or NODATA traffic is high, because it can consume memory without improving positive-answer reuse.
Required cache memory is close to the stated budget means the cache may fit, but extra daemon and operating system memory still need room outside the modeled cache limit.

Treat the estimate as a capacity planning checkpoint. Before applying a new limit, compare the result with resolver statistics after a warm period, process resident memory, cache hit and miss counters, and upstream resolver or forwarder capacity.

Worked Examples:

Busy BIND recursive view with measured hit rate:

The default BIND-style run uses 12,000 QPS, a 72% hit rate, 180 distinct cache inserts per second, a 1,800 sec positive TTL, 550 bytes per cached footprint, a 512 MiB budget, 38 ms miss latency, and 2 ms hit latency. The result shows a Recommended cache limit near 336.25 MiB, about 175.75 MiB spare against the budget, roughly 311,040 active entries, and about 3,528 QPS upstream. That fits the budget with reserve, but the upstream tier still needs to carry several thousand QPS.

Small Unbound resolver with ample headroom:

A campus resolver at 4,500 QPS, 88% hit rate, 60 distinct inserts per second, 900 sec positive TTL, 420 bytes per footprint, and a 256 MiB budget lands near 34.25 MiB for Recommended cache limit. The Resolver Sizing Ledger would split that target into an RRset share, a message-cache share, and a key or infrastructure allowance. The result suggests memory is not the limiting factor, so hit-rate quality and freshness policy deserve more attention than raising the cache budget.

DNSSEC-heavy hot set that exceeds budget:

A larger signed-zone workload at 30,000 QPS, 92% hit rate, 900 distinct inserts per second, 3,600 sec positive TTL, 900 bytes per footprint, a 1.6x DNSSEC multiplier, a 1.6x cache-layer multiplier, and 35% reserve needs about 8.19 GiB. Against a 1 GiB budget, Memory budget fit shows a shortfall. The next check is not the hit rate; it is whether TTL, insert churn, footprint, or available memory is realistic for that resolver.

Input pair that should be corrected:

If Hit path latency is entered as 18 ms while Miss path latency is 12 ms, the alert says the hit path should not exceed the miss path. Fix that before reading Latency payoff, because the model cannot claim a cache-latency benefit when cached responses are slower than recursive misses.

FAQ:

Does a higher DNS cache hit rate always mean I need more memory?

No. Hit rate reduces misses, but memory is driven by distinct cache inserts, TTL windows, average footprint, DNSSEC overhead, cache-layer overhead, and reserve. A high hit rate with a stable hot set can fit easily, while a lower hit rate with many unique names can still create memory pressure.

What should I use for distinct cache inserts?

Use unique cacheable RRsets or answer objects inserted per second during the same peak window as Client query rate. If logs are your source, sample unique QNAME and RRtype churn, then adjust if one client miss creates more than one cached RRset.

Why does negative answer share matter?

Negative answers such as NXDOMAIN and NODATA can be cached with their own TTL. The model counts them as a separate memory slice using Negative answer share and Negative TTL, so heavy bad-name churn does not hide inside positive-answer capacity.

Why does the tool warn when hit latency is higher than miss latency?

The latency payoff assumes cached answers are faster than recursive misses or upstream forwarder lookups. If Hit path latency is greater than Miss path latency, correct the measurement pair before using the blended latency or saved-latency result.

Does the calculation connect to my resolver?

No. The calculation runs from the values you enter and does not query BIND, Unbound, or a live DNS server. Use resolver statistics and process memory after a warm period to confirm the planning estimate.

Glossary:

Recursive resolver: A DNS server that answers client queries by using cache or by resolving the name through authoritative DNS.
RRset: A set of DNS resource records with the same name, class, and type, often treated as one cached answer unit.
TTL: Time to live, the number of seconds a DNS answer can remain in cache before it expires.
NXDOMAIN: A negative DNS answer indicating that the queried name does not exist.
NODATA: A negative DNS answer indicating that the name exists but has no record of the requested type.
DNSSEC: DNS Security Extensions, which add signed records and validation data that can increase cached answer size.

References:

RFC 1034: Domain Names - Concepts and Facilities, RFC Editor, November 1987.
RFC 2308: Negative Caching of DNS Queries, RFC Editor, March 1998.
RFC 4034: Resource Records for the DNS Security Extensions, RFC Editor, March 2005.
BIND 9 Configuration Reference, Internet Systems Consortium.
Unbound Performance Tuning, NLnet Labs.