要約

  • DNSSEC automation 第 05 版は DNSOP の活動中 Internet-Draft であり、RFC、導入実績、移行成功の証明ではない。Datatracker と文書ヘッダーには予定ステータスの不一致もある。
  • 提案はモデル 2 の複数署名者に対し、DNSKEY、CDS/CDNSKEY、CSYNC、親の DS/NS と四つの待機時間を用いて加入・離脱・ロールオーバーを順序づける。
  • 経過時間は必要条件であって観測ではない。各待機には、権威状態として確認した開始点、対象、責任者、終了時の再確認が必要になる。
  • 通常のゾーン内容同期は明示的に対象外である。同じ鍵で検証できる複数の権威が、異なる答えを返すことは残る。

鍵の一致と答えの一致

RFC 8901 のモデル 2 では、複数の事業者がそれぞれの秘密鍵を保持したまま同じゾーンを署名する。鍵を一社に集約せず冗長性を得られる一方、すべての参加者が互いの公開鍵とインフラ用レコードを正しく扱う必要がある。

第 05 版は CDS/CDNSKEY と CSYNC を組み合わせ、グループ形成、署名者の加入・離脱、ZSK や KSK/CSK のロールオーバー、アルゴリズム変更を自動化する手順を示す。重要なのは、単一の「有効」状態ではなく、依存する複数の状態を順に閉じる点である。

しかし文書は、NS、DNSKEY、CDS などを除くゾーン内容の同期を範囲外とする。同じ DNSKEY RRset を示す三台が、同じ A や MX、否定応答を示すとは限らない。DNSSEC は応答の認証を行うが、どの事業者のデータが所有者の最新意図かを選ばない。

したがって、鍵の面とデータの面には別の完了条件が要る。SOA シリアルだけで足りない構成なら、内容ハッシュ、転送世代、署名ポリシー、各権威への試験問い合わせまで記録する。

四つの待機は同じ時計ではない

DS-Wait-Time は親が新しい DS を公開した後に始まり、少なくとも DS TTL を守る。子が CDS/CDNSKEY を置いた時点や、親の処理系が依頼を受領した時点ではない。

DNSKEY-Wait-Time は全署名者の新しい鍵集合が公開された後に始まる。最大 DNSKEY TTL に加え、すべてのセカンダリへゾーンを公開する時間を含む。プライマリへの書き込み完了は、セカンダリの応答を証明しない。

NS-Wait-Time は親が新しい委任を公開してから、親と各署名者の NS TTL の最大値を基礎にする。CSYNC は希望する状態を伝える信号であり、親の変更そのものではない。

RRSIG-Wait-Time は旧鍵による署名生成を止めた後、その署名がキャッシュから消え得るまで旧 DNSKEY を残すための境界である。ロールオーバージョブの終了時刻と、最後の旧署名の失効時刻は別物である。

画面上では四つとも進捗バーにできる。だが、開始イベントも保護対象も異なる。共通の緑色表示にまとめれば、障害時にどの権威を早く外したのか説明できなくなる。

待機の前に開始点を観測する

長い待機でも、開始点が誤っていれば安全余裕にはならない。DS の要求送信から数えれば、親がまだ旧状態を配っていた時間を含めてしまう。ローカル更新から DNSKEY を数えれば、遅れたセカンダリを無視する。登録システムの受付から NS を数えれば、業務処理を公開 DNS と取り違える。

開始の証拠には、対象 RRset、権威の観測点、時刻、TTL、検証状態、ゾーン世代とポリシーを結びつける。時間が過ぎた後も後継状態を再観測する。単なる sleep は時間を消費するだけで、事実を観測しない。

世界中のキャッシュを列挙する必要はない。記録した TTL と前提から、旧状態が有効であり得る上限を説明すればよい。ただし「境界を過ぎた」と「すべてのリゾルバが新状態を見た」は同じ主張ではない。

加入時に離脱の材料を残す

新しい署名者は、動作する署名済みゾーンを持ち、グループと互換なアルゴリズムを使い、自分の鍵と他者の鍵、自分が管理する NS と外部から加わった NS を区別できなければならない。

加入処理では各署名者の公開鍵を全参加者へ追加し、全 KSK/CSK を含む CDS/CDNSKEY を公開する。親の組み合わせ DS を観測し、必要な DS と DNSKEY の待機後に共通 NS を構成し、親の委任変更を確認する。

一台の成功はグループの成功ではない。全参加者の観測を比較し、不一致を残す。加入時点で鍵とレコードの由来を保存しなければ、離脱時にどれを消すべきか判別できない。

離脱は到達経路と署名寿命を分ける

離脱では、残る署名者から退出者の NS を外し、親の委任を縮小し、NS の露出期間を待ってから退出者が応答を止める。その後に残存鍵だけの CDS/CDNSKEY を扱い、旧署名の寿命を待ち、最後に退出者の鍵を外す。

ここには二つの問いがある。問い合わせが旧権威へ到達し得るか。旧権威が作った署名済みデータがキャッシュに残り得るか。前者は NS、後者は RRSIG と DNSKEY の問題であり、一つの契約終了日では閉じない。

事業者との契約を予定日に止めたい圧力と、安全な重複期間を保つ必要は衝突する。誰が終了を延期できるか、重複費用を誰が負担するか、どの証拠が退出者を解放するかを事前に決める必要がある。

中央制御と分散制御の失敗は違う

中央モデルでは一つのコントローラが待機を計算し、すべての署名者を操作する。統一した帳簿を作りやすい反面、古い観測や過剰な資格情報が全体へ一度に影響する。

分散モデルでは各署名者が必要な情報を交換して自ら制約を守る。単一障害点は減るが、TTL、メンバー構成、親の観測が食い違う可能性がある。各ノードが手元の入力に正しく従っても、グループとしては危険になり得る。

DNSKEY や CSYNC を変更できる「信頼機構」の詳細も草案の範囲外である。それでも主体、ゾーンとレコード種別の範囲、承認、更新、失効、監査は必要だ。認証済みチャネルは、無制限の変更権限を意味しない。

文書の状態を強く読み替えない

証拠凍結時、Datatracker は第 05 版を DNSOP の活動中文書、WG 議長の許可待ち、IESG は I-D Exists と示す。Datatracker の予定ステータスは Informational だが、本文ヘッダーは Standards Track と書き、2027 年 1 月 6 日に失効するとする。

この不一致はそのまま記録すべきで、強い方を採用して合意済みと扱ってはならない。RFC 化、実装、導入、相互運用、性能を証明しない。ここでの冒頭事例は分析用で、実在する事業者、ゾーン、移行、障害を示さない。

状態遷移帳簿を成果物にする

帳簿の各行には、ゾーン、グループ世代、参加者、対象、期待値と観測値のハッシュ、権威の観測点、TTL、時刻、検証状態、次に進める最早時刻、承認主体を残す。子の意図と親の公開、キャッシュ境界と実際の観測、鍵同期と内容同期、DNS とアプリ結果を分ける。

不明は不明のまま残す。セカンダリの公開時刻を確認できなければ DNSKEY 待機の開始は不確実である。親の公開を見られなければ受付票では埋めない。内容同期が統合されていなければ「内容未検証」と表示する。

草案が支えるのは、多署名者移行の必要な順序と最低待機という限定的な主張である。グローバルなキャッシュ、ゾーン内容、各リゾルバ、利用者結果の収束は、別の観測者が別の証拠で閉じなければならない。

出典