CVE-2026-13321への対応で最初に押さえるべき結論は、Azure Linux 3.0のBINDをbind-9.20.26-1.azl3以上へ更新することです。9.20.23-1は修正済みとは判断できません。BINDの開発元であるISCは、9.20.0から9.20.24までを影響対象とし、9.20系の修正版を9.20.26としています。MicrosoftのAzure Linux公式パッケージ履歴でも、CVE-2026-13321の修正は9.20.26-1に記録されています。(ISCナレッジベース)
この脆弱性が悪用されると、DNSSECで正しく検証されたように見える偽の「ドメインが存在しない」という応答がキャッシュされる可能性があります。BINDプロセスが停止しなくても、Webサイト、API、認証基盤などへ名前解決できなくなる点に注意が必要です。
この記事では、CVE-2026-13321の仕組み、9.20.23-1を修正版と判断すべきでない理由、Azure Linux 3.0での確認・更新・再起動・検証手順まで具体的に解説します。
CVE-2026-13321の概要
CVE-2026-13321は、BINDのDNSSEC検証処理において、NSECレコードの範囲を正しく検証できない脆弱性です。
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-13321 |
| 対象ソフトウェア | ISC BIND 9 |
| Azure Linuxでの対象 | Azure Linux 3.0のBINDパッケージ |
| 脆弱性の種類 | DNSSEC検証回避、クロスゾーンのキャッシュ汚染 |
| 深刻度 | High |
| CVSS 3.1 | 8.6 |
| CVSSベクター | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N |
| CWE | CWE-346：Origin Validation Error |
| 攻撃経路 | ネットワーク |
| 攻撃に必要な権限 | 不要 |
| ユーザー操作 | 不要 |
| 既知の回避策 | なし |
| BIND 9.20系の影響範囲 | 9.20.0～9.20.24 |
| BIND 9.20系の修正版 | 9.20.26 |
| Azure Linux 3.0の対策基準 | bind-9.20.26-1.azl3以上 |
ISCは2026年7月22日に公開したアドバイザリで、遠隔から悪用可能なHighの脆弱性として公表しています。NVDにもCVSS 8.6およびCWE-346が登録されています。(ISCナレッジベース)
DNSSEC検証回避によって何が起こるのか
DNSSECは、DNS応答に電子署名を付け、応答が改ざんされていないことを検証する仕組みです。
存在しないドメイン名への問い合わせでは、DNSSEC署名付きのNSECレコードを利用して、「この範囲には問い合わせ対象の名前が存在しない」ことを証明します。
CVE-2026-13321では、BINDリゾルバーが、NSECレコードのNext Domain Nameフィールドが署名元ゾーンの外部を指している場合でも、そのレコードを受け入れてしまいます。
攻撃の流れは次のとおりです。
- 攻撃者がDNSSEC署名済みのドメインを管理する
- 対象のBINDリゾルバーに、攻撃者のドメインを問い合わせさせる
- 攻撃者が別の被害ドメインまで範囲に含めた不正なNSECレコードを返す
- BINDが不正なNSECレコードを正当なものとして検証する
- 別ドメインの名前が存在しないという情報がキャッシュされる
- 利用者には、DNSSECで認証済みであることを示すADフラグ付きの否定応答が返される
ISCは、攻撃者が管理するDNSSEC署名済みゾーンから別ゾーンへ範囲を広げ、認証済みの否定応答をキャッシュさせられると説明しています。(ISCナレッジベース)
任意のIPアドレスへ転送する脆弱性とは限らない
この脆弱性の中心は、任意のAレコードを挿入して攻撃者のサーバーへ誘導することではありません。
主な影響は、本来存在する名前について、次のような誤った結果を返させることです。
- ドメイン名が存在しない
- 該当するレコード種別が存在しない
- DNSSECで正しく検証された否定応答である
- 否定応答がキャッシュに残っている間、問い合わせが失敗し続ける
例えば、業務システムのAPI、ソフトウェア更新サーバー、認証サービス、メール配送先などの名前が存在しないと誤認されると、アプリケーション障害や通信断として現れます。
BINDが停止しなくても重大な障害になる
CVSSベクターは機密性がC:N、完全性がI:H、可用性がA:Nです。これは、BINDプロセスを直接クラッシュさせることよりも、DNSSEC検証結果の完全性を損なう性質が強いことを示しています。
ただし、利用者から見ると正しい名前を解決できないため、実運用ではサービス停止に近い障害になります。CPU使用率やプロセス監視が正常でも、DNS応答だけが壊れている可能性がある点が発見を難しくします。(ISCナレッジベース)
Azure Linux 3.0向け修正版は9.20.26-1
Azure Linux 3.0でCVE-2026-13321への対応完了を判断するときは、bind-9.20.26-1.azl3以上を基準にしてください。
MicrosoftのAzure Linux公式BINDパッケージ仕様では、9.20.26-1の変更履歴にCVE-2026-13321が明記されています。一方、9.20.23-1の変更履歴には別の脆弱性だけが記載されており、CVE-2026-13321は含まれていません。(GitHub)
MicrosoftのAzure Linux 3.0公式パッケージリポジトリにも、2026年7月29日付でbind-9.20.26-1.azl3のソースパッケージとバイナリパッケージが登録されています。(Microsoft Packages)
MSRCのFirstFixedに9.20.23-1が表示される場合の判断
MSRC Security Update GuideのFirstFixed情報として、次の表記を目にすることがあります。
azl3 bind 9.20.23-1 on Azure Linux 3.0しかし、CVE-2026-13321については、この値だけを根拠に9.20.23-1を修正版と判断すべきではありません。(Microsoft Security Response Center)
理由は次の3点です。
| 確認先 | 9.20.23の扱い |
|---|---|
| ISC公式アドバイザリ | 9.20.0～9.20.24を影響対象としている |
| Microsoft Azure Linuxパッケージ履歴 | CVE-2026-13321の修正を9.20.26-1に記録している |
| Microsoft公式パッケージリポジトリ | 9.20.26-1が公開されている |
Security Update Guideの表示、パッケージ情報、リポジトリへの反映には、データの解釈や反映時期による差が生じることがあります。原因を推測して更新を止めるのではなく、上流の影響範囲とMicrosoft自身のパッケージ変更履歴を照合して判断することが重要です。
2026年8月2日時点の公表情報では、次のように判断するのが安全です。
| 検出されたバージョン | 判断 |
|---|---|
bind-9.20.23-1.azl3 | 影響あり。更新が必要 |
| BIND 9.20.0～9.20.24 | 影響あり。更新が必要 |
bind-9.20.26-1.azl3 | 公表されている修正基準を満たす |
bind-9.20.26-1.azl3より新しい版 | 原則として修正済み。ただし最新のMicrosoft情報も確認する |
| 独自ビルドの9.11.0～9.18.50 | 上流の影響対象 |
| 独自ビルドの9.21.0～9.21.23 | 上流の影響対象 |
ISCが示した影響範囲と修正版は、9.20系だけでなく9.18系、9.21系およびSupported Preview Editionにも及びます。Azure Linux標準RPM以外のBINDを導入している場合は、上流バージョンも確認してください。(ISCナレッジベース)
影響調査の優先度が高い環境
CVE-2026-13321はBINDのリゾルバー処理に関係するため、再帰問い合わせやDNSキャッシュを提供しているサーバーほど優先度が高くなります。
| BINDの用途 | 対応優先度 | 判断理由 |
|---|---|---|
| 組織内の共有キャッシュDNS | 高 | 多数の端末やサーバーへ誤った否定応答を配布する可能性がある |
| DNSSEC検証を行う再帰リゾルバー | 最優先 | 脆弱な検証処理が直接利用される |
| インターネットから再帰問い合わせ可能 | 最優先 | 攻撃対象となる範囲が広い |
| クラウドサービスの名前解決基盤 | 高 | 障害が複数サービスへ連鎖しやすい |
| 権威DNS専用で再帰問い合わせ無効 | 相対的には低い | 主な影響箇所はリゾルバー処理。ただしパッケージ更新は必要 |
| 停止中の待機系サーバー | 中 | 切り替え時に脆弱な状態で稼働する可能性がある |
| コンテナイメージ内のBIND | 高 | ホストOSを更新してもコンテナ内は更新されない |
BINDがインターネットから直接参照できない社内DNSであっても、対応不要とは限りません。内部クライアントから攻撃者のDNSSEC署名済みゾーンへの問い合わせが発生すれば、再帰リゾルバーが不正な応答を処理する可能性があります。これはISCの攻撃条件から導ける実務上の判断です。(ISCナレッジベース)
Azure Linux 3.0でBINDの導入状況を確認する
OSがAzure Linux 3.0か確認する
最初に、対象サーバーのOSとバージョンを確認します。
grep -E '^(NAME|ID|VERSION_ID|PRETTY_NAME)=' /etc/os-releaseVERSION_IDが3.0であることを確認してください。似た名前のOSや別バージョンに対して、Azure Linux 3.0用のパッケージ基準をそのまま適用しないようにします。
インストール済みBINDパッケージを確認する
BIND本体のバージョンを確認します。
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' bindBIND関連のRPMをまとめて確認する場合は、次のコマンドを使用します。
rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' \
| grep -E '^(bind|python3-bind)-' \
| sort次のような結果であれば更新が必要です。
bind-9.20.23-1.azl3.x86_64
bind-libs-9.20.23-1.azl3.x86_64対策後は、少なくとも次の版になっていることを確認します。
bind-9.20.26-1.azl3.x86_64
bind-libs-9.20.26-1.azl3.x86_64ARM64環境では、末尾が.aarch64になります。
RPMが見つからなくても調査を終わらせない
rpm -q bindで「package bind is not installed」と表示されても、直ちに影響なしとは判断できません。
ソースコードからの独自インストール、/usr/local配下への配置、コンテナ内での実行などが考えられます。
command -v named || true
pgrep -a named || true
find /usr/local /opt -type f -name named 2>/dev/nullnamedが見つかった場合は、実体と管理元を確認します。
if command -v named >/dev/null 2>&1; then
named_path="$(readlink -f "$(command -v named)")"
printf 'named binary: %s\n' "$named_path"
rpm -qf "$named_path" || true
named -v
firpm -qfで所有パッケージが表示されなければ、独自ビルドや手動配置の可能性があります。その場合はRPMの更新ではなく、BIND本体の再ビルドや配布元製品の更新が必要です。
稼働中のBINDプロセスと待受ポートを確認する
pgrep -a named || true
ss -lntup | grep -E ':(53)\b' || true
systemctl list-units --type=service --all \
| grep -Ei 'named|bind' || trueポート53を待ち受けていても、実体がBINDとは限りません。反対に、フォワーダー用途やネットワーク名前空間内で動作している場合は、ホスト側の確認だけでは見つからないことがあります。
再帰問い合わせとDNSSEC検証の設定を確認する
設定ファイルに構文エラーがないか確認します。
sudo named-checkconf設定を正規化して、再帰問い合わせやDNSSEC検証に関係する項目を抽出します。
sudo named-checkconf -px /etc/named.conf \
| grep -E 'recursion|dnssec-validation|allow-recursion|allow-query-cache'-pは読み込まれた設定を標準形式で表示し、-xは共有秘密鍵を伏せます。設定内容をログやチケットへ貼り付ける場合は、秘密情報を露出しないために-xを併用してください。(BIND 9 9.20.26 Documentation)
ただし、該当項目が表示されないことだけで再帰問い合わせが無効とは判断できません。BINDの既定値、includeされた設定、ビューごとの設定、起動オプションも確認する必要があります。
Azure Linux 3.0のBINDを更新する手順
更新前に設定を検証する
パッケージ更新前に、現在の設定で正常に起動できることを確認します。
sudo named-checkconf権威DNSとしてゾーンファイルを管理している場合は、重要な設定ファイルとゾーンデータを、既存のバックアップ手順に従って退避してください。
バックアップを設定ディレクトリの内部へ作ると、ワイルドカード形式のincludeによってバックアップファイルまで読み込まれる可能性があります。退避先には/rootなど、BINDの設定から参照されない場所を使用します。
リポジトリで提供される版を確認する
tdnf list bind利用可能な版として、9.20.26-1.azl3以上が表示されることを確認します。
社内ミラーやプロキシリポジトリを使用している環境で9.20.23-1までしか表示されない場合は、ミラーの同期状況を確認してください。修正版が見えない状態で、脆弱性管理ツールだけを「対応済み」に変更してはいけません。
BINDパッケージを更新する
BINDだけを対象に更新する場合は、次のコマンドを実行します。
sudo tdnf update bindAzure Linux 3.0全体を最新状態にする運用であれば、通常のメンテナンス手順に従って全パッケージを更新します。
sudo tdnf updateAzure LinuxではTiny DNFであるtdnfがパッケージ管理に使用され、Microsoftの公式ドキュメントでもtdnf listおよびtdnf updateによる確認・更新方法が案内されています。(Microsoft Learn)
更新後、関連パッケージの版がそろっていることを確認します。
rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' \
| grep -E '^(bind|python3-bind)-' \
| sortbindだけが9.20.26で、bind-libsなどが9.20.23のまま残る状態は避けてください。
パッケージ更新後はBINDを再起動する
RPMを更新しただけでは、稼働中のnamedプロセスが古いコードをメモリ上で実行し続ける可能性があります。対策を完了するには、実際にBINDを管理しているサービス、プロセスマネージャーまたはコンテナを再起動する必要があります。
まず、実際のサービス名を確認します。
systemctl list-unit-files \
| grep -Ei 'named|bind'サービス名がnamed.serviceである場合の例は次のとおりです。
sudo systemctl restart named.service
sudo systemctl is-active named.service
sudo journalctl -u named.service -n 100 --no-pager環境によっては、サービス名が異なる場合や、独自のsystemdユニット、コンテナ、監視ソフトウェアから起動されている場合があります。確認せずにnamed.serviceを決め打ちしないでください。
冗長構成では、すべてのDNSリゾルバーを同時に再起動すると名前解決が停止します。ロードバランサーやクライアントの参照先を確認し、1台ずつローリング再起動します。
更新後に修正版が動いていることを確認する
RPMのバージョンを再確認する
rpm -q --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' bind期待する結果は次の版以上です。
bind-9.20.26-1.azl3ディスク上のBINDバージョンを確認する
named -vBIND本体が9.20.26以上であることを確認します。
稼働中のBINDバージョンを確認する
rndcを設定している場合は、実際に稼働中のデーモン情報を確認できます。
sudo rndc status | sed -n '1,10p'パッケージ情報とnamed -vが新しくても、rndc statusで古いバージョンが表示される場合は、再起動が完了していません。
プロセスの実行ファイルも確認できます。
if pid="$(pgrep -xo named)"; then
sudo readlink "/proc/${pid}/exe"
ps -o pid,lstart,cmd -p "$pid"
fi実行ファイル名の末尾に(deleted)が表示される場合は、更新前のバイナリをプロセスが保持している可能性があります。正しい方法で再起動してください。
DNSSECの正常応答を確認する
自組織で管理するDNSSEC署名済みゾーンを使い、正常な名前と存在しない名前の両方を確認します。
resolver="127.0.0.1"
zone="signed.example.jp"
dig @"${resolver}" "www.${zone}" A +dnssec
dig @"${resolver}" "not-exist-$(date +%s).${zone}" A +dnsseczoneは実際のDNSSEC署名済みドメインへ置き換えてください。
確認するポイントは次のとおりです。
- 正常な名前が期待するIPアドレスへ解決される
- DNSSEC署名のある応答で
adフラグを確認できる - 存在しない名前だけが
NXDOMAINになる - 更新後のログにDNSSEC検証エラーが大量発生していない
- フォワーダーや上流DNSへの通信が正常である
- 実際の業務アプリケーションから名前解決できる
本番環境に対して脆弱性を再現する攻撃用NSECレコードを送信する必要はありません。通常の正引き、否定応答、DNSSEC検証、業務通信を確認すれば、更新後の基本的な健全性を検証できます。
コンテナやAKS環境ではホスト更新だけで終わらせない
BINDがコンテナ内で稼働している場合、Azure LinuxホストのRPMを更新しても、コンテナイメージ内のBINDは更新されません。
次の範囲を個別に確認してください。
- Dockerまたはcontainerd上のBINDコンテナ
- KubernetesのPodやサイドカー
- プライベートコンテナレジストリに保存された旧イメージ
- CI/CDで使用するベースイメージ
- 停止中のPodやロールバック用イメージ
- VMイメージ、スナップショット、テンプレート
シェルを利用できるコンテナでは、コンテナ内で確認します。
rpm -q bind
named -vシェルを持たない最小構成イメージでは、SBOM、イメージスキャナー、Dockerfile、ビルドログなどからBINDのバージョンを確認します。
また、DNS関連のPodであっても、実装がCoreDNSやUnboundであれば、このBIND固有のCVEをそのまま適用することはできません。コンテナ名ではなく、実際のバイナリとパッケージを確認してください。
対応時に失敗しやすいポイント
| 失敗例 | 問題点 | 正しい対応 |
|---|---|---|
| 9.20.23-1を修正版と判断する | ISCの影響範囲に含まれている | 9.20.26-1以上を基準にする |
rpm -q bindだけで調査を終える | 独自ビルドやコンテナを見落とす | namedプロセス、実行パス、イメージも確認する |
dig -vだけを確認する | DNSクライアントの版であり、稼働中のnamedとは限らない | named -vとrndc statusを確認する |
| パッケージ更新後に再起動しない | 古いコードがメモリ上で動き続ける | 実際の管理方式に従って再起動する |
| 全リゾルバーを同時に再起動する | 組織全体で名前解決できなくなる | 1台ずつローリング再起動する |
| 外部公開の有無だけで判断する | 内部クライアント経由でも問い合わせが発生する | 再帰リゾルバーの役割と利用者範囲で判断する |
| DNSSECを無効にして恒久対応とする | DNSSEC本来の改ざん検知を失う | 既知の回避策はないため修正版へ更新する |
| ホストOSだけ更新する | コンテナや旧イメージが脆弱なまま残る | イメージを再ビルドして再デプロイする |
| スキャナーの表示だけを修正済みにする | 実際のパッケージやプロセスが古い可能性がある | RPM、実行バイナリ、稼働プロセスを三段階で確認する |
ISCは公開時点で既知の実悪用を把握していないとしていますが、同時に利用可能な回避策はないと説明しています。この情報は2026年7月22日時点のものであり、悪用未確認を更新延期の理由にすべきではありません。(ISCナレッジベース)
CVE-2026-13321への対応チェックリスト
最後に、Azure Linux 3.0で行うべき作業を整理します。
- Azure Linux 3.0を使用しているホストとイメージを洗い出す
- RPM、独自バイナリ、コンテナ内のBINDを確認する
bind-9.20.23-1.azl3を修正済みと扱わないbind-9.20.26-1.azl3以上へ更新する- 設定を検証してから実際の
namedプロセスを再起動する - 冗長構成ではローリング再起動する
- RPMの版、
named -v、rndc statusを照合する - 正常応答、否定応答、DNSSEC検証、業務通信を確認する
- コンテナ、VMテンプレート、停止中の待機系も更新する
- 脆弱性スキャンを再実行し、検出が解消したことを確認する
CVE-2026-13321では、表示上のFirstFixed情報だけでなく、上流の影響範囲とAzure Linuxのパッケージ修正履歴を照合することが重要です。まずrpm -q bindで導入版を確認し、9.20.23-1またはそれ以前であれば、9.20.26-1以上への更新、BINDの再起動、稼働版の再確認までを一連の作業として実施してください。
コメント