自社の社員が業務でアクセスするサイト、送受信するメール。その宛先を裏側で決めているのがDNSだ。そのDNSが「別の宛先」を返すよう仕込まれたら、社員は気づかないまま偽サイトに誘導される。 広く利用されているDNSサーバソフト「BIND 9」に、キャッシュ汚染を含む複数の脆弱性が公表され、開発元のISC（Internet Systems Consortium）は2026年7月22日、修正版となる BIND 9.20.26／9.21.24 を公開した。
DNSは、普段まったく意識されない。しかし止まれば全社の通信が止まり、汚染されれば全社員が偽の宛先へ流される。本記事は「DNSが何かを意識してこなかった」情シス・経営者を主対象に、今回の脆弱性の意味を非エンジニアの言葉に翻訳したうえで、自社のDNSを誰が握っているのかを確認する手順と、委託している場合に問うべき質問を整理する。
この記事の要点
-
ISCは2026年7月22日、BIND 9の複数の脆弱性に対する修正版（9.20.26／9.21.24、およびPreview Editionの9.20.26-S1）を公開した。修正対象にはキャッシュ汚染（利用者を偽の宛先へ誘導しうる）と、named（BINDの本体プロセス）を異常終了させるサービス妨害（DoS）が含まれる。
-
特に注意したいのはゾーンをまたぐキャッシュ汚染 CVE-2026-13321（CVSS 8.6・High）。DNSSEC署名済みゾーンを管理する攻撃者が、別の被害者ゾーンに対する認証済みの否定応答を作れる不具合だ。
-
影響を受けるのは主に キャッシュDNSサーバ（フルリゾルバ）。社内利用者からの名前解決を代理で行い、結果を一定時間キャッシュする役割のサーバだ。ここが汚染されると、影響は「その社内で名前を引く全員」に及ぶ。
-
CVE-2026-13321の影響版は9.11.0〜9.18.50、9.20.0〜9.20.24、9.21.0〜9.21.23。9.18系は2026年7月22日にEOLとなったため、継続利用ではなく9.20系などサポート中の系列への移行を判断する。修正版は9.20.26／9.21.24。
-
ただし本当の第一歩は「更新する」ことではない。自社のDNSを誰が運用しているのか（自社サーバ／ISP任せ／クラウド／委託先）を、まず特定することだ。ここが不明なままでは、更新の要否すら判断できない。
そもそもDNSとは何か、なぜ止まると全社が止まるのか
DNSは、人間が使う「gxo.co.jp」のような名前を、機械が使う数字の住所（IPアドレス）に変換する仕組みだ。社員がブラウザにURLを打ち込んでも、メールソフトが送信先を探すときも、業務システムがサーバに接続するときも、その裏では必ず「この名前の実際の住所はどこか」という問い合わせ（名前解決）が走っている。
ここで理解しておきたいのは、DNSは「一度も意識されないのに、全通信の起点にある」インフラだという点だ。電気やガスに近い。動いている間は誰も存在を思い出さないが、止まった瞬間に全業務が止まる。名前解決ができなければ、社内から見て「サイトが開かない」「メールが送れない」「クラウドの業務システムに繋がらない」が同時多発する。原因がDNSにあると気づくまでに時間がかかりやすいのも、普段意識していないインフラゆえの特徴だ。
そしてDNSには、止まるより厄介な壊れ方がある。「動いているのに、間違った答えを返す」状態だ。これがキャッシュ汚染である。
FREE DOWNLOAD
中小企業のDX推進「失敗を防ぐ5ステップ」ガイドを無料でお送りします
多くの企業がつまずくポイントを着手順に整理した無料ガイド。相談する前に、自社の現在地と進め方を掴めます。
キャッシュ汚染で何が起きるか：利用者を偽サイトへ、メールを攻撃者へ
キャッシュDNSサーバは、一度引いた名前解決の結果を「キャッシュ」として一定時間ためておき、次に同じ問い合わせが来たら即座に返す。速くするための仕組みだ。キャッシュ汚染とは、このキャッシュに 攻撃者が用意した偽の対応（この名前＝攻撃者の住所）を紛れ込ませる 攻撃を指す。
汚染が成立すると、非エンジニアの言葉で言えば次のようなことが起きうる。
-
利用者を偽サイトへ誘導する。 社員が正しいURLを打ち込み、正しいブックマークから開いても、DNSが偽の住所を返せば、たどり着くのは攻撃者が用意した偽サイトだ。見た目が本物そっくりの銀行サイトや取引先ポータルに、社員が自らIDとパスワードを入力してしまう。URLは正しいので、利用者側からはほとんど見抜けない。
-
メールを攻撃者側へ誘導する。 メール配送の宛先を決めるMXレコードなどが汚染されれば、送ったつもりのメールが攻撃者の経由地を通る、あるいは正規のメールサーバになりすました相手にやり取りを盗まれる、といった事態につながりうる。
-
社内システムやクラウド接続の乗っ取り起点になる。 業務システムやSaaSへの接続先が偽の住所に差し替われば、そこを入口に認証情報やデータが抜かれる。
要点は、キャッシュ汚染は「その汚染されたDNSサーバを使っている人、全員」に一斉に効くという点だ。1台のPCがウイルスに感染したのとはスケールが違う。社内の名前解決を1台のキャッシュサーバに集約している中堅企業であれば、汚染1回で全社員が同じ偽の宛先を掴まされうる。しかも各PCには何のマルウェアも入っていないので、端末を調べても異常は見つからない。
今回の脆弱性の中身：DNSSEC署名を逆手に取る「認証付きの嘘」
今回ISCが修正した中で最も注目されるのが、ゾーンをまたぐキャッシュ汚染 CVE-2026-13321（CVSS 8.6・High とされる）だ。ここは少しだけ技術に触れる。
DNSには、応答が本物であることを暗号署名で保証する DNSSEC という上位の仕組みがある。皮肉なことに、今回の不具合はその署名の検証の緩さを突く。ISCの説明によれば、BINDのリゾルバが、NSECレコードの「Next Domain Name（次のドメイン名）」フィールドが署名者のゾーンの外を指していても、それを妥当な署名済みレコードとして受け入れてしまう、というものだ。結果として、DNSSEC署名済みのゾーンを1つ正規に握った攻撃者が、無関係な被害者ゾーンについて「そのドメインは存在しない」という認証付きの否定応答（AD=1、検証済みの印付き）を偽造できるとされる。
平たく言えば、「正しく署名されているから安全」と信じて受け入れる仕組みを逆手に取り、署名のお墨付き（本物の証）を付けたまま嘘をつく攻撃だ。DNSSECを入れているから安心、という前提が崩れる点で、影響が理解しにくく、かつ厄介である。ISCは、この不具合に対して有効な回避策（ワークアラウンド）はなく、修正版への更新が必要としている。悪用の実例は現時点で確認されていないとされるが、それは「今は安全」を意味しない。
今回の修正には、このほかにもキャッシュ汚染系（ラベル数の不整合を突くもの、NXDOMAIN＝「存在しない」応答を偽造しうるものなど）や、namedを異常終了させてサービスを止めるDoS系、ランダムなサブドメインを大量に問い合わせてメモリを異常消費させるものなど、複数の不具合が含まれるとされる。CVSSの数値は不具合ごとに異なるが、経営判断としては数値の大小より「止まったとき・汚染されたときに自社の誰が困るか」で見るべきだ（この見方は後述する）。
最優先の一手：自社のDNSは「誰が」運用しているのか
ここで多くの企業がつまずく。「BINDを更新しなさい」と言われても、そもそも自社がBINDを使っているのか、DNSを誰が動かしているのかを、情シス自身が即答できないことが少なくない。だが、この特定こそが今回の本題だ。更新の要否も、委託先への問い合わせの要否も、すべてここから決まる。
自社のDNSは、おおむね次のどれか（複数併存も多い）に分類できる。
-
A. 自社でDNSサーバを立てて運用している。 社内にBINDやその他のDNSソフト（Unbound、Windows DNSなど）を動かすサーバがある。今回のBINDの脆弱性が直接刺さるのはここだ。誰がそのサーバのOSとBINDを更新しているか、が問われる。
-
B. ISP・回線業者に任せている。 社内PCが名前解決に使っている先が、契約プロバイダの提供するキャッシュDNSサーバである場合。更新の責任はプロバイダ側にあるが、「自社が使っているかどうか」の把握は必要だ。
-
C. クラウド／マネージドDNSを使っている。 権威DNS（自社ドメインの正解を持つ側）をクラウドのマネージドサービスに預けている場合。運用主体はクラウド事業者だが、設定（レコード）の管理責任は自社に残る。
-
D. 制作会社・保守ベンダー・データセンターに委託している。 サイト制作会社やサーバ保守業者がまとめてDNSも面倒を見ている、というケース。「誰が管理しているか自社では分からない」状態が最も危ない。
多くの中堅企業は、これらが歴史的経緯でバラバラに混在している。社内の名前解決用（キャッシュ側）はISP任せ、自社ドメインの権威側は昔の制作会社が管理、一部の業務システムだけ社内にDNSがある——といった具合だ。だからこそ、まず地図を描く必要がある。
自社のDNS運用者を確認する手順
情シスが手を動かして確認できる、実務的な順序を示す。
-
社内PCが名前解決に使っているサーバ（キャッシュDNS）を確認する。 WindowsならコマンドプロンプトでネットワークアダプタのDNSサーバ設定を確認する（
ipconfig /allで「DNSサーバー」を見る）。そこに出てくるアドレスが、社内のサーバか、ISPのものか、クラウド（例：著名なパブリックDNS）かを切り分ける。社内アドレスなら「A」の可能性が高い。 -
そのDNSサーバの正体を管理台帳・構成図で確認する。 台帳がなければ、それ自体が課題だ。サーバがあるなら、OSとDNSソフト（BINDか否か）、バージョン、誰が更新しているかを確認する。
-
自社ドメインの権威DNSがどこかを確認する。 自社ドメイン（例：会社の公式サイトのドメイン）について、権威DNSがどのサーバに設定されているかを調べる。ドメイン登録事業者の管理画面、あるいはNSレコードの確認で分かる。ここがクラウドか、制作会社のサーバかで、レコード変更の窓口が誰かが決まる。
-
契約書・保守契約を確認する。 「DNSの運用・更新は誰の責任か」が契約に明記されているかを見る。多くの場合、明記されていない。この曖昧さこそが、いざというときに「うちの担当ではない」と互いに押し付け合う原因になる。
-
BINDを自社で動かしていることが判明した場合は、バージョンを確認する。 動作中のBINDのバージョンは
named -vで確認できる。9.18系・9.20.24以前・9.21.23以前であれば、今回の修正対象に該当する可能性がある。
ケース別の動き方：自社運用と委託の分岐
確認の結果によって、次にやることが分かれる。
自社でBINDを運用している場合の更新統制
自社にBINDサーバがあるなら、更新は必要だ。ただし「すぐ最新版に上げる」を無計画にやると、DNSが止まって全社が止まる本末転倒になりかねない。DNSは土台インフラなので、更新の作法が問われる。
-
影響範囲を先に確定する。 そのBINDが、社内の名前解決（キャッシュ）を担っているのか、自社ドメインの権威側なのか、両方か。今回のキャッシュ汚染系はリゾルバ（キャッシュ側）に効くため、キャッシュを担うサーバを優先する。
-
冗長性を確認する。 DNSサーバが1台しかないなら、更新中の停止がそのまま全社停止になる。プライマリ・セカンダリの2台構成なら、片方ずつ更新して無停止で切り替えられる。冗長化されていないこと自体が、更新以前のリスクだ。
-
検証してから本番へ。 設定ファイル（named.conf）やゾーン設定が、新バージョンで問題なく動くかを検証環境で確認してから適用する。
-
「誰が」「いつ」「どのバージョンへ」更新したかを記録する。 DNSは属人化しやすい。担当者しか触れない状態は、その担当者が不在のときに更新が止まるリスクそのものだ。更新統制を仕組みにしておく。
自社にこうしたインフラの更新統制を回す体力がない場合、DNSのような止められない土台を含めた運用の設計・伴走は外部に持たせる選択肢がある。継続的な脆弱性対応や更新統制の型についてはセキュリティ運用伴走（リテイナー）で扱っている。
委託・ISP・クラウド任せの場合に「問う」
自社でBINDを触っていない場合、手を動かすのは委託先だ。だが「向こうがやってくれるはず」で放置するのは危うい。確認したという記録を、自社側に残すことが要点になる。丸投げは、いざ汚染や停止が起きたときに「誰の責任か」を宙に浮かせる。
委託先・ISP・クラウド事業者へ、次を確認する（そのまま使える確認文テンプレは後掲）。
- 自社が使っているDNS（キャッシュ側／権威側）にBINDが使われているか。使っている場合、今回の脆弱性の対象バージョンか。
- 修正版（9.20.26／9.21.24 相当）への更新予定と、その完了報告をもらえるか。
- 更新に伴うサービス停止の有無・時間帯。
- 今後、DNS関連の脆弱性が出た際の連絡と対応のフロー（誰から誰へ、どのくらいの速さで）。
「土台のインフラ」の棚卸し：DNSは氷山の一角
今回のDNSは、より大きな問題の入口にすぎない。多くの中堅企業では、普段意識しない土台インフラの「運用責任者」が曖昧なまま何年も動いている。DNSだけでなく、次のようなものが同じ構造を抱えている。
- ドメイン名の登録・更新（更新忘れでドメイン失効＝全サービス停止、という事故は実際に起きる）
- SSL/TLS証明書の管理と更新期限
- メール配送（SPF／DKIM／DMARCの設定）
- ファイアウォール・VPN機器のファームウェア更新
- 社内で動く各種ミドルウェア・OSの脆弱性対応
これらに共通するのは、①普段は誰も意識しない、②止まる／破られると影響が全社に及ぶ、③「誰が運用しているか」が社内で即答できない、という三点だ。今回のBIND脆弱性は、この曖昧さを点検する良い口実になる。DNSを起点に、「止まったら全社が困るのに、担当者名が空欄になっている土台」を洗い出すことを勧めたい。棚卸しから運用体制の再設計・実装までを含めて整理したい場合はDX・システム開発やセキュリティ事業が入口になる。
CVSSの高低ではなく「止まったときの影響範囲」で語る
脆弱性の記事には必ずCVSS（深刻度スコア）が出る。今回のCVE-2026-13321は8.6とされ、確かに高い。しかし経営判断の現場で、数値の大小だけを見ても意思決定はできない。CVSSは「その脆弱性そのものの技術的な危険度」を測る共通尺度であって、「自社にとっての痛さ」ではないからだ。
同じCVSS 8.6でも、自社で使っていないソフトなら痛みはゼロだし、逆にCVSSが中程度でも、全社の名前解決を担う1台に刺されば全業務が止まる。だから経営として問うべきは、スコアではなく次の一点に尽きる。
「これが悪用されて止まる／汚染されるとき、自社の誰が、どの業務が、どれだけ困るのか」
DNSの場合、答えは「全社員」「全通信」であることが多い。だからこそ、CVSSが7点台でも8点台でも、影響範囲が全社に及ぶ土台インフラは優先度を上げる——この読み替えが、非エンジニアの経営者が脆弱性ニュースを自社の判断に翻訳する唯一の実務的な方法だ。逆に、CVSSが9点台でも自社に無関係な製品なら、慌てて動く必要はない。数値に振り回されず、影響範囲で優先順位を決める習慣を、DNSを機に持っておきたい。
確認チェックリスト（そのまま使える）
- 社内PCが使っているキャッシュDNSサーバのアドレスを確認した（
ipconfig /all等） - そのアドレスが「自社サーバ／ISP／クラウド／委託先」のどれかを切り分けた
- 自社ドメインの権威DNSがどこか（クラウド／制作会社／自社）を確認した
- 自社でBINDを動かしているか、動かしている場合のバージョンを確認した（
named -v） - バージョンが影響版（9.18系／9.20.24以前／9.21.23以前）に該当するか照合した
- DNSサーバが冗長化（プライマリ・セカンダリ）されているか確認した
- DNSの運用・更新責任が、契約書・保守契約に明記されているか確認した
- 委託先・ISPに、対象か・更新予定か・停止有無を問い合わせ、回答を記録した
- DNS更新を「誰が・いつ・どのバージョンへ」記録する運用を決めた
- DNS以外の土台インフラ（ドメイン更新・証明書・メール認証・機器FW）の担当者空欄を洗い出した
- 影響範囲（全社か一部か）で脆弱性の対応優先度を判断する基準を共有した
委託先への確認文テンプレート
自社でDNSを触っていない場合、そのまま委託先・ISP・クラウド窓口へ送れる文面を用意した。適宜、自社名・ドメインに置き換えて使ってほしい。
お世話になっております。〔自社名〕でございます。 2026年7月22日にDNSサーバソフト「BIND 9」の複数の脆弱性（キャッシュ汚染を含む）が公表され、修正版が提供された件について、弊社が貴社に運用いただいているDNS環境の状況を確認させてください。
- 弊社が利用しているDNS（社内の名前解決を行うキャッシュ側、および弊社ドメインの権威側）に、BINDは使用されていますか。使用されている場合、今回の脆弱性の対象バージョン（9.18系／9.20.24以前／9.21.23以前）に該当しますか。
- 対象の場合、修正版（9.20.26／9.21.24 相当）への更新予定日と、更新完了のご報告をいただけますか。
- 更新に伴うサービス停止の有無・想定時間帯をご教示ください。
- 今後、DNS関連の重大な脆弱性が公表された際の、貴社から弊社への連絡フローと標準的な対応リードタイムをご共有ください。
お手数ですが、〔希望期日〕までにご回答いただけますと幸いです。
このテンプレの狙いは、更新そのものだけでなく、4番目の「今後の連絡フロー」を明文化させることにある。今回だけ更新して終わりでは、次の脆弱性でまた同じ「誰の担当か分からない」に戻る。連絡フローを契約の運用に組み込むところまでやって、初めて土台の運用責任が可視化される。
自社のDNSを「誰が握っているか」から一緒に洗い出しませんか
GXOでは、DNSのような普段意識されない土台インフラの運用主体の特定、更新統制の設計、委託先への確認と契約の見直し、そしてDNS以外も含めた土台インフラの棚卸しを支援しています。「そもそも自社のDNSを誰が動かしているのか分からない」という段階のご相談を歓迎します。
DNS・土台インフラの運用点検を相談する → GXO お問い合わせ
よくある質問（FAQ）
Q1. 自社は小さな会社で、専用のDNSサーバなんて立てていません。関係ありますか？
直接BINDを動かしていなくても、自社ドメインの権威DNSや、社内が使うキャッシュDNSは、必ずどこか（ISPやクラウド、委託先）にあります。今回の要点は「更新する」ことよりも「自社のDNSを誰が握っているかを把握する」ことです。把握できていないこと自体がリスクなので、規模の大小にかかわらず、確認の価値があります。
Q2. DNSSECを入れていれば汚染は防げるのではないですか？
一般論としてDNSSECはキャッシュ汚染への有力な対策です。しかし今回のCVE-2026-13321は、そのDNSSECの署名検証の緩さを逆手に取り、署名済みの体裁で偽の否定応答を作れる、とされる不具合です。「DNSSECを入れているから絶対安全」という前提が今回は崩れる点に注意が必要で、だからこそソフト自体の更新が求められています。
Q3. すぐに最新版へ更新すべきですか？
自社でBINDを動かしていて、対象バージョンに該当するなら、更新は必要です。ただしDNSは止まると全社が止まる土台なので、無計画な即時更新は避け、影響範囲の確定・冗長構成の確認・検証環境での動作確認を経てから本番適用するのが安全です。委託運用の場合は、委託先に更新予定と停止有無を確認し、その回答を記録してください。
Q4. 委託先に任せているので、うちは何もしなくていいですか？
「任せている」と「確認した記録がある」は別物です。丸投げのままだと、いざ汚染や停止が起きたときに責任の所在が宙に浮きます。本記事の確認文テンプレを使って、対象か・更新予定か・今後の連絡フローはどうかを問い合わせ、回答を書面で残してください。その記録が、次の脆弱性のときにも効きます。
Q5. CVSS 8.6という数字は、経営として「大至急」と受け止めるべきですか？
CVSSは脆弱性そのものの技術的危険度の共通尺度で、自社にとっての痛さとは別です。経営判断では、スコアの数値より「悪用されて止まる／汚染されるとき、自社の誰が・どの業務が困るか」で優先度を決めてください。DNSは影響範囲が全社に及びやすいため、数値が何点であれ、土台インフラは優先的に点検する対象と考えるのが実務的です。
まとめ：脆弱性ニュースを「自社の運用責任の点検」に変える
BIND 9のキャッシュ汚染を含む脆弱性と修正版公開は、単なる「更新してください」というニュースではない。普段は誰も意識しないのに、止まれば全社が止まり、汚染されれば全社員が偽の宛先へ流される——そんな土台インフラを、自社では誰が握っているのかを点検する契機だ。
まずやることは更新ではなく、確認である。社内PCが使うキャッシュDNSはどこか、自社ドメインの権威DNSはどこか、BINDを動かしているのは誰か、その運用責任は契約に明記されているか。ここが埋まって初めて、更新の要否も、委託先への問い合わせも判断できる。そして今回のDNSを入口に、ドメイン更新・証明書・メール認証・機器のファームウェアといった「担当者名が空欄の土台」を洗い出しておきたい。
GXOは、こうした土台インフラの運用主体の特定から、更新統制の設計、委託先の確認・契約見直し、棚卸しと再設計までを支援している。詳細はセキュリティ運用伴走・セキュリティ事業・DX・システム開発を参照いただきたい。
「うちのDNS、誰が動かしてるんだっけ？」で止まらないために
DNSを含む土台インフラの運用主体の洗い出し、更新統制の設計、委託先への確認と契約の見直しまで、貴社の実態に合わせて整理します。今回のBIND脆弱性を起点に、止まったら困る土台の「担当者空欄」を埋める好機です。
参考情報
- ISC（Internet Systems Consortium）BIND 9 Software Vulnerability Matrix（2026年7月22日更新。9件のCVE、9.18系EOL、9.20.26への修正状況を2026年7月27日に再確認）：https://kb.isc.org/docs/aa-00913
- ISC 公式「CVE-2026-13321」（2026年7月22日公開。CVSS 8.6・High、影響版、回避策なし、修正版9.20.26／9.21.24／9.20.26-S1、既知の悪用なしを2026年7月27日に再確認）：https://kb.isc.org/docs/cve-2026-13321
- ISC 公式サイト（BIND 9 のダウンロード・リリース情報）：https://www.isc.org/
- ※ 修正対象に含まれる各CVEの件数・個別のCVSS値・技術詳細は、上記ISC公式アドバイザリで最新情報を確認のこと。悪用実例の有無や「LLMによるコード監査で発見された」等の経緯に関する記述は、公表時点の情報および二次報道に基づくもので、状況は変わりうる。
