MENU

CVE-2026-11721対策：Azure Linux 3.0のBINDを9.20.26-1以上へ更新する手順

Linux

Azure Linux 3.0でBINDを運用している場合は、導入済みパッケージを確認し、9.20.26-1.azl3以上へ更新するのが安全です。

MSRCのCVE-2026-11721ページでは、Azure Linux 3.0向けのFirstFixedとしてazl3 bind 9.20.23-1が掲載されています。一方、BINDの開発元であるISCは、BIND 9.20.0から9.20.24までを影響範囲とし、修正版を9.20.26としています。さらに、MicrosoftのAzure Linux公式リポジトリにもbind-9.20.26-1.azl3が公開されています。したがって、9.20.23-1を修正済みと判断して更新を止めるのではなく、9.20.26-1.azl3以降を適用するのが実務上の適切な対応です。(Microsoft Security Response Center)

CVE-2026-11721は、DNSSEC署名に含まれるラベル数をBINDが適切に検証しないことで、DNSキャッシュに不正な情報を保存される可能性がある脆弱性です。本記事では、影響を受ける構成の見分け方、Azure Linux 3.0での確認コマンド、更新手順、更新後の検証方法まで具体的に解説します。

目次

CVE-2026-11721の概要

CVE-2026-11721は、BINDの再帰問い合わせ・キャッシュ処理に関係するDNSキャッシュポイズニングの脆弱性です。

攻撃者が管理するDNSゾーンから細工したDNSSEC応答を返すことで、BINDが本来とは異なる名前のレコードを生成し、キャッシュへ保存する可能性があります。

公式情報を整理すると、次のとおりです。(ISC Knowledgebase)

項目内容
CVE番号CVE-2026-11721
対象BINDの再帰・キャッシュDNS機能
脆弱性の種類DNSキャッシュポイズニング
CVSSスコア7.5／High
CVSSベクターCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
CWECWE-1284
CWEの内容入力で指定された数量の不適切な検証
攻撃条件細工したDNSSEC応答を再帰リゾルバーに処理させる
認証不要
利用者の操作不要
主な影響DNS応答の完全性が損なわれる
ISCの修正版BIND 9.20.26、9.21.24、9.20.26-S1
Azure Linux 3.0での更新基準9.20.26-1.azl3以上
公式な回避策なし

CVSSの評価では、機密性や可用性ではなく、完全性への影響がHighとされています。キャッシュポイズニングが成立すると、利用者を意図しないIPアドレスへ誘導するなど、DNS応答の信頼性を損なう恐れがあります。

MSRCのFirstFixedが9.20.23-1でも、そのまま安全と判断できない理由

今回の対応で特に注意したいのが、MSRC、ISC、Azure Linux公式パッケージの情報に不整合が見られる点です。

情報源掲載内容運用上の判断
MSRCFirstFixedはazl3 bind 9.20.23-1表示だけで修正済みと判断しない
ISCBIND 9.20.0～9.20.24が影響対象9.20.23は上流の影響範囲内
ISC修正版はBIND 9.20.269.20.26以上を基準にする
Azure Linux公式リポジトリ9.20.26-1.azl3を公開Azure Linuxではこの版以上へ更新する
Azure Linuxの9.20.23-1変更履歴別のCVE修正を記載CVE-2026-11721の修正を確認できない

Linuxディストリビューションでは、上流のバージョン番号を維持したまま、脆弱性修正だけをバックポートする場合があります。そのため、本来はバージョン番号だけで脆弱性の有無を断定できません。

しかし、Azure Linuxの9.20.23-1に関する変更履歴には、CVE-2026-11721とは異なる複数の脆弱性修正が記載されている一方、CVE-2026-11721の記載は確認できません。また、Microsoft公式リポジトリには、ISCの修正版と一致する9.20.26-1.azl3がx86_64、aarch64の両方で公開されています。(GitHub)

このため、2026年8月2日時点では、次のように判断するのが安全です。

  • 9.20.23-1.azl3以前は更新対象とする
  • 9.20.26-1.azl3以上を修正済みの基準とする
  • FirstFixedに表示された版へ固定するのではなく、公式リポジトリの最新パッケージを適用する
  • 自動判定では単純な文字列比較を使わず、RPMとパッケージマネージャーの情報を利用する

DNSSECラベル数の不整合でキャッシュポイズニングが起きる仕組み

DNSSECでは、DNSレコードの正当性を検証するためにRRSIGレコードを使用します。RRSIGには、署名対象となる名前のラベル数を示すLabelsフィールドがあります。

CVE-2026-11721では、攻撃者が管理するDNSゾーンから、実際のゾーン名より少ないラベル数を設定したRRSIGを返すことが問題になります。

攻撃の流れは次のとおりです。

  1. 利用者またはシステムが、攻撃者の管理するドメインを問い合わせる
  2. BINDの再帰リゾルバーが、攻撃者側の権威DNSサーバーへ問い合わせる
  3. 攻撃者が、ラベル数に不整合のあるRRSIGを含む応答を返す
  4. BINDが短いゾーン名に対するワイルドカード名を誤って合成する
  5. 本来とは異なる名前のDNS情報がキャッシュされる
  6. 後続の問い合わせに対して、不正なキャッシュ情報が返される可能性がある

ISCによると、この攻撃経路はsynt​h-from-dnssec yes;が有効な場合に影響し、この設定は既定で有効です。ISCは公式な回避策を提示しておらず、修正版への更新を推奨しています。(ISC Knowledgebase)

設定条件だけを見ると、synth-from-dnssecを無効にすれば回避できるようにも見えます。しかし、ISCが「既知の回避策なし」としている以上、設定変更だけを正式な脆弱性対策として扱うべきではありません。動作変更による名前解決への影響も考えられるため、パッケージ更新を優先してください。

特に優先して確認すべきBINDの構成

BINDがインストールされているすべてのホストで、同じ危険度になるわけではありません。役割と公開範囲によって、対応の優先順位が変わります。

構成優先度判断理由
インターネットから再帰問い合わせを受け付けるDNSサーバー最優先信頼できない利用者から攻撃用ドメインを問い合わせさせやすい
社内全体で利用するキャッシュDNSサーバー高多数の端末へ不正な応答を返す可能性がある
クラウドシステム内の名前解決用リゾルバー高アプリケーションや外部API接続に影響が波及する
権威DNS専用で再帰問い合わせを無効化しているサーバー中主な攻撃経路は限定されるが、脆弱なパッケージは更新すべき
bind-utilsなどのツールだけを導入しているホスト低namedが動いていなければキャッシュ攻撃の経路は通常存在しない
BINDパッケージが未導入のホスト対象外当該BIND実装を使用していない

特に危険なのは、意図せずオープンリゾルバーになっている構成です。インターネット側から再帰問い合わせが可能な場合は、パッケージ更新と併せて、allow-recursion、allow-query-cache、ネットワークACL、ファイアウォールの設定も確認してください。

Azure Linux 3.0でBINDのバージョンを確認する方法

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

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

続いて、導入済みのBIND関連パッケージを確認します。

rpm -qa --qf '%{NAME} %{VERSION}-%{RELEASE}.%{ARCH}\n' \
  | grep -E '^bind([[:space:]-]|$)' \
  | 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.23が導入されているため、CVE-2026-11721への対応として更新が必要です。

次に、BINDの実行ファイルと稼働中のプロセスを確認します。

command -v named
named -v
pgrep -a named

named -vはディスク上にある実行ファイルのバージョンを表示します。更新後にサービスを再起動していない場合、稼働中のプロセスは古い実行ファイルやライブラリを使用し続けることがあります。

そのため、パッケージのバージョン確認だけでなく、更新後のサービス再起動まで実施することが重要です。

再帰問い合わせに関係する設定を確認する

設定ファイルに構文エラーがないか確認します。

sudo named-checkconf

再帰問い合わせやDNSSEC合成に関係する設定を抽出する場合は、次のように確認できます。

sudo named-checkconf -p -x \
  | grep -E 'synth-from-dnssec|recursion|allow-recursion|allow-query-cache'

-xは、出力時に共有シークレットを隠すための指定です。ただし、設定内容には内部ネットワークなどの情報が含まれる可能性があるため、結果をそのまま外部へ公開しないでください。

また、項目が表示されないからといって無効とは限りません。明示設定がない場合は既定値が使われるため、ファイアウォールやロードバランサーを含めた実際の到達範囲も確認する必要があります。

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

Azure Linuxでは、パッケージ管理にtdnfを使用します。Microsoftの公式ドキュメントでも、システム全体のパッケージ更新にはtdnf upgradeが案内されています。(Microsoft Learn)

更新前に実施すること

本番環境では、更新前に次の点を確認してください。

  • DNSサーバーの冗長構成と切り替え方法
  • BIND設定ファイルとゾーンファイルのバックアップ
  • named-checkconfによる構文チェック
  • 更新後に名前解決を確認するテスト項目
  • UDPとTCPの53番ポートを利用する監視や疎通確認
  • 変更時間帯における利用者への影響
  • Azure Linuxのパッケージリポジトリへ接続できること

複数台で冗長化している場合は、一斉に更新せず、1台ずつ更新して名前解決を確認する方法が安全です。

方法1：システム全体を更新する

組織の更新方針で問題がなければ、システム全体を更新する方法が最も確実です。

sudo tdnf upgrade -y

この方法では、BIND本体だけでなく、依存するbind-libsなどもパッケージマネージャーが整合性を保ちながら更新します。

ただし、BIND以外のパッケージも更新される可能性があります。本番環境では、事前にステージング環境で確認するか、変更対象を確認してから実行してください。

方法2：導入済みのBIND関連パッケージだけを更新する

変更範囲をBIND関連に限定する場合は、最初にパッケージ名を取得します。

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

printf '%s\n' "${BIND_PKGS[@]}"

表示されたパッケージ名を確認したうえで、次の処理を実行します。

if ((${#BIND_PKGS[@]})); then
  sudo tdnf upgrade -y "${BIND_PKGS[@]}"
else
  echo "BIND関連パッケージは見つかりませんでした"
fi

bindだけでなく、bind-libs、bind-utils、bind-dnssec-utils、bind-chrootなどが導入されている場合があります。手作業で一部だけを指定するより、導入済みパッケージをまとめて更新する方が、バージョンの不整合を避けられます。

更新されたパッケージのバージョンを確認する

更新後、もう一度RPM情報を確認します。

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

2026年8月2日時点の確認基準は、次のとおりです。

9.20.26-1.azl3

または、それより新しいAzure Linux公式パッケージであれば問題ありません。

「9.20.26」という文字列が含まれているかだけでなく、RELEASEに1.azl3などのAzure Linux向けリリース情報が付いていることも確認してください。

BINDを再起動して修正版を反映する

パッケージを更新しただけでは、稼働中のnamedプロセスに新しい実行ファイルやライブラリが反映されない場合があります。

最初に、実際のsystemdユニット名を確認します。

systemctl list-unit-files --type=service \
  | grep -E '^(named|bind).*\.service'

サービス名がnamed.serviceの場合は、次のように設定を確認してから再起動します。

sudo named-checkconf

UNIT=named.service
sudo systemctl restart "$UNIT"
sudo systemctl --no-pager --full status "$UNIT"

環境によってユニット名が異なる場合は、UNITの値を実際のサービス名に変更してください。

rndc reloadはゾーンや設定を再読み込みする操作であり、namedプロセス自体を新しい実行ファイルへ置き換えるものではありません。脆弱性修正を反映するときは、原則としてサービスを再起動します。

HA構成では、次の順序で実施すると影響を抑えられます。

  1. 1台を名前解決先から外す
  2. パッケージを更新する
  3. BINDを再起動する
  4. 名前解決とDNSSEC検証を確認する
  5. 正常であればサービスへ戻す
  6. 次のサーバーを同じ手順で更新する

更新後に確認すべき項目

稼働中のBINDバージョンを確認する

named -v
sudo rndc status

rndcの制御チャネルが設定されている場合、rndc statusで稼働中のサーバー情報を確認できます。

named -vの結果だけでは、すでに起動しているプロセスの状態を証明できません。サービスの再起動時刻とrndc status、systemdの状態を組み合わせて確認してください。

通常の名前解決を確認する

dig @127.0.0.1 example.com A

少なくとも、次の点を確認します。

  • タイムアウトしない
  • status: NOERRORになっている
  • 想定したANSWERが返る
  • 応答時間が更新前と比べて大幅に悪化していない
  • UDPだけでなく、必要に応じてTCPでも応答する

TCPで確認する場合は、次のように実行します。

dig @127.0.0.1 example.com A +tcp

DNSSECを利用した問い合わせを確認する

ルートゾーンのDNSKEYを問い合わせる例です。

dig @127.0.0.1 . DNSKEY +dnssec

DNSSEC検証を有効にしている環境では、正常に検証された応答のフラグにadが含まれることがあります。ただし、リゾルバーの設定や問い合わせ条件によって表示は異なるため、adの有無だけで正常・異常を判断しないでください。

組織内にDNSSEC署名済みの検証用ドメインがある場合は、そのドメインでも更新前後の応答を比較します。

BINDのログを確認する

ユニット名がnamed.serviceの場合は、次のコマンドで直近のログを確認できます。

sudo journalctl \
  -u named.service \
  --since "-15 minutes" \
  --no-pager

特に確認したいのは、次のような事象です。

  • 設定ファイルの読み込みエラー
  • ゾーンファイルの構文エラー
  • DNSSEC検証エラーの急増
  • trust anchorに関するエラー
  • 外部DNSへの到達エラー
  • namedの異常終了や再起動の繰り返し
  • 応答遅延やタイムアウトの増加

更新直後だけでなく、一定時間経過後にも監視システムや問い合わせ件数を確認してください。

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

ISCは、CVE-2026-11721に対する公式な回避策を提示していません。そのため、以下は修正版の代わりではなく、更新までの露出を抑えるための暫定対応です。(ISC Knowledgebase)

再帰問い合わせ元を制限する

社内向けのキャッシュDNSであれば、再帰問い合わせを許可するネットワークを必要最小限に限定します。

確認対象となる主な設定は次のとおりです。

recursion
allow-recursion
allow-query-cache

BINDのACLだけでなく、Azureのネットワークセキュリティグループ、ホスト側ファイアウォール、ロードバランサーの受信規則も確認してください。

オープンリゾルバーになっていないか確認する

インターネット側から任意のドメインについて再帰問い合わせが成功する状態は避けます。

権威DNSとして公開する必要がある場合でも、権威応答と再帰問い合わせの許可範囲は分離してください。

信頼できないネットワークからのDNS利用を減らす

ゲストネットワーク、外部委託先、検証環境など、管理範囲が異なるネットワークから本番の再帰リゾルバーを利用できる状態になっていないか確認します。

監視を強化する

更新までの間は、次の変化を重点的に監視します。

  • 普段問い合わせのないドメインへの急増
  • 特定クライアントからの大量問い合わせ
  • DNSSEC関連エラーの増加
  • 通常と異なるTTLや応答IPアドレス
  • 外部向けDNS通信量の急増
  • キャッシュヒット率の不自然な変化

ただし、ログ監視やキャッシュ削除だけでは脆弱性そのものは解消できません。更新可能になり次第、修正版を適用してください。

CVE-2026-11721対応で起きやすい失敗

MSRCの9.20.23-1だけを見て対応済みにする

今回最も注意すべき点です。

MSRCのFirstFixed表示だけを見ると、9.20.23-1で修正済みと判断できます。しかし、ISCは9.20.24までを影響範囲としており、Azure Linux公式リポジトリには9.20.26-1が公開されています。

9.20.23-1で更新を止めず、9.20.26-1.azl3以上を適用してください。

named -vだけで判断する

named -vは実行ファイルのバージョン確認には役立ちますが、導入済みの関連ライブラリや、現在稼働中のプロセスまで完全に確認できるわけではありません。

RPM情報、systemdの状態、rndc statusを併せて確認します。

パッケージ更新後に再起動しない

BINDが古い実行ファイルや共有ライブラリを読み込んだまま動作する可能性があります。

パッケージ更新後は、named-checkconfを実行してからサービスを再起動してください。

bindだけを更新して関連パッケージを残す

bind-libsなどが古いまま残ると、依存関係の不整合や想定外の動作につながる可能性があります。

システム全体を更新するか、導入済みのBIND関連パッケージをまとめてtdnf upgradeへ渡します。

権威DNS専用だから更新不要と判断する

再帰問い合わせを完全に無効化した権威DNS専用構成では、今回の主な攻撃経路は限定されます。しかし、設定変更や運用ミスによって再帰機能が有効になる可能性があります。

また、BINDの同じパッケージ系列には複数の脆弱性修正が含まれる場合があります。攻撃経路が限定的でも、保守期間内に修正版へ更新してください。

synth-from-dnssec noだけで対応を終了する

ISCは公式な回避策を提示していません。設定変更による機能影響もあるため、synth-from-dnssecの変更だけを恒久対策として扱うべきではありません。

Azure Linux 3.0管理者が今すぐ実施すべきこと

CVE-2026-11721への対応では、次の順序で作業を進めてください。

  1. Azure Linux 3.0を使用するサーバーからBIND導入ホストを抽出する
  2. rpmでBIND本体と関連パッケージの版を確認する
  3. namedが稼働しているか、再帰問い合わせを提供しているか確認する
  4. 9.20.23-1.azl3以前であれば、9.20.26-1.azl3以上へ更新する
  5. named-checkconfで設定を確認する
  6. BINDサービスを再起動する
  7. RPM、rndc status、dig、ログで更新結果を検証する
  8. 再帰問い合わせのACLとファイアウォールを見直す

MSRCのFirstFixed表示とISCの影響範囲が一致していないため、今回は「FirstFixedに書かれた最小バージョン」ではなく、「ISCが示す修正版を取り込んだAzure Linux公式パッケージ」を基準にすることが重要です。

Azure Linux 3.0では、bind-9.20.26-1.azl3またはそれより新しい公式パッケージへ更新し、サービス再起動と名前解決テストまで完了させてください。

Linux
bind DNSSEC 脆弱性対策 Azure Linux CVE-2026-11721

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次