要約

  • DNS Delegation Extensions の草案では、DE は対応能力の交渉、ADT は検証済み DNSKEY に基づく証明義務を担い、両者は同じ成功状態ではない。
  • ADT がクリアでも正の DELEG 応答をそれだけで DNSSEC-bogus としてはならないが、その応答には Delegation Type の除去を検知するための永続的なコミットメントがない。

監視画面に二つの表示が並んだ。DNSSEC 署名は有効。DELEG RRset も検証できる。しかし、委任元ゾーンの DNSKEY には ADT がない。単純な状態機械なら、赤か緑のどちらかに押し込もうとする。

赤ではない。草案は、ADT がクリアであることだけを理由に正の DELEG 応答を DNSSEC-bogus と扱うべきではない、と明示する。だが緑を「ダウングレードから保護済み」の意味で使うこともできない。ADT がなければ、委任応答に Delegation Type の存在・不存在を証明させる追加の整合性検査は発動しない。

この中間状態こそ、draft-ietf-dnsop-delext-11 が浮かび上がらせる重要な境界である。文書は 2026 年 9 月 17 日付で、2027 年 3 月 21 日に失効する DNSOP ワーキンググループの Internet-Draft だ。標準化トラックを意図しているが、最終 RFC でも、製品実装や普及の証拠でもない。以下は提案仕様の分析であり、現実の配備を推定するものではない。

同じビット列に見えても役割は違う

草案は EDNS(0) の bit 2 に Delegation Extensions、DE フラグを割り当てるよう求める。対応リゾルバはクエリで DE を立てる。対応する再帰リゾルバが対応 stub から DE を受ければ、応答にも DE を返して、Delegation Types を理解できることを示す。

これは能力交渉である。権威サーバが DE=0 のクエリを受け取ると、従来互換の挙動を取り、新しいタイプを通常のデータタイプとして扱う。古いリゾルバに理解できない委任を渡さないための仕組みだ。

しかしクエリ中の DE は経路上で削除できる。攻撃者が DE を落とせば、権威サーバは NS のみを返す正当な理由を得る。応答から NS-Omitting の Delegation Type と関連する拒否証明を除き、未署名 NS だけを残す攻撃も考えられる。別の境界で DE が返ってきたという事実は、権威問い合わせまで同じ状態が保たれたことも、委任データが完全であることも証明しない。

そこで草案は DNSKEY の bit 14 に Authoritative Delegation Types、ADT を置く。検証リゾルバは、委任元ゾーンについて検証済みの DNSKEY RRset から ADT を読む。どれか一つの DNSKEY でも ADT を立てていれば、委任応答には、その委任名に Delegation Types が存在するかしないかを示す NSEC または NSEC3 証明が必要になる。

DE はこの一回の会話における能力表示、ADT は署名済みゾーンによる持続的な約束である。表示場所と寿命が違うため、証明できることも違う。

ADT は「あるはずのもの」を照合させる

検証器は、応答の Authority section にある NS-Omitting、NS-Preserving、Private の各 RRset を、委任名に対応する NSEC/NSEC3 の Type Bit Maps と照合する。認証されたビットマップが存在を示すタイプが応答から欠けていれば、改ざんとみなして応答を無視する。

On-Demand タイプは例外である。ビットマップに存在しても、通常の委任応答に含める必要はない。オンデマンドという分類自体が「明示的に問い合わせるまで送らない」という意味を持つからだ。

この検査が DE 削除攻撃にも効く理由は、義務がクエリから生じていない点にある。攻撃者が DE を消して権威サーバに NS だけを返させても、検証器は以前に検証した DNSKEY の ADT を覚えている。必要な NSEC/NSEC3 証明がなければ、応答を受け入れない。

ただし、委任元ゾーンが DNSSEC 署名され、ADT が設定され、リゾルバが DNSSEC 検証を行い、この規則を実装している場合に限る。どれかが欠ければ、この仕組みによる暗号学的なダウングレード保護はない。「ADT 対応」という一語では前提条件を表せない。

受理可能と保護済みを分ける

ADT がクリアな場合、上記の整合性検査は適用されない。正の DELEG RRset は、他の DNSSEC 検証や委任処理の規則に従って処理される。ここで「ADT がないから bogus」と判断すれば、草案が許容する正のデータを過剰に拒否する。

一方、「署名が有効だから除去攻撃にも安全」と判断すれば、存在しない保証を追加する。Delegation Type RRset 自体の署名は、その RRset が届いたときの真正性を支える。ADT は、届かなかったときにも検証器が欠落を検知するための義務を支える。この二つは同じではない。

運用記録には少なくとも三状態が必要だ。第一に、受信した正の RRset が有効。第二に、ADT による存在・不存在証明の義務あり。第三に、その義務が満たされた。赤と緑だけでは、「受理できるが除去耐性を主張できない」が消えてしまう。

タイプ番号が委任の優先順位を決める

草案は 0xF0000xF1FF を Delegation Types に予約し、四区分にする。0xF0000xF07F は NS-Omitting、0xF0800xF0FF は NS-Preserving、0xF1000xF1EF は On-Demand、0xF1F00xF1FF は NS を保持する Private Use である。

DE=1 のクエリに対し、権威サーバは委任名にある NS-Omitting、NS-Preserving、Private を応答に含める。On-Demand は明示問い合わせがない限り含めない。NS-Omitting が一つでもあれば、他のタイプや QTYPE=NS にかかわらず NS RRset を省略する。

リゾルバも NS-Omitting があればその情報を使い、同居する NS を無視し、検証もキャッシュもしない。NS-Omitting がなければ NS を使い、NS-Preserving と Private を補助情報として扱う。

つまりコードポイントの区分は登録上の整理ではない。未知の将来タイプに対する汎用実装の挙動を決める。置換型を NS-Preserving 区分に登録すれば、番号が誤ったフォールバックを命令する。Expert Review は将来のソフトウェアが実行するデフォルトを審査している。

フォールバックしないことが安全性になる

NS-Omitting の情報が存在するが利用不能だった場合、リゾルバは NS に戻ってはならない。到達不能なサーバで SLIST が満たされたように扱う。この規則は可用性に厳しいが、失敗時に従来の暗号化されない Do53 へ密かに戻ることを防ぐ。

障害対応では、生きている NS を使えば直るように見える。しかしその「修復」は、新タイプが与えるはずだった輸送上の性質を破棄する政策変更である。ライブラリが自動的に行うべき判断ではない。可用性を優先してロールバックするなら、誰がどの証拠で許可したかを残す必要がある。

ADT がある場合も、検知は必ずしもサービス継続を意味しない。改ざんされた応答を正しく拒否すれば、ユーザーは答えを得られないことがある。安全に失敗した状態と、成功したサービスを同じ指標にしてはいけない。

負の応答が示すもの

親が Delegation Types だけを公開し NS を持たないとき、DE を送らない旧リゾルバには使える委任がない。権威サーバは負の応答を返し、原則として EDE 34 “New Delegation Only” を付ける。EDE は不具合の原因を説明するが、旧リゾルバに新機能を与えない。

攻撃者が DE を落としてこの負の応答を誘発する場合、ADT を検証したリゾルバは NSEC/NSEC3 証明を要求できる。Compact Denial of Existence では、委任点のタイプビットを隠す NXNAME ベースの応答では足りず、通常の Name Error 証明が必要になる。

ここでも証拠と結果を分けるべきだ。証明が欠けているため応答を拒否できたことは、代わりの委任経路を得たことではない。EDE 受信は診断成功であって、名前解決成功ではない。

SLIST は利用実績ではない

草案は SLIST を複数種類の委任情報を保持できる集合として定義し直し、同じ値を一度だけ表す。委任は循環依存や暴走処理を生み得るため、適切な上限も必要だ。

だが RFC 1034 とこの草案が規定するのは SLIST の作り方であり、使い方ではない。候補が入ったことは、サーバが選ばれ、接続され、暗号化された通信に成功し、回答したことを証明しない。

監査可能な記録は、DE の送受信、検証済み DNSKEY と ADT、NSEC/NSEC3 証明、タイプ区分、NS 優先順位、SLIST 候補、実際の選択、輸送、最終結果を分ける。正の RRset を受理できたという最初の事実に、後段の成功を借りてきてはいけない。

ADT がない応答を即座に赤くしないことは、基準を緩めることではない。どの保証が存在し、どの保証が欠けているかを正確に残すことだ。精密な中間状態を持てる組織だけが、互換性のための受理と、降格に耐える委任を混同せずに移行できる。

出典