MENU

CVE-2026-11331対策：Azure Linux 3.0のBIND修正版と更新手順

Linux

Azure Linux 3.0でBINDを運用している場合、bind-9.20.23-1.azl3をCVE-2026-11331の修正済み版と判断しないでください。MSRCのFirstFixed欄には「azl3 bind 9.20.23-1 on Azure Linux 3.0」と表示されますが、BINDの開発元であるISCは9.20.0から9.20.24までを影響範囲とし、9.20系の修正版を9.20.26としています。

さらに、Microsoft公式パッケージリポジトリには、x86_64とaarch64の両方でbind-9.20.26-1.azl3が公開されています。したがって、2026年8月2日時点では、Azure Linux 3.0の対応完了基準をbind-9.20.26-1.azl3以上とするのが安全です。(Microsoft Security Response Center)

CVE-2026-11331は、RPZでワイルドカードCNAMEポリシーを使用するBINDリゾルバーに対し、細工したDNS問い合わせを送ることでポリシーを回避できる可能性がある脆弱性です。本記事では、影響の仕組み、修正版の判断基準、Azure Linux 3.0での確認コマンド、更新後に見落としやすい再起動と動作確認まで解説します。

目次

CVE-2026-11331で最初に確認すべきこと

CVE-2026-11331の概要は次のとおりです。

項目内容
CVE番号CVE-2026-11331
対象ソフトウェアBIND 9
Azure Linuxの対象Microsoft Azure Linux 3.0上のBIND
脆弱性の内容ワイルドカードCNAMEを利用するRPZルールの回避
発生条件RPZ処理中に長すぎる問い合わせ名によってNAMETOOLONGエラーが発生する
想定される影響対象RPZルールの回避、BINDプロセスの予期しない終了
CVSS7.5、High
CVSSベクトルCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
CWECWE-790：特殊要素の不適切なフィルタリング
ISCが示す影響範囲BIND 9.20.0～9.20.24など
ISCが示す9.20系修正版BIND 9.20.26
既知の回避策なし
Azure Linux 3.0での実務上の更新先bind-9.20.26-1.azl3以上

ISCは、この脆弱性をネットワーク経由で悪用可能なHighの問題として扱っています。2026年7月22日の公開時点では、ISCは実際の悪用を確認していないとしていますが、公式な回避策も示されていません。(ISC Knowledgebase)

ワイルドカードCNAMEでRPZポリシーが回避される仕組み

RPZは「Response Policy Zone」の略で、DNSリゾルバーが返す応答をポリシーに基づいて制御する機能です。

たとえば、次のような用途で利用されます。

  • マルウェア配布ドメインの名前解決を拒否する
  • フィッシングサイトをブロックページへ転送する
  • 特定ドメインをNXDOMAINとして応答する
  • 組織のセキュリティポリシーに基づいてDNS応答を書き換える

CVE-2026-11331では、RPZにワイルドカードCNAMEポリシーが設定されている環境で、攻撃者が極端に長い問い合わせ名を作成します。

処理の流れは次のとおりです。

  1. BINDリゾルバーがRPZのワイルドカードCNAMEルールを使用している
  2. 攻撃者が長く細工したDNS名を問い合わせる
  3. RPZ処理中にNAMETOOLONGエラーが発生する
  4. エラーが正しく処理されず、対象のRPZルールが適用されない可能性がある
  5. 状況によってはBINDプロセスが予期せず終了する

重要なのは、通常のCNAMEレコードすべてが問題になるわけではない点です。問題の中心は、RPZでワイルドカードCNAMEポリシーを処理する経路です。(ISC Knowledgebase)

RPZ回避が実務に与える影響

RPZルールが回避されると、本来ブロックされるはずのドメインが通常どおり名前解決される可能性があります。

たとえば、組織が既知の不正ドメインをRPZで遮断している場合、次のような防御が期待どおりに機能しない恐れがあります。

  • マルウェアの外部通信先遮断
  • フィッシングサイトへのアクセス防止
  • コマンド＆コントロールサーバーの名前解決停止
  • DNSを利用した情報持ち出し対策
  • 社内ポリシーで禁止したサービスへの接続制御

また、ISCはBINDが予期せず終了する可能性も挙げています。CVSSベクトル上は可用性への影響がA:Nと評価されていますが、実際の運用ではDNSリゾルバー停止による業務影響も別途考慮すべきです。(ISC Knowledgebase)

CVSS 7.5とCWE-790の読み方

CVSSベクトルは次の条件を示しています。

指標評価意味
AVNetworkネットワーク経由で到達可能
ACLow攻撃条件の複雑さが低い
PRNone攻撃者の事前権限が不要
UINone利用者の操作が不要
SUnchanged影響範囲は同一セキュリティ権限内
CHigh機密性への影響が大きい
INone完全性への影響は評価されていない
ANoneCVSS上の可用性影響は評価されていない

CWE-790は「Improper Filtering of Special Elements」、日本語では「特殊要素の不適切なフィルタリング」に相当します。本脆弱性では、長すぎるDNS名によって生じる例外的な状態をRPZ処理が適切に扱えないことが、ポリシー回避につながります。(NVD)

MSRCのFirstFixed「9.20.23-1」だけで完了判定してはいけない

この脆弱性で最も注意すべき点は、MSRCのFirstFixed表示と、ISCおよびMicrosoft公式リポジトリの情報が一致していないことです。

確認先公開されている情報実務上の判断
MSRC FirstFixedazl3 bind 9.20.23-1 on Azure Linux 3.0単独では修正済みと判断しない
ISC影響範囲BIND 9.20.0～9.20.249.20.23は影響範囲に含まれる
ISC修正版BIND 9.20.269.20系で使用すべき修正版
Azure Linux 3.0の9.20.23 spec2026年5月22日付で、別のCVE対応として9.20.23へ更新CVE-2026-11331のバックポート根拠を確認できない
Microsoft公式リポジトリbind-9.20.26-1.azl3を2026年7月29日に公開Azure Linux 3.0で利用できる更新先

Azure Linuxの公開specでは、9.20.23-1への更新理由としてCVE-2026-3039、CVE-2026-3592、CVE-2026-3593などが記録されています。一方、CVE-2026-11331の修正は記載されていません。加えて、Microsoft公式リポジトリには、その後の9.20.26-1が公開されています。

これらを総合すると、MSRCのFirstFixed文字列だけを根拠に9.20.23-1を対策済みと扱うのは危険です。MSRC側から明示的なバックポート説明や表示修正が公開されるまでは、9.20.26-1.azl3以上を完了基準としてください。(Microsoft Security Response Center)

インストール済みバージョン別の判断

確認結果判断必要な対応
bind-9.20.23-1.azl3.x86_64修正済みとは判断できない9.20.26-1.azl3以上へ更新
bind-9.20.23-1.azl3.aarch64修正済みとは判断できない9.20.26-1.azl3以上へ更新
BIND 9.20.0～9.20.24の独自ビルドISCの影響範囲修正版へ入れ替える
bind-9.20.26-1.azl3以上現時点の修正基準を満たす実行中プロセスの再起動と確認を行う
package bind is not installedRPM版のBINDサーバーは未導入コンテナや独自インストールを追加確認
RPMは9.20.26だが実行中プロセスが古い更新後の再起動漏れ実際のBINDプロセスを再起動
namedがRPM管理外独自ビルドの可能性配置元、ビルド版、更新方法を確認

対応を優先すべきAzure Linux 3.0環境

今回の脆弱性はRPZを使用するリゾルバーが中心ですが、「インターネットから53番ポートへ直接接続できないから安全」とは限りません。

社内利用者がWebサイトやメール、アプリケーションを通じて攻撃者の管理するドメインを名前解決した場合、内部DNSリゾルバーまで細工した問い合わせが到達する可能性があるためです。

環境対応優先度判断理由
外部公開された再帰DNSでRPZを使用最優先攻撃者がDNS問い合わせを直接送信できる可能性が高い
社内向け再帰DNSでRPZを使用高内部端末を経由して攻撃用ドメインを問い合わせさせられる可能性がある
ワイルドカードCNAMEを含むRPZを使用高公表された攻撃条件に直接該当する
RPZは使用しているがワイルドカードCNAMEは未使用中直接の発生条件からは外れるが、設定変更や未把握ルールを考慮して更新する
権威DNS専用で再帰問い合わせとRPZを使用していない相対的に低い公表された脆弱な処理経路を通常は使用しない
BINDを停止中中再稼働前に必ず更新する
コンテナ内でBINDを実行高ホストOSのRPM更新だけではコンテナ内のBINDは修正されない

この優先度は、公表された発生条件から導いた運用上の判断です。直接の条件に該当しない環境でも、恒久対応はBINDパッケージの更新としてください。(ISC Knowledgebase)

Azure Linux 3.0で影響を確認する手順

OSの種類とバージョンを確認する

最初に、対象ホストがAzure Linux 3.0であることを確認します。

grep -E '^(NAME|ID|VERSION_ID|PRETTY_NAME)=' /etc/os-release

VERSION_ID="3.0"など、Azure Linux 3.0であることが分かる出力を確認してください。

インストール済みのBINDパッケージを確認する

BINDサーバー本体のバージョンは次のコマンドで確認できます。

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' bind

関連パッケージも含めて確認する場合は、次のコマンドを実行します。

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' \
  | grep -E '^bind($|-)' \
  | sort

更新が必要な出力例は次のとおりです。

bind-9.20.23-1.azl3.x86_64
bind-libs-9.20.23-1.azl3.x86_64
bind-utils-9.20.23-1.azl3.x86_64

現時点の更新基準を満たす出力例は次のとおりです。

bind-9.20.26-1.azl3.x86_64
bind-libs-9.20.26-1.azl3.x86_64
bind-utils-9.20.26-1.azl3.x86_64

aarch64環境では、末尾が.aarch64になります。Microsoft公式リポジトリには、両アーキテクチャ向けの9.20.26-1.azl3が公開されています。(Microsoft Packages)

実際に実行されるnamedのバージョンを確認する

パッケージ情報だけでなく、ディスク上にあるnamedバイナリも確認します。

command -v named
named -V | head -n 1

続いて、namedがどのRPMパッケージに含まれているかを確認します。

named_path="$(readlink -f "$(command -v named)")"
printf 'named path: %s\n' "$named_path"
rpm -qf "$named_path"

rpm -qfで所有パッケージが表示されない場合は、次のような可能性があります。

  • /usr/local/sbinなどへ独自にインストールしている
  • ソースコードからビルドしている
  • 別の製品にBINDが組み込まれている
  • コンテナ内のBINDを参照している
  • PATH上のnamedとサービスが実行するnamedが異なる

なお、dig -vで確認できるのは主にbind-utils側のバージョンです。DNSサーバー本体の修正確認として、dig -vだけを使用してはいけません。

実行中のBINDプロセスを確認する

更新後も古いプロセスが動き続けていないか確認します。

ps -eo pid,lstart,args | grep '[n]amed'

実行中プロセスが参照しているバイナリを確認するには、次のようにします。

pid="$(pgrep -o named)"
sudo readlink -f "/proc/${pid}/exe"

出力末尾に(deleted)が付いている場合、ディスク上の実行ファイルは更新されていますが、プロセスは更新前のバイナリを引き続き使用しています。BINDプロセスの再起動が必要です。

RPZ設定の有無を確認する

設定ファイルの構文を確認します。

sudo named-checkconf

続いて、RPZ関連の設定を検索します。

sudo grep -RniE 'response-policy|rpz' \
  /etc/named.conf /etc/named 2>/dev/null

includeで別ファイルを読み込んでいる環境では、検索結果に出ない設定ファイルが存在することがあります。named-checkconfの結果や構成管理ツールの定義も確認してください。

設定ファイルを外部へ共有する際は、TSIG鍵、RNDC鍵、転送先、内部ネットワーク情報などを必ずマスクします。

DNSの待受ポートを確認する

DNSはUDPだけでなくTCPも使用します。両方の待受状態を確認してください。

sudo ss -lntup | grep -E '(:53[[:space:]]|:53$)'

インターネットへ公開していないつもりでも、意図しないインターフェイスやIPv6アドレスで待ち受けている場合があります。

コンテナ内のBINDを確認する

ホストOSでrpm -q bindを実行しても、コンテナ内のBINDは確認できません。

Dockerの場合は、対象コンテナ内で確認します。

docker exec <コンテナ名> named -V

Kubernetesの場合は次のとおりです。

kubectl exec -n <名前空間> <Pod名> -- named -V

脆弱なコンテナイメージを使用している場合は、稼働中コンテナ内で直接更新するのではなく、修正版パッケージを含むイメージを再ビルドし、再デプロイするのが基本です。

Azure Linux 3.0のBINDを修正版へ更新する手順

更新前に設定と冗長性を確認する

本番環境では、更新前に次の項目を確認します。

  • セカンダリDNSや別のリゾルバーが正常に応答している
  • ロードバランサーから対象ノードを切り離せる
  • BIND設定ファイルとRPZゾーンファイルを復旧できる
  • 現在のDNS応答結果を記録している
  • RPZが意図したドメインを遮断できている
  • 監視システムのアラート抑止やメンテナンス設定を行っている

設定とゾーンの読み込みテストも実行します。

sudo named-checkconf
sudo named-checkconf -z

複数台でDNSを運用している場合は、一斉更新を避け、1台ずつ更新してください。

DNFでパッケージ情報を更新する

Azure LinuxではDNF5が標準のパッケージ管理基盤です。dnf、yum、tdnfなどの従来コマンドも、互換シンボリックリンクを通じてDNF5へ接続されます。リポジトリ設定は/etc/yum.repos.d/にあります。(Microsoft Learn)

古いキャッシュを削除し、利用可能なBINDパッケージを確認します。

sudo dnf clean all
sudo dnf makecache
dnf info bind

候補バージョンが次のいずれかであることを確認します。

9.20.26-1.azl3

または、それより新しいAzure Linux 3.0向けパッケージです。

BINDパッケージを更新する

BINDサーバー本体を更新します。

sudo dnf upgrade bind

bind-libsやbind-utilsなども導入している場合は、インストール済みパッケージ名を確認したうえで更新します。

rpm -qa --qf '%{NAME}\n' \
  | grep -E '^bind($|-)' \
  | sort -u

たとえば、次のように指定します。

sudo dnf upgrade bind bind-libs bind-utils

システム全体を通常の更新方針に従って最新化できる場合は、次の方法でも構いません。

sudo dnf upgrade

DNFのupgradeは、有効なリポジトリからインストール済みパッケージの最新利用可能版を選択します。(Microsoft Learn)

9.20.26-1が表示されない場合の確認事項

dnf info bindを実行しても9.20.23-1までしか表示されない場合は、次を確認します。

dnf repolist
sudo dnf clean all
sudo dnf makecache
dnf info bind

主な原因は次のとおりです。

  • Azure Linux公式リポジトリが無効になっている
  • 社内ミラーへの同期が遅れている
  • プロキシが古いメタデータをキャッシュしている
  • バージョンロックが設定されている
  • リポジトリへの通信がファイアウォールで遮断されている
  • 独自リポジトリの優先度が公式リポジトリより高い
  • コンテナイメージのビルドキャッシュが残っている

公式リポジトリではbind-9.20.26-1.azl3が公開済みです。更新候補が表示されない場合は、修正版が存在しないのではなく、自組織のリポジトリ経路に問題がないかを確認してください。(Microsoft Packages)

ミラー反映が遅れているからといって、出所不明のRPMファイルを検索して手動インストールするのは避けてください。署名検証、依存関係、将来の更新経路を損なう恐れがあります。

実際のBINDサービスを再起動する

RPMを更新しただけでは、すでに起動しているBINDプロセスのコードは置き換わりません。

まず、サービス名を確認します。

systemctl list-unit-files | grep -Ei 'named|bind'

サービス名がnamedの場合は、次のように再起動します。

sudo systemctl restart named
sudo systemctl --no-pager --full status named

環境によっては、次のような管理方式が使われています。

  • named-chrootなど別のsystemdユニット
  • 独自のsystemdユニット
  • supervisord
  • コンテナランタイム
  • Kubernetes Deployment
  • 仮想アプライアンス独自のサービス管理機能

実際にBINDを起動している仕組みから再起動してください。

rndc reloadやrndc reconfigは、設定やゾーンを再読み込みするための操作です。実行中のプログラム本体を修正版へ入れ替える操作ではないため、更新後はプロセス再起動が必要です。

更新後に修正を確認する手順

RPMとnamedのバージョンを再確認する

rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' bind
named -V | head -n 1

期待するRPM出力例は次のとおりです。

bind-9.20.26-1.azl3.x86_64

または、これより新しいAzure Linux 3.0向けBINDパッケージです。

プロセスの起動時刻を確認する

ps -eo pid,lstart,args | grep '[n]amed'

パッケージ更新後の時刻にBINDプロセスが起動していることを確認します。

さらに、実行中バイナリの状態を確認します。

pid="$(pgrep -o named)"
sudo readlink -f "/proc/${pid}/exe"

(deleted)が表示されず、想定したnamedのパスになっていることを確認してください。

設定とサービス状態を確認する

sudo named-checkconf
sudo systemctl --no-pager --full status named

RNDCを設定している環境では、次の確認も有効です。

sudo rndc status

UDPとTCPのDNS問い合わせを確認する

ローカルホストで待ち受けている場合の例です。

dig @127.0.0.1 example.com A +time=2 +tries=1
dig +tcp @127.0.0.1 example.com A +time=2 +tries=1

別のサービスIPで待ち受けている場合は、127.0.0.1を実際のアドレスへ置き換えます。

次の項目を確認してください。

  • UDP問い合わせが正常に応答する
  • TCP問い合わせが正常に応答する
  • 再帰問い合わせが許可対象クライアントから成功する
  • 許可対象外クライアントの再帰問い合わせが拒否される
  • DNSSEC検証が従来どおり動作する
  • セカンダリとのゾーン転送が正常に行われる

RPZの動作を確認する

組織が管理するテスト用ドメインをRPZへ登録し、期待した応答が返るか確認します。

確認対象の例は次のとおりです。

  • NXDOMAINを返すルール
  • CNAMEでブロックページへ誘導するルール
  • ワイルドカードで一致するルール
  • 例外設定により通常解決させるルール
  • RPZログに正しいポリシー名が記録されること

本番DNSサーバーに対し、脆弱性を再現する目的で極端に長い問い合わせ名を送信するのは避けてください。対策確認は修正版の導入、プロセス再起動、通常のRPZ機能テストによって行います。

ログに異常がないか確認する

サービス名がnamedの場合は、次のコマンドで更新後のログを確認できます。

sudo journalctl -u named --since "-10 min" --no-pager

次のような兆候がないか確認してください。

  • 設定ファイルの構文エラー
  • RPZゾーンの読み込み失敗
  • 権限エラー
  • ポート53の競合
  • ゾーン転送の失敗
  • DNSSEC鍵やトラストアンカーの読み込み失敗
  • 起動直後の異常終了や再起動ループ

対応完了として残すべき証跡

脆弱性管理表に「パッチ適用済み」と記載するだけでは、再起動漏れやコンテナの見落としを発見できません。

少なくとも次の情報を残してください。

証跡確認内容
OS情報Azure Linux 3.0であること
RPM情報bind-9.20.26-1.azl3以上
関連パッケージbind-libsなどに古い版が残っていないこと
実行バイナリnamedの配置先と所有RPM
プロセス起動時刻パッケージ更新後に再起動していること
サービス状態BINDが正常稼働していること
UDP/TCPテスト両方のDNS問い合わせが成功すること
RPZテスト組織のポリシーが期待どおり適用されること
コンテナ情報修正版イメージのダイジェストやタグ
作業情報作業日時、担当者、変更管理番号

完了判定は、「RPMを更新した」ではなく「修正版のBINDプロセスが実際に動作し、RPZを含むDNS機能が正常である」ことを基準にします。

すぐに更新できない場合の暫定対応

ISCは、CVE-2026-11331に対する公式な回避策を示していません。そのため、次の対策は被害可能性を下げるための暫定措置であり、修正版への更新を置き換えるものではありません。(ISC Knowledgebase)

  • 再帰問い合わせを許可する送信元を必要最小限に制限する
  • インターネットからの不要なUDP/TCP 53番ポートを遮断する
  • オープンリゾルバーになっていないことを確認する
  • 脆弱なノードをロードバランサーから一時的に切り離す
  • BINDプロセスの異常終了と自動再起動を監視する
  • RPZルール適用失敗を検知できるログ監視を追加する
  • コンテナの修正版イメージを優先してビルドする
  • 更新までの期間を明確に定め、恒久対応を先送りしない

RPZそのものを安易に無効化すると、既存の不正ドメイン遮断機能まで失われます。影響評価を行わずにRPZを停止するのは避けてください。

CVE-2026-11331対応でよくある失敗

MSRCの9.20.23-1だけを見て修正済みにする

ISCの影響範囲では9.20.23が明確に含まれています。Azure Linux 3.0では9.20.26-1.azl3以上まで更新してください。

digのバージョンだけを確認する

digはクライアントツールです。DNSサーバー本体であるnamedのバージョン、配置先、実行中プロセスを確認する必要があります。

RPM更新後にBINDを再起動しない

パッケージが9.20.26になっていても、起動中のプロセスが旧版を使用していれば対応は完了していません。

rndc reloadだけで作業を終える

設定再読み込みでは、実行中のプログラム本体は入れ替わりません。サービスまたはコンテナを再起動してください。

ホストOSだけを確認する

コンテナ、Kubernetes Pod、独自ビルド、アプライアンス内のBINDは、ホスト側のrpm -q bindでは確認できません。

UDPだけを動作確認する

DNSはTCPも使用します。更新後はUDPとTCPの両方をテストしてください。

複数のDNSサーバーを同時に更新する

設定ミスや起動失敗が発生した場合、組織全体の名前解決が停止する恐れがあります。冗長構成では1台ずつ更新します。

ミラーが遅れているため非公式RPMを導入する

出所不明のRPMは、改ざん、署名、依存関係、更新経路の問題を招きます。公式リポジトリまたは組織で検証済みのミラーを使用してください。

よくある質問

Azure Linux 3.0のbind 9.20.23-1は修正済みですか

現時点の公開情報からは、CVE-2026-11331の修正済み版とは判断できません。

ISCはBIND 9.20.0から9.20.24までを影響範囲としており、9.20系の修正版を9.20.26としています。Microsoft公式リポジトリにもbind-9.20.26-1.azl3が公開されているため、同版以上へ更新してください。(ISC Knowledgebase)

RPZを使用していなければ更新しなくてもよいですか

公表された直接の発生条件からは外れる可能性がありますが、恒久的な未更新理由にはなりません。

将来RPZを有効化する可能性、設定ファイルの把握漏れ、コンテナや別インスタンスでの利用を考慮し、通常のセキュリティ更新として修正版を適用してください。

DNSの53番ポートをインターネットへ公開していなければ安全ですか

外部から直接問い合わせを送られる可能性は下がりますが、完全な対策ではありません。

社内端末やアプリケーションが攻撃者の管理するドメインを名前解決すると、内部リゾルバーまで問い合わせが到達する可能性があります。内部向けDNSでも、RPZを使用している場合は優先して更新してください。

OSの再起動は必要ですか

BINDは通常ユーザー空間で動作するため、一般的にはBINDサービスまたはコンテナの再起動が中心です。

ただし、同時にカーネルや重要ライブラリを更新した場合、組織の更新基準やパッケージの指示に従ってOS再起動の要否を判断してください。

どこまで確認すれば対応完了ですか

次のすべてを確認した時点で完了とします。

  • bind-9.20.26-1.azl3以上がインストールされている
  • 実行中のnamedがRPM管理下の修正版である
  • 更新後にBINDプロセスを再起動している
  • UDPとTCPの問い合わせが成功する
  • RPZルールが期待どおり動作する
  • コンテナや独自バイナリに旧版が残っていない
  • 作業結果を証跡として保存している

まとめ：9.20.26-1以上への更新と実行プロセスの確認が必要

CVE-2026-11331は、BINDのRPZでワイルドカードCNAMEポリシーを使用する際に、細工された長いDNS名によってポリシーが回避される可能性がある脆弱性です。状況によっては、BINDプロセスが予期せず終了する可能性もあります。

Azure Linux 3.0では、次の順番で対応してください。

  1. rpm -q bindでインストール済みバージョンを確認する
  2. 9.20.23-1.azl3を修正済みと判断しない
  3. bind-9.20.26-1.azl3以上へ更新する
  4. コンテナや独自インストールのBINDも調査する
  5. 実際に動作しているBINDプロセスを再起動する
  6. UDP、TCP、RPZの動作を確認する
  7. RPM情報、プロセス起動時刻、テスト結果を証跡として残す

MSRCのFirstFixed表示だけで完了判定せず、ISCの影響範囲、Azure Linuxのパッケージ履歴、Microsoft公式リポジトリを照合することが重要です。2026年8月2日時点では、bind-9.20.26-1.azl3以上をCVE-2026-11331の対応完了基準としてください。

Linux
bind DNSセキュリティ Azure Linux 3.0 RPZ CVE-2026-11331

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次