Running a local root

Introduction

Every time a recursive resolver encounters a query it cannot answer from cache, it starts at the root of the DNS hierarchy. For most resolvers, this means sending a query over the Internet to one of the 13 root server identities.

A local root eliminates that network round trip by maintaining a current copy of the root zone data directly on the resolver. The resolver answers root-level queries from its local copy, only reaching out over the network to keep the zone data fresh via periodic zone transfers.

This approach is formalized in RFC 8806 (which obsoletes the earlier RFC 7706). It does not change the global root system — it is purely a local optimization that any resolver operator can adopt.

Why run a local root

There are three primary motivations for running a local root:

• Latency. Root queries are answered from local data with no network round trip. This is especially valuable for resolvers far from the nearest anycast root server instance, or in environments where every millisecond matters.
• Privacy. Root queries never leave the local network. Without a local root, an observer at the network level can see which TLDs the resolver's users are querying. With a local root, that information stays on the resolver.
• Resilience. If network connectivity to the root servers is temporarily lost, the resolver can continue answering root queries from its local copy for as long as the zone data remains valid (governed by the SOA expire timer).

These benefits come with modest operational overhead: the resolver must be configured to fetch and maintain a current copy of the root zone.

How it works

The mechanism is straightforward: the resolver acts as a secondary (slave) for the root zone, obtaining zone data via standard DNS zone transfer protocols.

• AXFR (full zone transfer) is used for the initial download of the complete root zone.
• IXFR (incremental zone transfer) is used for subsequent updates, transferring only the records that changed since the last version.
• The resolver checks the root zone's SOA record periodically (based on the SOA refresh interval) to detect when a new version is available.
• When the root zone is updated (typically twice daily), the resolver pulls the changes and updates its local copy.

Once the local copy is loaded, the resolver intercepts queries that would normally go to a root server and answers them from its local zone data. The answers are identical to what the root servers would return because the data is the same root zone.

RFC 8806 overview

RFC 8806 ("Running a Root Server Local to a Resolver") is the current standard describing this practice. It obsoletes RFC 7706 and incorporates operational experience from early deployments.

• It specifies that the resolver should obtain the root zone via AXFR or IXFR from a configured source.
• It requires that the local copy be validated with DNSSEC before use, ensuring the resolver does not serve tampered data.
• It addresses freshness: if the local copy expires (SOA expire timer), the resolver must fall back to querying the root servers over the network.
• It clarifies that this is not a modification to the root server system — the resolver is a consumer of published root zone data, not a participant in the root server infrastructure.
• It notes that the practice should be transparent to end users. DNS resolution behavior is unchanged from the user's perspective.

The RFC deliberately avoids mandating a specific zone transfer source, leaving operators to choose based on their environment and trust model.

Implementation considerations

Setting up a local root involves several practical decisions:

• Zone transfer source. The resolver needs a server to transfer the root zone from. Options include the root servers themselves (some support AXFR/IXFR), IANA's zone transfer service, or a local authoritative server that mirrors the root zone. The choice depends on network policy, access control, and transfer volume.
• Transfer frequency. The root zone is typically updated twice per day. The resolver should poll at least as often as the SOA refresh interval (currently 1800 seconds) to stay current.
• DNSSEC validation. The local copy must be DNSSEC-validated. The resolver should verify the root zone's signatures against the root trust anchor before serving data from the local copy. This prevents serving forged zone data from a compromised transfer source.
• Storage. The root zone is approximately 2 MB, well within the capacity of any resolver. Storage is not a meaningful constraint.
• Fallback behavior. If the local copy becomes stale (the SOA expire timer elapses without a successful refresh), the resolver must fall back to querying the root servers over the network. This ensures that a misconfigured or disconnected resolver does not serve outdated data indefinitely.

Major resolver software has built-in support or straightforward configuration for local root operation:

• Unbound supports auth-zone configuration to serve the root zone locally with automatic AXFR/IXFR.
• BIND can be configured as a secondary for the root zone using standard zone transfer directives.
• Knot Resolver includes a prefill module designed specifically for local root zone operation.

When to use it

A local root is appropriate in several scenarios:

• Enterprise networks. Large organizations with their own recursive resolvers benefit from reduced external DNS traffic and improved privacy. Root queries from thousands of internal users stay on the local network.
• ISP resolvers. Internet service providers operating high-volume resolvers can reduce latency for their subscribers and decrease load on the global root server system.
• Research and testing. Network researchers and DNS developers can use a local root to study resolver behavior without generating external traffic or being affected by network conditions.
• High-security environments. Networks with strict security policies can minimize external DNS dependencies. Combined with DNSSEC validation, a local root provides verifiable root data without constant external connectivity.
• Remote or poorly-connected locations. Sites with high-latency or unreliable Internet connections benefit significantly from having root zone data available locally.

For small-scale or home use, the benefit is marginal because caching already handles most root queries effectively, and anycast root instances provide low latency for most locations.

Comparison with traditional resolution

The following comparison highlights the key differences between standard recursive resolution and local root operation:

• Root query latency. Traditional: network round trip to nearest anycast instance (typically 5–50 ms). Local root: sub-millisecond from local data.
• Privacy. Traditional: root queries are visible on the network path. Local root: root queries never leave the resolver.
• Resilience to root outage. Traditional: if all reachable root instances are unavailable, resolution stalls after cache expires. Local root: continues answering from local data until SOA expire.
• Operational complexity. Traditional: no additional configuration needed. Local root: requires zone transfer setup, monitoring, and fallback configuration.
• Data freshness. Traditional: always queries the live root. Local root: zone data may be up to one refresh interval behind, but root zone changes are infrequent and typically involve TLD delegation updates.

In practice, the staleness window is negligible. Root zone changes are rare enough that a refresh interval of 30 minutes means the local copy is almost always current.

Further reading

RFC 8806 is the definitive reference for running a local root. RFC 7706 is the predecessor document. RFC 7720 documents the DNS root name service protocol. IANA publishes the root zone file and zone transfer access details.