Summary

  • A January 2026 controlled study featured by APNIC PING on 3 September compares ordinary root-query traffic with the traffic required to keep local root-zone copies current.
  • The four-day local measurements average 4.35 MB per resolver per day for BIND using IXFR, 3.93 MB for DNS-based Unbound and 2.65 MB for Knot Resolver using one HTTPS update a day.
  • A fourth result, 105.12 MB per day for HTTPS-based Unbound, came from downloading a full 2.19 MB zone every 30 minutes. The study records this as an acknowledged bug, not a property of HTTPS.

At 12:06 each day, one resolver in a virtual testbed fetched a complete root zone. Two others waited for the serial to change and then transferred an increment. A fourth fetched the complete file every half-hour, changed or not.

All four machines were described as serving the root locally. Their traffic bills were anything but equivalent.

That distinction is the useful news in an APNIC PING article published on 3 September. George Michaelson discusses a University of Amsterdam research project with its author, Ilyas Rahimi, and NLnet Labs' Willem Toorop. The experiment does not ask whether a local copy acquires authority over the DNS root; it does not. It asks what happens to traffic when routine queries are replaced by zone distribution.

Four refresh loops, four totals

Rahimi's research report puts conventional and local-root traffic into one unit: megabytes per resolver per day. The conventional side uses RSSAC002 observations from 1 to 7 January. Most root letters land between 0.67 and 1.34 MB per day in the paper's calculation, while F-root is an 11.18 MB outlier. The local side uses packet captures from 20 to 23 January in a controlled virtual environment.

The local results separate implementation from slogan.

Tested local-root configuration Observed update behaviour Average MB/resolver/day
BIND over DNS IXFR Transfer after serial change; 2-4 updates/day 4.35
Unbound over DNS IXFR Transfer after serial change; 2-4 updates/day 3.93
Knot Resolver over HTTPS About one full update/day 2.65
Unbound over HTTPS Full download every 30 minutes 105.12

BIND moved about 1.45 MB per incremental update. DNS-based Unbound moved about 1.31 MB. The root serial advanced two, three, four and three times over the four observed days, so update count explains the changing daily totals.

Knot Resolver took a different bargain. Its tested configuration fetched one complete copy per day, averaging 2.65 MB. That is the smallest local total in this experiment, not a universal efficiency award. A more conservative cadence also means that a change is not necessarily obtained immediately. Traffic and freshness are two parts of the same decision.

The 105.12 MB result needs the strongest boundary. The Unbound HTTPS configuration downloaded a 2.19 MB file 48 times a day because it did not first establish that the serial had changed. The report says a discussion with an Unbound developer confirmed the behaviour as a bug expected to be corrected. APNIC's account makes the same point. Calling this “the cost of HTTPS” would erase the experiment's most important diagnosis: transport did not demand the repeated full downloads; update logic did.

A measurement, not a deployment verdict

Every local configuration exceeded the paper's conventional baseline during the selected windows. That finding is narrower than “local root uses too much traffic.” The local captures span four days, the comparison window seven. They measure bytes, not latency, DNSSEC computation, operational complexity, failure recovery or the value of reduced dependence on public root paths.

The denominator is also modelled. RSSAC002 unique source addresses are treated as approximate resolver instances. NAT, IPv6 aggregation and repeated appearances prevent that number from becoming a census. The report's later multiplication across an estimated 59 million resolvers is an illustration of linear scale, not a forecast that a stated number of terabytes will appear on real networks.

Stable guidance remains important. RFC 8806 describes a complete, current and DNSSEC-valid root copy with non-local fallback before stale data is served. A newer individual Internet-Draft, version 07, proposes checking state before whole-zone retrieval and discusses efficient HTTPS distribution. Despite its historical filename, its editor note says it is not being pursued as a Best Current Practice. It is work in progress, not current IETF policy.

The safest conclusion is operationally modest. Local root service turns a stream of small queries into a refresh obligation. The obligation can be efficient or wasteful, current or dangerously delayed. Its actual behaviour is visible in serial checks, transfer type, bytes per update, update count, validation and copy age. Those are better facts than a configuration label.