Summary

  • draft-hoffman-duj-06 replaces informal DNS-edit prose with a constrained, ordered DUJS or DUJ64 package that a human copies from a service and pastes into a DNS operator interface.
  • A valid package is bounded evidence of requested intent. The operator must still verify the user's authority over the zone, apply local policy, preserve whole-package atomicity and observe the resulting DNS state before anyone treats the change as effective.

A perfect package from an imperfect channel

Imagine a certificate service displaying one compact value. The value parses as I-JSON. Its first element says DUJS; its second contains three ordered actions. One old TXT record will be deleted, another added, and a service-specific name created. Every owner name is fully qualified. Every record type and data value is syntactically valid. Nothing has been mistyped.

The display can still be the wrong authority.

The browser session might terminate at an impostor. A compromised service account might present a malicious change. The human copying the package might have access to the DNS console but not the corporate authority to alter this zone. The DNS account might govern one zone while the pasted owner name falls below a delegated child. The change might be syntactically legal and operationally disastrous.

Revision 06 of DNS Update with JSON is valuable because it does not pretend to settle those questions. It standardizes a narrow handoff: a service gives a human an exact description of additions and deletions, and the human carries that description to a DNS operator. It says explicitly that DUJ is not for automatic zone updates. It also says that DUJ has no cryptographic protection.

That restraint is the mechanism's most important property. Precision travels farther than authority.

What DUJ removes from the instruction

Today's manual workflow often begins with prose: “Create a TXT record at this name with this value.” The user must decide which screen field means owner name, whether the provider expects a trailing dot, how quotation marks should be handled, and whether an existing record should be replaced or supplemented. A service may mix the actual record with explanation, urgency and marketing language.

DUJ narrows that surface. The outer value is a two-element array. Its first element is exactly DUJS or DUJ64. Its second is a non-empty ordered array of action templates. Each template contains exactly an add or delete action and one record-data string in RFC 1035 zone-file form.

The choice of arrays rather than an extensible object is deliberate. The draft does not allow a side field saying “urgent security update” or “required for your account”. Such language could persuade a user to approve a change that the bare DNS data would not justify. The format is intentionally non-extensible; a later design needs a different identifier rather than an unnoticed optional key.

DUJS keeps the DNS record-data somewhat readable, while forbidding comments, directives and embedded newlines. DUJ64 Base64-encodes the same record-data. It can carry awkward bytes without transcription damage, but it is intentionally opaque to an ordinary reader. The person can still see whether an action adds or deletes; they cannot infer the record's meaning from the encoded payload.

Base64 is not encryption. I-JSON is not a signature. A recognized RR type is not an authorization token. These are representation decisions, not a trust system.

The human is a transport, not a cryptographic bridge

DUJ crosses two connections. A service shows the package to a user. The user later pastes it into an operator interface. The draft says the package's source authenticity and integrity on the first leg are only as strong as the user's connection to the service; on the second, only as strong as the user's connection to the DNS operator.

The human presence does not join those sessions into one authenticated delegation. It can add judgment, but only if the interface exposes enough evidence for judgment. It can also hide provenance: the DNS operator receives bytes from an authenticated customer account without necessarily knowing which service created them, which service session displayed them, or whether they changed in a clipboard, ticket or chat.

This is a recurring automation error. A system sees an authenticated account submit a well-formed request and silently upgrades that fact into “the upstream service was authentic” and “the account holder intended the effect”. Neither conclusion follows. Authentication identifies the current session. Authorization binds that session to the permitted zone and action. Provenance identifies the origin of the proposed content. Consent records the human decision. They may coincide; DUJ does not make them coincide.

Atomicity prevents a half-change, not a bad whole change

The strongest processing rule is whole-package atomicity. The operator must determine that the entire ordered update array can be applied to the target zone. If any action prevents atomic application, no action may be processed.

That matters. Deleting an old verification record without installing its replacement could strand a service. Adding a new mail policy without removing a conflicting value could create a different failure. An ordered package should not stop halfway because the third action is invalid.

Atomicity, however, answers only whether the package commits as a unit. It does not say that the unit is wise.

A malicious package can be perfectly atomic. So can a change prepared for the wrong customer, an obsolete service workflow, or a record that redirects a verification step to an attacker. Transaction integrity protects the relationship among actions; it does not create legitimacy for the transaction.

The draft therefore keeps local control explicit. An operator may reject any package, including one that adds and later deletes the same record. It may refuse unknown RR types even when RFC 3597 makes their representation syntactically possible. It must check that a fully qualified owner name can be changed in the relevant zone, which can fail at a zone cut. Most importantly, it must verify that the user is authorized to change the zone named in the action.

The shared format is minimal. The future decision remains local.

Idempotency needs a truthful receipt

The draft allows an operator to skip an add when the exact record already exists or a delete when the exact record is absent. It also directs action processing to verify exact absence or presence. Those rules make repeated or stale packages an operational question rather than an excuse to infer failure from a single UI message.

An operator response should therefore say more than “accepted”. Did it parse the package? Did local policy approve every action? Was an add skipped because the record already existed? Did a delete find no matching record? Did the transaction commit? Which zone serial or internal version contains the result? Was the new data loaded by the authoritative servers?

Revision 06 says the operator should tell the user about every change made. A leadership-grade implementation can turn that into a durable mutation receipt. The receipt should bind the exact package hash to the authenticated account, target zone, authorization basis, policy result, before-and-after RRset state, skipped operations, commit identity and time. That recommendation is operational analysis, not language already required by the draft.

The distinction matters because “the package was valid” and “the requested state is live” sit on different reality layers. The first can be checked before mutation. The second requires evidence from running systems.

Publication is another boundary

Even a committed operator transaction is not the end of the chain. The authoritative serving system may load changes asynchronously. Secondary servers may lag. Recursive resolvers may retain earlier data until TTL expiry. A downstream certificate, mail or social-media service may query from a view different from the operator's check. A DNSSEC signing pipeline may introduce a further stage.

DUJ does not claim to solve those systems. Nor should it. Its job is to carry an exact manual instruction.

The operational error would be to let the neatness of the instruction mask the unfinished work after it. If the business decision depends on a verifier observing the record, the evidence chain should preserve at least one authoritative observation and, where material, observations from the resolver views that the verifier is likely to use. The verifier's own acceptance remains a separate outcome.

An operator can therefore report three different successes without contradiction:

  1. the package was valid and authorized;
  2. the zone mutation committed atomically;
  3. the intended public and downstream observations occurred.

Collapsing those successes into one green badge creates false confidence and makes rollback harder.

A current draft with a deliberately small claim

The frozen subject is revision 06, uploaded on 26 September 2026 and expiring on 30 March 2027. Datatracker lists it as an active individual Internet-Draft with no RFC stream and no formal standing in the IETF standards process. The document carries Standards Track intent in its text, but it is not a working-group document, IETF consensus, an approved standard or an RFC.

The revision change from 05 to 06 refreshed the dates and revision identifier; the frozen diff does not show a new processing mechanism. That is useful discipline for readers: a newer draft number is evidence of a new submission, not evidence of broader review or deployment.

The source set establishes no implementation, interoperability result, adoption rate, security incident, performance result or named DNS operation. It also does not establish that a particular certificate authority, social network or DNS provider will adopt DUJ. This Article evaluates the control boundary described by the text, not a market outcome.

Sources