DNSSEC questions

[Matthijs Mekking]

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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>