Summary

  • RFC 10026 treats clientUpdateProhibited and serverUpdateProhibited as actor-scoped controls, not proof that every route to a domain's DS data is frozen.
  • Continuing authenticated, validated DS maintenance can protect continuity during key and algorithm changes; the lock, request, acceptance checks, publication and notification remain separate receipts.
  • A reassuring “locked” badge proves neither that no data moved nor that a change was authorised. Operators need an actor-aware decision record and an independent recovery route.

The domain-management portal says “locked.” Later, the DS record in the parent is different. That sequence can describe a breach, an error or exactly the maintenance the domain needed to stay secure. The word on the screen cannot decide among them.

An update lock sounds comprehensive because everyday language supplies the missing scope. Locked means closed. In a registration system, however, a status belongs to an actor model and a command path. It may reject a request from the sponsoring registrar while leaving a registry's own locally authorised action untouched. It may protect the customer-portal route while remaining removable by the registrar that set it.

RFC 10026, co-authored by Steve Sheng and Peter Thomassen and published as an IETF Best Current Practice in July 2026, turns that distinction into operational guidance for automated DNSSEC Delegation Signer maintenance. Its surprising recommendation is not that locks are unimportant. It is that a lock must not be credited with power it does not have.

A status name is not its authority boundary

RFC 5731 gives EPP domain statuses a grammar of control. A status prefixed with client is managed by the sponsoring client, normally the registrar. A status prefixed with server is managed by the EPP server, normally the registry. Both clientUpdateProhibited and serverUpdateProhibited say that requests to update the object must be rejected, except a request to remove the status.

The symmetry ends there. The standard also says a client may not alter server-set status, while a server may alter or override client-set status subject to local policy. The same word “update” therefore sits inside two different control relationships.

For a client update lock, the protected path is chiefly a request sent as the sponsoring registrar's EPP client. The registrar can remove the lock, and the registry is not made incapable of action by a status the registrar set. The lock can reduce accidental or malicious customer-portal changes without protecting the registrant from a compromised registrar or registry.

A server update lock is stronger against the registrar. The registrar's update request must be rejected. Yet the status still does not say that the server operator has cryptographically erased its own ability to change state. RFC 5731 allows server-operator action and makes the result subject to server policy.

This is the first receipt an operator needs: not “lock present,” but status setter, current status, protected command class and actors still technically able to act.

DNSSEC turns “set and forget” into a continuity risk

Before DNSSEC, a domain registration could often be configured, locked and left alone. DNSSEC introduces state that must sometimes move to remain safe. A key can be rolled. A signing algorithm can be retired. A child operator can change. The parent DS set must follow without losing the validation path.

A universal freeze would convert a security control into an expiry mechanism. If the child has prepared a replacement key but the parent cannot update its DS data, validators can eventually be left with a trust reference to a key the child no longer uses. A lock that blocks maintenance forever can preserve the old value while destroying the function that value was meant to secure.

RFC 7344 lets a child publish CDS or CDNSKEY information to request parent-side DS maintenance. RFC 9615 adds authenticated bootstrapping for a delegation that does not yet have a DS path. These are not anonymous suggestions. They are protocol evidence whose authenticity and safety must be checked.

RFC 10026 therefore says automated DS maintenance must not be suspended on the basis of a registrar update lock alone. When the registry performs the automation, it must not suspend the process on the basis of a registry update lock alone. Initial bootstrapping and later rollovers receive the same treatment.

The rule does not say “ignore locks.” It says the ordinary lock is orthogonal to an authenticated maintenance path that its own actor model does not prohibit. A proprietary out-of-band lock may have a different scope. Its operator must document that scope rather than borrow it from an EPP label.

The maintenance path still has several gates

Allowing a path to remain open is not the same as approving every request that reaches it. RFC 10026 places acceptance checks before the parent changes anything.

The parental agent must establish unambiguous intent. Any CDS and CDNSKEY records must refer to the same keys, and the relevant state must be plausibly consistent across all authoritative nameservers in the delegation. It must then project the resulting DS set and verify that at least one valid DNSSEC path would remain. If either test fails, the update is cancelled.

Those checks make five different claims visible:

  1. the lock has a defined scope;
  2. a child-side request exists;
  3. the request is authenticated and coherent;
  4. the proposed parent state preserves validation;
  5. the parent actually published the accepted result.

No claim inherits the others. A lock does not authenticate CDS. Valid CDS does not prove cross-server consistency. Consistency does not prove continued validation. Passing the checks does not prove publication. Publication does not prove every resolver has left its cache of the previous DS set.

This separation is especially important after Article 40's all-authoritative-server test. That test asks whether the child service expresses one coherent request. The lock question begins elsewhere: which administrative actor and command path a registration status can restrain. One evidence set cannot substitute for the other.

A registrar lock cannot defend against the registrar

The most uncomfortable part of RFC 10026's rationale is also its most useful. A client update lock is unsuitable as protection against illegitimate action by the registrar or registry. The registrar can remove its own status. The registry can override it under local policy. An attacker who controls either high-privilege actor is not stopped merely because the status was visible a moment earlier.

That does not make the lock worthless. It makes its threat model honest. The lock can stop an ordinary update command while present. It can reduce mistakes and account-level abuse. It cannot become proof that the organizations operating the command path were technically unable to act.

The distinction matters in incident review. A screenshot of a green lock badge is evidence of presentation state at a time. It is not evidence of the server-side status readback, the actor that later submitted a change, the authorization used, the acceptance checks run or the final parent publication.

A stronger product may require an out-of-band ceremony, multiple approvers or a delayed release before the registry acts. That can materially change the control. But “registry lock” is then a product contract whose precise override and emergency semantics must be preserved. It should never be conflated with the two EPP status values merely because the vocabulary overlaps.

The change needs witnesses, not surprise

In the registrant–registrar–registry model, registry-side automation can legitimately change DS data without a registrar update command. That creates a visibility problem even when the action is correct.

RFC 10026 answers with separate reporting channels. A registry performing DS automation should inform the registrar through the EPP Change Poll extension defined by RFC 8590 or a similar mechanism. Relevant contacts should be notified for significant updates and deactivation. The registrant or designated party should be able to inspect the active DS configuration in the management portal.

The parental agent should also retain a structured decision record: timestamp, triggering CDS/CDNSKEY data, notification channel, authoritative nameservers consulted, verification results, decision outcome, and the DS set applied or reason for cancellation.

That ledger converts an apparently impossible sentence—“the locked domain changed correctly”—into an auditable sequence. It shows that the lock remained in force on its intended path, a separate authenticated signal entered a different path, all safety checks passed, the competent parent actor acted, the registrar was told and the public DS state changed.

If any link is missing, the conclusion narrows. An absent notification proves a reporting failure, not automatically an unauthorised DS set. A changed DS set proves parent publication, not the authenticity of the request. A portal badge proves user-interface state, not the EPP server's decision.

Recovery must not depend on the same key

Automation also cannot be the only door. The child may lose the signing key needed to authenticate a rollover. A provider in a multi-operator setup may refuse to cooperate. A DNS operator may not support CDS/CDNSKEY at all.

RFC 10026 requires registries and registrars to keep another DS-maintenance channel available for those cases. The recovery path can be manual, but it must be able to restore control when in-band evidence is no longer producible.

This is not an exception that weakens automation. It defines its boundary. A protocol that authenticates with the current key cannot prove a transition after that key is destroyed. The institution must not pretend that a missing cryptographic receipt can be manufactured by repeating the same failed mechanism.

The recovery record should name the human or organizational authority, the out-of-band checks, the requested DS state, any period in which automation is suspended, the condition for resumption and the later parent readback. Otherwise “manual override” becomes another label with undisclosed scope.

Sheng's name marks contribution, not control

The RFC Editor records Steve Sheng and Peter Thomassen as the two authors of RFC 10026. Sheng's IETF Datatracker record also lists RFC 7485 and RFC 7710. ICANN's official archive identified him in 2022 as Senior Director, Policy Development Support; his current public biography says he concluded fifteen years at ICANN in 2024 and holds a Carnegie Mellon doctorate in Engineering and Public Policy.

These facts locate a documented contribution at the intersection of protocols and institutional operations. They do not make Sheng the operator of a registry, registrar, parent zone or deployment. They do not turn an IETF consensus document into personal command over domain holders. Nor do they prove universal implementation.

The authorship boundary mirrors the lock boundary. A name can identify a contribution without transferring operational authority. A status can identify a prohibition without binding every actor in the system.

The real proof is an actor-aware decision receipt

An operator should be able to reconstruct a DS change from one joined record. Begin with the public and server-side lock status, its setter and timestamp. Add the submitting actor and command path. Preserve the CDS/CDNSKEY material, authentication result, all-authoritative consistency check, projected-validation test, local acceptance policy and decision.

Then add publication time, resulting parent DS set, relevant TTL, registrar and registrant notifications, resolver-visible verification and recovery channel. Secrets and unnecessary personal data do not belong in the record. The evidence needed to explain authority and outcome does.

This is running-code primacy applied to a reassuring badge. The specification supplies a common minimum: do not let an ordinary registration lock accidentally destroy authenticated DNSSEC continuity, and do not let automation erase recovery. Local operators can choose stronger lock products, additional checks and different notification policies. They must say which path each choice binds.

The durable rule is narrower than “locked means safe” and more useful: a lock is evidence only inside its documented actor and command boundary. Everything beyond that boundary needs its own receipt.

Sources