要約

  • 検証に使われるDS RRsetは親ゾーンにある。CDS/CDNSKEYは子側が望む置換後の状態を示す。既存DSがある更新では現在の信頼連鎖で認証できるが、初回登録にはその連鎖がまだない。
  • RFC 9615は、親NSに載る各域外ネームサーバーの安全な名前空間に同一シグナルを置き、該当する全運用者の一致を要求する。証明されるのは運用者の同意であり、登録者の権原ではない。
  • 親側の受入れ規則、ダイジェスト選択、DS公開、TTL経過、リゾルバーでの成立は独立した証拠である。アルゴリズム0による全DS削除は通常の鍵更新とは別の破壊的変更として扱う。

自分を署名できても、自分を信頼開始点にはできない

ある組織がマネージドDNSでDNSSECを有効にした。サービスは鍵を生成し、ゾーン頂点にDNSKEY、CDS、CDNSKEYを置き、全てを正しく署名する。複数の権威サーバーは同じ内容を返す。サービス画面は準備完了と表示するが、親ゾーンにはまだDSがない。

この時点で署名が正しいことは十分ではない。リゾルバーが子のDNSKEYを選ぶ根拠は、その鍵自身が自分を含むRRsetを検証できることではない。親DSが、既に信頼される親の状態から特定の子鍵へ橋を架ける。最初のDSが存在しない以上、子の回答は整合していても信頼起点を欠く。

DNS運用者は秘密鍵と配信面を支配していることを示せる。ドメイン登録者は通常、運用者を選ぶ主体である。レジストラはアカウント関係を確認できる。レジストリまたは別の親側エージェントは親にDSを入れられる。それぞれが持つ事実を一つの署名に代行させることはできない。

CDS/CDNSKEYが解消する摩擦は大きい。KSKやCSKの変更ごとに長いダイジェストを人手で移す運用は、誤記、遅延、更新回避を生む。しかし、人の作業を減らすことと、権限の根拠を省略することは別である。

子が希望を示し、親が自分のデータを書く

DSは親ゾーンの権威データである。鍵タグ、アルゴリズム、ダイジェスト種別、ダイジェストによって子DNSKEYへの信頼を表す。CDSはDSと同じフィールドを別のRR型で運び、CDNSKEYは親がDSを計算するための公開鍵を運ぶ。

RFC 7344では、CDS/CDNSKEY RRsetは置換後に望むDS集合を表す。親側エージェントは現在のDSと比較し、追加と削除へ変換する。子が親へ直接DNS UPDATEを行う仕組みではなく、親データの作成責任も移転しない。

両方のRRsetが存在しなければ「変更しない」である。同期後に子がシグナルを消すことは許される。取得失敗や空の回答をDS削除と読む実装は、通信障害を安全性の低下へ変えてしまう。

親はCDSを採用するか、CDNSKEYからDSを作るかを決める。ダイジェスト方針も親に残り、対応するダイジェスト種別だけを公開できる。子は表現したい鍵を選び、親は支える形式と受入れ条件を選ぶ。

公開、受入れ、記録、検証という四つの動詞は分離されている。機械可読なRRsetは、その境界を速く通るための共通語であって、境界を消す命令ではない。

既存のDSが鍵更新を認証する

現在の親DSが現行DNSKEYに一致するなら、新しいCDS/CDNSKEYは既存の信頼の連鎖で検証できる。ゾーン頂点のシグナルは、現在のDNSKEYとDSの双方で代表される鍵により署名され、適用後も委任を壊してはならない。

古い安全な信頼起点が、次の信頼起点への限定的な橋になる。親側エージェントはRRsetを検証し、現在の親状態と比較し、古い観測の再生を防ぐ。RRSIGの署名開始時刻やSOAのシリアル番号は順序の材料になるが、最後に受け入れた状態を保持する責任までなくならない。

親が新しいDSを公開しても、切替は継続中である。リゾルバーごとに古いDS、DNSKEY、RRSIGのキャッシュ期限が異なる。新しい鍵は全権威サーバーに先に行き渡り、古い鍵は古いDSが残る可能性のある期間を越えて保たれる必要がある。

BINDの現行解説はこの待機を具体化する。CDS/CDNSKEYを公開し、設定したparental-agentsへDSを問い合わせ、期待した応答が全て揃うまで鍵更新を止められる。親がRRを自動処理しなければ手動提出へ戻る。子の自動化は親の対応を作り出さない。

初回登録はネームサーバー運用者の連鎖を借りる

RFC 8078は初回DSのために、認証済みの管理画面やAPI、登録情報の追加確認、複数地点からの継続観測、確認用の問い掛け、委任開始時の処理を挙げた。関係に応じて有用だが、まだ安全でない子からDNSSEC固有の認証を生む方式ではない。

RFC 9615は少なくとも一つの域外ネームサーバーがある場合に、外部の連鎖を利用する。親NSに記載された各ネームサーバー名の前へ_signalを付けてシグナル用ドメインを作り、その下の_dsboot名で子を識別する。同じCDS/CDNSKEYを子のゾーン頂点とシグナル位置の両方に置く。

信号側RRsetは、既にDNSSECで検証できるシグナル用ゾーンの鍵で署名される。親は運用者側の確立済み連鎖で内容を認証し、まだ安全でない子のゾーン頂点から直接得た内容と照合する。子自身への信頼ではなく、ネームサーバー運用者の名前空間から信頼を移す構造である。

親側エージェントは、子にDSがないことと親側のNS集合を確認する。キャッシュを使わず、全権威サーバーへ子のゾーン頂点のCDS/CDNSKEYを直接問い合わせる。次に各域外シグナル名をDNSSEC検証付きで解決し、レコード型ごとに完全一致を確認する。

一台でも取得に失敗する、信号が認証されない、片方だけ空である、内容が異なる――いずれも手順を中止させる。ネームサーバーが全て子ドメイン内にある場合、外部連鎖がないためこの初期確立方式は使えない。

この全員一致は複数事業者の環境で意味を持つ。一社だけが自社KSKへのDSを作らせ、他の権威サーバーが異なる鍵集合を返す事態を防ぐ。RFC 8901の複数署名者運用でも、親に見せるCDS/CDNSKEYの共通状態が必要になる。

運用者の同意は登録者の権原ではない

RFC 9615の検証が示すのは、親NSに現れる運用者が子の署名者として振る舞う意思と、同じ鍵材料への合意である。契約を誰が結んだか、社内で誰が承認したか、ドメイン所有者が認識しているかは別問題である。

RFC自身、DNS運用者が所有者の明示的認識なしにCDS/CDNSKEYとシグナルを追加できると述べ、事前説明や通知を勧めている。正当な自動有効化、操作ミス、侵害された事業者アカウントは、いずれも暗号学的には本物のシグナルを生成し得る。

親側エージェントは技術的支配を委任関係へ結び付ける必要がある。初回登録、鍵更新、安全でない状態への復帰を誰が依頼できるか、所有者へ何を知らせるか、意図しない処理をどう止めるかを記録する。DNSSECは証拠の来歴を強くするが、制度上の権限を創設しない。

RFC 9615がQNAME最小化を勧める理由もこの境界にある。完全な問い合わせ名が上位へ見えると、シグナル用ドメインの上位ゾーンが委任応答を返さず、自分の署名付き回答を試みる余地が増える。最小化は攻撃面を狭めるが、最終ゾーンとRRsetの一致確認は残る。

アルゴリズム0は鍵の選択ではなくDS全削除である

CDS 0 0 0 0とCDNSKEY 0 3 0 0はRFC 8078が定めた正確な一件の形式である。アルゴリズム0は署名検証に使う新しいアルゴリズムではなく、親DS RRset全体を削除せよという信号である。

親はシグナルと追加の受入れ条件を確認してからDSを消す。子は親側TTLに応じた時間を待ってから署名を停止する。DNSKEYを先に消せば、古いDSをキャッシュするリゾルバーには、存在しない鍵を要求する不正な委任として見える。

Cloudflareの現行状態は一つの実装例を示す。無効化の途中ではゾーンへの署名を続け、ゼロシグナルを出し、親DSの消失後にDNSSECレコードを削除する。名称や制御は製品固有でも、要求、親での公開、キャッシュ失効、子の停止が同時でないことは共通である。

安全でない状態へ戻る変更は、通常の鍵更新より強い通知と復旧策を要する。安全性を下げ、再登録に使える最後の認証経路を失うことがある。取得できなかったRRsetや空集合をゼロシグナルの代わりにしてはならない。

証拠はリゾルバーまで到達して完成する

変更前に、親側NSとDS、各子側権威サーバーの直接応答、全シグナル名と検証連鎖、内容の一致、鮮度、ダイジェスト方針、受入れ根拠、提案DSとの差分を保存する。アカウント上の権限とDNS上の支配は別欄に置く。

公開後は、全親側権威サーバーでDSを確認し、定義したTTLを待ち、全子側権威サーバーで必要なDNSKEYと署名を確認し、異なるネットワークの検証リゾルバーで試験する。画面上の成功は命令の受理、親応答はレコード状態、リゾルバー成功は一つの実行経路の結果である。

中止理由も重要な証拠である。運用者の不一致、無効なシグナル連鎖、非対応ダイジェスト、完全な域内構成は、機構が権限境界を守った結果である。中止を説明できなければ、次の担当者は安全制御を単なる停滞として迂回する。

情報源