☰

命名/バインディング構成をdnssec-policyに移行中に問題が発生しました。

tag-icon • tag-icon bind dnssec
命名/バインディング構成をdnssec-policyに移行中に問題が発生しました。

利用可能なDNSSECネームサーバーがあります。 Fedoraの最新のBIND 9.18で動作します。私は両方のキー（KSK、ZSK）を持ち、両親（DNS方式）には有効なDSレコードがあり、すべてが正常です。本当。 DNSSECアナライザも設定に満足しています。

ところで、次のログメッセージが表示されました。

"auto-dnssec"オプションは廃止され、BIND 9.19から削除されます。 dnssec-policyに移行します。

9.19アップデートがいつプッシュされるかわかりません。しかし、私はそれを準備しようとし、次の構成を置き換えました（ゾーンブロックで）。

auto-dnssec maintain;
inline-signing yes;

そして：

dnssec-policy sk_policy;
inline-signing yes;

ポリシー自体は最上位構成で定義されます。

dnssec-policy "sk_policy" {
    keys {
        ksk key-directory lifetime unlimited algorithm ecdsa256;
        zsk key-directory lifetime unlimited algorithm ecdsa256;
        // zsk rollover postponed for later
        // zsk key-directory lifetime P90D algorithm ecdsa256;
    };  
    nsec3param iterations 0 optout no salt-length 0;
    parent-ds-ttl PT1H;
};

ただし、サーバーは10分ごとにエラーを記録します。

reconfiguring zone keys
zone_rekey:dns_dnssec_keymgr failed: error occurred writing key to disk

このエラーメッセージを検索すると、Googleは何も見つかりませんでした。

私はキーディレクトリのすべてを許可するためにファイル権限を試してみましたが、SELinuxを一時的に無効にしようとしましたが（正確に言うと厳格 - >緩い）、警告は生成されませんでした。これまでは何も役に立ちません。サーバーがどのファイルを書き込もうとしているのか、どこに何のエラーがあるのか​​わかりません。ログファイルなども削除してみましたが、これは本番マシンであり、多くの実験ができないため、すべてを元の状態に復元し、現在は9.18バージョンを維持しています。

「dnssec-policy」が機能するのを手伝うことができる人はいますか？

アップデート＃2： - （予備）回答として実験の概要を公開しました。私はこの試行錯誤実験を中止するためにまだ良い情報源を探しています。

答え1

私は同じ問題があります：

zone_rekey:dns_dnssec_keymgr failed: error occurred writing key to disk

ただ権限問題のようです。

ディレクトリの権限を（774）/etc/bind/keysに変更しrwxrwxr-- 、その中のすべてのファイルをrw-rw-r-- （664）に変更しました。

  • keysディレクトリ所有者はルートです。
  • keysディレクトリグループがバインドされました。

その後は大丈夫です。次のメッセージが表示され、一部のファイルの所有者が変更されました。

2023-02-05T17:27:16+0100 fake_servername 名前 [1234441]        .....(以前にも関連ニュースがありました)
2023-02-05T17:27:16+0100 fake_servernamenamed[1234441]: 一般: 警告: /etc/bind/keys/fake_domainname.de.+015+60580.private ファイルに対する権限がこの時点で0664から0されました。作戦の結果。

答え2

私は成功したと思います（まだテストしていないキーロールオーバーを除いて）。私は要約を書くことにしました。

BINDのDNSSECキーは、公開部分、秘密コピー、キーステータスファイルの3つのファイルで構成されています。拡張子は.key、.private。.state

を使用すると、auto-dnssec maintainDNSSECキーファイルを読み取り専用にすることができます。ただし、に移行すると、dnssec-policyBINDサーバーは状態だけでなく、重要なファイルと3つのファイルの両方を変更します。 （理由がわかりません。ステータスファイルがあれば、「実際の」キーファイルを編集する必要がなくなると思います。）

明らかな要件は、重要なファイルの権限を調整することです。

私はroot:namedディレクトリ、ファイルに所有者：グループ、およびモードを使用しました。明らかに、これは唯一の可能な設定ではありません。重要なことは、サーバーがファイルを変更できる必要があることです。秘密鍵は保護する必要があります。 "le luxe fou"の回答もご覧ください。彼のシステムでは、ユーザーはと呼ばれます。07700660namedbind

最初に私が経験した問題はSELinuxにありました。このセクションはFedoraに固有のものであり、SELinuxポリシーは将来変更される可能性があります。最初はAVC拒否メッセージを受け取らなかったため（どこで間違えた可能性がある）、これがこの質問を投稿した理由です。

要するに、私は/etc/named/keysディレクトリに鍵を持っています。 SELinuxはこの場所のファイルを書き込み禁止構成として扱います。そのため、/var/named/keysサーバーがファイルを変更できる場所に置きました。これが鍵の正しい位置であるかどうかはわかりません。ただしaudit2allow、必ずしも必要でない限り、ローカルポリシーを追加したくありません。

最後の注意：サーバーログ：

この操作の結果、/var/named/keys/KXXX.+YYY+ZZZZ.private ファイルの権限が 0660 から 0600 に変更されました。

しかし、そうではありません。権限は変更されていません。named（）ユーザーがbindキーファイルの意図した所有者である可能性があります。これに関する文書が見つかりませんでした。

関連情報