Summary

  • DNSOP opened Working Group Last Call for draft-ietf-dnsop-integration-04 on 24 August 2026, with a scheduled closing date of 7 September. The captured Datatracker state remains In WG Last Call; the draft is not an approved RFC.
  • The draft asks applications to handle more than initial domain control. Expiration, a DNSSEC-status change and removal of an expected record can all require the application to revise its state.
  • A useful conformance test has four transitions: establish, update, delete, and transfer or re-registration. For each, the implementer should identify the trigger, verifier, resulting state and maximum stale interval.
  • AT Protocol handles illustrate periodic, bidirectional revalidation. The draft’s ENS example exposes a different edge: without negative proofs in that path, removing a DNS record does not itself replace an older positive on-chain claim.
  • The four-transition matrix is Daniel Kade’s analytical proposal, not text adopted by the IETF. Its purpose is to make lifecycle behaviour observable without prescribing one implementation.

The deadline is a review event, not a verdict

The DNSOP chairs opened Working Group Last Call on 24 August and set 7 September as the closing date. A 6 September reminder said the call would end the following day. That is the news event. It should not be upgraded into a decision the record does not contain.

The Datatracker page identifies revision 04 as an Internet-Draft intended to be Informational. Its Working Group state is In WG Last Call; its IESG state is only I-D Exists. There is no basis here for calling it an RFC, claiming IETF consensus, or predicting the next state. Last Call is the period in which support, objections and missing cases are meant to become visible.

That restraint matters because the document is guidance about applications that import authority from DNS. A loose account of its own status would be an awkward way to report a draft whose subject is accurate state.

The application inherits a lifecycle, not just a string

An application often presents DNS integration as an onboarding action: publish a TXT record, import a name, verify a handle. The initial success can look like the whole feature. Revision 04 says otherwise.

Its lifecycle section names expiration, a change in DNSSEC status and removal of an expected resource record as events that may alter control or status after integration. Its control section asks how the application knows that only the registrant or an authorised party can establish the binding. Its completeness section warns against arbitrary restrictions such as a static list of favoured top-level domains. Its synchronisation section asks implementations to document how application state is brought back into line with the global DNS, while recognising that constant checking has cost and failure modes of its own.

These requirements point to a state machine. The application does not merely consume a domain-shaped identifier. It takes responsibility for the interval between DNS changing and its own interpretation changing.

The article’s proposed minimum test is therefore four transitions:

Transition Evidence question Observable result
Establish What proves current registrant control or delegated authority? A new binding is accepted or rejected.
Update What newer assertion supersedes the old one? The application changes the destination or identifier.
Delete How does absence become evidence, and when? The binding becomes invalid, empty or explicitly stale.
Transfer or re-registration How does a new registrant displace the prior binding? Old application authority ends; the new controller starts cleanly.

For every row, a conformance statement should name the trigger, verifier, cache or refresh rule, resulting application state, maximum stale interval and manual recovery route. This matrix is an inference from the draft’s requirements, not language adopted by DNSOP. It deliberately avoids mandating one protocol. It asks each protocol to expose the transitions it already claims to manage.

AT Protocol closes the loop by looking again

The draft’s AT Protocol example separates a stable account identifier from a mutable, human-readable domain handle. The protocol’s own handle specification requires bidirectional verification: resolving the handle must identify the DID, and resolving the DID document must link back to the handle. Anyone can publish a one-way alias; the reverse check prevents that alias from becoming a trusted binding by itself.

The specification also defines a failure state. When a known handle is confirmed to no longer resolve, it should be marked invalid. Services can cache resolution results, but they should re-resolve periodically. That makes deletion legible through a future lookup, even though DNS changes do not arrive as guaranteed application events.

The interval is still a policy choice. A long cache is cheaper but preserves a wrong display longer. Aggressive re-resolution shortens the window but increases resolver traffic, exposes the service to transient DNS failures and may create operational load. The important point is that the mechanism has a negative outcome and a path for reaching it.

This example also prevents an overbroad conclusion. AT Protocol says DNSSEC is not required for its handle resolution. The draft is not a universal command to deploy DNSSEC. It is a demand to explain how the chosen integration establishes authority and follows later change.

ENS shows why a new positive is not the same as a deletion

The ENS example follows another architecture. A DNSSEC proof can be submitted to establish DNS-derived state on-chain. A newer positive proof can supersede an older one, and when control of the name changes, a new registrant can submit a proof for its own record.

Then the draft states the awkward case. ENS does not currently support NSEC negative proofs in the described path, so non-existence or removal of the DNS record cannot be proven on-chain. An old positive claim therefore remains until a newer positive proof replaces it. Deleting the underlying record, or allowing the name to lapse, does not by itself deliver a revocation event to the on-chain state.

This limitation is not new to revision 04. It already appears in revision 03; the 03-to-04 comparison should stop readers from treating it as a last-minute discovery. Revision 04’s change log describes updated completeness text.

ENS’s own DNS import guidance supplies the operator view. A new owner can change the _ens TXT record and use the interface’s refresh action to update the ENS side. That is a way to submit newer positive state. It is not proof that record removal alone is observed.

Nor should this example be inflated into a claim about every ENS record or every DNS integration. It describes one proof path and one documented limitation. Its analytical value is narrower and stronger: any system that knows how to accept a positive assertion must separately say how it learns that the assertion has ceased to exist.

Deletion measures who bears the stale-state risk

Creation is commercially attractive. A smooth verification screen brings a user, name or asset into the application. Deletion produces no comparable growth metric. It consumes resolver queries, proof-verification work, state transitions, support time and sometimes on-chain transactions. The incentive to make establishment visible and revocation implicit is structural, even without misconduct.

The resulting risk is not identical in every application. A stale display name may confuse readers. A stale routing destination can misdirect traffic. A stale binding used as a credential or control signal can preserve authority after its DNS basis has vanished. The test must therefore describe the application consequence, not just whether a record can be fetched.

Expiry should also be handled carefully. ICANN’s gTLD lifecycle shows multiple stages between ordinary registration, expiry and possible availability to another registrant. Policies vary. The governance requirement is not an invented universal countdown; it is a declared rule for when this application changes state at each relevant registration or DNS event.

This is where Heng Lu’s preference for a minimum initial specification with local future decisions becomes useful. A shared four-transition test can be small and portable. Each application can choose its resolver, proof system, cache duration and recovery process. The common obligation is to make the choices inspectable.

The companion principle that running code is primary sharpens the evidence standard. “DNS verified” is a feature label. A test that publishes a record, changes it, deletes it and re-registers the name is behaviour. The latter shows where authority really moves.

Sources

  1. DNSOP Working Group Last Call
  2. DNSOP Last Call reminder
  3. IETF Datatracker record
  4. IETF document history
  5. DNS integration draft, revision 04
  6. DNS integration draft, revision 03
  7. Official revision 03–04 comparison
  8. DNSSEC protocol modifications, RFC 4035
  9. AT Protocol handle specification
  10. AT Protocol repository synchronization
  11. ENS on-chain DNS import guidance
  12. ICANN gTLD lifecycle
  13. Heng Lu — Minimum initial specification and localized future decision
  14. Heng Lu — Running Code Primary