要約

  • draft-hoffman-duj-06 は、サービスが示した DNS の追加・削除を人が DNS 事業者へ運ぶための、非自動・非暗号保護の DUJS / DUJ64 形式を定める。
  • 正しい構文と原子的な処理は、変更意図の表現を改善する。出所の真正性、利用者のゾーン権限、事業者の方針、権威サーバーへの反映、下流サービスの判断までは証明しない。

転記事故を減らすための仕様

現在の手順では、サービスが「この名前にこの TXT 値を追加してください」と文章で指示する。利用者は、DNS 管理画面の「ホスト」欄が完全修飾名を求めるのか、引用符を含めるのか、既存値を置き換えるのかを解釈する。入力環境が通常の引用符をスマートクォートに変えれば、見た目の似た別のデータになる。

DUJ はその翻訳作業を狭める。外側は二要素の JSON 配列で、先頭が DUJS または DUJ64、次が一件以上の更新配列である。各アクションは add か delete と、RFC 1035 のゾーンファイル形式で書かれたレコードデータだけを持つ。

DUJS では内容をある程度読めるが、コメント、ディレクティブ、埋め込み改行を許さない。DUJ64 ではレコードデータを Base64 にするため、壊れにくい代わりに普通の人には読めない。操作が追加か削除かは見えるが、効果を理解できるとは限らない。

これは有用な交換条件である。ただし Base64 は暗号ではなく、I-JSON は署名ではない。転記が正確でも、変更要求の作者と権限は未確定のままだ。

説明文を入れられないことの意味

仕様がオブジェクトではなく配列を選んだ理由の一つは、任意のキーを足せないようにすることだ。サービスは「緊急セキュリティ更新」などの説明を構造に埋め込み、利用者の判断を誘導できない。将来拡張するなら、先頭識別子を変えて別版にする。

この設計は、指示データと説得を分ける。だが説得欄を消しても、サービス自体が正当になるわけではない。偽サイトも正しい配列を生成できる。侵害されたアカウントも、構文上完璧な削除を指示できる。古いチケットからコピーした値も、正確なまま時代遅れになりうる。

形式は「何を求めているか」を明確にする。「なぜ従うべきか」は別の審査である。

人を挟んでも二つの接続は一つにならない

DUJ はサービスから利用者へ、次に利用者から DNS 事業者へ移る。草案は、それぞれの区間での出所真正性と完全性が、その接続の強さを超えないと明記する。

DNS 画面で認証された利用者が貼り付けたという事実は、元のサービスを認証しない。サービスとの TLS セッションが真正でも、その利用者が対象ゾーン全体を変更できるとは限らない。親ゾーンの画面から見える名前が、実際には子ゾーンのカットの下にあることもある。

事業者は、現在のアカウント、対象 FQDN が属するゾーン、そのアカウントの権限、パッケージの来歴を別々に記録する必要がある。人は判断主体になり得るが、暗号学的な中継証明書ではない。

原子的であることの限界

更新配列は順序を持つ。事業者は全体を対象ゾーンへ原子的に適用できると確認してから処理し、一つでも全体の適用を妨げるなら、途中まで実行してはならない。古い検証値だけを消して新しい値を入れ損ねる、といった半端な状態を避けられる。

しかし「全部一緒に」は「全部正しい」を意味しない。悪意ある変更も一括で成功する。別顧客向けの手順も、古い手順も、整合した一個のトランザクションになれる。

だから草案はローカル判断を残す。事業者は利用者がその FQDN のゾーンを変更する権限を持つか確認しなければならない。ワイルドカード所有者名は禁止される。RFC 3597 で未知タイプを書けても、ローカル方針で拒否できる。追加後に同じレコードを削除するようなパッケージを含め、任意の理由で拒否でき、UI では理由を明確にすることが望ましい。

共有するのは最小の記述であり、将来の判断は運用現場に局在する。

「成功」を分解する回収票

再送時には、完全一致のレコードが既にあるため追加を飛ばす場合や、対象が消えているため削除を飛ばす場合がある。草案は正確な存在・不存在の確認を求め、行った変更を利用者へ知らせるよう勧める。

従って、画面の「成功」だけでは監査できない。運用上の回収票には、パッケージのハッシュ、認証アカウント、ゾーン、権限根拠、方針判断、変更前後の RRset、スキップした操作、原子コミット識別子と時刻を結び付けるべきだ。この詳細な回収票は本稿の提案であり、修訂 06 の規範要件ではない。

さらに、コミットと公開は同じではない。権威サーバーの読み込み、セカンダリーへの反映、TTL による再帰キャッシュ、証明書やメールサービスからの観測には時間差がある。必要な成果が下流検証なら、権威 DNS の観測と下流サービスの判定を別の証拠として保存する必要がある。

06 という数字が示さないもの

修訂 06 は 2026 年 9 月 26 日に提出され、2027 年 3 月 30 日に失効する。Datatracker 上では、RFC ストリームも IETF 標準化過程での正式な地位もない、活動中の個人 Internet-Draft である。本文の Standards Track 意図は、WG 採用、IETF 合意、IESG 承認、RFC 化を意味しない。

凍結した 05 から 06 の差分は、版番号、日付、失効日の更新だけである。実装、相互接続、普及、性能、事故、攻撃、商用成果の証拠もない。本稿は仕様上の境界だけを評価する。

情報源