Zusammenfassung

  • Eine am 16. Oktober eingereichte Stellungnahme bittet ICANN, ihre Bewertung der DNSSEC-DS-Automatisierung mit RFC 10026, der inzwischen veröffentlichten IETF-Betriebsleitlinie, abzugleichen.
  • Der Bericht vom Juni verlangt an einer Stelle den Stopp bei einer Registry-Sperre, erklärt später aber, dass Registry-seitige Automatisierung fortgesetzt werden kann. Die verbindliche Vorgabe HR-4 benennt ausdrücklich nur die Registrar-Sperre.
  • ICANN will die Beiträge prüfen und könnte die Bewertung aktualisieren. Die Frist endet am 23. November, der Kommentarbericht ist für den 7. Dezember vorgesehen; eine abschließende Entscheidung oder Vertragsfassung liegt noch nicht vor.

Im Mittelpunkt steht nicht die Grundsatzfrage, ob DNSSEC automatisiert werden sollte. Entscheidend ist, welchen Akteur eine Registrierungssperre bindet, wenn ein DS-Eintrag in der übergeordneten Zone geändert wird. Genau dazu fordert eine Stellungnahme an ICANNs Sicherheits- und Stabilitätsbewertung der DS-Automatisierung Klarheit.

Quynh Nguyen hält in ihrem Beitrag vom 16. Oktober die Behandlung der wesentlichen Sicherheits- und Stabilitätsfragen für gelungen, verlangt aber eine einheitliche Aussage zu serverUpdateProhibited. Sie reicht den Beitrag ausdrücklich in eigener Funktion ein. Er ist damit weder eine Feststellung von ICANN noch Ausdruck eines Community-Konsenses. Die Auslegung kann dennoch relevant werden: ICANN will die Bewertung als technische Grundlage für einen Fast-Track im Registry Services Evaluation Policy-Verfahren (RSEP) für Registry-Betreiber nutzen.

Der Bericht der Interisle Consulting Group trägt das Datum 23. Juni 2026. Abschnitt 4.4 übernimmt die Auffassung, dass die automatisierte DS-Pflege bei gesetztem serverUpdateProhibited ausgesetzt werden sollte. Zugleich beschreibt der Abschnitt die gegenteilige Position des damals herangezogenen IETF-Entwurfs für Registry-geführte Abläufe: Der EPP-Server muss Änderungsanträge des Registrars zurückweisen; die Sperre hindert die Registry jedoch nicht daran, selbst Änderungen vorzunehmen.

Aus dem Entwurf wurde im Juli RFC 10026, Best Current Practice 246. Abschnitt 6.1(2) legt fest, dass eine Registry ihre DS-Pflege nicht allein wegen serverUpdateProhibited aussetzen darf. Abschnitt 6.2.1 erklärt die Akteursgrenze: Der Status verhindert EPP-Änderungen durch den Registrar, nicht die Registry-seitige Automatisierung. Eine Benachrichtigung des Registrars soll solche Änderungen nachvollziehbar machen.

Auch im Bericht selbst stehen Aussagen nebeneinander, die nicht ohne Weiteres zusammenpassen. Abschnitt 4.7 lässt die Fortsetzung bei clientUpdateProhibited und serverUpdateProhibited zu; Abschnitt 6.1 sagt ebenfalls, dass diese Sperren die routinemäßige Wartung nicht stoppen müssen, sofern der Registrar die Registry-Automatisierung abwählen kann. HR-4 formuliert ausdrücklich aber nur, dass clientUpdateProhibited allein kein Grund zum Aussetzen sein darf. Nguyen fordert deshalb eine eindeutige, mit RFC 10026 vereinbare Regel.

Ein weiterer zeitlicher Bezugspunkt ist SAC126v2 vom 31. August. Der SSAC erklärt, seine Empfehlungen an RFC 10026 angepasst zu haben; der Standard löse die Frage aus Abschnitt 4.4 der früheren Version. SAC126v1 sei abgelöst. Die Juni-Bewertung entstand somit vor der endgültigen RFC und vor dem aktualisierten SSAC-Rat.

Die Stellungnahme bittet außerdem um nachvollziehbare Kriterien und Wiederholungsintervalle, bevor ein autoritativer Nameserver als dauerhaft nicht erreichbar gilt; um Regeln für durch uneinheitliche Antworten verzögerte Schlüsselwechsel; um Hinweise auf Folgen einer DS-Entfernung; sowie um Mindestanforderungen an Benachrichtigungen und Prüfprotokolle bei erfolgreichen wie abgewiesenen Änderungen. Das sind Vorschläge einer einzelnen Person, keine beschlossenen Pflichten.

Die ICANN-Verfahrensseite kündigt eine Zusammenfassung der Stellungnahmen, deren Prüfung und eine mögliche Aktualisierung mit Nachtrag an. Die Frist endet am 23. November 2026; der Bericht soll am 7. Dezember vorliegen. Der Vertragsentwurf für den Fast-Track soll später separat zur Kommentierung gestellt werden. Weder die Bewertung noch der Beitrag genehmigt einen Einsatz oder legt künftige Vertragsbedingungen fest.

Quellen