Hi Allesandro,
Your policy has three keys:
keys {
ksk key-directory lifetime unlimited algorithm rsasha256 2048;
zsk key-directory lifetime unlimited algorithm rsasha256 2048;
csk key-directory lifetime unlimited algorithm rsasha256 2048;
};
Two of them require DS records (ksk and csk), so that is why you have
double CDS/CDNSKEY records.
On 27-10-2021 12:54, Alessandro Vesely wrote:
Hi all,
I recently installed version 9.16, and have a number of doubts. During
the upgrade, named didn't want to load signed zones because of
CDS/CDNSKEY inconsistency. There were CDS records in the zone files,
which I removed.
I also switched to dnssec-policy. Somewhere I read that I should have
defined a policy with keys matching the existing keys. I also defined a
"combined" key. Now I have two DS, two CDS, and two CDNSKEY RRs. I
attach a picture of a zone and paste the policy below.
Adding the combined key to the policy means you did not create a policy
that matched the existing keys. BIND notices that you want three keys,
you only have two, so it creates the CSK.
The questions:
1. Now, how do I get rid of the extra ksk and zsk? Is it enough to
remove them from the policy?
You can remove them from the policy yes, but make sure the migration is
complete. You can check with "rndc dnssec -status <zone>" and make sure
that your key states are in "omnipresent".
2. I have double CDS/CDNSKEY records, but they're not in the zone
files. Do I have to run rndc dnssec -checkds to remove them?
That's because you added the additional CSK to the policy. It is
probably best to remove it again from the policy and only change the
policy if the migration is complete.
3. The server produces new .signed and .signed.jnl files every day,
which is inconvenient as the zone files directory is checked by
tripwire. Is that timing determined by the dnskey-ttl? Would it be
okay to set it to one month?
The zone is signed if a signature is about to expire. It is not
determined by dnskey-ttl. I would exclude these files from tripwire
because they need to written out anyway.
4. Is rndc managed-keys status supposed to display anything meaningful,
given my setup? It talks about a non-existing key id. The sync option
produces no output at all. How do I know the overall dnssec status?
"rndc managed-keys status" is for trust anchors, use "rndc dnssec
-status <zone>" instead.
Best regards,
Matthijs
Here's my policy setting:
dnssec-policy "explicit" {
// Keys
keys {
ksk key-directory lifetime unlimited algorithm rsasha256 2048;
zsk key-directory lifetime unlimited algorithm rsasha256 2048;
csk key-directory lifetime unlimited algorithm rsasha256 2048;
};
nsec3param iterations 1 optout false salt-length 16;
// Key timings
dnskey-ttl 86400;
publish-safety P3W;
retire-safety P3W;
purge-keys P1Y;
// Signature timings
signatures-refresh P2M;
signatures-validity P6M;
signatures-validity-dnskey P6M;
// Zone parameters
max-zone-ttl 86400;
zone-propagation-delay PT1H;
// Parent parameters
parent-ds-ttl 86400;
parent-propagation-delay PT1H;
};
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
