要約

  • Automating DNS Delegation Management via DDNS の revision 02 は DNSOP の進行中 Internet-Draft であり、RFC でも実装報告でもない。
  • DSYNC は親側 UPDATE Receiver の探索を可能にし、SIG(0) は要求を認証する。しかし、探索結果そのものは変更権限でも、公開済み状態でもない。
  • NOERROR は受信と受理を確認する。文書は親ゾーンへの公開を将来の出来事として書いており、権威サーバ群、キャッシュ、アプリケーションの結果までは証明しない。
  • 安全な停止や旧経路の撤去には、探索、鍵のブートストラップ、名前範囲、親側ポリシー、プロビジョニング、権威公開、観測結果を別々に残す必要がある。

探索レコードが与えるもの

RFC 9859 の DSYNC は、同期のためのエンドポイントと用途を示す。子側にとっては、登録事業者ごとの独自 API を推測せずに更新先を見つけられることが大きい。しかし、そこから分かるのは「どこへ送るか」であって、「誰があらゆる変更を許されるか」ではない。

revision 02 は RFC 2136 の通常の DNS UPDATE を用い、SIG(0) で要求を保護する。既定の規則では、信頼済み鍵の名前が変更対象の子ゾーン名と正確に一致しなければならない。ある子の鍵が別の子の委任を変更することを防ぐためだ。

親がレジストラ用の広域鍵など別の方式を採ることはできる。その場合、範囲拡大はプロトコルの自動的な帰結ではなく、親が引き受ける認可設計である。鍵一つの侵害半径、顧客ごとの承認、監査が新たに必要になる。

したがって、運用記録には DSYNC の所有名、TTL、ターゲット、解決結果、トランスポート、Receiver の識別根拠を残すべきである。エンドポイントへ到達できたという事実を、委任変更の権限や結果へ昇格させてはならない。

自己署名は秘密鍵の所持だけを示す

最初の鍵登録では、子は候補 KEY を自己署名した UPDATE で提示できる。署名検証が成功すると、対応する秘密鍵を送信者が持つことは分かる。子の委任を管理する正当な主体かどうかは、まだ分からない。

Receiver はこの鍵を「既知だが未信頼」として扱う。署名済み子ゾーンの頂点、署名済みネームサーバ名の配下、または手動確認によって認可を検証した後で、初めて信頼集合へ上げる。

署名なしのブートストラップは、現在の権威サーバ運用者を認証するが、登録者そのものを認証するわけではない。利用可能な強い方式から弱い方式へ誘導される危険もあるため、親が SVCB で示す方式と、その表示の DNSSEC 検証状態を記録しなければならない。

再ブートストラップでは、置換鍵が検証されるまで旧信頼鍵を消してはならない。新候補が失敗する前に旧鍵だけが消えれば、攻撃者は権限を得ずとも正規の制御経路を壊せる。ここで重要なのは個々の署名の成否より、状態遷移の順序である。

暗号検証の後に親の判断が残る

信頼済みで名前範囲も正しい SIG(0) を確認しても、更新は自動的に親ゾーンへ流れ込まない。Receiver は CDS/CDNSKEY や CSYNC の処理に相当する整合性・ポリシー検査を行う。

親側の監査、レート制限、承認規則、プロビジョニングシステムとの接続も残る。文書自身が、複雑さを消すのではなく子側へ一部移すと説明している。ポーリングを減らすことと、親の意思決定を放棄することは同じではない。

この境界は、認証と認可を分けるだけでは足りない。要求が正しい形式で、正しい主体から届き、ローカル規則を通り、どの親側生成物へ変換されたかまでを追跡する必要がある。

記録する項目は、変更前後の NS・glue・DS、署名鍵、時刻窓、名前範囲、検査結果、ポリシーバージョン、承認者、プロビジョニング識別子である。「署名 OK」だけでは、その後の権力行使を説明できない。

NOERROR の文法は未来形である

文書は NOERROR を、UPDATE が受信され受理された確認と定義する。そして変更は将来のある時点で親 DNS データに公開されるはずだと続ける。この一文は、受理と公開の間に制度的・技術的な距離があることを明示している。

Receiver がデータベースへ書き、別 API を呼び、ゾーン生成を待つことがある。プライマリが新世代をロードしても、セカンダリの一部は旧世代を提供し得る。権威側が揃った後も、再帰キャッシュは旧 TTL の範囲で以前の値を返し得る。

そのため、NOERROR を受けて旧ネームサーバを停止するのは早い。まず親権威から意図した RRset を観測し、対象サーバ、時刻、TTL、検証状態、ゾーン世代を保存する。複数権威が異なれば、状態名は「部分公開」である。

再帰リゾルバやアプリケーションの検査はさらに別の証跡だ。サービスが動くことは有用だが、古いキャッシュや代替経路で動いている可能性がある。反対に、DNS が正しくてもアプリケーションは別の理由で失敗する。

応答にも相手方の鍵が要る

子が要求を署名しただけでは、返ってくるメッセージの発信者は保証されない。Receiver は自身の SIG(0) 鍵で応答を署名し、子は親 DNSSEC または手動ブートストラップでその公開鍵を信頼する必要がある。

この逆向き信頼がなければ、攻撃者が「子鍵は未知」と偽って不要な再登録を誘発できる。偽応答は不正な委任変更を成立させなくても、停止、鍵交換、再試行の連鎖を起こせる。

ログには応答署名の有無、Receiver 鍵の指紋、その信頼根拠、RCODE、拡張エラー、対応する要求世代を残す。「サーバから返答があった」と「期待した Receiver が認証済みの声明を出した」は違う。

それでも認証済み応答の意味は受理までである。正しい主体による狭い声明を、親ゾーン全体の公開証明へ広げてはならない。

無応答は実行されなかった証拠にならない

応答がない場合、要求が届かなかったのか、受理後に返答だけ失われたのか、Receiver が止まったのかを区別できない。revision 02 のタイムアウト、指数バックオフ、上限付き再試行は負荷を制御するが、この不確実性を消さない。

再試行には意図世代が必要である。古い UPDATE が新しい決定より後に適用されてはならない。SIG(0) の inception と expiration はリプレイ可能時間を狭めるが、正規に署名された二つの要求の新旧関係までは決めない。

再送前に親権威を観測すれば、すでに公開済みの変更を不要に繰り返すことを避けられる。観測が混在していれば、再試行より先にプロビジョニングと転送状態を調べるべきである。

沈黙を「失敗」と塗るのも、「たぶん成功」と塗るのも同じ誤りだ。未知は未知として残し、次に必要な観測を状態機械が示す方が強い。

草案の状態も証拠境界である

証拠固定時、revision 02 は 2026 年 6 月 17 日付、Datatracker の最終更新は 9 月 25 日、失効予定は 12 月 19 日だった。WG 状態は Waiting for WG Chair Go-Ahead Other - see Comment Log、IESG 状態は I-D Exists である。

Datatracker は intended RFC status を表示していないが、文書ヘッダは Standards Track と記す。記事はこの不一致を保持する。提案中の番号やレジストリ項目を確定値として扱わない。

固定資料は特定レジストリ、TLD、レジストラ、権威 DNS 事業者の導入を示していない。冒頭は構成例であり、実事故の報道ではない。

成果物は受付番号ではなく証跡グラフである

グラフの最初は子の意図、前状態、希望 RRset、世代、承認者である。次に DSYNC、双方の鍵信頼、名前範囲、検査、親ポリシー、応答を結ぶ。その後へプロビジョニング、親ゾーン世代、権威観測、キャッシュ上限、リゾルバ標本、アプリ結果を追加する。

各辺は所有者、時刻、入力、出力、ハッシュを持つ。未知を成功で埋めない。この形なら、旧経路を残す、再試行を止める、旧鍵を保護する、正しい担当へ障害を渡すという判断ができる。

結論は狭い。SIG(0) は範囲付き要求を認証でき、NOERROR は Receiver の受理を示せる。親ゾーンの現実は、親ゾーンを観測した証跡だけが示す。

出典