BINDも「LLMによる終末」をすべきなのか……“脆弱性報告”急増で9.20系列にメンテナンス一本化、セキュリティアップデートは「毎月出すからよろしく」!?

BIND 9.22のリリースの延期

　次期安定バージョンとして2026年第2四半期に予定していたBIND 9.22のリリースを延期し、現在の安定バージョンである9.20系列のメンテナンスに注力する。また、ISCは6月にメンテナンスを終了したBIND 9.18系列を速やかにBIND 9.20系列に移行することも呼び掛けている。つまり、BIND 9を運用するDNSオペレーターに、当分の間、9.20系列を使い続けることを求めていることになる。

セキュリティアップデートの高頻度化

　少なくとも今年中、BIND 9のセキュリティアップデートを高頻度化する。ISCでは毎月のメンテナンスリリースごとのセキュリティアップデートに備えるよう呼び掛けており、当分の間、BIND 9を毎月更新しなければならないことになる。

対象バージョン特定の省略

　ISCではこれまで、どのバージョンで脆弱性が混入したか、つまりどのバージョンから脆弱性の対象となるかを精査、公開していた。今後はこの調査を省略する。そのため、セキュリティアップデートの際には、常に最新版に更新する必要があることになる。アナウンスの発表後、最初の脆弱性情報公開となった2026年7月のセキュリティアップデートでは従来と同様、どのバージョンから対象となるかが公開されたが、今後は予断を許さないため、注意する必要がある。

再現テストの公開

　脆弱性を公開した時点で、その脆弱性の再現テストを公開する。つまり「どうすれば脆弱性を再現できるか」という情報、つまり攻撃者の立場から見ると「どうすればnamedを落としたり誤動作させたりできるか（Proof of Concept：PoC）」が、脆弱性情報が公開された時点で公知の事実となることになる。これまでは脆弱性情報の公開からPoCの作成・公開まではある程度のタイムラグが期待できたが、今後はそうした状況は期待できないということになる。

　続いて、2026年5月のDNS-OARC[*5] 46で発表された、代表的な4つのオープンソースDNSソフトウェアベンダー（ISC、PowerDNS、NLnet Labs、CZ.NIC）の連名による発表が紹介された（図4）。発表では、原文のスライドから、品質の低い（有効でない）脆弱性報告数が急増したことで、開発者にさまざまな鬱積が溜まってきていることが紹介されている。

　スライドでは、脆弱性情報のトリアージ（緊急度や重要度に応じた優先順位付け）の負荷が高まり、開発チームへのDoS攻撃の様相を呈していること、「頼むからちゃんとしたレポートを送ってくれ」といった、開発者の悲痛な声も記載されていることなどが紹介されている（図5～図8）。

図4　DNS 4ベンダー連名の発表

図5　2026年5月時点の状況

図6　開発者の嘆き（オープンソースを助けてない）

図7　ある開発者の発言

図8　こんな動きも…

　図5で示されたスライドを見ると、CVEやトリアージ対象の件数に目がいくが、注目すべきは「有効なCVE報告」の比率がPowerDNS+dnsdist では5％程度、BINDでは10％未満しかないという点である。つまり、それらのソフトウェアでは脆弱性報告の90％以上が有効ではない、すなわちノイズであるという事実である。それらには、不完全なもの、重複しているもの、ソフトウェアのバグではなく運用上の不備であるものなどが含まれているようだが、そうした状況を考え合わせると、図6や図7で示された開発者の嘆き・発言は当然のこととも思える。ぜひ読んでいただきたい。

　また、DNS以外のソフトウェアでは図8に示したような、開発者の開き直りや諦めのようなものも見て取ることができる。「コードがなければ脆弱性も脆弱性対応もない」「情報を受け付けなければ脆弱性対応もない」と取られかねない行動は過激なものであるが、筆者はそれらを完全に否定することができない。

　その後、森下氏からは「いち情報発信者としての所感」が説明された。「また一つ、ものすごい道具ができた」で始まる所感のスライド（図9）と現場での発言をまとめると、おおむね次のようなことが話されている。

　「ものすごい道具ができて、できることが増え、できる速度も爆速になった。しかし、それは人類がこれまでに何度も経験してきたことである。その過程で、例えば人が死んだりとか、町が一つ丸焼けになったりとか、民族が滅ぼされたりということが起きている。今回起こっていることは『そういうことがまた起きている』ということである。こうした技術革新は、例えば産業革命のときのラッダイト運動（機械打ち壊し運動）のようなことでは抵抗できないし、止められない。つまり、生き延びるためには道具のリスクを認識した上で、手なずけるしかない。実際、我々はそうして生きてきた。しかしそれには、時間がかかるだろうと考えている。」

　「では、我々情報発信者が何をするかということになると、おそらくあまり変わらない。しかし、頻度は爆上がりするので、たとえば脆弱性情報の文章を作る機会はこれまでよりもずっと増えることになるであろうと考えている。」

　続いて、会場の参加者に聞いてみたいこと（図10）として、「この状況はいつ収束するのか」「BINDもLinuxで実施されたような『LLMによる終末（使われていない古いコードの大規模な削除）』をすべきか、できるのか」「脆弱性対応を1カ月休む『Curl至福の夏』についてどう思うか」の3項目を挙げた。

図9　いち情報発信者としての所感

図10　いち情報発信者として聞いてみたいこと

複数サービスを組み合わせる

　これは、多様性確保の話である。複数のサービスを組み合わせる、たとえばA社のサービスだけでなくB社のサービスも使うといったかたちである。そうすることでシステム、ネットワーク、ソフトウェアやその運用における多様性が確保され、あるサービスやシステムが攻撃を受けてサービスに影響が及んでも、別のサービスやシステムは攻撃の影響を回避できる可能性が高まるというのが、その理由である。

　ただし、多様性の確保にはコストの増大が伴うため、会社や組織などの状況により、必ず認められるわけではないことに注意が必要である。そうした方法が認められない、つまり使用するサービスやネットワークにおける多様性の確保が難しい場合であっても、「複数のサーバー実装を組み合わせている」、もしくは「脆弱性対応が早い」ことが分かっているサービスを使うことで、単一のサービスであってもある程度の多様性や障害耐性を確保できるといった考え方も重要である。

　DNSのように、複数の構成要素が連携してサービスを提供するシステムでは、あるサービスが止まると、他のサービスにも影響が及ぶことになる。その点をどう判断し、どこまで対応するかは、脆弱性対応をはじめとするシステムやサーバーの運用における、重要な考慮点である。実際の運用では、サービスがダウンした際の被害とサービスの維持に要するコストを天秤にかけて判断することになる。

脆弱性対応のSLAなどがあり、十分短いところを選ぶ

　事業者によっては、自身が提供するサービスにSLA（Service Level Agreement）を設定しているものが存在する。SLAとは、サービス事業者が利用者に「サービスの品質をどのような条件で、どの程度保証するか」を、具体的な数値で提示する取り決めである。サービスが止まるダウンタイムは何分以内とか、問題発生から何時間以内に対応するといった項目が、SLAで定められることになる。

　とはいえ、筆者は脆弱性について、その発見から対応までの時間に関する具体的なSLAを用意しているサービス事業者を聞いたことがない。しかし、サービスの障害については発生からどれくらいの時間で対応されるかというSLAを設定しているサービス事業者が存在しており、こうしたSLAを脆弱性対応における目安とすることは可能である。

自前運用サーバーを組み合わせる（権威サーバー）

　何らかの攻撃によるサービスの停止は、サービスの運用において想定しなければならない問題である。そして、攻撃による影響を考慮する場合、自身が対象になる場合に加え、他者が対象となった際の巻き添えについても、ある程度想定しておく必要がある。

　この問題は、多数のユーザーがサービス事業者の提供する１セットのサーバーやネットワークを共用する共用サービスを使う限り、回避できない。後述するフルサービスリゾルバーでも同様であるが、専用のサーバーを自前運用することで、こうした巻き添えの回避が可能になる。

　ここでの考慮点は、自前運用にかかるコストと人材の確保であろう。つまり、ネットワークやサーバーを構築するためのコスト（ヒト・モノ・カネ）や管理運用コストをどの程度確保できるか、という話である。専用のサーバーを自前運用することで、共用サービスにおけるサービス障害のリスクや、別の組織（ドメイン名）が攻撃された際の巻き添えを食らいづらくなるといった効果を期待できるが、専用のサーバーを確保したとしても、そのサーバーが接続されているネットワークを大規模かつ無差別に攻撃されれば、被害が及ぶことは避けられない。島村氏は発表で、「それでも、自前で運用したほうが安心感は上がる」と述べたが、運用の複雑さが増しているDNSをオンプレミスできちんと運用できる技術者は明らかに少なくなっており、最終的には「ヒト」の問題に行き着くことになる。なかなかに難しい問題である。

ISPなどのフルサービスリゾルバー（キャッシュDNSサーバー）を使わない

　こちらも、巻き添え問題を念頭に置いている。ISPが提供する、多くのユーザーが使用するフルリゾルバーを使う限り、この問題は避けられない。

　オープンリゾルバーは、利用者を自社の顧客に特定せず他者にも利用させるフルサービスリゾルバー（キャッシュDNSサーバー）のことであるが、そのようなサービスは特に攻撃されやすい。つまり、名前解決のサービスに影響が及ぶリスクが高いことになる。また、オープンリゾルバーではなかったとしても、ISPの同じフルサービスリゾルバーに収容されている顧客のPCの中にボット（bot）がいて、そのボットが大量のDNSクエリを送信したらどうなるか、といった心配も考えられるということである。

　筆者は、顧客の中にボットがいる場合の心配はさすがに極端であると感じたが、確かに、フルサービスリゾルバーにおいても自前運用を考えることを選択肢に入れるべきであろう。ただし、ここで注意したいのは、安易にGoogle Public DNSのようなパブリックDNSサービスの利用を選択しないようにすることである。筆者は、パブリックDNSサービスよりもISPが提供するDNSサービスのほうが信用できると考えている。まっとうなISPであれば、フルサービスリゾルバーの運用における攻撃への対応も考慮・準備されているはずだからだ。

　では、自身でネットワークやサービスを運用する「運用者」はどうすればいいのであろうか。島村氏からは、さまざまな考慮点が指摘された。まずは図12と図13をご覧いただきたい。

図12　運用者：情報の先行入手

図13　運用者：サポート切れ製品を使わない

　ここに書かれていることはシンプルである。OSS（オープンソースソフトウェア）を使っている場合、少しでも早く情報を入手する、脆弱性情報が出回る前に対策版（アップデート）を得られるようにするために有償サポートを購入する、サポート切れの製品は危険なので使わないという、システムの運用において当然すべきことを改めて確認する内容となっている。

　ただし、同じ有償サポートでもメニューの違いにより内容が異なり（図12）、サポートポリシーも異なる（図13）という点には、注意を払うべきであろう。これらは、製品の選択における選定材料になるはずである。

　続いて、ディストリビューションパッケージの話に移るが、ここでの話は、「権威サーバーやフルサービスリゾルバーの運用では、標準のディストリビューションパッケージに頼るな」という点がポイントである（図14～図16）。ディストリビューションの種類にもよるが、Linuxにおいて広く使われているRed Hat Enterprise Linux（RHEL）は「対策が出るのが遅すぎる！」とのことで、迅速に対応するためには「DNSソフトウェアの開発元が提供するパッケージを使う」ことを推奨する旨が説明された。

　そのようなことも含めて大事なのは、図15や図16で示されるように、純正パッケージの有無や、サポート・リリースポリシーを十分に評価することであろう。この件は自身でサーバーを運用する「運用者」にとって、極めて重要な考慮点である。

図14　運用者：ディストリビューションパッケージに頼らない

図15　運用者：ディストリビューションパッケージに頼らない

図16　運用者：サポート・リリースポリシーを評価する

　OSSではなくクローズドソースの製品を使っている場合については、図17で示された。島村氏が資料で指摘している、「きっと対策にならない」し、「（セキュリティAIは）ソースがなくてバイナリだけでも逆コンパイルして解析してくる」というのは、まさにその通りであると感じた。

　とはいえ、「そのバイナリが攻撃者の手に入らなければ難しい」のは確かなので、開発側の管理体制についても考慮する必要がある。島村氏が「個人的に、クローズドソース製品を使うのはいいと思うけれど……」と控えめに述べたのは、オープンソースのように第三者による評価が入りにくいからではと感じた。

　だからこそ、スライドにある「『セキュリティAI（モデル名付き）でスキャンして、指摘事項は対応済』などの明記が無いプロダクトは使いづらい時代に」なってきているともいえる。まとめると、事前にAIによる脆弱性スキャンをしており、そこで発見された問題点は全て対策済みであるという表明がされていることが重要になるということだ。実際に、そのような取り組みを始めているベンダーもあると聞いている。

　また、サポート契約によっては、「一般公開前の先行提供というものに意味がある」かもしれない。ただ、この辺は契約内容やメニューにもよるであろう。

図17　運用者：クローズドソース製品を使う

　ここまでの話は基本的な部分の紹介であった。ここからは話が少し複雑になる。顧客に対する確認と同意を求める例が登場するからだ。図18を見てほしい。

図18　運用者：CI/CDを整える

　「CI/CD」というのは、「Continuous Integration（継続的インテグレーション）」「Continuous Delivery（継続的デリバリー）」のことである。ここでは、ソフトウェアのセキュリティアップデートに関して、修正プログラム（パッチ）を当ててからテストするまでがCI、それが終わったあとに本番環境に移すまでがCDと理解するとよい。これを自動化することになる。

　スライドでは単純化されているが、もしこれらを手動で実施していた場合、ツールを使うなどして何らかのかたちで自動化・システム化する必要がある。最近では脆弱性が発見されてから攻撃が出回るまでの猶予はせいぜい2日しかないと言われているため、悠長なことはいっていられないはずである。

　「人手でやるには無理がある」という島村氏の説明通り、バージョンアップのたびに実施するテストはCIに落とし込むべきだし、検証に取られる時間や工数はできるだけ無くすようにすべきである。それによりヒューマンエラーも減少するし、後行程での手戻りを少なくすることにもつながる。

　CDでは、バージョンアップのコストをできるだけ下げていくという話だが、切り戻しを容易にできるよう準備すること、複数の系統を扱っている場合、1系統ずつ実施していくことでリスクを下げるといった項目も含まれることになる。

　そして、難しいのは図19と図20にあるような話であろう。誤解を恐れずシンプルに説明するなら、「できること、すべきことをリストアップし、その中で優先順位（トリアージ）を決め、リスクベースでサービスを止めることを恐れずに対応する」ということになる。もちろん、そのためには経営層や顧客に、サービス全体を守るために「覚悟を決めてもらう」ということも必要になってくる。なかなかにハードである。

　スライドの中にある「フロンティアAI」の話題[*6]についてはリンク先を一読することをお勧めするが、筆者なりに要約すると、以下のようになると考える（図19）。

図19　運用者：トリアージをしておく

図20　運用者：覚悟を決める（決めてもらう）

　AIにより、脆弱性の発見や高度な攻撃コードの生成が容易になり、脆弱性の発見から攻撃に至るまでの期間が大幅に短縮されている。また、攻撃者のスキルが低い場合もAIを用いることで、高度なサイバー攻撃が可能になることも懸念される。

　こうした状況に対応するため、パッチが短期間に大量に提供される可能性があることから、金融機関等においては、こうした事態に備え、迅速かつ適切に対応できる態勢が整備されているかを至急点検し、必要な強化を図ることが求められる。また同時に、経営トップがリーダーシップを発揮してこれらの対応を主導し、必要なリソース配分を含めた意思決定をすることも求められる。

　ということで、なかなかに緊張感のある内容ではないだろうか。図20は、上司や顧客に「バージョンアップによる不具合や非互換はあって当然。バージョンアップしないほうが危険」という意識を持ってもらうことの大事さが述べられている。また、「最悪」としてリモートコード実行からの侵害発生が挙げられているが、これは一般に「RCE（Remote Code Execution）」のことを示している。RCEとは、攻撃者が外部からネットワーク越しに対象となるシステムやアプリケーション上で任意のコード（プログラム）を実行できてしまうという、深刻なセキュリティ上の危機をもたらすものだ。

　島村氏の発表は時間的な制約によりここまでであったが、その後のQ＆Aでは非常に多くの質問やコメントが寄せられた。その中から、特に考えさせられたものをいくつか紹介する。

• 純正パッケージが使えないのなら、RHELを使う意味がないのでは？
• DNS以外にもやばそうなものがあるし、組み込まれているソフトウェア全部について保守ポリシーを考えるのは難しい
• たとえばBINDの「あまり使われていない機能を削ったバージョン」が出たとして、使いたい人はどれくらいいるのか？
• 今後は、攻撃者がクローズドソースのバイナリを手に入れるための攻撃も増えそうである

　会場から出た意見の多くはパッケージを使う側からのものであるが、面倒なことは開発側だけではなく、利用者にも及んでいるということが実感できた。システムの管理・運用をされている方はセッションの内容をベースに、自分はどうすべきかを考えてみていただきたい。