web-dev-qa-db-ja.com

中断せずにBIND構成をauto-dnssec維持からdnssec-policyに移行する方法は？

BIND 9.16は、長い間確立された dnssec-policy 機能にさらに自動化されたDNSSECキー管理および署名機能として、新しい auto-dnssec maintain 機能を導入しました。

ドキュメントは古いものから新しいものへの移行をカバーしていないようですが、 関連するWikiページ は、既存のキーがdnssec-policyによって取得されることを示しているようです。

つまり、dnssec-policyを使用して新しいゾーンを設定することは簡単ですが、既存のゾーンをauto-dnssec maintainからdnssec-policyに移行することは、期待どおりに機能しないようです。
私が期待していたことは、既存のキーと互換性のあるポリシーがこれらのキーを使い続けることでした。

新しいポリシーが互換性のあるキーのセット（同じアルゴリズムとサイズ）を要求し、既存のキーが持っているにもかかわらず、「期限切れ」で新しいキーに置き換えられたため、既存のキーはすべてゾーンからすぐに削除されているようですサポート終了のプロパティは定義されていません（.keyファイルのCreated、PublishおよびActivateタイミングのみ）。

テスト時に使用したポリシーは次のようになります（テスト中の内容を反映するために名前が付けられています）。

dnssec-policy alg13-ksk-unlimited-zsk-60day {
     keys {
         ksk key-directory lifetime unlimited algorithm ECDSAP256SHA256;
         zsk key-directory lifetime P60D algorithm ECDSAP256SHA256;
     };
};

これは、構成がauto-dnssec maintain;からdnssec-policy alg13-ksk-unlimited-zsk-60day;に変更されたときのログ出力です。

zone zone.example/IN (signed): reconfiguring zone keys
keymgr: DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) created for policy alg13-ksk-unlimited-zsk-60day
keymgr: DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) created for policy alg13-ksk-unlimited-zsk-60day
Removing expired key 20481/ECDSAP256SHA256 from DNSKEY RRset.
DNSKEY zone.example/ECDSAP256SHA256/20481 (ZSK) is now deleted
Removing expired key 12506/ECDSAP256SHA256 from DNSKEY RRset.
DNSKEY zone.example/ECDSAP256SHA256/12506 (KSK) is now deleted
Fetching zone.example/ECDSAP256SHA256/49004 (KSK) from key repository.
DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) is now published
DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) is now active
Fetching zone.example/ECDSAP256SHA256/54646 (ZSK) from key repository.
DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) is now published
DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) is now active
zone zone.example/IN (signed): next key event: 22-Mar-2020 15:08:19.805

ご覧のように、既存のキーはすぐに削除され（通常のロールオーバー手順を実行していなくても！）、同じタイプの新しいキーに置き換えられました。
意図したロールオーバー手順に従うのではなく、ただちにキーを置き換えるとすべてが壊れることを考えると、構成をdnssec-policyに切り替えるだけでは何の問題もないことは明らかです。

キーファイルを見ると、古いキーと新しいキーの両方に.stateファイルが追加されていることがわかります。
このファイルが適切なdnssec-policy操作の要件であるかどうかわかりませんか？これらのファイルを事前に作成しておくと、この動作を回避できますか？

その核心にある質問は、無停止でdnssec-policyを使用するように移行する方法はありますか？もしそうなら、どうですか？

domain-name-systembinddnssec
4
Håkan Lindqvist

質問で説明されている動作はバグであり、BINDバージョン9.16.2以降で解決する必要があります。

BIND 9.16.2リリースノート から：

バグ修正

[をちょきちょきと切る]

  • すでに署名されたゾーンをauto-dnssecメンテナンスからdnssec-policyに基づいたゾーンに移行しようとすると、既存のキーがすぐに削除され、新しいキーに置き換えられました。重要なロールオーバーのタイミング制約が守られていなかったため、古いDNSSEC情報がすべてキャッシュからタイムアウトするまで、一部のクライアントが応答を検証できなかった可能性があります。 BINDは現在、既存のキーのメタデータを調べ、そのDNSSECポリシー操作に組み込みます。 [GL＃1706]
0
Håkan Lindqvist