要約

  • 9月2日公開のNSD 4.15.2は、証明書名を同じアクセス規則のアドレス、TSIG条件と組み合わせて確認する修正を含む。
  • 発端となった報告は、二つ目の正当な証明書名が存在すると転送が拒否されるというもの。回帰テストは複数の有効な証明書を扱うが、報告された設定の全条件を再現してはいない。

証明書の更新で旧名と新名を併存させる。セカンダリーDNSサーバーを増やし、それぞれに別の証明書を持たせる。こうした変更で必要なのは、各クライアントが自分に対応する規則を満たせることだ。一つのクライアントが、異なる二つの名前に同時に一致する必要はない。

NSDが修正した不具合は、この区別が可用性に直結する例となった。7月24日の利用者報告では、RHEL 9.8上のEPEL版NSD 4.14.0をプライマリーとし、別のソフトウェアを使う二つのセカンダリーへゾーンを転送していた。セカンダリーごとにアドレスと証明書名を分け、二つの許可規則では同じTSIG鍵を指定していた。

ログ上はTLSのクライアント認証付きハンドシェイクが成功し、TSIGも受け入れられ、最初の証明書名が一致していた。それでも別の名前との不一致が続き、転送は拒否された。規則を一つだけにすると成功したという。これは公開された試験環境の報告であり、プライベートアドレスを実際の公衆ネットワークの障害範囲とみなすことはできない。

8月28日、保守担当者は再現と修正を報告した。9月2日のリリース告知も同じ規則内での照合を修正点に挙げる。9月8日の確認時点で、公式ダウンロードページは4.15.2を現行版としていた。ただし、元の報告者が公開後に再試験した記録はなく、利用者全体の復旧を示す資料ではない。

条件を弱めず、条件の所属を直す

コードの変更では、アクセス規則の一項目を調べる際に、アドレス、TSIG鍵、証明書名の照合を組み合わせた。それ以前は、証明書名を別のループで調べる処理が、他の名前に出会った時点で失敗を返す可能性があった。

修正は誤った名前の証明書を許可するものではない。その名前を要求する規則には一致しない、という判定を保つ。一方、別の有効な選択肢まで他の名前との違いで否定しないようにする。明示的な遮断規則も依然として関係するため、NSDのアクセス制御全体を「どれか一つに一致すれば必ず許可」と一般化するのは不正確だ。

この仕組みから見れば、TLSセッションの成立だけを成功指標にする危うさも分かる。暗号化された通信路ができても、その後の転送許可が得られなければ、セカンダリーは必要なゾーン内容を受け取れない。

テストが保証する範囲を読み分ける

回帰テストの追加は、二つ目の証明書と対応する規則を用意した。リリースタグに固定したテスト全文では、二つの正当な証明書を使う各要求が、転送対象ゾーン内の目印を取得することを確認する。名前が違う場合、未知の認証局の場合、クライアント証明書を出さない要求などについては、その内容を取得できないことも調べている。

ただし証明書用の二つの規則は任意のIPv4送信元を許容し、NOKEYを使う。元の報告にあった、別々のアドレスと共通TSIG鍵の組み合わせとは異なる。複数証明書の挙動を確認する断言と、実運用の全条件を網羅した証拠は別だ。本稿はソースと断言を読んだもので、NSDを実行した独自の再現試験ではない。

テストには別途TSIGで許可する規則もあり、それに該当する要求は通常のTLSやTCPで転送できる。この明示された選択肢を、新たな認証回避と呼ぶべきではない。RFC 9103が区別するように、TSIGによる認証だけではゾーン内容は暗号化されない。転送グループ全体の機密性は、一つのTLS接続ではなく、各転送関係に適用する方針で決まる。

また、NLnet Labsのセキュリティ情報にあるCVE-2026-12490は、6月に公表され4.14.3で修正された別の証明書確認回避問題だ。今回の複数識別名による拒否に、その番号や影響バージョン範囲を流用する根拠はない。新たな悪用事例、影響顧客数、網羅的な影響版一覧も確認されていない。

Lu Hengが論じる厳密で局所的に検証できる安全条件は、この事例にも限定的に適用できる。成功のために条件を黙って緩めるのではなく、どの組み合わせを許すのかを明確にするという読み方だ。これは本稿の分析であり、Lu HengによるNSDへの評価ではない。