Summary

  • The Root Server System Governance Working Group's final model would let the future Security Incident Reporting function suspend an RSO's operations in an extreme case where noncompliance poses a significant threat to the RSS. The power would exist only after a staged transition into a fully empowered Governance Phase; the reviewed public record does not show that phase or power exists today.
  • Permanent removal follows a different route. The Designation and Removal function gives opportunities for correction, recommends removal to the Council and coordinates orderly removal from the three DNS root sources identified by RSSAC030. The model does not say whether a temporary SIR suspension touches those sources, how long it lasts or how an operator is reinstated.
  • Before empowerment, the Council should ratify a versioned suspension-and-return continuity receipt. It should expose authority, scope, clock, correction, appeal, return test and any DNR handoff while keeping attack-enabling evidence in a protected annex.

One verb opens an unfinished state

The Root Server System Governance Working Group spent nearly four years turning earlier RSSAC advice into a functional model. Its final report, approved by the working group on 18 February 2026, is not timid about the responsibilities a future governance structure may need.

In the fully empowered Governance Phase, the Security Incident Reporting function, or SIR, could investigate security incidents, request data and cooperation, mandate security enhancements, enforce security policy and impose corrective measures. In the most serious case, it could “suspend operations of an RSO” where noncompliance poses a significant threat to the Root Server System.

That is a defensible power to consider. Critical infrastructure governance that can collect reports but cannot contain an acute risk may discover the problem and still be unable to protect the system.

The difficulty begins after the verb. The report does not define the object of suspension. It does not state whether the action changes only an operator's standing in the governance structure, restricts a particular service obligation, isolates part of an operator's infrastructure, affects one root identifier, or ultimately changes the public sources through which the DNS identifies root server operators.

It also does not name reinstatement. A search of the final 86-page model finds no return state connecting correction, technical readiness, appeal and restored authority. Suspension is presented as an available power; restoration is left to the procedures that future institutions would have to write.

This is not evidence that a current RSO is unsafe. It is not evidence that ICANN, RSSAC or IANA can suspend one today. It is a design question that should be settled before the proposed structure reaches the stage at which the verb can be executed.

The power is proposed, not active

The model's staging is its strongest answer to premature alarm.

The Initiation Phase would form the Council and Secretariat. It is intentionally limited in scope and authority. The Establishment Phase would create and charter the functions, write security and performance policy, define designation and removal, build due process and appeals, secure finance, and memorialize the structure's relationship with ICANN, IANA and RSSAC.

The transition gate is substantial. All functions must be operating. Core governance policies must be ratified. Completion of Milestones 1 through 11 must be recorded in a comprehensive public assessment. A public consultation must occur, the Participant Stakeholder Communities must be consulted for consensus, and the Council must formally vote that the structure is ready. Only then does Milestone 12 say the structure begins operating with authority over RSS governance.

The public trail reviewed for this Article does not show that sequence has happened. The GWG Chair delivered the final model to the ICANN community, Board, IETF/IAB, RSSAC and RSOs on 20 February. The Board Chair replied with thanks and said the Board looked forward to the path ahead. That is receipt, not an adoption resolution. ICANN planning material anticipated Board adoption and later implementation, but a forecast is not an executed decision.

The distinction is essential. The Article can test whether the proposed model is complete enough to activate. It cannot turn a future power into a present fact.

SIR and DNR run on different clocks

The final report does not put every form of operator accountability into one committee. SIR and the Designation and Removal function, or DNR, have different starting points and different outputs.

SIR begins with a security incident. Its scope includes standardized reporting, post-incident review, security controls, audits, vulnerability mitigation and external communication. In the Governance Phase, it gains investigative and enforcement powers designed for urgency. It can order correction, authorize emergency actions and, at the extreme, suspend operations.

DNR begins from performance concern or noncompliance identified through the Performance Monitoring and Evaluation function. It investigates, works with the operator on remediation within set timelines and recommends removal only when required standards are still unmet after sufficient opportunities for correction. The Council gives final approval. DNR then coordinates orderly shutdown and removal from DNS root sources, with communication to IANA.

The distinction protects both continuity and fairness. A security response may need to happen before a permanent-status case can be investigated. Permanent removal changes the composition of the operator community and deserves a higher, slower threshold.

But two paths create a handoff problem. A temporary SIR suspension can be followed by successful correction, a contested finding, a narrower measure or a DNR case. The model does not say which event transfers custody, who owns the operator's status between functions, or what public decision closes the SIR case.

A corrective action plan is not reinstatement. Completion of remediation is a fact about technical or procedural work. Reinstatement is an authorized state change. If the model does not connect those two facts, a temporary measure can remain in force through institutional memory rather than an affirmative decision.

RSSAC030 makes the ambiguity technical

“Suspension” might sound like a governance label until it is read beside RSSAC030.

That one-page statement identifies three key sources maintained by the IANA Functions Operator: the root hints file, the root zone and the root-servers.net zone. They contain the names and IP addresses used to define root servers for clients. Inclusion of an organization's information in those sources is what identifies it as a root server operator and enables its service to be discovered through the conventional system.

The Functional Model invokes RSSAC030 in DNR's removal scope. DNR would coordinate an orderly shutdown and removal of an RSO from those sources. It does not use that wording for SIR suspension.

That leaves at least three separate states.

First is governance status: an institutional decision declares an operator suspended. Second is operating state: some or all service activity may be restricted, isolated or changed during incident response. Third is root-source state: IANA-maintained sources are modified so that the organization's identifying service information is removed or altered.

Those states should not be inferred from one another. A governance suspension need not automatically erase root-source entries. A technical isolation during an incident need not be a permanent removal. A root-source change should not occur under the shadow of an undefined temporary measure if the model reserves permanent removal for DNR and Council approval.

The public record must therefore say what changed. Without that field, two readers can see the same word and imagine different consequences: one a temporary compliance status, the other an effective removal from the root.

An appeal does not restore service by itself

The model does provide checks. SIR is to publish annual reports, maintain channels for external feedback, submit security recommendations to peer review and undergo periodic external review. RSOs and other stakeholders may appeal SIR decisions through the Council. DNR decisions have their own direct Council appeal, and removal recommendations require final Council approval.

An appeal route is not a state machine.

The text does not say whether filing an appeal stays a suspension. It does not state whether the Council may issue an emergency stay, what service state applies while review is pending or whether a successful appeal restores every prior permission automatically. It does not say whether technical readiness must be retested after a suspension caused by a security vulnerability. Nor does it identify who certifies that the corrective measure is complete.

Those questions cannot safely be improvised during the first extreme case. The operator will want rapid return and protection from an indefinite sanction. SIR will want confidence that the significant threat is gone. Other RSOs will want collective resilience without turning peer review into competitive leverage. IANA and the Root Zone Maintainer will need an exact instruction if any source or coordination action is involved. Resolvers and users will need the collective service to continue while the dispute is decided.

Due process and operational continuity run on different clocks. A Council may need days or weeks to review evidence. Incident mitigation may need minutes. A complete procedure must allow fast containment, a defined interim state and a later merits decision without treating any one of those as a substitute for the others.

Public accountability does not require publishing the exploit

RSSAC062 supplies the right confidentiality boundary. Its 2025 guidance focuses on incidents with a material adverse effect on RSS availability, integrity or confidentiality. It says reporting should not interfere with mitigation and that resolution comes first. Detailed reports may carry Traffic Light Protocol restrictions. Information that could help a future attacker should be excluded.

The same document recommends authenticated submission, confidential handling and a timely public TLP:Clear version. The Functional Model likewise calls for non-sensitive security summaries while protecting sensitive operational detail. In the public-comment disposition, detailed confidentiality rules were left for future SIR procedures.

That combination makes a thin public receipt possible. The public does not need private keys, topology, query logs, unpatched-vulnerability details or a forensic recipe. It does need to know that an enumerated authority acted, the general class of trigger, the scope of the measure, its review clock and its current outcome.

The protected annex can contain evidence, names, detailed remediation and attack indicators. Its existence, custodian, access class and integrity history can be recorded without publishing its contents. Transparency concerns the exercise of power; it is not a command to expose the system to a second attack.

The strongest defence is the reason to finish the procedure

The proposed model deserves its best defence.

The RSS is critical infrastructure. Redundancy can make isolation of one dangerous component safer than tolerating a system-wide threat. An extreme-case suspension power is narrower than a general licensing discretion. The model separates functions, requires appeals and oversight, gives an operator opportunities to correct before permanent removal, and postpones full authority until policy and accountability mechanisms are built and publicly assessed.

It is also reasonable for a functional model to leave implementation detail to the Establishment Phase. The people writing the charter will have to integrate live response, protected evidence, IANA coordination and operator autonomy. A top-level report cannot specify every incident playbook.

None of that makes the return path optional. Delegating detail is sound only if the activation checklist requires the detail to exist. Milestone 7 already calls for security policy, incident response and escalation. Milestone 8 calls for designation, removal, due process, appeal and dispute resolution. Milestone 10 calls for accountability and any further review procedures. These milestones are the natural place to require one joined suspension-and-return lifecycle.

Heng Lu's Running-Code Primacy offers a useful discipline here without supplying a literal template. Institutional authority should be tested against the minimum technical effect running systems require. If the governance structure says “suspended,” it should identify the operational change rather than assume symbolic status will produce a uniform technical reality.

His registry-continuity distinction is equally useful when adapted carefully. Continuity belongs to the service, security chain, records and downstream users; it does not automatically mean preserving every authority of the governor or every status of the operator. A suspension can be justified to protect the collective RSS. That same objective requires a bounded return or removal path so the temporary measure does not become the continuity risk.

Publish a suspension-and-return continuity receipt

Before the Governance Phase begins, the Council should ratify a versioned receipt for every SIR suspension. It should open with minimal metadata at the moment of action and mature as the incident stabilizes. It should never delay containment.

The receipt should record:

  • a stable case identifier and the affected RSO;
  • the SIR authority, policy version and accountable institutional role;
  • a non-sensitive trigger class and whether emergency procedure was used;
  • the exact scope: governance status, service obligation, infrastructure subset and any root-source effect;
  • the decision time, maximum initial duration and next mandatory review;
  • how collective RSS continuity is being preserved;
  • corrective measures and a public completion state;
  • protected-evidence custody and classification without the sensitive contents;
  • appeal status, any request for a stay and whether a stay was granted;
  • the authority and criteria for return;
  • technical readiness and peer or independent review status;
  • every extension, with a new decision and reason;
  • the terminal outcome: restored, narrowed, superseded or handed to DNR; and
  • any separate IANA, RZM or root-source action, including its authority and reversal state.

The vocabulary must be exact. Appeal filed is not stay granted. Correction complete is not return approved. Suspension reviewed is not suspension continued. DNR referral is not removal approved. Removal approved is not root-source change completed.

The receipt should also carry explicit null states. If no root-source action occurred, say so. If no appeal was filed, say so. If restoration has not been decided, show pending decision rather than leaving the field blank. Governance errors often survive inside empty cells because readers cannot distinguish absence, delay and a deliberate negative result.

This record would not create an RSO veto. It would not force SIR to publish an exploit. It would not let a public comment overrule emergency mitigation. It would make each coercive state accountable to an authority, scope, clock and terminal decision.

Evidence limits

The reviewed evidence does not show formal adoption of the Functional Model or activation of the Governance Phase. Delivery to the Board, a grateful response and an operating-plan expectation are not substitutes for an adoption resolution and completed milestones.

No reviewed source shows that an RSO has been suspended under this model, that any current operator is noncompliant or that a current body possesses the proposed power. The absence of the word reinstatement does not prove that future chartering work cannot create a return procedure. It shows why that procedure should be a condition of empowerment.

The meaning of suspend operations is not specified. The Article therefore does not claim that suspension removes entries from the root hints file, root zone or root-servers.net zone. RSSAC030 is used to show why any such effect would be a distinct, identifiable technical action.

Finally, the proposed receipt is not a demand for sensitive incident evidence. Its public layer is about authority and state. The detailed facts may remain protected when disclosure could assist an attack or expose legitimate operational confidentiality.

Sources

  1. ICANN — The Root Server System Governance Structure, 18 February 2026
  2. ICANN — Governance Principles for the Root Server System
  3. GWG Chair Brad Verd — Final report and deliverables
  4. ICANN Board Chair Tripti Sinha — Response to the GWG
  5. ICANN Public Comment — Functional Model for Root Server System Governance
  6. RSSAC030 — Statement on Entries in DNS Root Sources
  7. RSSAC058 — Success Criteria for the RSS Governance Structure
  8. RSSAC062 — Security Incident Reporting
  9. RSSAC055 — Principles Guiding the Operation of the Public Root Server System
  10. ICANN Draft Operating and Financial Plan FY2027–2031 — Strategic Initiative 33
  11. Heng Lu — Running-Code Primacy
  12. Heng Lu — The Registry Continuity Fallacy
  13. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile