Zusammenfassung

  • Das Wachstum neuer gTLDs, Portfolios mit Hunderten Domains und häufigere DNSSEC-Aktualisierungen veränderten die Arbeitslast, die das RZMS bewältigen musste.
  • Der Neuaufbau brachte Freigabeschwellen je Antragstyp, parallele Anträge, eine API und unabhängig weiterentwickelbare technische Prüfungen; für passende Regeln und Kontinuität der Konten bleiben die TLD-Verwalter zuständig.

Analyse

Mehr Anträge veränderten die Arbeit

Das frühere RZMS war kein gescheitertes System. Es automatisierte bereits Abläufe, erhöhte die Genauigkeit, verkürzte Bearbeitungszeiten und bot TLD-Verwaltern ein Selbstbedienungsportal für häufige Aufgaben. Der Druck entstand durch eine andere Arbeitslast: Das neue-gTLD-Programm vergrößerte die Zahl der Delegierungen, manche Organisationen verwalteten Portfolios mit Hunderten Domains, und DNSSEC-Schlüssel mussten häufiger aktualisiert werden.

Im Mai 2022 erklärte Davies, dass ICANNs Engineering- und IT-Team den modularen Neuaufbau beschlossen hatte. Ein kleines, fachübergreifendes Team arbeitete mehrere Jahre daran. Sein Bericht beschreibt Anlass und Betriebsentscheidungen, behauptet aber nicht, er habe die Plattform allein entwickelt. Das Ziel war, neue Antragsmuster aufzunehmen, ohne jede Weiterentwicklung an einen festen Ablauf zu binden.

Modernisierung für ein größeres Arbeitsvolumen

Das ältere RZMS hatte bereits viele Abläufe automatisiert, die Genauigkeit verbessert, Bearbeitungszeiten reduziert und ein Selbstbedienungsportal für häufige Aufgaben angeboten. Der Kontext veränderte sich: Das neue-gTLD-Programm vergrößerte die Zahl der Zonen, manche Organisationen verwalteten Hunderte Domains, und wiederkehrende DNSSEC-Schlüsseländerungen erzeugten neue Antragsmuster. Laut Davies entschied das Engineering- und IT-Team von ICANN, die Plattform modular neu aufzubauen. Ein kleines, bereichsübergreifendes Team setzte den Plan um.

Davies schilderte die institutionelle Entscheidung, ohne sich als alleinigen Entwickler darzustellen.

Das IANA-Änderungsprotokoll hält fest, dass die erste neue Version mehr als zwei Freigebende, unterschiedliche Schwellen je Antragstyp, eine API und parallele Anträge unterstützte. Technische Konformitätsprüfungen wurden aus dem Antragsmanagement herausgelöst, damit sie unabhängig weiterentwickelt werden konnten.

Das RZMS ist dennoch nicht die gesamte Entscheidung über die Root Zone. Die IANA beschreibt ihre Aufgaben als Zuweisung von TLD-Verwaltern, Erfassung technischer Delegierungsdaten und Veröffentlichung eines zugehörigen Registers. Die Übersicht zur Root Zone unterscheidet die Root Zone Database mit Angaben zu Verwaltern, Technik und Kontakten von der separat verfügbaren DNS-Zonendatei. Eine Freigabe im System bringt einen Antrag voran; sie ersetzt weder die Prüfung noch die Implementierung.

Mehr Sicherheit, aber auch ein Rückweg ins Konto

Mehr-Faktor-Authentisierung (MFA) war beim Start 2022 noch nicht verpflichtend. Davies verwies darauf, dass eine Lösung weltweit funktionieren müsse und manche Kunden möglicherweise jahrelang nicht auf ihr Konto zugriffen. Gerade bei selten genutzten Konten ist Wiederherstellung ein Teil der Sicherheitsfrage: Ein berechtigter Vertreter muss nach Verlust eines Geräts oder von Zugangsdaten zurückkehren können.

Die Studie zum Root-Zone-Änderungsprozess von 2022 zeigte unterschiedliche Einschätzungen. 82 Prozent der Befragten hielten die damaligen Sicherheitsvorkehrungen für ausreichend; 18 Prozent nannten mögliche Schwächen, einige davon empfahlen MFA. Diese Werte beschreiben die Teilnehmenden dieser Studie, keine Gesamterhebung über TLD-Verwalter oder den heutigen Stand. Die Studie behandelte außerdem, dass Anträge damals nicht ausschließlich einer festen Liste benannter Kontakte vorbehalten waren. Davies verwies auf diese Rahmenbedingungen, als er die Zurückstellung einer allgemeinen MFA-Pflicht erläuterte.

Im Januar 2025 stellte Davies MFA und Identitätsprüfung als freiwillige Funktionen vor. Die aktuelle IANA-Hilfe, zuletzt im Juli 2026 aktualisiert, verlangt Identitätsprüfung für die Aktivierung von MFA und den API-Zugang, nicht aber für die übrige Nutzung des RZMS. Die API erlaubt nur Aktionen, für die ein Konto berechtigt ist. Mit der OTE-Umgebung können Integrationen getestet werden, ohne Änderungen in der Produktion vorzunehmen; das beschreibt der API-Leitfaden.

Die Wiederherstellung hat einen Datenschutzpreis. Ein externer Anbieter speichert Ausweis- und Selbstporträtbilder höchstens sieben Tage. Die IANA behält während der aktiven Kontolaufzeit den amtlichen Namen, das Geburtsdatum und das Prüfergebnis. Stärkere Identitätsprüfung kann die Rückkehr in ein Konto erleichtern, bringt aber persönliche Daten in die Betriebsarchitektur ein.

Mit der Skalierung wächst die Verantwortung der Verwalter

Konfigurierbare Schwellen und parallele Anträge machen den Dienst anpassungsfähiger. Die Software kann jedoch keine passende Freigaberegel für jede Organisation wählen. TLD-Verwalter müssen ihre Berechtigten aktuell halten, die nötige Zahl von Freigaben je Antragstyp festlegen und einen Wiederherstellungsweg für selten genutzte Konten vorsehen. Zu wenige Freigebende schaffen einen Engpass; zu viele können routinemäßige Änderungen verzögern.

Die API erweitert den Ablauf um programmatische Nutzung, umgeht aber keine Kontoberechtigungen. In IANAs Operational Test and Evaluation-Umgebung lassen sich Integrationen vor dem Produktionseinsatz testen. Technische Konformitätsprüfungen bleiben ebenfalls von der Autorisierung getrennt: Eine technisch korrekte Konfiguration genehmigt keinen Antrag, und eine Freigabe ersetzt weder Prüfung noch Umsetzung.

Das RZMS ist nur ein Teil der Root-Zone-Verwaltung. IANA weist TLD-Verwalter zu, erfasst technische Delegierungsdaten und veröffentlicht die Root Zone Database, die von der DNS-Root-Zonendatei getrennt ist. Das Änderungsprotokoll vom Juni 2026 führt Version 3.6.1 auf. Der bleibende Beitrag des Neuaufbaus ist ein anpassbarer Ablauf, keine Garantie für eine gute Konfiguration in jeder Organisation. Entscheidend ist, ob lokale Freigaberegeln, Kontowiederherstellung und technische Tests mit der tatsächlichen Arbeitslast Schritt halten.

Quellen