BIND 9が四つの脆弱性を修正｜DNSの構成別条件と9.20.30への更新を確認

ISCは2026年10月21日、BIND 9に関する四つのセキュリティアドバイザリを公開しました。修正版として9.20.30などが案内され、JVNも10月22日に注意を呼びかけています。DNSを自社運用している場合は、WebサーバーやPHPの更新とは別に、名前解決を担う基盤の確認が必要です。

今回の問題は、すべて同じ条件で起こるわけではありません。再帰問い合わせの処理、GSS-TSIG、redirectゾーン、RPZという異なる機能や構成が関係します。特に遠隔コード実行の可能性が示された問題には、署名済みメッセージの取得と再送などの条件があります。「BINDを使っていれば誰でも直ちにコード実行できる」と広げず、利用構成と修正状況を照合することが重要です。

本記事は10月22日にISCの各アドバイザリと配布ページ、JVNを直接確認したニュースです。以下の運用手順や確認項目は本サイトの提案であり、対象環境で攻撃や性能の実験を行った結果ではありません。

四つの問題は影響する機能が違う

JVNの注意喚起が紹介しているのは、CVE-2026-19630、CVE-2026-94300、CVE-2026-96888、CVE-2026-97313です。ISCはいずれも深刻度をHighとしていますが、攻撃成立条件まで同一という意味ではありません。

CVE	ISCが説明する主な条件・影響	CVSS v3.1
CVE-2026-19630	リゾルバーの受信メッセージ処理で資源消費が増大しサービス拒否につながる	7.5
CVE-2026-94300	GSS-TSIGの署名済みUDPメッセージの再送などによりメモリー破壊やコード実行の可能性	8.1
CVE-2026-96888	redirectゾーンと厳格なQNAME minimizationの併用でnamedが異常終了する可能性	7.5
CVE-2026-97313	複数RPZのrecursive-only設定の組み合わせなどにより異常終了する可能性	7.5

表の数値はそれぞれの脆弱性の評価です。四件をまとめた総合スコアではありません。数値だけで並べるより、自社のDNSが再帰リゾルバーなのか、権威DNSなのか、両方の役割を持つのかを先に整理すると、調べるべき設定を絞れます。

資源消費の問題はリゾルバーの処理能力に関わる

ISCのCVE-2026-19630の説明によると、特定の構造を持つDNSメッセージを受け取った際、追加の処理が十分に抑制されず、多数のメッセージによってCPUやメモリーを消費する可能性があります。影響はリゾルバーのサービス拒否です。

本サイトの運用上の見方では、Webページの公開用DNSだけでなく、アプリケーションが外部APIやメール配信先を調べるための名前解決も確認対象です。公開サイトのHTMLを正常に配れていても、裏側の名前解決が滞れば、一部の外部連携が失敗する構成があります。

ただし、今回の脆弱性が特定のサイト障害を引き起こしたと報告するものではありません。自社の通信経路と依存先を把握するための確認項目です。障害を見つけても、DNSの応答遅延だけで今回の攻撃と断定せず、通常時の負荷やネットワークの問題も含めて切り分けます。

コード実行の可能性にはGSS-TSIGの条件がある

CVE-2026-94300のアドバイザリは、GSS-TSIGで署名されたUDPメッセージの並行処理がメモリー破壊につながり得ると説明しています。攻撃者が以前に署名されたUDPメッセージを取得し、交渉済みのTSIG鍵が有効な間に再送できることなどが関係します。

ISCは、攻撃者が管理するゾーンへの細工した問い合わせを組み合わせることで、遠隔コード実行につながる可能性も示しています。この条件を省いて「DNSへの通常の問い合わせだけで全環境がRCE」と表現するのは適切ではありません。

運用者が確認すべきなのは、パッケージ名だけではなく、GSS-TSIGの利用、関係する通信経路、設定を管理している担当です。自社で利用していないと判断する場合も、古い設定や別のDNSインスタンスまで含めて確認します。一方、この一件の条件に当てはまらないことだけで、残る三件も影響なしとはできません。

redirectとRPZは設定の組み合わせまで読む

CVE-2026-96888では、リゾルバーにredirectゾーンが設定され、qname-minimizationがstrictであることの組み合わせが問題となります。特定の問い合わせを契機にアサーションに失敗し、namedが終了する可能性があります。

CVE-2026-97313は、再帰問い合わせを許可し、少なくとも二つのRPZを使用する構成が対象です。一方のRPZがrecursive-only yes、別のRPZがrecursive-only noという組み合わせなどが関係します。yesは既定値であるため、設定ファイルに明示していない項目も含めて読む必要があります。

本サイトの提案は、設定の検索結果だけで判断せず、include先や生成される設定を含め、実際に起動しているインスタンスへ結び付けることです。テンプレート上の記述がなくても、別ファイルで有効になっている機能を見落とさないようにします。設定変更を回避策として独自に組み立てるより、まず提供元の修正を適用できるか確認してください。

9.20.30と開発版を同じ更新先として扱わない

ISCの各告知は、修正版として9.20.30、9.21.27、購読者向けの9.20.30-S1を案内しています。公式配布ページでは、9.20.30はCurrent Stable ESV、9.21.27はDevelopmentと区別されています。本番環境の更新先を決める際は、この違いも確認してください。

通常版について、CVE-2026-19630とCVE-2026-94300の影響範囲には9.11.0から9.18.50、9.20.0から9.20.29、9.21.0から9.21.26が含まれます。CVE-2026-96888とCVE-2026-97313の通常版は9.16.0以降の該当系列が示されています。購読者向けの範囲は別に記載されているため、使用する製品系列の表を直接照合する必要があります。

注意したいのは9.18系です。配布ページには9.18.50が残っていますが、状態はEOLとされています。四件のアドバイザリが案内する修正版に9.18系はありません。「公式サイトから取得できるから今回も安全」と判断せず、サポートされる系列への移行、またはOS提供元が保証する修正状況を確認します。

OSのパッケージでは修正のバックポートにより、上流版と表示番号の対応が単純でない場合があります。本サイトは今回、各OSの修正済みパッケージ番号を網羅して検証していません。番号だけを比較せず、利用するディストリビューションのアドバイザリと変更履歴で、今回のCVEへの対応を確認してください。

パッケージ更新と稼働中のプロセスを照合する

ここからは本サイトの適用確認の提案です。最初に、自社運用のDNS、コンテナー、委託先、マネージドDNSを分け、誰が修正を適用するかを決めます。外部サービスを契約しているだけで、その内部がBINDだと推測する必要はありません。自分が管理できない範囲は、提供元の告知や問い合わせで状況を確認します。

• 稼働するBINDの系列、配布元、役割、関係する設定を記録する
• 対象CVEを修正した配布物であることを確認し、設定の互換性を検証する
• 冗長構成の切り替え順序と復旧手順を決め、更新を適用する
• 必要なプロセスの再起動・置き換えを行い、稼働中の版を確認する
• 権威応答と再帰問い合わせを用途ごとに試験し、負荷や異常終了を監視する

インストール済みファイルが新しくても、古いプロセスが動き続けていれば完了とはいえません。コンテナーを使う構成でも、イメージの取得と稼働インスタンスの置き換えを区別します。どの操作で新しい実行ファイルが使われるかは、実際の配布方式に合わせて確かめます。

試験は、任意の外部DNSへ攻撃用の問い合わせを送ることを意味しません。自社で管理する範囲で、通常の名前解決、必要な更新処理、監視の動作を確認します。複数台を同時に止めて冗長性を失わないよう、作業中も利用者の名前解決を維持できる順序を用意してください。

悪用未確認と更新不要は同じではない

ISCは四件とも、アドバイザリの公開時点で実環境における悪用を認識していないとしています。また、既知の回避策はないと説明しています。これは将来の悪用が起きない保証ではなく、現時点の提供元の把握状況です。

本サイトの提案は、悪用の報道を待つのではなく、適用可能な修正版と構成を今確認することです。特にサポート終了系列を使い続けている場合、今回の更新作業だけでなく、次のセキュリティ修正を受け取れる状態へ戻す計画も必要になります。

DNSの脆弱性対処と、ドメイン登録アカウントの保護は別の作業です。更新を終えた後の運用整理には、ドメイン登録とDNS管理を守る既存解説も参考になります。リンク先は恒久対策の解説で、今回のBINDの修正情報を掲載した記事ではありません。