Summary
- LocalRoot removes many small exchanges with public root servers but replaces them with a control plane that obtains and verifies complete root-zone states.
- In Ilyas Rahimi’s short 2026 test, every measured LocalRoot configuration transferred more bytes per resolver per day than the study’s conventional-query baseline; update frequency and implementation logic mattered more than transport labels.
- The finding is a bounded measurement, not a universal bandwidth verdict. Count queries, bytes, changes, retries, validation, activation and user-visible resolution separately.
A quieter wire can carry a larger object
The persuasive LocalRoot picture is a resolver that stops sending routine questions toward the public root. The queries remain on the host, latency may fall, and one external observation point sees less. Yet the root zone is not static. The resolver must acquire current states of it, decide whether a newer serial exists, retrieve the data and prove that the candidate is safe to serve.
That distinction is the opening of Rahimi’s January 2026 University of Amsterdam project, supervised with support from NLnet Labs. It compares query-driven interaction with update-driven distribution in one unit: bytes per resolver per day. Seven days of RSSAC002 data supplied an estimate for conventional root traffic. Four days of packet captures measured BIND, two Unbound configurations and Knot Resolver in a controlled virtual testbed.
The conventional estimates varied sharply by root letter. Most averages in the paper’s table sat between 0.67 and 1.34 MB per resolver per day; f-root was an 11.18 MB outlier. For a later scaling exercise, the paper used roughly 2 MB as an average across roots. Those figures are derived from aggregate traffic, size buckets and approximate unique-source counts. They are useful for comparison, not a meter attached to every resolver.
Four configurations, four different obligations
BIND and DNS-based Unbound checked the SOA serial on the root zone’s 1,800-second refresh rhythm and transferred data after a change. The observed BIND updates were about 1.45 MB each and averaged 4.35 MB a day. DNS-based Unbound updates were about 1.31 MB and averaged 3.93 MB. Their daily totals moved with the number of actual root-zone changes.
The HTTPS-based Unbound configuration did something more expensive: it downloaded a roughly 2.19 MB complete zone every 30 minutes, 48 times a day, for 105.12 MB. The paper says this behaviour was considered a bug after discussion with a senior Unbound developer. The number is therefore evidence about that measured logic, not evidence that HTTPS inherently causes 105 MB a day.
Knot Resolver also used HTTPS, but fetched roughly once daily. Its four-day average was about 2.65 MB. That result breaks the tempting transport story. HTTPS appears at both extremes; scheduling and pre-download change detection decide much of the cost.
Distribution is a chain, not one counter
The July 2026 individual Internet-Draft on populating resolvers with the root zone makes the missing operations explicit. A LocalRoot implementation identifies sources, chooses one, checks freshness with mechanisms such as HTTP HEAD or a root SOA query, rejects an older serial and tries another source after failure. It should avoid downloading the full contents at every refresh. After download, it must verify the zone’s ZONEMD record and validate that record with DNSSEC under the configured IANA root trust anchor before the data is used.
The draft also separates availability from correctness. An implementation checks for new data regularly, but a candidate does not become active merely because bytes arrived. If no usable copy is available, or the active copy becomes stale, normal queries to the Root Server System resume. The expiry ceiling cannot exceed the root SOA expire value.
RFC 8806 supplies the established boundary beneath that proposal. The copy must be complete, remain identical to the public root data, validate signed records and answer only resolvers on the same host. It must not serve stale data. Local execution narrows a delivery path; it does not abolish publication, trust-anchor or fallback dependencies.
What the measurement does not prove
Rahimi observed LocalRoot for four consecutive days and conventional traffic for seven. The testbed simplified real networks. The analysis excluded latency, computational cost, operational complexity and mixed deployment. Its global resolver count used RSSAC unique sources as an approximation. A longer period, other software versions or different source behaviour could change the ratios.
The right conclusion is narrower and more valuable: query count is not total traffic, and total traffic is not service quality. Fewer visible root queries can coexist with more distribution bytes. More bytes can coexist with better resilience or privacy at a named observation point. A low-byte update path can coexist with stale data. None of those predicates may stand in for the others.
The receipt set
A defensible deployment retains at least these separate records: client query count and bytes; refresh and change checks; selected source; downloaded bytes and retry bytes; transport and update mode; software version and configuration; SOA serial, refresh and expire; ZONEMD and DNSSEC result; candidate hash; activation or quarantine; fallback event; residual privacy observers; latency; and the user-visible resolution outcome.
Link them by one update cycle. Do not merge them into “LocalRoot healthy”. That phrase cannot explain whether a quiet resolver is serving a verified current copy, retrying a broken source, repeatedly downloading an unchanged file or already answering through remote roots.
Sources
Rahimi’s research report, the NLnet Labs student-project record, the APNIC interview summary, draft-wkumari-dnsop-localroot-bcp-07 and RFC 8806.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
