Zusammenfassung

  • ICANN bittet um Rückmeldung, ob die Sicherheits- und Stabilitätsbewertung der DNSSEC-DS-Automatisierung die Risiken erfasst und ausreichende, verhältnismäßige und umsetzbare Schutzmaßnahmen vorsieht.
  • Ein positives Ergebnis setzt sieben verbindliche Anforderungen und sieben Offenlegungen je Betreiber voraus. Es ist keine pauschale Freigabe für jede Implementierung.

Die Wirkung von Registrierungssperren ist die konkrete Frage, die ICANN vor einem beschleunigten DNSSEC-Verfahren klären muss. Die öffentliche Konsultationsankündigung nennt Frist und Prüfungsumfang.

Die auf den 23. Juni datierte Bewertung betrachtet einen klar abgegrenzten Ablauf. Ein Betreiber der Child-Zone veröffentlicht CDS- oder CDNSKEY-Einträge. Der Parent-Agent — meist Registry oder Registrar — prüft diese und kann daraufhin den DS-Eintrag in der Parent-Zone ändern. Behandelt werden laufende Pflege, erstmalige Einrichtung und der Übergang zu einer unsicheren Delegation. Push-Benachrichtigungen, externe APIs und CSYNC bleiben außen vor. Die Schlussfolgerung gilt daher weder für jede Art der Delegationsänderung noch für die konkrete Implementierung eines bestimmten Anbieters. Der 41-seitige Interisle-Bericht sieht keine erheblichen Sicherheits- oder Stabilitätsprobleme, sofern die beschriebenen Anforderungen eingehalten werden.

Sieben harte Anforderungen bilden die Voraussetzung. Vor einer Änderung muss der Parent prüfen, dass jeder neue DS zu einem DNSKEY der Child-Zone passt und der Schlüssel den DNSKEY-Satz signiert. Außerdem sind CDS- und CDNSKEY-Antworten aller autoritativen Nameserver zu vergleichen; bei Abweichungen wird abgebrochen. Eine manuelle Verwaltungsoberfläche muss bestehen bleiben. Registrar müssen der Automatisierung widersprechen können. Das Verfahren muss ein authentifiziertes Signal zur Entfernung aller DS-Einträge korrekt verarbeiten und den Registrar benachrichtigen, wenn die Registry selbst die Änderung vornimmt.

Sieben weitere Punkte müssen Betreiber dokumentieren: etwa Prüftakt, erwartbare Reaktionszeit, Umgang mit mehreren Signierern und die Empfänger von Meldungen. Vier zusätzliche Praktiken werden empfohlen, sind aber keine Bedingung des positiven Ergebnisses.

Damit trennt der Bericht den gemeinsamen Mindeststandard von lokalen Betriebsentscheidungen. Die Übereinstimmung der Nameserver gemäß RFC 9975 ist eine Pflicht. Wie oft geprüft und wer bei Erfolg, Ablehnung oder Abweichung informiert wird, hängt von der Architektur ab. Diese Angaben sind relevant, weil sie bestimmen, wie lange ein fehlerhafter DS-Eintrag unbemerkt bleiben kann und wer die Wiederherstellung anstößt. Die einschlägigen RFCs schreiben keinen einheitlichen Meldeweg für jedes Ergebnis vor. Ein technisch überprüfbares Verfahren ist deshalb noch keine Garantie, dass Betroffene eine verwertbare Rückmeldung erhalten.

Der zeitliche Abstand eröffnet eine konkrete Prüfspur. Der Bericht trägt das Datum 23. Juni; RFC 10026 wurde im Juli als Best Current Practice der IETF veröffentlicht. Die aktuelle ICANN-Verfahrensseite führt RFC 10026 inzwischen als Begleitmaterial auf; der Berichtstext mit Datum Juni bewahrt jedoch die frühere Entwurfs-Chronologie. RFC 10026 behandelt Annahmekontrollen, Rückmeldungen, Registrierungssperren und konkurrierende Updates. Das macht die frühere Bewertung nicht automatisch falsch. Die Konsultation kann aber klären, wie ihre sieben Anforderungen und Offenlegungen zum veröffentlichten BCP 246 stehen und welchen Nachweis spätere Anträge hierzu liefern sollen.

Die Abweichung zeigt sich in der Sperrenanalyse des Berichts. Er übernimmt SAC126: serverUpdateProhibited soll Registry-geführte Automatisierung stoppen, während clientUpdateProhibited allein sie nicht anhalten soll. Die endgültige IETF-Fassung vertritt zur Registry-Sperre die Gegenposition: RFC 10026 sagt, dass Registry-eigene Automatisierung nicht allein wegen dieses Status ausgesetzt werden darf, den die Registry selbst überschreiben kann. Ein Opt-out des Registrars ist der Kontrollweg für einen entgegenstehenden Wunsch. Die konsolidierte Liste der harten Anforderungen nennt die Client-Sperre ausdrücklich, enthält aber keine entsprechende Registry-Sperren-Regel. Da die aktuelle ICANN-Seite RFC 10026 aufführt, können Kommentierende fragen, welche Regel spätere Anträge und Vertragstexte anwenden werden.

Der ICANN-Vorstand hatte im September 2025 einen beschleunigten RSEP-Weg für Registries angeordnet, sofern ICANN keine erheblichen Sicherheits- oder Stabilitätsprobleme feststellt. Für Registrare gilt eine andere Grenze: Sie dürfen den Dienst ohne ICANN-Zustimmung einführen. Die RSEP-Regeln sehen weiterhin eine vorläufige Prüfung vor und erlauben eine Überweisung an ein technisches Gremium. Die Bewertung ist somit ein gemeinsamer technischer Maßstab für spätere Registry-Anträge, keine Genehmigung für einen bestimmten Betreiber und noch keine geltende Vertragsklausel. Der Vorstandsbeschluss und die RSEP-Regeln legen die Zuständigkeiten fest.

Die Kommentare können drei konkrete Fragen prüfen: Entsprechen die Pflichtanforderungen dem nun veröffentlichten BCP? Erklären die Offenlegungen Prüfverzögerung, Benachrichtigung und Wiederherstellung so, dass Registranten sie beurteilen können? Und verlangt die spätere Vertragsfassung weiterhin eine Prüfung der jeweiligen Architektur? Da der Vertragsentwurf erst nach dieser Konsultation folgt, werden der Bericht vom Dezember und die nächste Runde getrennte Belege dafür liefern, wie aus einer technischen Bewertung ein Zulassungsverfahren wird.