Summary

  • ACSP suggestion 2026.1 requested automatic updates of DNSSEC DS records. ARIN answered on 21 January that this would be beneficial but would require work on its provisioning system; it referred the idea for prioritization and closed the suggestion. Closure is not a release notice.
  • ARIN's current DNSSEC instructions describe authorized DS changes in ARIN Online, while its reverse-DNS guide also points holders to Reg-RWS. An authenticated API command is machine-friendly, but it is not the same trust path as a parent automatically acting on a child-zone CDS or CDNSKEY signal.
  • RFC 7344, RFC 8078 and RFC 9615 explain ways to carry and validate those signals, including the harder first-use case. None establishes which method ARIN has deployed or promised to deploy.
  • A defensible future service would make the authorization and state transition inspectable: eligible delegation, signal and validation method, holder control, accepted or rejected change, parent publication and correction. That is an editorial test, not a description of an existing ARIN feature or a reported DNSSEC incident.

The ticket stopped before the trust boundary

The request is short. Brandon Applegate asked ARIN on 7 January to support automatic updates of DNSSEC DS records, citing three RFCs and explaining that key rollovers should not require a person to enter ARIN's web interface to change the parent record. ARIN did not dismiss the idea. On 21 January it called the improvement beneficial, identified development work in its provisioning system, referred it to internal prioritization and implementation planning, and marked the suggestion closed. Those verbs matter. They describe acceptance into a planning channel, not acceptance of a particular DS value into the parent zone.

ARIN's public operating instructions still show a different workflow. For a resource holder using ARIN Online, the DNSSEC guide says to select the reverse zones, paste or upload DS text, parse it and apply it. The reverse-DNS guide also describes management through Reg-RWS. A holder can build automation around an authenticated API. In that model, however, the holder or its delegated account presents a command to ARIN. The suggestion asks for something more specific: ARIN, as the parent-side actor, recognizing a DNS signal published by the child and deciding whether that signal is sufficient to change the DS set. The first is account-authorized provisioning; the second is a protocol-mediated transfer of evidence across a delegation boundary.

The distinction is not pedantry. A DS record in the parent zone points a validating resolver toward the key material of a signed child zone. A DNS operator may run that child zone for the number-resource holder, perhaps as an outsourced service. The operator can publish CDS or CDNSKEY records expressing the change it wants. It cannot alone publish into ARIN's parent-side delegation. Nor does an ARIN account with authority to submit a DS value prove that ARIN has built a service that watches and authenticates the child's signal. Each path has a different initiating actor, evidence source, authorization rule and recovery route.

ARIN's software release history records long-standing DNS and delegation capabilities. It does not announce this exact child-signal-driven capability in the reviewed entries. That is a limit on what the public record demonstrates, not proof that no internal prototype, limited test or later plan exists. No public source reviewed for this article reports an ARIN customer's failed rollover, a broken reverse delegation or a current service-level target for automated DS updates. There is no incident to reconstruct.

A signal is not an order

The standards make the trust boundary easier to see. RFC 7344 specifies child-side CDS and CDNSKEY records as a way to communicate desired DS changes. RFC 8078 discusses how a parental agent can process them. For a delegation that is already securely linked, the existing DNSSEC chain can help authenticate a change. For a first-time secure delegation, that chain does not yet exist. Accepting the child's untrusted appearance as its own proof would be circular; the parent must use a separate validation method.

RFC 9615 offers a cryptographically authenticated bootstrapping signal through the child's nameserver operator. It is a meaningful answer to the first-use problem, but not a magic switch that every parent can flip for every reverse zone. The RFC describes validation against the nameservers actually delegated by the parent and notes a concrete limit: wholly in-domain nameservers cannot supply the necessary pre-existing trust path for this bootstrapping method. A future ARIN implementation would have to state its supported cases and its alternative for excluded ones. The RFC defines a method; it does not state that ARIN has chosen, implemented or tested it.

The same care applies after the first DS exists. A routine key rollover can be legitimate, but a parent still needs to know which old and new records are intended, whether the signal is consistently served by the delegated nameservers, and whether an authorized holder has opted into a particular automatic path. A move between DNS operators adds another timing problem: the old operator may still serve a valid old zone while the new operator prepares the replacement. A removal request is more consequential again, because removing the DS can make the child insecure from the parent's perspective.

Those cases may share transport but should not silently share one approval policy.

RFC 9859 adds a useful notification mechanism. A parent-side agent can be prompted to check CDS or CDNSKEY instead of relying solely on a periodic scan. The notification says, in effect, “look now.” It is not the same as “publish this DS,” and a successfully delivered notification is not evidence that ARIN accepted a record, changed a parent zone or that resolvers have seen the change. Discovery, validation, decision, publication and external observation remain five distinguishable states.

That separation also prevents the wrong reading of “automatic.” Automation can remove a repeated manual copy-and-paste step; it cannot remove the need to define who is entitled to propose the change. In reverse DNS, the number-resource holder, its ARIN account, a contracted DNS operator and the parent-zone publisher may be four different parties. The registry has a narrow but powerful job: maintain the authoritative delegation consistent with the right holder's instructions and a disclosed verification rule. The DNS operator has an equally real job: keep the child zone signed and available through the transition.

Neither role becomes the other merely because a CDS record exists.

The evidence a holder should be able to retrieve

If ARIN advances this service, its public contract should start with scope, not with a green “automation” badge. Which reverse zones are eligible? Is automatic processing opt-in, opt-out or enabled by another explicit authorization? Does it cover maintenance of an existing secure delegation, first-time bootstrapping, removal, or some subset? Which party may enable and disable the path for a resource? How are a resource reassignment and an outsourced DNS-operator change handled? Those questions decide who can speak for the child before any parser interprets its records.

For an individual change, an operator needs a compact receipt. It would identify the delegation and the version of the rule applied, the old and proposed DS sets, the signal type and observation time, the delegated nameservers tested, the validation outcome, the holder-control basis, the accept or reject decision, the parent publication version and time, and a correction or rollback route. Secret account material, private keys and personal contact details need not be public. A holder-accessible record and privacy-safe aggregate reporting can expose the transition without turning a DNS operation into a disclosure of credentials.

The receipt's final line should not pretend to speak for the whole Internet. ARIN could show when its authoritative parent-side record changed and how it independently checked that publication. A validating resolver may continue using cached data until its own timing rules allow or require a refresh. A customer's service outcome also depends on its child-zone state and applications. The parent can be accountable for its publication without claiming control over every downstream cache. Conversely, a resolver's old answer cannot alone establish that ARIN failed to publish.

There is a mundane economic reason to get this right. Reverse DNS is often treated as ancillary because it does not itself carry a packet. Yet an operator's mail, abuse handling, migration plan and customer due diligence may depend on the delegation remaining coherent. A delayed or ambiguous DS handoff can be expensive even without a large outage. The public record here does not show such a loss; it shows a design question worth resolving before an automated path can be called complete.

Sources