結論から。Internet Systems Consortium（ISC）は2026年7月22日、DNSサーバソフト「BIND 9」のセキュリティ更新を公開し、9件の脆弱性を修正しました。最大はCVSS 8.6のCVE-2026-13321で、DNSSECの検証をすり抜けてキャッシュポイズニング（キャッシュ汚染）を成立させ得る内容です。BIND 9をキャッシュ（フルサービス／リゾルバ）DNSサーバとして自社運用している組織は、影響有無の確認と計画的な更新適用を急いでください。JPRS（日本レジストリサービス）なども緊急対応を呼びかけています。
- 何が起きたか：BIND 9で9件の脆弱性が修正。修正版は9.20.26／9.21.24。
- 誰に影響するか：BIND 9をキャッシュDNSサーバとして運用する組織（特にDNSSEC検証を有効にしている場合）。
- 今すぐ何をすべきか：稼働中バージョンの棚卸し→修正版への更新計画。回避策が無い脆弱性が多く、更新が基本対応。
何が起きたのか
BINDはインターネットで最も広く使われるDNSサーバ実装の一つで、社内の名前解決やキャッシュDNSサーバとして利用している組織も少なくありません。今回ISCは9件の脆弱性（うち重要度「高」が7件）をまとめて修正し、9.20.26および9.21.24（サポート版は9.20.26-S1）をリリースしました。
特徴的なのは、深刻な脆弱性の多くがDNSSECの検証（validation）層に集中している点です。DNSSECは応答が正規のものかを電子署名で保証する仕組みですが、その検証にすり抜けの穴があると、「署名で守られているはず」という前提そのものが崩れます。ここが今回の肝です。
主な脆弱性の一覧
影響を受けるバージョンは各CVEで概ね共通し、9.11.0〜9.18.50／9.20.0〜9.20.24／9.21.0〜9.21.23（系統により範囲差あり）です。修正版はいずれも9.20.26／9.21.24です。
| CVE | CVSS | 種別 | 概要 |
|---|---|---|---|
| CVE-2026-13321 | 8.6 | キャッシュ汚染（DNSSEC） | NSEC/NSEC3レコードで署名者ゾーンの一致を検証しない経路があり、別ゾーンの署名で被害ゾーンの「存在しない」応答などを偽造され得る |
| CVE-2026-11721 | 7.5 | キャッシュ汚染（ラベル数不整合） | RRSIGのLabels値と署名者名のラベル数の不整合を突いてワイルドカード応答を偽装。既定有効の synth-from-dnssec が関与 |
| CVE-2026-10723 | 6.8 | NXDOMAIN偽造 | 存在しない応答（NXDOMAIN）の偽造につながる |
| CVE-2026-11331 | 7.5 | RPZバイパス | Response Policy Zone（フィルタ）のルールを回避され得る |
| CVE-2026-11605 / 11622 | 7.5 | リソース枯渇（DoS） | CPU／メモリを消費させるサービス妨害 |
| CVE-2026-12617 / 13204 / 10822 | 7.5前後 | クラッシュ（DoS） | 細工した応答等でbindを異常終了させ得る |
※CVSSスコア・影響範囲の正確な値は各CVEで差があります。適用判断は必ずISC公式アドバイザリの一次情報で確認してください。
なぜDNSSECの穴は特に危険なのか
問いに簡潔に答えると、DNSSECは「信頼の最後の砦」だからです。キャッシュポイズニングは、DNSキャッシュに偽の名前解決結果を注入し、利用者を偽サイトへ誘導したり通信を横取りしたりする攻撃です。DNSSECはまさにこれを署名検証で防ぐための仕組みなので、検証をすり抜けられると、「守られている」と信じたまま偽の応答をキャッシュして配ってしまいます。
CVE-2026-13321では、攻撃者が自分の管理する署名済みゾーンを一つ持っていれば、被害ゾーンについて認証済みに見える否定応答を偽造できるとされます。リゾルバと権威サーバの間に立てる（中間者）位置にいる攻撃者にとっては、影響範囲が広い危険な穴です。
現場目線の課題
率直なところ、DNSは「動いていて当たり前」で、いったん安定稼働すると更新の優先度が後回しになりがちなミドルウェアです。しかも今回のように公式の回避策が無く「更新するしかない」脆弱性が多いと、限られた人員での計画停止・切り替え作業の段取りがそのまま負担になります。冗長構成のキャッシュDNSを順番に更新する、社内解決に使っているアプライアンスやコンテナ内のBINDまで漏れなく把握する——このあたりの棚卸しの精度が、対応の速さを左右します。
「自社はDNSSEC検証を有効にしていないから関係ない」と早合点しないことも大切です。DoS系やRPZバイパスなど、検証設定に依らず影響し得る脆弱性も含まれています。まずは全体像として「9件まとめて修正された」と捉え、対象バージョンかどうかで判断するのが安全です。
情シスはどうすべきか
基本対応はシンプルで、対象バージョンなら修正版（9.20.26／9.21.24）へ更新することです。ディストリビューションのパッケージを使っている場合は、各ベンダの更新（例：Debian等のセキュリティ更新）が出ているので、そちらの適用でも構いません。作業前後で名前解決とDNSSEC検証が正常かを確認しましょう。
脆弱性管理の進め方や、パッチ適用を含む日常運用の考え方は、公的機関の指針が土台になります。まずはIPAの資料に目を通しておくと、経営層・他部署への説明材料としても使えます。
- IPA「中小企業の情報セキュリティ対策ガイドライン」：https://www.ipa.go.jp/security/guide/sme/index.html
- ISC公式（BIND 9のアドバイザリ・KB）：https://kb.isc.org/／https://www.isc.org/blogs/
あわせて、DNSの権威側・キャッシュ側それぞれで「誰が・どのソフトを・どのバージョンで」動かしているかを可視化しておくと、次に同種の脆弱性が出たときの初動が速くなります。
まとめ
- ISCが2026年7月22日、BIND 9で9件（高7件）の脆弱性を修正。修正版は9.20.26／9.21.24。
- 最大はCVSS 8.6のCVE-2026-13321。DNSSEC検証をすり抜けるキャッシュ汚染で、深刻な脆弱性は検証層に集中している。
- 公式回避策の無いものが多く、基本対応は対象バージョンの棚卸し＋修正版への更新。検証無効でも影響し得るDoS系も含むため油断しない。
関連記事
出典
- Security NEXT「『BIND 9』にキャッシュ汚染など複数脆弱性 – 修正版を公開」：https://www.security-next.com/187829
- ISC KB「CVE-2026-11721」：https://kb.isc.org/docs/cve-2026-11721
- BIND 9 Release Notes（9.20系）：https://bind9.readthedocs.io/en/stable/notes.html
