Summary

  • A 13 September observation found that .ps root glue now matches the current IPv6 address of its RIPE NCC AuthDNS hostname; .ne, .sd and .tj still carried the old IPv6 glue identified in August.
  • RIPE NCC said IANA could not process its requests without approval from the relevant ccTLD contacts. The different outcomes are therefore consistent with four separate delegation workflows, not one repair batch.
  • No outage was established. RIPE NCC reported alternative IPv6 and IPv4 glue for every delegation. The missing public control is a privacy-safe receipt that shows the state and disposition of each case.

Four is a satisfying number for an incident list. It suggests a set with a beginning, a shared cause and, eventually, a single closing line. Root-zone maintenance is less obliging.

On 15 August, Patrik Wallstrom told the RIPE DNS Working Group that the root still carried old IPv6 glue for four names under cctld.authdns.ripe.net: the names serving .ne, .ps, .sd and .tj. RIPE NCC had announced in January that its AuthDNS IPv6 renumbering was complete, the former /48 had been withdrawn completely and most cleanup was done. The four records made the residue visible beyond RIPE NCC’s own network.

RIPE NCC’s 20 August reply supplied the important boundary. It had tried email, telephone and regional contacts and opened requests with IANA. Those requests could not be processed without approval from the ccTLD contacts. The TLD managers, RIPE NCC noted, are responsible for keeping their root-zone glue current.

That is not bureaucratic friction pasted onto a routing change. It is the authorization model. A nameserver operator may know that its address has changed; the root-zone maintainer still cannot accept an unauthorised third party’s instruction to alter another manager’s delegation.

The count moved, but not as one count

At 17:14 UTC on 12 September—already 13 September in Shanghai—this research compared referrals from a.root-servers.net and b.root-servers.net with hostname answers returned by 1.1.1.1 and 8.8.8.8.

For ps.cctld.authdns.ripe.net, both root servers supplied 2a13:27c0:30::105 as glue. Both recursive resolvers supplied the same current AAAA address for the hostname. IANA’s .ps delegation page also displayed that address and carried a page-level update date of 8 September.

The other three still split. The root supplied 2001:67c:e0::101 for .ne, 2001:67c:e0::109 for .sd and 2001:67c:e0::117 for .tj; the corresponding hostname answers were 2a13:27c0:30::101, ::109 and ::117. Their IPv4 glue and hostname addresses matched at 193.0.9.101, .109 and .117.

The modest conclusion is the useful one. August’s four mismatches had become three. The observation does not identify who submitted or approved the .ps change, nor the moment at which the root first served it. Page-level update dates do not identify which field changed. But the differential outcome fits the stated control path: one TLD manager can complete an authorised change while three other delegation records remain in a different state.

Continuity is not the same as correctness

RIPE NCC said every affected delegation had at least one other working IPv6 glue record and several working IPv4 glue records, allowing resolvers to follow the delegation and resolve names. That is strong evidence against describing the mismatch itself as an outage.

This research sent no packet to the old IPv6 addresses. It did not measure reachability, retry delay or user-visible effect. It found no basis to claim a lame delegation, DNSSEC failure, resolver failure or loss of authoritative service. Alternative glue is a continuity control, not proof that every resolver chose the same path with zero delay.

The distinction matters because alarm can destroy the lesson. Old glue should be corrected, especially after the old prefix has been withdrawn. Yet the root’s refusal to accept an unapproved change is also a safety property. The operational objective is not “make all four rows change at once”. It is “make every authorised row converge, while preserving service and an evidence trail”.

An old closure is not a current queue

IANA’s July 2025 root-operations audit lists nameserver-change requests involving all four hostnames as Administratively Closed on 18 July 2025. The table does not state a reason for each closure. Those entries are historical outcomes; they cannot be treated as a live status board for the later requests described by RIPE NCC, and they do not explain the subsequent .ps alignment.

This is precisely why a batch-shaped narrative is inadequate. A public audit can show that an old request ended. A delegation page can show what data is currently published. A DNS query can show what a server returned at one instant. None alone binds the requester, the manager’s authorization, the technical checks, the disposition and the observed root result into one case history.

Give each delegation its own receipt

A privacy-safe receipt should carry the TLD, nameserver hostname, old and requested address, requester role, public-safe request identifier, TLD-manager authorization state and timestamp, technical-check result, terminal state and reason category. It should add a root-zone serial or observation time, the glue currently served, the next action and any superseding request.

Personal contact details need not be exposed. Nor should the receipt invite outsiders to bypass a TLD manager. Its purpose is narrower: let the operator, the manager and an auditor distinguish “awaiting authorization” from “failed technical check”, “withdrawn”, “implemented” or “superseded”.

RIPE 91 minutes describe the renumbering as an operational improvement and record a plan to capture queries sent to old IPv6 addresses after shutdown for possible follow-up. That observation can identify continuing use. A per-delegation receipt can identify the authority and decision needed to retire it. Together they turn an imprecise cleanup list into four accountable paths.

The arithmetic now says three. The governance still says four cases.

Sources