要約

  • 悪意ある署名済みゾーンは、同一key tagの鍵と多数の署名候補を組み合わせ、検証失敗に至るまでの暗号処理を膨張させた。
  • 修正はDNSSECを捨てることではなく、一つの異常な検証を打ち切り、他の問い合わせを守り、上限到達を観測可能にすることだった。

正しい検証が可用性を奪うとき

DNSSECでは鍵のロールオーバー、アルゴリズム移行、複数署名者のため、DNSKEYとRRSIGが複数存在し得る。RRSIGの16ビットkey tagは候補鍵を探す手掛かりだが、固有識別子ではない。異なる鍵が同じ値を持つことがある。

KeyTrapは、この正常な柔軟性に計算量の罠を置いた。攻撃者は自分のゾーンにtagが衝突する鍵を多数配置し、検証できない署名候補を組み合わせる。検証器は「どれも正しくない」と結論するまで多くの組み合わせを試す。送信されるデータは有限でも、受信側の公開鍵演算は大きく増える。

偽造が成功したわけではない。別のドメインの権威を得ず、ルートからの連鎖を破らず、不正データをSecureにもしない。狙いは検証器を働かせ続けることだった。したがってDNSSECの恒久停止は適切な修正ではない。負荷とともに認証機能まで消してしまうからだ。

ATHENEは2023年11月から主要実装と大規模運用者へ非公開で共有し、2024年2月13日に共同開示された。実験では実装・設定により約1分から数時間に及ぶ停止が報告されたが、これは試験対象での上限的結果であり、全運用環境の停止時間を示さない。

上限値より重要な共通原則

ISCはCVE-2023-50387をHighかつ遠隔悪用可能と評価し、対象BIND 9系列の更新を勧告した。公開時点で実悪用を把握していないとも明記した。脆弱性の存在から、発生していない攻撃史を作ってはならない。

Unbound 1.19.1は、一定回数の検証後に処理をサスペンドする。重い処理がCPUを譲り、他の仕事が進み、限られた再開後に問題の問い合わせを失敗させる。暗号関数だけでなく、スケジューリングとキューの保護が防御になった。

CloudflareはRRset単位と解決タスク全体の双方に検証上限を置き、超過時のエラーと計測指標を加えた。同社によれば1.1.1.1は2023年12月8日にKeyTrap対策を完了し、内部CDNリゾルバーは2024年2月13日に関連NSEC3問題を含む対策を完了した。

実装ごとの数値は異なってよい。共通なのは、署名済み資料を提示する権限が、相手のCPUや待ち行列を無制限に使う権限ではないという境界である。

標準が答えなかった資源問題

RFC 4034はDNSSECのデータを、RFC 4035は検証を定義した。共通手順は相互運用の基盤だ。しかし敵対者が探索空間を選べるなら、「最後には正しく失敗する」手順も、その前にサービスを止め得る。

2026年のDNS上限値に関するInternet-Draftは、DNSKEY、DS、RRSIGの明示的上限がなかった問題を記す。これは検討の継続を示す資料であり、完成した標準ではない。

したがって、この事例の持続的な制度上の焦点はIETFの標準化プロセスにある。問われるのは、どのベンダーが最初に修正したかだけではなく、どの上限を共通プロトコルの契約に含め、どの資源判断を実装ごとの局所権限として残すかである。個人提出のドラフトはIETFコンセンサスではなく、運用者は進行中の作業を配備済みの上限の代替にできない。

Heng Luの枠組みでは、最低限の初期仕様が暗号的な共通言語を守り、将来判断の局所化が各リゾルバーに資源配分を返す。自発的採用によって複数の実装が安全な境界を運用で証明でき、一社のスケジューラを普遍的制度にする必要もない。

運用者が証明すべきもの

棚卸しには実装名、正確な版、配布元、修正の来歴、導入日が要る。「DNSSEC有効」だけでは高コスト経路が残っていないと証明できない。

署名試行数、検証時間、worker待ち時間、キャッシュ応答、上限超過エラーを分けて計測する。悪性ゾーンの試験は隔離しつつ、キャッシュ済み・未キャッシュ双方の通常問い合わせが進み続けることを確認する。

緊急時に検証を止めるなら、責任者、狭い範囲、期限、復帰の証拠が必要だ。暫定措置が残れば、可用性攻撃は恒久的な認証低下に変わる。

証拠の限界

一次資料は世界的な実悪用、全地球規模の障害、脆弱なリゾルバーの完全な割合を示していない。ベンダーの公開日は全下流環境の更新日ではない。ATHENEの測定を全構成へ一般化せず、宣伝的な最上級表現も比較事実として扱わない。

確かな教訓は限定的で強い。署名は検証を求められる。しかし、検証に費やす資源の決定権は依存側に残る。

出典