Hi Matthijs,

thanks for clarifications.

On Wed 27/Oct/2021 17:53:46 +0200 Matthijs Mekking wrote:
On 27-10-2021 12:54, Alessandro Vesely wrote:

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.


Yup, the intention was (and still is) to migrate to CSK, as it's simpler, without breaking existing status. So now I need to get rid of the old keys.


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".


Thanks, that's what I was looking for. I have to check all zones (and two views each). I'll write a script for that.


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.


Right.  So the script must also check that the new keys have a parental DS.


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.


Then, why does it have to rewrite it every day, if the zone didn't change? dnskey-ttl is the only one-day timing thing, except parent-ds-ttl.

BTW, DS RR has a ttl of 10800 at the parent; should I copy that to parent-ds-ttl in my policy definition? What for?


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.


OK.  Thanks again,
Ale
--










_______________________________________________
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

Reply via email to