Zusammenfassung

  • In einer künftigen, vollständig ermächtigten Governance Phase könnte Security Incident Reporting den Betrieb eines RSO suspendieren, wenn Nichtbefolgung in einem Extremfall eine erhebliche Gefahr für das RSS darstellt. Diese Befugnis setzt elf Meilensteine, eine öffentliche Bewertung, Konsultation und einen formellen Council-Beschluss voraus; die geprüften öffentlichen Unterlagen belegen keine heutige Aktivierung.
  • Die dauerhafte Entfernung folgt dem gesonderten DNR-Verfahren: Untersuchung, hinreichende Korrekturmöglichkeiten, Empfehlung an den Council und geordnete Entfernung aus den drei in RSSAC030 beschriebenen DNS-Root-Quellen. Ob eine SIR-Suspendierung diese Quellen berührt, wie lange sie gilt, wie ein Rechtsbehelf wirkt und wer die Rückkehr genehmigt, bleibt offen.
  • Vor Milestone 12 sollte der Council einen versionierten Kontinuitätsnachweis von Suspendierung bis Rückkehr verlangen. Befugnis, Umfang, Uhr, Abhilfe, Rechtsbehelf und Ergebnis gehören in den öffentlichen Teil; angriffsrelevante Beweise in einen geschützten Anhang.

Die Lücke beginnt nach dem Eingriff

Der Bericht der RSS Governance Working Group ist das Ergebnis von fast vier Jahren Arbeit. Er baut einen Council, ein Secretariat, Stakeholder-Gruppen und fünf Funktionen in drei Stufen auf. Sein Ziel ist nicht nur Austausch, sondern eine Governance-Struktur, die im letzten Stadium Entscheidungen treffen und durchsetzen kann.

Bei Security Incident Reporting, kurz SIR, wird dieser Anspruch besonders deutlich. Die Funktion soll Vorfälle definieren, Meldungen standardisieren, Ursachen untersuchen, Sicherheitskontrollen entwickeln, Audits begleiten, Schwachstellen mindern und die Öffentlichkeit informieren. In der Governance Phase könnte sie Ermittlungen eröffnen, Daten und Mitwirkung verlangen, Verbesserungen anordnen, Sicherheitsrichtlinien durchsetzen und Korrekturmaßnahmen auferlegen. Im Extremfall dürfte sie den Betrieb eines RSO suspendieren, wenn dessen Nichtbefolgung das Root Server System erheblich bedroht.

Eine solche Notfallbefugnis kann legitim sein. Eine Sicherheitsstruktur, die Gefahr erkennt, aber bis zum Ende eines langwierigen Statusverfahrens nicht reagieren darf, schützt die Infrastruktur womöglich nicht.

Der Bericht sagt jedoch nicht, was „Betrieb suspendieren“ technisch und institutionell bedeutet. Ist die Mitglieds- oder Governance-Stellung eingefroren? Betrifft die Maßnahme eine bestimmte Pflicht, einzelne Instanzen, Infrastruktursegmente oder den Dienst eines Root-Identifiers? Kann sie Auswirkungen auf die Quellen haben, über die Clients Root-Server finden?

Ebenso fehlt ein ausdrücklicher Zustand der Wiedereinsetzung. Das Dokument kennt Untersuchung, Korrektur, Berufung und eine andere Spur zur dauerhaften Entfernung. Es verbindet die Beseitigung einer Gefahr nicht mit einer autorisierten Statusänderung zurück.

Das ist kein Befund über die Sicherheit eines heutigen RSO. Es ist auch keine Behauptung, ICANN, RSSAC oder IANA verfügten bereits über diese Befugnis. Die Lücke liegt im vorgeschlagenen Zustandsmodell und kann vor dessen Aktivierung geschlossen werden.

Ein zugestellter Bericht ist noch keine Governance Phase

Die gestufte Umsetzung ist mehr als Übergangsrhetorik.

In der Initiation Phase würden Council und Secretariat mit absichtlich begrenztem Mandat gebildet. Die Establishment Phase müsste die Funktionen aufbauen, ihre Chartas verfassen, Sicherheits- und Leistungsregeln entwickeln, Finanzierung sichern sowie Designation, Removal, ordentliches Verfahren und Rechtsbehelfe festlegen.

Der Übergang verlangt, dass alle Funktionen eingerichtet und tätig sind. Zentrale Regeln müssen vom Council ratifiziert werden. Milestones 1–11 sind in einem umfassenden öffentlichen Bericht nachzuweisen. Vor der Abstimmung findet eine öffentliche Konsultation statt; die Participant Stakeholder Communities werden auf Konsens hin einbezogen; anschließend entscheidet der Council formell über die Bereitschaft. Erst Milestone 12 beginnt die volle Governance-Befugnis.

Die geprüfte öffentliche Spur endet deutlich davor. Der GWG verabschiedete seinen Bericht am 18. Februar 2026 im Konsens und übergab ihn am 20. Februar an die ICANN-Community, das Board, IETF/IAB, RSSAC und RSOs. Die Board-Vorsitzende dankte und blickte auf den weiteren Weg. Ihre Antwort enthält keinen Adoptions- oder Aktivierungsbeschluss. Ein ICANN-Planungsdokument erwartete eine spätere Annahme und stellte die Umsetzung unter künftige Entscheidung und Priorisierung.

Deshalb lautet die korrekte Aussage: Das Modell würde SIR die Befugnis geben. Die Existenz des Berichts überträgt sie keiner gegenwärtigen Stelle.

Zwei Funktionen, zwei Zeitlogiken

SIR und Designation and Removal, kurz DNR, beantworten unterschiedliche Fragen.

SIR beginnt bei einem Sicherheitsereignis. Verfügbarkeit, Integrität oder Vertraulichkeit des RSS können materiell betroffen sein, während die Beweislage noch unvollständig ist. Eindämmung kann Minuten erfordern.

DNR beginnt bei Leistung, Regelverstoß und dauerhafter Eignung. Die Funktion untersucht, begleitet Abhilfe innerhalb gesetzter Fristen und empfiehlt dem Council eine Entfernung erst, wenn ein RSO trotz hinreichender Korrekturmöglichkeiten die Anforderungen nicht erfüllt. Der Council muss abschließend zustimmen. Danach koordiniert DNR mit IANA die geordnete Stilllegung und Entfernung aus DNS-Root-Quellen.

Die Trennung verhindert, dass jeder Vorfall sofort zum Urteil über die Existenz des Betreibers wird. Zugleich verhindert sie, dass die notwendige Langsamkeit eines Entfernungsverfahrens eine akute Sicherheitsreaktion blockiert.

Doch das Modell regelt die Übergabe nicht. Eine SIR-Suspendierung kann nach erfolgreicher Korrektur enden, durch einen Rechtsbehelf aufgehoben, auf einen engeren Umfang begrenzt oder in ein DNR-Verfahren überführt werden. Der Bericht benennt weder die formelle Übergabe noch die Stelle, die den Zwischenstatus pflegt, noch die SIR-Entscheidung, die den Fall schließt.

„Korrektur abgeschlossen“ ist ein Beweiszustand. „Rückkehr genehmigt“ ist ein Autoritätszustand. Ohne getrennte Felder kann die Technik wieder sicher sein, während die Suspendierung aus bloßer institutioneller Trägheit fortbesteht.

RSSAC030 macht die Folgen messbar

RSSAC030 beschreibt drei zentrale Quellen, die der IANA Functions Operator pflegt: die Root-Hints-Datei, die Root Zone und die Zone root-servers.net. Sie ordnen Namen des Root-Dienstes den von RSOs kontrollierten IPv4- und IPv6-Adressen zu. Die Aufnahme der Angaben identifiziert die Organisation als Root Server Operator und macht ihren Dienst im gemeinsamen System auffindbar.

Das Functional Model verweist bei DNR ausdrücklich auf RSSAC030. DNR soll die geordnete Stilllegung und Entfernung aus diesen Quellen koordinieren. Bei der SIR-Suspendierung fehlt dieser Verweis.

Damit sind mindestens drei Ebenen zu unterscheiden.

Erstens der Governance-Status: Eine zuständige Funktion erklärt den RSO für suspendiert. Zweitens der Betriebsstatus: bestimmte Systeme, Instanzen oder Pflichten werden während der Eindämmung eingeschränkt. Drittens der Quellenstatus: IANA ändert eine der drei maßgeblichen Veröffentlichungen.

Keine Ebene folgt automatisch aus einer anderen. Eine institutionelle Suspendierung muss keine Quellenentfernung sein. Die technische Isolation einer Komponente ist keine dauerhafte Abberufung. Und eine Quellenänderung unter dem vorläufigen Etikett SIR darf nicht unbemerkt die Wirkung des strengeren DNR-Verfahrens vorwegnehmen.

Der Kontinuitätsnachweis soll nicht im Voraus festlegen, welche Kombination im Notfall richtig ist. Er soll exakt festhalten, welche Ebene tatsächlich verändert wurde und welche ausdrücklich nicht.

Ein Rechtsbehelf braucht eine operative Zwischenwirkung

Das Modell erlaubt RSOs und anderen Betroffenen, SIR-Entscheidungen beim Council anzufechten. Auch DNR-Entscheidungen können direkt dorthin gebracht werden; Entfernungsempfehlungen bedürfen der abschließenden Zustimmung. SIR soll Jahresberichte veröffentlichen, Peer Reviews einsetzen und extern überprüft werden.

Diese Kontrollen beantworten noch nicht die Frage, was während der Prüfung läuft.

Hat die Einlegung aufschiebende Wirkung? Kann der Council einen vorläufigen Aufschub anordnen? Darf ein nicht betroffenes Segment weiterarbeiten? Führt ein erfolgreicher Rechtsbehelf automatisch zur vollen Wiederherstellung, oder ist nach einer Schwachstelle ein technischer Bereitschaftstest erforderlich? Wer bestätigt, dass die Korrektur die erhebliche Gefahr beseitigt hat?

Verfahrensgerechtigkeit und Netzbetrieb arbeiten mit unterschiedlichen Geschwindigkeiten. Die erste Reaktion kann in Minuten fallen; Akteneinsicht, Stellungnahme und Council-Prüfung benötigen länger. Gute Regeln trennen deshalb Sofortmaßnahme, Interimszustand und Sachentscheidung. Danach verbinden sie diese Zustände in einer gemeinsamen Akte.

Ohne eine solche Verbindung kann der Rechtsbehelf institutionell laufen, während SIR, RSO, IANA und RZM jeweils eine andere operative Wirkung annehmen.

Transparenz muss keine Schwachstelle offenlegen

RSSAC062 setzt eine brauchbare Grenze. Das Dokument behandelt Vorfälle mit materieller Auswirkung auf Verfügbarkeit, Integrität oder Vertraulichkeit des RSS. Es stellt klar, dass Berichterstattung die Eindämmung nicht stören darf und die Lösung des Vorfalls Vorrang hat.

Details können nach dem Traffic Light Protocol geschützt werden. Informationen, die einen künftigen Angriff unterstützen, sollen ausgeschlossen bleiben. Einreichungen brauchen Authentifizierung und Vertraulichkeit. Gleichzeitig empfiehlt RSSAC062 eine zeitnahe öffentliche TLP:Clear-Fassung.

Der öffentliche Kontinuitätsnachweis kann daher schmal sein. Er nennt zuständige Befugnis, allgemeine Auslöserklasse, Umfang, Zeitpunkt, nächste Prüfung und Ergebnis. Schlüssel, interne Topologie, Rohprotokolle, Schwachstellendetails und Forensik bleiben im geschützten Anhang.

Öffentlich festgehalten werden können dessen Verwahrer, Zugriffsklasse und Integritätskette. Offenheit gilt der Machtausübung, nicht dem Angriffsrezept.

Die beste Verteidigung des Modells verlangt einen Abnahmetest

Es ist plausibel, dass ein Functional Model nicht jedes Einsatzhandbuch enthält. Die Establishment Phase ist der richtige Ort, um operative Erfahrung, RSO-Autonomie, Beweisschutz und die Zusammenarbeit mit IANA in konkrete Regeln zu übersetzen.

Auch die vorhandenen Schranken sind ernst zu nehmen: Extremfall, erhebliche Gefahr, getrennte Funktionen, Rechtsbehelf, Peer Review, externe Prüfung, Korrekturmöglichkeiten vor dauerhafter Entfernung sowie öffentliche Konsultation vor der vollen Ermächtigung.

Die Vielfalt und Redundanz des RSS kann eine zeitweise Isolation sogar zum verhältnismäßigen Mittel machen, wenn dadurch der Gesamtdienst geschützt wird. Eine Governance ohne Notfalloption wäre möglicherweise selbst unzureichend.

Gerade deshalb muss die Rückkehr zum Aktivierungskriterium werden. Milestone 7 entwickelt Sicherheits- und Eskalationsverfahren. Milestone 8 entwickelt Designation, Removal, ordentliches Verfahren und Rechtsbehelf. Milestone 10 ergänzt Verantwortlichkeit und weitere Prüfungen. Der öffentliche Abschlussbericht zu Milestones 1–11 sollte diese Teile nicht einzeln abhaken, sondern ihren durchgehenden Zustandspfad testen.

Heng Lus Running-Code Primacy bietet dafür eine Reichweitendisziplin: Institutionelle Aussagen sollten auf die minimale, überprüfbare Wirkung begrenzt werden, die laufende Systeme benötigen. „Suspendiert“ ist keine zuverlässige technische Anweisung, wenn jede beteiligte Stelle darunter etwas anderes versteht.

Seine Unterscheidung der Kontinuität führt zum gleichen Ergebnis. Zu schützen sind Root-Dienst, Sicherheitskette, Aufzeichnungen und Nutzer, nicht automatisch jede Macht des Governance-Gremiums oder jeder Status eines Operators. Eine Suspendierung kann den Gesamtdienst schützen. Ein definierter Rückkehr- oder Entfernungspfad schützt ihn vor der Trägheit dieser Maßnahme.

Ein versionierter Nachweis von Suspendierung bis Rückkehr

Vor Milestone 12 sollte der Council für jede SIR-Suspendierung eine gemeinsame, versionierte Akte vorschreiben. Sie beginnt bei der Maßnahme mit minimalen öffentlichen Daten und wird ergänzt, sobald sich die Lage stabilisiert. Die Eindämmung darf nicht auf Dokumentation warten.

Der öffentliche Teil sollte enthalten:

  • stabile Fall- und RSO-Kennung;
  • entscheidende Funktion, Rechtsgrundlage, Regelversion und verantwortliche Rolle;
  • nicht sensible Auslöserklasse und Kennzeichnung des Notfallwegs;
  • genaue Wirkung auf Governance, Dienstpflicht, Infrastruktur und Root-Quellen;
  • Beginn, anfängliche Höchstdauer und nächsten Pflichttermin;
  • Vorkehrungen für die kollektive RSS-Kontinuität;
  • Korrekturmaßnahmen und öffentlichen Erfüllungsstatus;
  • Verwahrung und Klassifizierung geschützter Beweise;
  • Rechtsbehelf, Antrag auf Aufschub und Entscheidung darüber;
  • zuständige Rückkehrinstanz, Kriterien und technischer Bereitschaftstest;
  • unabhängige oder Peer-Prüfung;
  • jede Verlängerung mit neuer Entscheidung und Begründung;
  • Endzustand: wiederhergestellt, verengt, ersetzt oder an DNR übergeben;
  • jede gesonderte IANA-, RZM- oder Quellenmaßnahme und ihren Rücknahmestatus.

Die Begriffe dürfen nicht ineinanderfallen. Rechtsbehelf eingelegt ist nicht Vollzug ausgesetzt. Korrektur erledigt ist nicht Rückkehr genehmigt. An DNR übergeben ist nicht Entfernung beschlossen. Entfernung beschlossen ist nicht Quellenänderung abgeschlossen.

Auch negative Zustände gehören hinein: keine Quellenmaßnahme, kein Rechtsbehelf, Rückkehrentscheidung offen. Ein leeres Feld unterscheidet nicht zwischen Nicht-Ereignis, Verzögerung und fehlender Zuständigkeit.

Die Akte gibt dem RSO kein Veto, legt keine Angriffsdaten offen und überträgt dem Publikum nicht die Incident Response. Sie sorgt dafür, dass vorläufige Macht einen Inhaber, Umfang, Termin und Abschluss besitzt.

Grenzen des Befunds

Die geprüften Quellen belegen weder eine formelle Board-Annahme noch die Governance Phase noch eine Suspendierung eines RSO nach diesem Modell. Sie erlauben auch kein Urteil über Sicherheit oder Regelbefolgung eines heutigen Betreibers.

Dass der Bericht keine Wiedereinsetzung nennt, beweist nicht, dass künftige Chartas sie nicht regeln können. Es begründet die Forderung, dies vor der Ermächtigung zu tun. Weil der technische Gegenstand der Suspendierung offen ist, behauptet der Artikel nicht, dass Root Hints, Root Zone oder root-servers.net zwingend geändert würden.

Der öffentliche Teil betrifft Befugnis und Zustand. Angriffsrelevante oder legitim vertrauliche Betriebsbeweise dürfen geschützt bleiben.

Quellen

  1. ICANN — The Root Server System Governance Structure, 18. Februar 2026
  2. ICANN — Governance Principles for the Root Server System
  3. Brad Verd — Übergabe des GWG-Abschlussberichts
  4. Tripti Sinha — Antwort der ICANN-Board-Vorsitzenden
  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 — Entwurf des Betriebs- und Finanzplans FY2027–2031
  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