DNS priming

Priming is the process by which a recursive resolver learns the current set of root servers from the root servers themselves, refreshing the information originally provided by root hints.

Resolver Behavior 6 min read Reviewed 19 Sep 2026

The big picture

Root hints bootstrap the resolver. Priming replaces those hints with authoritative data from the root itself.

Root hintsStatic bootstrap
addresses

Priming query. IN NS
to a root server

Priming responseAuthoritative
root NS set

OperationalResolver uses
fresh root data

Introduction

Before a recursive resolver can answer any DNS query, it needs to know the current root server addresses. Root hints provide a static starting point, but that file can become outdated. Priming is the mechanism that bridges the gap between the static hints and the live root server system.

During priming, the resolver asks a root server for the authoritative list of root name servers. The root server responds with the current NS records and their addresses, which the resolver then caches and uses for all subsequent root interactions.

Why priming exists

Root hints are a static file. They represent a snapshot of root server addresses at the time the file was created or last updated. Over time, root server addresses can change:

A root server operator may renumber their IPv4 or IPv6 service address.
New address families may be added (as happened when IPv6 addresses were introduced for root servers).
The hints file shipped with resolver software may be months or years old by the time a resolver is deployed.

Priming solves this by going directly to the source. Rather than relying solely on the static file, the resolver asks the root servers themselves for the current, authoritative answer. As long as at least one address in the hints file is still reachable, priming succeeds and the resolver gets up-to-date data.

How priming works

The priming process is straightforward:

Step 1 — The resolver selects a root server address from its hints file (or from a previously cached root NS set, if available).
Step 2 — The resolver sends a query for . IN NS — an NS query for the root zone — to the selected address.
Step 3 — The root server responds with the full set of root NS records in the answer section, plus their corresponding A and AAAA glue records in the additional section.
Step 4 — The resolver caches the NS records and their associated address records, replacing the static hints data with the authoritative primed data.

If the selected root server is unreachable, the resolver tries other addresses from the hints file until one responds. If none respond, the resolver cannot prime and cannot resolve any queries — a condition that typically indicates a network problem rather than a hints file issue.

The priming response is authoritative (the AA flag is set), because the root server is answering about its own zone. This distinguishes it from a referral, where the root server directs the resolver to a different zone.

BCP 209 / RFC 9609

The current standard for priming behavior is RFC 9609, published as BCP 209 (Best Current Practice). It obsoleted the earlier RFC 8109 and provides updated guidance for resolver implementers.

Key points from BCP 209:

Priming is required — A resolver MUST prime when it starts with no cached root NS data, and SHOULD re-prime when the cached root NS records expire.
Query type — The priming query MUST be . IN NS. It should not be a query for a specific domain name.
Response handling — The resolver should use both the NS records from the answer section and the address records from the additional section. If the additional section is incomplete, the resolver should issue follow-up queries for missing addresses.
DNSSEC — If the resolver performs DNSSEC validation, the priming response should be validated. The root zone trust anchor is the starting point for this validation chain.
Fallback — If priming fails, the resolver should retry with different root server addresses from the hints. It should not serve stale cached root NS data beyond their TTL without attempting to re-prime.

Priming frequency and behavior

Priming is not a one-time event. It recurs throughout the resolver's lifetime:

At startup — Always. A resolver with an empty cache must prime before it can resolve any queries.
On cache expiry — The root NS records have a TTL (typically 518,400 seconds, or 6 days). When this TTL expires, the resolver should re-prime to get fresh data.
After failure — If the resolver encounters persistent errors reaching root servers, it may re-prime to refresh its address set.

In practice, a healthy resolver primes roughly once every 6 days. The actual frequency depends on the resolver's uptime and cache management policy. Some resolvers pre-emptively re-prime before the TTL expires to avoid a gap in coverage.

The priming query itself is lightweight — a single DNS query and response. The overhead is negligible compared to the resolver's total query volume. Root server operators expect and plan for priming traffic from resolvers worldwide.