Summary

  • A 16 October public comment asks ICANN to reconcile its DNSSEC delegation-signer (DS) automation assessment with RFC 10026, the IETF’s published operational guidance.
  • The June report says automation should stop under a registry update lock in one section, but later says registry-side automation may continue; its hard requirement HR-4 names only the registrar-side lock.
  • ICANN says it will consider comments and may update the assessment. The proceeding closes on 23 November, with a comment report due on 7 December; no final decision or contract language has been announced.

The question is not whether DNSSEC should be automated. It is which actor a registration lock constrains when a parent-zone DS record is changed. That distinction is now at the centre of a public comment on ICANN’s security and stability assessment of DNSSEC DS automation.

Quynh Nguyen’s submission, posted on 16 October, says the assessment covers the main security and stability concerns but should state one consistent position on serverUpdateProhibited. The comment is offered in an individual capacity; it is not an ICANN finding or evidence of community consensus. Its request matters because ICANN says the assessment will form the technical basis for a Fast-Track Registry Services Evaluation Process (RSEP) for registry operators that want to automate DS maintenance.

The report prepared by Interisle Consulting Group is dated 23 June 2026. In section 4.4, it adopts the view that automated DS maintenance should be suspended when serverUpdateProhibited is present. The section notes that the IETF draft then took the opposite position for registry-led automation, on the ground that the status requires an EPP server to reject registrar update requests but does not bar the registry from making its own changes.

That draft became RFC 10026, published as Best Current Practice 246 in July. Section 6.1(2) says that when the registry performs DS maintenance, automation must not be suspended solely because serverUpdateProhibited is set. Section 6.2.1 explains the actor distinction: the status prevents a registrar from applying an update through EPP, while registry-side automation remains possible; notification to the registrar helps make such changes visible.

There is also a tension inside the assessment itself. Section 4.7 says deployments may proceed under both clientUpdateProhibited and serverUpdateProhibited, and section 6.1 repeats that the two locks do not require routine maintenance to stop when the registrar can opt out of registry-led automation. Yet HR-4 expressly says only that clientUpdateProhibited must not alone suspend automation. Nguyen asks ICANN to make the rule explicit and align it with RFC 10026.

The timing adds another reference point. On 31 August, the SSAC published SAC126v2, saying it had aligned its advice with RFC 10026, that the standard resolved the earlier Section 4.4 question, and that SAC126 Version 1 was retired. The June assessment therefore predates both the final RFC and the updated SSAC advice it assesses.

The comment raises more than the lock issue. It asks for clearer criteria and retry schedules when an authoritative nameserver is deemed permanently unreachable, treatment of rollovers delayed by inconsistency, disclosure of the downstream consequences of removing a DS record, and minimum notification and audit records for successful and rejected updates. These requests remain proposals from one commenter.

ICANN’s proceeding page says comments will be summarized, considered and may lead to an assessment update and addendum. Submissions close on 23 November 2026; the report is due on 7 December. ICANN has said draft Fast-Track amendment language will be presented in a later proceeding. Neither the assessment nor the comment has approved a deployment or settled that future contract text.

Sources