DNSOPのDNS統合案が最終意見募集の期限へ、削除処理が決定的な試験に

要約

• DNSOPは2026年8月24日、draft-ietf-dnsop-integration-04のワーキンググループ最終意見募集を開始し、9月7日を終了予定日とした。保存したDatatrackerの表示はなおIn WG Last Callであり、承認済みRFCではない。
• 案は初回のドメイン管理確認だけでなく、失効、DNSSEC状態の変化、対象レコードの削除、再同期を扱うよう求めている。
• 本稿は登録、更新、削除、移転・再登録の4遷移を共通試験として提案する。各遷移には、契機、検証主体、到達状態、古い状態が残り得る上限が必要だ。
• AT Protocolは双方向検証と定期的な再解決によって無効状態へ進む。一方、案にあるENSの例では、当該経路がNSECの否定証明を扱わないため、DNSレコードの削除だけでは古い肯定的なオンチェーン主張を取り消せない。
• 4遷移の表はDaniel Kadeによる分析で、IETFが採択した要件ではない。異なる実装を同じ動作結果で比較するための最小枠組みである。

期限到来と合意形成は別の出来事だ

DNSOP議長の案内は8月24日に意見募集を始め、9月7日を終了日と記した。9月6日のリマインダーも翌日まで意見を求めている。ここから確認できるのは募集の予定期限であって、支持の集計やラフコンセンサスではない。

Datatrackerでは、04版はInformationalを想定したInternet-Draftである。ワーキンググループ状態はIn WG Last Call、IESG状態はI-D Existsにとどまる。RFCになったとも、次段階への移行が決まったとも読めない。

時点を混同しないことは、この記事の対象そのものでもある。過去に正しかったDNS情報と、現在も正しいアプリ内状態は同じではない。

アプリはドメイン名と一緒に変化の責任を取り込む

04版は、ドメインのライフサイクルとして失効、DNSSEC状態の変更、期待されたリソースレコードの削除を挙げる。こうした変化に追随できなければ、最初の登録者がドメインを失った後もアプリ内の支配を保つ可能性がある。

初回登録では、現在の登録者または正当な委任を受けた者だけが結び付けられる必要がある。利用可能な名前を固定TLD一覧で恣意的に狭めず、国際化ドメインの表示上の危険も扱う必要がある。そして、世界のDNSとアプリ状態をどう再同期するかを文書化する。

しかし常時照会は無料ではない。問い合わせ量、レート制限、一時障害、乗っ取りや誤設定を考えれば、キャッシュと再確認の間隔は設計判断になる。判断をなくすのではなく、結果を明示することが統治である。

本稿が提案する最小試験は次の通りだ。

遷移	検証する問い	観測する結果
登録	現在の管理権または有効な委任を何が証明するか	新しい結び付きを受理または拒否する。
更新	どの新しい主張が古い主張に優先するか	宛先または識別子が切り替わる。
削除	不在をどう証拠化し、いつ反映するか	無効、空、明示的な期限切れのいずれかになる。
移転・再登録	新登録者が以前の結び付きをどう排除するか	旧管理者のアプリ内権限が終わる。

各行には、確認を始める契機、検証者、キャッシュ規則、最長の不整合時間、手動復旧方法を添えるべきだ。この表はDNSOP案の本文ではなく、ライフサイクル、管理権、完全性、同期という4つの論点を動作試験へ置き換えた提案である。

AT Protocolには「無効」が用意されている

AT Protocolは、比較的永続的なDIDと、人が読む可変のドメインhandleを分ける。handle仕様は双方向の確認を要求する。handleからDIDを引けるだけでなく、DID文書側も同じhandleを示さなければならない。第三者が一方的な別名を作っても、それだけでは信頼済みの結び付きにならない。

既知のhandleが解決しなくなったと確認された場合は、無効として扱う。サービスは結果をキャッシュできるが、定期的に再解決することが推奨される。DNS変更がアプリへイベントとして届かなくても、次の照会で不在を状態に変えられる。

再解決間隔には代償がある。長ければ負荷は下がるが誤った表示が長く残る。短ければ不整合は縮むが、一時的なDNS障害にも反応しやすい。重要なのは、否定的な結果と、そこへ到達する経路が定義されていることだ。

なお、AT Protocolのこの解決方式はDNSSECを必須としていない。DNSOP案を「すべての統合にDNSSECを要求する文書」と読むのは誤りだ。方式ではなく、管理権とその後の変化を説明することが共通要件である。

ENSの例では削除と上書きが同じではない

ENSの例はDNSSECの肯定証明をオンチェーンへ持ち込む。新しい肯定証明が古いものを上書きし、登録者が変われば、新登録者は自分のレコードの証明を提出して統合を作り直せる。

問題は次の肯定証明がない場合だ。案によれば、この経路のENSは現在NSECの否定証明を扱わず、レコードの不存在や削除をチェーン上で証明できない。古い肯定的主張は、新しい肯定証明に置き換えられるまで残る。元のDNSレコードを削除したことや名前が失効したことだけでは、オンチェーン状態の取消しにならない。

この記述は04版で突然加わったものではない。03版にも存在し、差分もそれを示す。04版の変更履歴は完全性に関する文言の更新を掲げている。

ENSのDNSインポート案内では、新しい所有者が_ens TXTを書き換え、更新操作でENS側へ反映できる。これは新しい肯定状態を提出する手順であり、TXTを消すだけで古い状態が自動消去されるという説明ではない。

ここから全ENSや全DNS統合へ一般化してはいけない。特定の証明経路に関する制約である。ただし、「肯定を受け入れる仕組みに、不在を受け入れる仕組みもあるか」という監査質問には広い価値がある。

削除の遅さは誰かの負担になる

登録は利用者獲得につながり、成功画面も作りやすい。削除は新規利用を生まず、再照会、証明検証、状態更新、サポート、場合によってはオンチェーン取引を必要とする。悪意がなくても、入口が詳細で出口が曖昧になる誘因がある。

古い表示名なら誤認、古い宛先なら通信の誤配送、支払い先や管理権なら実質的な権限残存になる。評価すべきはDNS取得の可否だけでなく、アプリ内で何が許可され続けるかだ。

また、失効から他者による再登録までが常に一瞬というわけではない。ICANNのgTLDライフサイクルには複数段階がある。すべてに共通する架空の秒数を置くのではなく、各アプリがどのイベントで状態を変えるかを示す必要がある。

Heng Luが示す最小の初期仕様と、その後の局所的な判断なら、4遷移だけを共通化できる。解決方式、証明、キャッシュ、復旧は実装ごとに選べる。

動いているコードを第一の証拠とするなら、「DNS認証対応」という表示より、実際に登録、変更、削除、再登録したときの出力が重要になる。そこで初めて、権限がどこに残るかが見える。

参照資料

1. DNSOPワーキンググループ最終意見募集
2. DNSOP最終意見募集のリマインダー
3. IETF Datatracker文書ページ
4. IETF文書履歴
5. DNS統合案04版
6. DNS統合案03版
7. 03版と04版の公式比較
8. DNSSECプロトコル変更、RFC 4035
9. AT Protocol handle仕様
10. AT Protocolリポジトリ同期仕様
11. ENSオンチェーンDNSインポート案内
12. ICANNのgTLDライフサイクル
13. Heng Lu：最小初期仕様と局所的な将来判断
14. Heng Lu：動いているコードを第一に