DNSSEC questions

[Alessandro Vesely]

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