MENU

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

Azure

Azure Linux 3.0でUnboundを利用している場合は、まずインストール済みパッケージを確認してください。unbound-1.25.1-1.azl3以前であれば、unbound-1.25.2-1.azl3以上への更新を推奨します。

MSRCのFirstFixed欄では「azl3 unbound 1.25.1-1 on Azure Linux 3.0」と表示される一方、Unboundの開発元であるNLnet Labsは、1.25.1までを影響対象、1.25.2を修正版としています。さらに、MicrosoftのAzure Linux 3.0向け公式リポジトリにも、x86_64・aarch64の両方で1.25.2-1が公開されています。公開情報に不一致があるため、実務ではFirstFixed欄だけで対応完了と判断せず、1.25.2-1以上を安全側の更新基準とするのが適切です。(Microsoft Security Response Center)

CVE-2026-44690は、DNSSECのRRSIG情報を悪用し、UnboundのDNSキャッシュへ不正なレコードを混入させる脆弱性です。攻撃が成立すると、利用者を本来とは異なるIPアドレスへ誘導するなど、DNS応答の完全性が損なわれる可能性があります。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

CVE-2026-44690の概要

CVE-2026-44690は、DNSSEC検証に対応するキャッシュDNSリゾルバーで発見された、ゾーンをまたぐワイルドカードキャッシュポイズニングの脆弱性です。

Unboundでは、RFC 8198に基づく「Aggressive NSEC」を利用している場合に影響を受けます。攻撃者は、自身が管理する委任済みゾーンから細工したDNS応答を返し、同じ親ゾーンに属する無関係な兄弟ゾーンについて、不正なワイルドカード情報をキャッシュさせる可能性があります。(NLnet Labs)

項目内容
CVE番号CVE-2026-44690
対象ソフトウェアNLnet Labs Unbound
Azureでの対象Microsoft Azure Linux 3.0
影響を受ける上流版Unbound 1.7.0以上、1.25.1以下
上流の修正版Unbound 1.25.2
Azure Linux 3.0で推奨する基準unbound-1.25.2-1.azl3以上
脆弱性の種類DNSキャッシュポイズニング
CVSS v3.17.5、重要度High
CVSSベクターAV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
CWECWE-345：データ真正性の検証不備

CVSSベクターでは、ネットワーク経由で攻撃でき、攻撃条件の複雑さは低く、事前の権限や利用者操作も不要と評価されています。主な影響は機密性や可用性ではなく、DNS応答の完全性です。(NVD)

RRSIG操作でDNSキャッシュポイズニングが起きる仕組み

DNSSECのRRSIGレコードには、署名対象となった名前のラベル数を示す「Labels」フィールドがあります。

たとえば、通常の名前であるwww.example.comと、ワイルドカード名である*.example.comでは、署名時に扱うラベル数が異なります。DNSSEC検証側はLabelsフィールドを使い、応答がワイルドカードから生成されたものかを判断し、署名時の元の名前を復元します。(IETF Datatracker)

CVE-2026-44690では、次の処理が組み合わさることで問題が発生します。

  • RRSIGのLabelsフィールドに対する下限チェックが不十分だった
  • DNSSEC検証が完了する前に一部の情報がキャッシュへ書き込まれた
  • Aggressive NSEC処理で、キャッシュ済みのNSEC情報やワイルドカード情報が再利用された
  • ワイルドカード更新時のゾーン境界チェックが不十分だった

攻撃者が細工したRRSIGやワイルドカードDSレコードを返すと、存在しない委任情報を不正に作り出し、攻撃者とは無関係な兄弟ドメイン向けの応答へ影響を与えられる可能性があります。

Unbound 1.25.2では、Labelsフィールドの下限チェック、検証完了後へのキャッシュ書き込み移動、ワイルドカード更新時のbailiwickチェック追加によって修正されています。(NLnet Labs)

Aggressive NSECが有効な環境は優先して確認する

Aggressive NSECは、DNSSEC検証済みのNSECまたはNSEC3レコードを再利用し、権威DNSサーバーへ毎回問い合わせることなく、存在しない名前に対するNXDOMAIN応答などを生成する仕組みです。

問い合わせ回数や遅延を減らせる一方、CVE-2026-44690では、このキャッシュ再利用処理が攻撃成立の条件に含まれます。Unbound 1.25.2の設定資料では、aggressive-nsecの既定値はyesです。そのため、設定ファイルに明示的な記述が見つからない場合も、無効とは限りません。(Unbound Documentation)

現在有効になっている値は、次のコマンドで確認できます。

sudo unbound-checkconf -o aggressive-nsec /etc/unbound/unbound.conf

次のように表示された場合は有効です。

yes

ただし、aggressive-nsec: noであっても、脆弱なパッケージを放置してよいわけではありません。将来の設定変更や構成管理による再有効化に備え、パッケージ自体を修正版へ更新してください。

MSRCのFirstFixed表記と修正版が一致しない点に注意

2026年8月2日時点の情報では、修正版に関する公開情報を次のように整理できます。

情報源記載内容実務上の判断
MSRCのFirstFixed欄azl3 unbound 1.25.1-1 on Azure Linux 3.0この表示だけで対応完了と判断しない
NLnet Labsのアドバイザリ1.7.0から1.25.1までが影響対象、1.25.2で修正1.25.2以上を基準にする
Microsoft公式パッケージリポジトリunbound-1.25.2-1.azl3を公開Azure Linuxでは1.25.2-1以上へ更新する

Microsoftの公式リポジトリでは、1.25.1-1が2026年5月23日、1.25.2-1が同年7月23日付で公開されています。x86_64とaarch64の両方に1.25.2-1が用意されています。(Microsoft Packages)

公開情報だけでは、MSRCのFirstFixed表記と上流情報が一致しない理由を確定できません。ベンダーが修正をバックポートする場合は上流版だけで判定できないこともありますが、今回のAzure Linux公式リポジトリには1.25.2-1が存在します。

そのため、運用上は次のように判断するのが安全です。

  • unbound-1.25.1-1.azl3以前：更新対象
  • unbound-1.25.2-1.azl3以上：CVE-2026-44690の修正版基準を満たす
  • 独自ビルドの1.25.1：修正パッチの適用記録が確認できなければ更新対象
  • コンテナ内のUnbound：ホストとは別にコンテナイメージを確認

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

OSがAzure Linux 3.0か確認する

最初に、対象サーバーのOS情報を確認します。

cat /etc/os-release

次のような情報が含まれていることを確認してください。

NAME="Microsoft Azure Linux"
VERSION_ID="3.0"
ID=azurelinux

Azure Linux 2.0や別のLinuxディストリビューションでは、対象パッケージ名や修正版のリリース番号が異なる可能性があります。

RPMパッケージのバージョンを確認する

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

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

unbound-1.25.1-1.azl3.x86_64

修正版基準を満たす例は次のとおりです。

unbound-1.25.2-1.azl3.x86_64

ARM64環境では、末尾が次のようになります。

unbound-1.25.2-1.azl3.aarch64

UnboundがRPMとして導入されていない場合は、次のメッセージが表示されます。

package unbound is not installed

この場合も、コンテナ、独自ビルド、別ディレクトリへ配置したバイナリがないか確認してください。

実行バイナリとサービスの状態を確認する

command -v unbound
unbound -V 2>&1 | head -n 1
systemctl is-active unbound
systemctl --no-pager --full status unbound

RPMの確認結果とunbound -Vの結果が一致しない場合、/usr/local/sbinなどに独自ビルド版が残っている可能性があります。

次のコマンドで、実際に参照されているバイナリを確認できます。

readlink -f "$(command -v unbound)"

単にRPMを更新するだけでは、別の場所にある古いバイナリや独自のsystemdユニットには反映されません。

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

Azure Linuxでは、パッケージ管理にTiny DNFのtdnfを使用します。(Microsoft Learn)

設定ファイルをバックアップする

sudo tar -C /etc \
  -czf "/root/unbound-backup-$(date +%Y%m%d-%H%M%S).tar.gz" \
  unbound

バックアップファイルが作成されたことを確認します。

sudo ls -lh /root/unbound-backup-*.tar.gz

更新前に設定ファイルを検証する

sudo unbound-checkconf /etc/unbound/unbound.conf

設定に問題がなければ、通常は次のように表示されます。

unbound-checkconf: no errors in /etc/unbound/unbound.conf

エラーが表示された場合は、更新や再起動の前に設定を修正してください。

リポジトリで利用可能なバージョンを確認する

tdnf list unbound

利用可能なパッケージとして、少なくとも次の版以上が確認できることが基準です。

unbound 1.25.2-1.azl3

1.25.2-1が表示されない場合は、リポジトリ設定、ネットワーク接続、キャッシュされているメタデータを確認します。

sudo tdnf clean all
sudo tdnf makecache
tdnf list unbound

Unboundを更新する

sudo tdnf update unbound

確認を求められたら、更新対象とバージョンを確認したうえで続行します。

更新後にRPMのバージョンを確認してください。

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

期待する結果は次のとおりです。

unbound-1.25.2-1.azl3.x86_64

または、より新しいバージョンです。

更新後の設定を検証して再起動する

sudo unbound-checkconf /etc/unbound/unbound.conf
sudo systemctl restart unbound

再起動後、サービス状態とログを確認します。

sudo systemctl --no-pager --full status unbound
sudo journalctl -u unbound -n 100 --no-pager

active (running)になっていることに加え、設定エラー、権限エラー、ポート53の競合、DNSSEC関連の初期化エラーがないことを確認してください。

パッケージ更新後もサービスを再起動しなければ、更新前のプロセスがメモリ上で動き続ける可能性があります。再起動は新しいバイナリを読み込むだけでなく、通常のメモリ上のDNSキャッシュを破棄する意味でも重要です。

DNS名前解決を確認する

digを利用できる場合は、ローカルのUnboundへ直接問い合わせます。

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

確認するポイントは次のとおりです。

  • 応答がタイムアウトしない
  • 想定外のSERVFAILが継続しない
  • 業務で利用するドメインを正常に名前解決できる
  • 転送先DNSを設定している場合は、外部への問い合わせが正常に行われる
  • IPv4とIPv6の両方を利用する環境では、AレコードとAAAAレコードを確認する

監視システムやアプリケーションからも名前解決を行い、Unboundを利用するクライアント側まで正常に戻っていることを確認してください。

すぐ更新できない場合の一時的な緩和策

NLnet Labsは、Unboundがaggressive-nsecを利用している場合に影響を受けると説明しています。そのため、修正版をすぐに適用できない場合は、Aggressive NSECを一時的に無効化することで攻撃対象となる処理を停止できます。ただし、これは修正版への更新に代わる恒久対策ではありません。(NLnet Labs)

/etc/unbound/unbound.confのserver:セクションへ、次の設定を追加または変更します。

server:
    aggressive-nsec: no

設定を検証して再起動します。

sudo unbound-checkconf /etc/unbound/unbound.conf
sudo systemctl restart unbound

有効な値を再確認します。

sudo unbound-checkconf -o aggressive-nsec /etc/unbound/unbound.conf

次のように表示されれば無効です。

no

Aggressive NSECを無効にすると、キャッシュ情報からNXDOMAINなどを合成できなくなり、権威DNSサーバーへの問い合わせ回数や名前解決の待ち時間が増える可能性があります。緩和策を適用した場合も、更新可能になり次第、1.25.2-1以上へ更新してください。

併せて、DNSの待受ポートを必要なネットワークだけに制限します。外部公開が不要な再帰DNSサーバーでは、不特定多数からUDP・TCPの53番ポートへアクセスできる状態を避けてください。ただし、アクセス制御だけでは、許可されたクライアントを経由して攻撃用ドメインを問い合わせられる可能性があるため、パッチ適用の代替にはなりません。

AKSのAzure Linuxノードで検出された場合の対応

AKSのAzure Linuxノードで脆弱性スキャンに検出された場合、ノードへSSH接続して個別にtdnf updateを実行する方法は推奨できません。AKSノードは再イメージ化やスケール操作によって置き換わるため、手動変更が失われる可能性があります。

利用可能なノードイメージを確認します。

az aks nodepool get-upgrades \
  --resource-group <RESOURCE_GROUP> \
  --cluster-name <AKS_CLUSTER> \
  --nodepool-name <NODE_POOL>

現在のノードイメージも確認します。

az aks nodepool show \
  --resource-group <RESOURCE_GROUP> \
  --cluster-name <AKS_CLUSTER> \
  --name <NODE_POOL> \
  --query nodeImageVersion

新しいイメージが利用できる場合は、対象ノードプールを更新します。

az aks nodepool upgrade \
  --resource-group <RESOURCE_GROUP> \
  --cluster-name <AKS_CLUSTER> \
  --name <NODE_POOL> \
  --node-image-only

AKSのLinuxノードイメージは定期的に更新されますが、リージョン全体へ展開されるまで時間差が生じる場合があります。Microsoftは、ノードイメージの定期更新や自動アップグレードチャネルの利用を推奨しています。(Microsoft Learn)

ただし、UnboundがAKSノードではなくアプリケーションコンテナ内に入っている場合、ノードイメージを更新してもコンテナは修正されません。コンテナイメージのDockerfileやビルド定義でUnboundを更新し、新しいイメージをビルドして再デプロイする必要があります。

優先して更新すべき環境

次の環境では、CVE-2026-44690への対応優先度を高くしてください。

環境優先度を高くする理由
インターネットから問い合わせ可能な再帰DNS攻撃用ドメインへの問い合わせを外部から誘発されやすい
多数の端末が共有する社内DNSキャッシュ汚染時の影響範囲が大きい
VPNやリモートワーク端末向けDNS認証先や業務サービスへの接続に影響する可能性がある
DNSSEC検証とAggressive NSECを利用脆弱性の対象処理を利用している
プロキシやメールサーバーが参照するDNS誤った名前解決が通信経路や配送先へ影響し得る
AKSや自動スケール環境古いノードやコンテナが再作成される可能性がある

内部ネットワーク限定のUnboundでも、更新の優先度を過度に下げるべきではありません。利用者が攻撃者の管理するドメインへアクセスするだけでDNS問い合わせが発生する構成もあるため、外部からポート53へ直接接続できないことだけでは安全と判断できません。

対応時に起きやすい失敗

1.25.1-1を修正版と判断して作業を終了する

MSRCのFirstFixed欄だけを見ると、1.25.1-1で修正済みと判断する可能性があります。しかし、上流のアドバイザリでは1.25.1が影響対象です。

Azure Linux 3.0では1.25.2-1が公式リポジトリに公開されているため、1.25.2-1以上へ更新してください。

パッケージだけ更新してUnboundを再起動しない

ディスク上のファイルが更新されても、実行中のプロセスは旧バイナリのままです。更新後は設定を検証し、Unboundを再起動します。

RPMだけを確認し、独自ビルド版を見落とす

rpm -q unboundが安全な版でも、systemdサービスが/usr/local/sbin/unboundを起動している場合は別管理です。

次のコマンドで実行ファイルやsystemdユニットを確認してください。

systemctl cat unbound
readlink -f "$(command -v unbound)"

ホストOSだけを更新してコンテナを確認しない

ホストのAzure Linuxとコンテナ内のAzure Linuxは別のファイルシステムです。ホストを更新しても、古いコンテナイメージ内のUnboundは更新されません。

イメージの再ビルド、脆弱性スキャン、ワークロードの再デプロイまで実施してください。

AKSノードを1台ずつ手動更新する

手動更新したノードは、再作成時に古いノードイメージへ戻る可能性があります。AKSではノードイメージ更新または自動アップグレードを使用し、ノードプール単位で是正します。

CVE-2026-44690への対応チェックリスト

CVE-2026-44690への対応は、次の順序で進めます。

  • Azure Linux 3.0であることを確認する
  • RPM、実行バイナリ、systemdサービスの各バージョンを確認する
  • aggressive-nsecの有効状態を確認する
  • unbound-1.25.1-1.azl3以前なら更新対象とする
  • unbound-1.25.2-1.azl3以上へ更新する
  • unbound-checkconfで設定を検証する
  • Unboundを再起動して新しいバイナリを読み込む
  • サービス状態、ログ、DNS名前解決を確認する
  • コンテナや独自ビルド版も別途確認する
  • AKSではノードイメージまたはコンテナイメージを更新する

特に重要なのは、MSRCのFirstFixed欄にある1.25.1-1という表記だけで安全と判断しないことです。上流の影響範囲とAzure Linux公式リポジトリを突き合わせ、Azure Linux 3.0ではunbound-1.25.2-1.azl3以上を更新完了の基準にしてください。

Azure
Azure Linux 3.0 Unbound CVE-2026-44690 DNSキャッシュポイズニング

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次