Summary

  • RIPE NCC’s Q3 plan says the K-root hardware refresh is in progress and Amsterdam has been refreshed; because the page was last updated on 11 June, it does not establish the present state of London or Tokyo.
  • Anycast resilience can keep K-root available while a particular site is withdrawn, rolled back or still under observation. Completion therefore needs one safe acceptance record per site, not a service-wide green light.

One row, three changes

The clearest sentence in RIPE NCC’s Q3 2026 DNS and K-root plan is also the sentence that makes aggregate reporting inadequate. Hardware at the K-root core sites in Amsterdam, London and Tokyo had reached end of life after seven years and needed replacement. The item was marked “In progress”, with a parenthetical update: Amsterdam had been refreshed.

Both statements can be true. A programme with three sites can be one-third complete while one site is fully accepted. It can also be in a more complicated state: Amsterdam may have passed a cutover but remain in an observation period; a component may have been replaced while another stayed on the old generation; one address family may have returned before the other; or a change may have been rolled back without affecting the global service. None of those possibilities is asserted by the public page. They show why a single status field cannot carry the meaning readers may load into it.

There is a second clock. The RIPE NCC Activity Plan and Budget 2026 committed to refresh the K-root core-site hardware by July 2026. The quarterly page says it was last updated on 11 June. Reading the two together does not prove that the commitment was met, and it does not prove that it was missed. A document timestamp is evidence about the representation, not a hidden camera on the work. The honest conclusion is narrower: the public record names the target, the three locations and one reported site outcome, but it does not yet close the three-site state.

That distinction matters because these are not three interchangeable boxes. RIPE NCC’s K-root peering policy lists five core nodes—Amsterdam, Frankfurt, London, Miami and Tokyo—and describes different exchange relationships at each. Amsterdam is associated with AMS-IX and NL-IX; London with LINX and LONAP; Tokyo with JPNAP and DIX-IE. The 2026 replacement covers three of the five core locations, not the entire K-root footprint. Each change therefore has a location, a routing edge and an operational sequence of its own.

Availability is designed to be an incomplete witness

K-root is delivered through distributed IPv4 and IPv6 anycast nodes. RIPE NCC’s service overview says the nodes announce K-root prefixes from AS25152 and run one or more of BIND, Knot or NSD. This architecture is valuable precisely because one site need not carry the meaning of the service as a whole.

RIPE NCC makes the point directly in its response to RSSAC001v2. It says planned maintenance can be performed by taking individual sites or components out of service and that built-in redundancies keep K-root as a whole available. The RSSAC001v2 expectation is framed the same way: maintenance of an individual infrastructure element should not make the entire root-server service unavailable.

This creates an important evidentiary inversion. For many ordinary services, continued availability during a hardware change is treated as strong evidence that the change succeeded. In an anycast root service, continued global availability is also evidence that redundancy worked. It may say very little about the changed site. Traffic may have reached another K-root location. A probe may have observed a correct answer without observing Amsterdam, London or Tokyo. An aggregate dashboard may remain calm because the architecture successfully contained the work.

That is not a weakness in K-root. It is the purpose of redundancy. The mistake would be to ask a service-wide signal to certify a site-level act that it was designed to mask.

The current K-root directory data illustrates the boundary. Amsterdam, London and Tokyo are each described as operational Global sites with three instances. Those are useful public service identities. Their records do not name a 2026 hardware generation, a cutover or an acceptance decision, and their displayed update timestamps predate the refresh programme. “Operational” must therefore remain separate from “refresh accepted”.

What an acceptance record should contain

The missing object does not need to be a public change ticket. Publishing serial numbers, rack layouts, internal capacity thresholds or detailed security tests would be irresponsible. The public need is smaller: a record that proves what decision was made, for which site, on what evidence and with which exceptions.

Start with identity. The record should name the stable public site code and classify the changed scope—router, DNS server, connectivity edge or monitoring path—without disclosing exploitable detail. It should distinguish the retired generation from the accepted generation at a safe class or version level. “Amsterdam refreshed” is meaningful only if a later reviewer can tell which change that sentence refers to.

Then record time. A planned window and an actual start and end are not the same thing. Neither is the observation period. A site may return to advertisement at 02:00 and remain under heightened review until 14:00. If those states are compressed into a single completion timestamp, operators cannot know whether a later anomaly fell inside acceptance or after it.

Routing deserves two tracks. K-root has both IPv4 and IPv6 service, so withdrawal, restoration and external observation should be recorded separately for each address family. A route being visible is not proof that DNS answers are correct. A DNS answer being correct is not proof that the intended site answered it. The receipt should preserve those differences rather than manufacture a single green state.

Service checks also need types. Did the site answer? Was the answer complete and unmodified? Was the root zone current? Did the sampled vantage point reach the intended site? Were expected traffic and error distributions observed during the bounded period? Each result should carry a method and version. An “all checks passed” label without the check classes cannot be compared with the next seven-year renewal.

Finally, exceptions and reversibility must be first-class states. Accepted with exception, rolled back, restored but observing and accepted are different outcomes. The record should name an owner and reviewer, preserve the sign-off time, and allow a later correction without deleting the earlier representation. A batch view can then calculate zero, one, two or three accepted sites. It should never overwrite the three records from which that number came.

Existing measurements are ingredients, not the receipt

RIPE NCC already publishes more operational evidence than the quarterly row suggests. RIPE-859 says it uses continuous monitoring, including distributed observations from more than ten thousand RIPE Atlas vantage points. It also links to a public RSSAC002 metrics archive with records through 2026.

The RSSAC002v5 specification standardises daily records for zone load time, traffic volume, response-size distribution, response codes and, optionally, unique sources. It permits operator-specific metrics as well. Those series can be valuable before-and-after evidence. They still do not identify the old hardware generation, bind a sample to a maintenance window, record a rollback decision or say who accepted a site.

Metrics and acceptance answer different questions. A traffic-volume series can show a discontinuity. It cannot tell whether that discontinuity was intended withdrawal, changed routing, a collector difference or ordinary demand without more context. A zone-load measure can test one part of freshness. It cannot establish that both address families returned through the intended peering edge. A RIPE Atlas sample can add outside observation. Its result remains dependent on probe, path, time and anycast catchment.

The right design is a join, not a new dashboard. The acceptance record should point to a bounded set of existing observations and state what each one supports. It should also state what was redacted by category. That approach gives readers a reproducible conclusion without teaching an attacker how the site is built.

The strongest case for restraint

RIPE NCC can reasonably argue that public per-site detail has limits. Root-server operations attract adversarial attention. Hardware inventories age into vulnerability maps. Capacity figures and failover thresholds can reveal more than accountability requires. Some tests are meaningful only when their design and trigger remain confidential. The absence of a public field is not evidence that an internal control is absent.

The institution can also point to diversity. RIPE-859 says K-root uses at least two, and usually three, DNS code bases, two software BGP-router implementations and two hardware-router implementations. That is a serious resilience choice. It makes a simplistic “old box replaced by new box” narrative less accurate, not more.

There is also published evidence of reversible site operation. RIPE NCC’s 2015 K-root expansion plan says a location causing negative service impact can stop advertising the K-root prefix, with traffic rerouted and the advertisement restored after the problem is fixed and verified by tests. That document concerns the hosted-node expansion model, so it cannot be treated as the 2026 core-site procedure. It nevertheless shows why withdrawal, test and return are legitimate public result classes.

The answer is not maximal disclosure. It is typed disclosure. A safe acceptance record can say that route restoration was observed across a bounded sample without publishing peers, thresholds or internal topology. It can say that a rollback path was tested without describing the exploit-sensitive method. It can record that an exception exists without identifying the vulnerable component. Restraint becomes credible when readers can see the boundary it protects.

Completion should survive the next refresh

RIPE NCC’s archived DNS and K-root plans contain a useful precedent. A separate set of DNSSEC signers also reached end of life after seven years; RIPE NCC retained the chosen platform, refreshed the hardware and marked the item completed in Q3 2025. That record shows that completion is a normal public planning state. It does not expose how completion was tested.

For K-root, the more durable outcome would be three site records behind the programme state. That would allow the next refresh team to compare like with like: how long withdrawal lasted, which evidence classes were used, when observation closed, which exceptions recurred and whether the definition of acceptance changed. It would also allow RIPE NCC to correct one site’s record without reopening the other two.

A root service is supposed to make component failure less visible to users. Governance should not mistake that success for proof that every component change is complete. Amsterdam, London and Tokyo are three operational boundaries. The public record will be strongest when it lets each boundary close on its own evidence.