権威DNSサーバの代表格であるISC BIND 9で、DNSSEC（DNS応答の改ざんを電子署名で検証する仕組み）の検証をすり抜けられる脆弱性が見つかった。Internet Systems Consortium（ISC）は2026年7月22日、BIND 9.20.26および9.21.24をリリースし、CVE-2026-13321を含む9件の脆弱性を一括で修正した[1][2]。もっとも深刻なCVE-2026-13321（CVSS 8.6）は、NSEC/NSEC3（DNSSECでレコードの不存在を証明するための仕組み）のレコードがゾーンの外を指していても検証をすり抜けてしまう不具合で、あるゾーンを管理する攻撃者が別のゾーンの否定応答を偽造できる「ゾーン越えキャッシュポイズニング」につながる[1]。影響バージョンは9.11.0〜9.18.50、9.20.0〜9.20.24、9.21.0〜9.21.23と広く、権威DNS・キャッシュDNS双方の運用チームに棚卸しとパッチ適用の判断を迫る。DNSはあらゆるサービスの入口であり、検証をすり抜ける脆弱性は事業影響が読みにくい分、優先順位付けの考え方を平時から整理する価値がある。
予備知識
- DNSSEC（DNS Security Extensions）: DNS応答が改ざんされていないことを電子署名で検証する拡張機能。
- NSEC/NSEC3: DNSSECで「このドメイン名は存在しない」ことを証明するためのリソースレコード。自ゾーン内の次のドメイン名（Next Domain Name）を示す。
- 権威DNSサーバ: ドメインのゾーン情報を保持し、問い合わせに正式な回答を返すサーバ（BINDなど）。
- キャッシュ（フル）リゾルバ: クライアントに代わって権威DNSへ問い合わせ、DNSSEC検証を行うサーバ。
DNSSEC時代のDNS設定・運用を体系的に解説しており、検証バイパス対応の背景知識として参照できる
BIND 9のDNSSEC検証バイパスとは CVE-2026-13321の技術的な中身
CVE-2026-13321は、DNSSEC検証を行うBINDのリゾルバが、正しく署名されたNSEC/NSEC3レコードの「Next Domain Name」フィールドが署名者自身のゾーンの外を指していても拒否せず受け入れてしまう脆弱性である[1]。本来NSEC/NSEC3レコードは自ゾーン内の「次に存在するドメイン名」を示すことで、問い合わせたドメインが存在しないことを証明する仕組みだ。BINDは署名者名とゾーンの一致を検証していなかったため、自分の管理する署名済みゾーンを持つ攻撃者が、別ゾーン（被害者ゾーン）にまで及ぶNSECレコードを作成できてしまう[1]。
結果として、DNSSEC検証を有効にしたリゾルバは偽造された否定応答を「AD=1（認証済み）」としてキャッシュし、クライアントへ正当な応答として返してしまう。ISCの脆弱性区分ではCWE-346（信頼できない入力の誤った受け入れ）に該当し、CVSSスコアは8.6（High）と評価された[1]。ISCは本稿執筆時点で実際の悪用は確認していないとしつつ、既知の回避策は存在しないと明記している[1]。発見者はPalo Alto NetworksのQifan Zhang氏である[1]。
BIND9自体の構築・設定・運用手順を扱っており、パッチ適用や設定確認の実務に直結する
影響範囲とパッチ状況 9件のCVEと対象バージョン
今回のBIND 9.20.26／9.21.24は、CVE-2026-13321を含む計9件を一括で修正する、定例を超えた規模のセキュリティリリースである[1][2]。CVE-2026-13321の影響バージョンは9.11.0〜9.18.50、9.20.0〜9.20.24、9.21.0〜9.21.23で、長期にわたる複数ブランチにまたがる[1]。
JPCERT/CCが公開したJVNVU#97496543は、9件のうち6件を次のように分類している[2]。
| 分類 | 該当CVE | 内容 |
|---|---|---|
| DNSSEC検証バイパス | CVE-2026-13321 | ゾーン外NSEC/NSEC3の誤許容によるキャッシュポイズニング |
| デーモン異常終了（DoS） | CVE-2026-12617、CVE-2026-13204、CVE-2026-10822 | レコード順序やNSEC/NSEC3併存時、PRIVATEDNSアルゴリズムの鍵レコード処理での異常終了 |
| リソース枯渇 | CVE-2026-11605、CVE-2026-11622 | 不要な署名検証によるCPU消費、ランダムサブドメイン攻撃時のメモリ超過 |
残る3件は報道ベースでRPZポリシー回避やキャッシュ関連の問題と伝えられるが、ISC・JPCERT双方でのCVE番号単位の確認は本稿執筆時点で取れておらず[未確認]、分類名にとどめる[3]。
今回取り上げるのはAD FS（Active Directory Federation Services、Windows Server上でSSO・フェデレーション認証を提供する機能）のDKM（Distributed Key Manager）[…]
パッチ適用の優先順位付け 運用チームが今判断すべきこと
パッチ適用の優先順位付けとは、限られた保守時間の中で影響が大きいシステムから修正を当てる順番を決める作業である。BIND運用チームがまず行うべきは稼働中BINDバージョンの棚卸しだ。対象範囲（9.11.0〜9.18.50、9.20.0〜9.20.24、9.21.0〜9.21.23）に該当するかを、権威サーバとキャッシュ/フルリゾルバの両方で確認する[1]。
次に優先度を分ける軸は、DNSSEC検証（validation）を有効にしているかどうかだ。CVE-2026-13321はDNSSEC検証を行うリゾルバでのみ意味を持つため、検証を有効化したサーバが最優先の対象になる[1]。権威専用でDNSSEC検証を行わないサーバはCVE-2026-13321自体の影響は小さいが、DoS系・リソース枯渇系の他CVEは権威サーバ側にも及ぶため、パッチ適用そのものは先送りしない方がよい[2]。
パッチ未適用の期間は、ISCが既知の回避策がないと述べている以上、外部到達可能なリゾルバの棚卸しと限定公開化、異常なNSEC応答の監視程度しか緩和策がない[1]。恒常的にはマイナーバージョンアップを定例保守サイクルに組み込み、サポート対象ブランチを追い続ける運用に寄せることが適用漏れを減らす。
Linuxカーネルに組み込まれた仮想化基盤「KVM（Kernel-based Virtual Machine）」のx86シャドウMMU（ゲストのメモリ管理をホスト側で模倣する仕組み）に、導入からおよそ16年間気づかれずに存在していたuse[…]
DNSインフラの防御多層化 BIND単体に頼らない設計
防御多層化とは、単一ソフトウェアの脆弱性が事業影響に直結しないよう複数の防御層を重ねる設計思想である。DNSSEC検証ロジックにバグが混入しても、実装依存の欠陥は避けられない。
ソフトウェア層では、BINDに限らずUnbound・Knot Resolver等の異なる実装を組み合わせ、同一の脆弱性を全系統が同時に踏むリスクを下げる選択肢がある。設定層では、どのサーバがDNSSEC検証を有効にしているかを一覧化し、優先順位付けの判断材料として常に更新しておく。監視層では、想定外のNSEC/NSEC3応答やAD=1フラグの異常な出現をログから検知する体制を整える。
まとめ
BIND 9のDNSSEC検証バイパスは、DNSSECという「信頼を検証する仕組み」自体の実装に穴があった点で、権威DNS運用の見落としを問う事例だ。読者がまず着手すべきは、稼働中BINDのバージョン棚卸しと、DNSSEC検証を有効にしているサーバの洗い出しである。該当バージョンかつ検証有効のリゾルバは最優先でパッチを適用し、権威専用サーバも定例保守の枠内で速やかに追随する。異なるDNS実装の併用や異常応答の監視といった多層防御を平常時から整えておくことが、次回以降の広範囲パッチへの対応速度を左右する。
よくある質問（FAQ）
Q1. CVE-2026-13321はすでに悪用されていますか。
ISCは本稿執筆時点で実際の悪用は確認されていないとしている[1]。既知の回避策がないため、対象バージョンかつDNSSEC検証を有効にしている場合は早期のパッチ適用が推奨される。
Q2. DNSSEC検証を使っていない権威DNSサーバも対応が必要ですか。
CVE-2026-13321自体はリゾルバに関わる脆弱性だが、今回同時修正された9件にはデーモンの異常終了やリソース枯渇に関わるものも含まれるため、権威専用サーバでもバージョンアップは対象になる[2]。
Q3. 影響バージョンの範囲が広いのはなぜですか。
NSEC/NSEC3の署名者名とゾーンの一致検証が長期間実装されていなかったためで、9.11.0以降の広いブランチに共通するロジック上の欠陥だったと説明されている[1]。
