MENU

CVE-2026-12617：Azure Linux 3.0のBIND修正版と更新・確認手順

Linux

Azure Linux 3.0でBINDを利用している場合は、まずインストール済みパッケージを確認し、bind-9.20.26-1.azl3以上へ更新してください。CVE-2026-12617は、CNAMEまたはDNAMEとAレコードに対する応答の順序や内容によって、DNSサーバープロセスのnamedがアサーションエラーで異常終了する脆弱性です。CVSS基本値は7.5で、DNS名前解決が停止する可用性への影響が中心となります。(ISC Knowledgebase)

MSRCのFirstFixed欄に「azl3 bind 9.20.23-1 on Azure Linux 3.0」と表示される場合でも、9.20.23-1だけを根拠に修正済みと判断するのは避けるべきです。BIND開発元のISCは9.20.24までを影響対象とし、修正版を9.20.26としています。さらに、MicrosoftのAzure LinuxリポジトリでもCVE-2026-12617への対応として9.20.26への更新が行われ、公式パッケージリポジトリにはbind-9.20.26-1.azl3が公開されています。(Microsoft Security Response Center)

目次

結論：Azure Linux 3.0ではBIND 9.20.26-1以上へ更新する

2026年8月2日時点で公開されている公式情報を突き合わせると、Azure Linux 3.0におけるCVE-2026-12617の対応完了基準は、次のように整理できます。

確認項目内容
脆弱性CVE-2026-12617
対象ソフトウェアBIND 9
Azure Linuxで確認すべき系統BIND 9.20系
主な影響namedの異常終了、DNS名前解決の停止
CVSS基本値7.5
CVSS上の影響機密性・完全性への影響なし、可用性への影響が高い
CWECWE-617：Reachable Assertion
ISCが示す影響範囲BIND 9.20.0～9.20.24
ISCが示す修正版BIND 9.20.26
Azure Linux 3.0の対応目安bind-9.20.26-1.azl3以上
既知の回避策なし
悪用状況ISCは2026年7月22日の公開時点で、実際の悪用を把握していない

ISCは、BIND 9.20.0から9.20.24までを影響対象としており、9.20.26への更新を解決策として示しています。また、MicrosoftのAzure Linux向け変更履歴でも、9.20.23から9.20.26への更新理由にCVE-2026-12617が明記されています。(ISC Knowledgebase)

Microsoftの公式パッケージリポジトリでは、x86_64版とaarch64版の両方について、bind-9.20.26-1.azl3が2026年7月29日付で公開されています。(Microsoft Packages)

CVE-2026-12617で何が起きるのか

CVE-2026-12617は、DNSレコードそのものに不正なコードが含まれる脆弱性ではありません。複数のDNS問い合わせに対する応答の順序と内容の組み合わせによって、BIND内部の想定が崩れ、アサーションが発生する問題です。

CNAME処理で異常終了するケース

CNAMEは、特定のホスト名を別のホスト名へ対応付けるレコードです。

ISCが説明しているCNAME側の発生条件は、概ね次の流れです。

  1. クライアントが同じ名前についてCNAMEレコードとAレコードを問い合わせる
  2. 権威DNSサーバーがAレコードへの肯定応答を先に返す
  3. CNAMEへの応答を遅延させる
  4. 後から、自分自身を参照するCNAMEを返す
  5. BINDのnamedがアサーションにより終了する可能性がある

DNAME処理で異常終了するケース

DNAMEは、あるドメイン名以下の名前空間を、別の名前空間へまとめて置き換えるためのレコードです。

DNAME側では、次のような応答順序が問題になります。

  1. クライアントがDNAME配下の名前についてDNAMEレコードとAレコードを問い合わせる
  2. 権威DNSサーバーがAレコードへの肯定応答を先に返す
  3. DNAMEへの応答を遅延させる
  4. 後からDNAMEへの否定応答を返す
  5. BINDのnamedが異常終了する可能性がある

いずれも、問い合わせ先の権威DNSサーバーから返される応答の順序や内容によって問題が誘発されます。攻撃者がクライアントからの問い合わせと、攻撃者管理下のドメインから返すDNS応答を組み合わせることで、脆弱な再帰DNSリゾルバーへ影響を与えられる可能性があります。(ISC Knowledgebase)

CWE-617が示すリスク

CVE-2026-12617は、CWE-617「Reachable Assertion」に分類されています。

アサーションは、プログラム内部で「通常は必ず成立するはずの条件」を確認する仕組みです。想定外の状態を検知した際、安全のためにプログラムを終了させる目的などで使用されます。

しかし、外部から与えられるデータによってアサーションを意図的に発生させられる場合、攻撃者がサーバープロセスを終了させるDoS攻撃につながります。MITREもCWE-617について、攻撃者がアサーションを発生させることでアプリケーション終了やサービス拒否を引き起こす問題と説明しています。(CWE)

CVE-2026-12617のCVSSベクトルでは、次の点が重要です。

  • ネットワーク経由で到達可能
  • 攻撃条件の複雑さは低い
  • 認証や利用者操作を必要としない
  • 機密情報の漏えいは想定されていない
  • データ改ざんは想定されていない
  • 可用性への影響は高い

したがって、リモートコード実行や情報漏えいの脆弱性ではないものの、DNSリゾルバーが停止すると、多数のシステムで名前解決ができなくなる可能性があります。DNSサーバー単体の停止であっても、Webアクセス、API通信、認証、メール配送、パッケージ更新などへ連鎖的に影響する点に注意が必要です。(ISC Knowledgebase)

MSRCの9.20.23-1を修正版と判断しない理由

MSRCのFirstFixed欄にazl3 bind 9.20.23-1 on Azure Linux 3.0と表示されている場合、管理者は「9.20.23-1なら対応済み」と判断しやすくなります。

しかし、現在公開されている公式情報では、次の3点が確認できます。

  1. ISCはBIND 9.20.0から9.20.24までを影響対象としている
  2. ISCが示す修正版はBIND 9.20.26である
  3. MicrosoftのAzure Linux向け変更では、9.20.23から9.20.26への更新理由にCVE-2026-12617が含まれている

Microsoftの変更記録には、更新前の対象バージョンが9.20.23、解決後のバージョンが9.20.26であることも示されています。(ISC Knowledgebase)

そのため、Azure Linux 3.0の公式パッケージについては、次のように判断するのが安全です。

検出された状態判断必要な対応
bind-9.20.23-1.azl3修正前として扱う9.20.26-1以上へ更新
bind-9.20.24以前影響対象9.20.26-1以上へ更新
bind-9.20.26-1.azl3修正パッケージの候補サービス再起動と動作確認
9.20.26-1より新しい公式パッケージ原則として修正を含む変更履歴を確認して適用
bindが未導入ホスト上のRPMは非該当コンテナや独自導入を確認
独自ビルドや非公式RPMバージョン表示だけでは判断不可配布元の修正履歴を確認

MSRC表示と上流・製品リポジトリの情報が一致しない正確な理由は、公開ページからは断定できません。メタデータの反映時期やパッケージ対応付けの違いなどが考えられますが、脆弱性対応では推測ではなく、上流の影響範囲、Microsoftの修正履歴、実際に配布されているパッケージの3点を確認することが重要です。

影響確認を優先すべきBINDサーバー

すべての該当サーバーで更新が必要ですが、障害時の影響と到達経路によって優先順位を付けると対応しやすくなります。

運用形態優先度判断理由
インターネットから利用可能な再帰DNSリゾルバー最優先外部から問い合わせを受け、攻撃者管理ドメインを名前解決する可能性がある
社内向け再帰DNSリゾルバー高社内端末から攻撃者管理ドメインへの問い合わせが発生する可能性がある
VPN利用者向けDNSリゾルバー高接続端末を経由して問題を誘発される可能性がある
権威DNS専用で再帰問い合わせを無効化したサーバー中公開された発生条件はリゾルバー処理に関係するが、将来の運用変更も考慮して更新が必要
停止中の検証サーバー中～低稼働再開前に更新すればよい
コンテナ内で稼働するBIND構成次第ホスト側RPMの確認だけでは検出できない

社内限定のDNSサーバーであっても、インターネット上のドメインを再帰名前解決する構成なら対象になり得ます。「外部にTCP/UDP 53番ポートを公開していないから安全」とは限りません。

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

OSがAzure Linux 3.0か確認する

最初に、対象ホストのOSとCPUアーキテクチャを確認します。

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

VERSION_IDが3.0であることを確認します。

uname -mの主な出力は次のとおりです。

  • x86_64：x86_64版パッケージ
  • aarch64：Arm64版パッケージ

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

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

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

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

出力例が次の場合は更新が必要です。

bind-9.20.23-1.azl3.x86_64

修正版へ更新済みの場合は、次のような出力になります。

bind-9.20.26-1.azl3.x86_64

BIND関連パッケージをまとめて確認するには、次のコマンドを使用します。

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

bind-chroot、bind-utils、BINDのライブラリなどが混在している場合は、古い9.20.23系のパッケージが残っていないか確認してください。

実際に使用されているnamedを確認する

RPMを更新していても、独自に配置したBINDが起動している可能性があります。

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

表示されたバイナリがどのRPMに含まれているか確認します。

rpm -qf "$(command -v named)"

rpm -qfで「ファイルはいずれのパッケージにも属していません」と表示された場合は、ソースコードからのビルドや手動配置が考えられます。その場合はAzure LinuxのRPMだけでなく、独自バイナリ自体をBIND 9.20.26以上へ更新する必要があります。

なお、次のコマンドで確認できるdigのバージョンだけでは、DNSサーバー本体の修正状況を判定できません。

dig -v

digはクライアント側のツールです。脆弱性の影響を受けるnamedと、異なるバージョンやパッケージから提供されている場合があります。

BINDが実際に稼働しているか確認する

サービスとプロセスを確認します。

systemctl list-unit-files | grep -E '^(named|bind).*\.service'
sudo systemctl --no-pager --full status named.service
ps -eo pid,lstart,cmd | grep '[n]amed'

53番ポートの待ち受け状態も確認します。

sudo ss -lnutp | grep ':53'

DNSではUDP 53番だけでなく、応答サイズや処理内容によってTCP 53番も使用します。片方だけを確認して「稼働している」と判断しないようにしてください。

再帰DNS機能の設定を確認する

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

sudo named-checkconf

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

sudo named-checkconf -p \
  | grep -E '^[[:space:]]*(recursion|allow-recursion|allow-query-cache)'

特に確認したい項目は次のとおりです。

  • recursion
  • allow-recursion
  • allow-query-cache
  • viewごとの設定
  • 設定ファイルから読み込まれるinclude
  • Azure NSGやホストファイアウォールの許可範囲

recursion yes;であり、不特定の接続元から利用できる状態なら優先的な対応が必要です。

コンテナ内のBINDを見落とさない

ホスト上でbindパッケージが見つからなくても、DockerやKubernetesのコンテナ内でBINDが動いている場合があります。

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

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

Kubernetesでは、対象Pod内で確認します。

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

コンテナのベースイメージがAzure Linux以外の場合は、Azure Linux用RPMではなく、そのディストリビューションやイメージ提供元が公開する修正版へ更新してください。

Azure Linux 3.0で修正版へ更新する手順

更新前に構成と冗長性を確認する

DNSサーバーを更新すると、サービス再起動が必要になります。更新前に次の点を確認してください。

  • 冗長化されたDNSサーバーが正常に応答している
  • 更新対象をロードバランサーから一時的に外せる
  • DNSクライアントに複数のDNSサーバーが設定されている
  • BINDの設定ファイルとゾーンデータをバックアップしている
  • 変更前のRPMバージョンとサービス状態を記録している
  • 監視システムのアラート抑止やメンテナンス設定を行っている

複数台のDNSサーバーがある場合は、全台を同時に更新せず、1台ずつ更新して応答を確認するローリング方式が安全です。

BINDの設定を事前検証する

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

sudo named-checkconf

マスターゾーンを含めて読み込みを検証できる環境では、次のコマンドも実行します。

sudo named-checkconf -z

動的更新を利用しているゾーンでは、単純なゾーンファイルのコピーだけでは最新状態を保存できない場合があります。ジャーナルファイルや運用中の更新方法を考慮し、既存のバックアップ手順に従ってください。

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

Azure Linuxではパッケージ管理にTiny DNFのtdnfを使用します。Microsoftの資料でも、パッケージ情報の削除にはtdnf clean all、更新にはtdnf updateやtdnf upgradeを使用する構成が示されています。(Microsoft Learn)

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

sudo tdnf clean all
tdnf list bind
tdnf info bind

候補バージョンに9.20.26-1以上が表示されることを確認してください。

BINDを更新する

BIND本体を更新します。

sudo tdnf update bind

BIND関連の別パッケージがインストールされている場合は、一覧を再確認します。

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

bind-chrootなどが古いまま残っている場合は、インストール済みのパッケージ名を指定して更新します。

sudo tdnf update bind-chroot

システム全体の更新を適用できるメンテナンス方針であれば、個別更新ではなく次の方法もあります。

sudo tdnf upgrade

ただし、システム全体の更新ではBIND以外のパッケージも変更されます。事前に変更内容を確認し、組織のパッチ適用手順に従ってください。

9.20.26-1が表示されない場合

tdnf list bindで9.20.26-1が表示されない場合は、次を確認します。

tdnf repolist
tdnf list bind

リポジトリ設定も確認します。

grep -RnsE '^[[:space:]]*(enabled|baseurl|metalink)' \
  /etc/yum.repos.d/ 2>/dev/null

修正版が取得できない主な原因は次のとおりです。

  • tdnfのキャッシュが古い
  • Azure Linux 3.0のベースリポジトリが無効
  • 社内ミラーへの同期が完了していない
  • パッケージのバージョン固定や除外設定がある
  • プロキシやファイアウォールでリポジトリ通信が遮断されている
  • 使用しているイメージが更新停止されたスナップショットである

Microsoftの公式リポジトリには9.20.26-1が存在するため、候補に表示されない場合は、パッケージが未公開なのではなく、対象環境のリポジトリ経路や同期状態を調査する必要があります。(Microsoft Packages)

出所不明のRPMをインターネット上から直接取得して上書きする方法は避けてください。依存関係、署名、今後の更新経路が崩れる可能性があります。

更新後はnamedを必ず再起動する

RPMを更新しただけでは、すでにメモリ上で動作している古いnamedプロセスは入れ替わりません。

通常のサービス名を使用している場合は、次のように再起動します。

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

環境によっては、次のような別のユニットを使用している場合があります。

  • named-chroot.service
  • 独自に作成したsystemdユニット
  • コンテナ管理サービス
  • KubernetesのDeploymentやStatefulSet

先に次のコマンドで、実際のユニット名を確認してください。

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

rndc reloadは設定やゾーン情報を再読み込みする操作であり、実行中のプログラム本体を修正版へ入れ替える操作ではありません。

sudo rndc reload

上記のコマンドだけでCVE対応を完了させず、systemctl restartまたはコンテナの再作成によって、修正版バイナリを起動してください。

更新後の確認方法

RPMと実行ファイルのバージョンを再確認する

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

Azure Linux 3.0の公式パッケージを利用している場合は、少なくとも次の状態になっていることを確認します。

bind-9.20.26-1.azl3.x86_64

Arm64環境では次のようになります。

bind-9.20.26-1.azl3.aarch64

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

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

更新作業より前の起動時刻が表示されている場合は、古いプロセスが動作し続けている可能性があります。

systemdの起動時刻も確認できます。

sudo systemctl show named.service \
  -p ActiveEnterTimestamp \
  -p ExecMainStartTimestamp

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

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

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

  • 設定ファイルの構文エラー
  • ゾーンファイルの読み込み失敗
  • 53番ポートの競合
  • 権限エラー
  • アサーションエラー
  • サービスの再起動ループ

再帰DNSサーバーの応答を確認する

UDPでの名前解決を確認します。

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

TCPでも確認します。

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

正常な応答が返るだけでなく、SERVFAIL、タイムアウト、異常な遅延が発生していないか確認してください。

権威DNSサーバーの応答を確認する

権威DNS専用サーバーでは、実際に管理しているゾーンを指定します。

dig @127.0.0.1 your-zone.example. SOA \
  +norecurse \
  +time=2 \
  +tries=1

ローカルホストだけでなく、実際のクライアントネットワークやロードバランサー経由でも確認してください。

冗長構成へ戻す

1台目の更新と動作確認が完了したら、ロードバランサーやDNS配布先へ戻します。その後、同じ手順で次のサーバーを更新します。

更新完了後は、少なくとも次の情報を作業記録として残しておくと、監査やインシデント対応で役立ちます。

  • 対象ホスト名
  • 更新前のBINDバージョン
  • 更新後のBINDバージョン
  • 更新日時
  • namedの再起動日時
  • UDP・TCPの名前解決結果
  • ログ確認結果
  • コンテナや独自バイナリの確認結果

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

ISCはCVE-2026-12617について、既知の回避策はないとしています。そのため、設定変更だけで脆弱性を完全に解消することはできません。(ISC Knowledgebase)

更新までの間は、次の対策で影響範囲を限定します。

再帰DNSを利用できる接続元を制限する

再帰問い合わせは、社内ネットワーク、VPNネットワーク、必要なアプリケーションサブネットなどに限定します。

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

  • BINDのallow-recursion
  • BINDのallow-query-cache
  • Azure NSG
  • Azure Firewall
  • ホストファイアウォール
  • オンプレミス側ファイアウォール
  • ロードバランサーの受信規則

TCP 53番とUDP 53番の両方を確認してください。

脆弱なノードを処理経路から外す

修正版のDNSサーバーが別にある場合は、脆弱なノードをロードバランサーやDNS配布設定から外します。

単にサービスを自動再起動するだけでは、攻撃のたびに停止と再起動を繰り返す可能性があります。自動再起動は停止時間を短くする補助策であり、修正版への更新の代わりにはなりません。

権威DNSと再帰DNSの役割を分離する

1台のBINDで権威DNSと再帰DNSを兼用している場合は、役割分離も検討します。

権威DNS専用サーバーで再帰名前解決が不要なら、影響確認のうえで再帰機能を無効化できます。ただし、運用中のサーバーへ一律にrecursion no;を設定すると、社内システムの名前解決が停止する可能性があります。構成を確認せずに変更しないでください。

自組織のCNAMEやDNAMEだけを削除しない

問題は、自組織が管理するゾーン内のCNAMEやDNAMEだけで発生するとは限りません。再帰リゾルバーが外部の権威DNSサーバーから受け取る応答によって誘発される可能性があります。

そのため、自組織のゾーンからCNAMEやDNAMEを削除する方法は、一般的な回避策にはなりません。

対応時によくある失敗

失敗例問題点正しい対応
9.20.23-1を修正版として完了扱いするISCの影響範囲に9.20.23が含まれる9.20.26-1以上へ更新
dig -vだけを確認するクライアントツールのバージョンしか分からないrpm -q bindとnamed -Vを確認
RPM更新後に再起動しないメモリ上で古いnamedが動き続ける実際のサービスを再起動
rndc reloadだけを実行する設定再読み込みであり、バイナリは入れ替わらないsystemctl restartを実施
ホストだけを確認するコンテナ内のBINDを見落とすDockerやKubernetes内も確認
UDP 53番だけをテストするTCPでのDNS応答障害を見落とすUDPとTCPの両方を確認
全DNSサーバーを同時更新する名前解決基盤が一斉停止する可能性がある1台ずつローリング更新
非公式RPMを直接導入する署名・依存関係・更新経路に問題が生じる公式または承認済みリポジトリを使用
社内DNSだから後回しにする社内端末から外部ドメインを問い合わせられる再帰DNSなら優先的に更新
パッケージ候補が古いまま放置する社内ミラーやリポジトリ設定の問題を見落とすキャッシュ、同期、除外設定を調査

CVE-2026-12617への対応を完了するチェックリスト

対応は、パッケージをインストールした時点ではなく、修正版プロセスが正常に稼働していることを確認して完了です。

  • Azure Linux 3.0であることを確認した
  • bindのRPMバージョンを確認した
  • bind-9.20.26-1.azl3以上へ更新した
  • BIND関連パッケージに古い版が残っていない
  • 独自ビルドのnamedが使われていない
  • DockerやKubernetes内のBINDを確認した
  • 実際に使用しているsystemdサービスを再起動した
  • プロセスの起動時刻が更新後になっている
  • UDPとTCPの両方でDNS応答を確認した
  • ログにアサーションや起動エラーがない
  • 冗長構成を1台ずつ更新した
  • 更新結果を作業記録へ残した

CVE-2026-12617では、CNAMEまたはDNAME処理に関係する特定の応答順序によって、BINDのnamedが異常終了します。Azure Linux 3.0を利用している管理者は、まずrpm -q bindで導入済みバージョンを確認してください。

bind-9.20.23-1.azl3であれば修正済みとせず、bind-9.20.26-1.azl3以上へ更新します。その後、実際のnamedサービスを再起動し、RPM、実行ファイル、プロセス起動時刻、DNS応答、ログの順に確認することで、更新漏れや再起動忘れを防げます。

Linux
DNS 脆弱性 bind Azure Linux 3.0 CVE-2026-12617

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次