[DNSSEC] testing KASP

[adrien sipasseuth]

Only if KSK has DSState: rumoured. If the DSState is hidden it means
that it is not expected to be in the parent (for example because the
DNSKEY has not yet been fully propagated).


> Do you need to withdraw the old key too immediatly ? anything else to do ?

>>> Do you mean withdraw the old DS?

Yes, the old DS should be not yet withdraw because some RRSIG could be
still valid ? or can i withdraw the old DS / KSK immediatly ?

In my logic :
For each file en .state
    If is KSK with "DSState: rumoured" or "DSState: hidden"
        If not in my registar (dig ds <my_zone> +dnssec +multiline)
            Publish on my Registar(api register)
            Notify Bind(bind rndc dnssec -checkds -key <New ID KSK>
published <my_zone>)
            Notify Bind(bind rndc dnssec -checkds -key <Old ID KSK>
withdraw <my_zone>)

In my understanding, i shouldn't do "Notify Bind(bind rndc dnssec -checkds
-key <Old ID KSK> withdraw <my_zone>)" and wait until all RRSIG sign (with
the old KSK) expire. In that case, how can i check this ? (some dig command
? or check state file for "DSState: unretentive" ?)

regards,

Adrien


Le ven. 17 mai 2024 à 15:13, Matthijs Mekking <matthijs at isc.org> a écrit :

> Hi,
>
> On 5/16/24 14:02, adrien sipasseuth wrote:
> > Hello,
> >
> > I try to set up a testing environment in order to create some scripts
> > for automated the roll over KSK.
> >
> > ############# question 1 #############
> > this is my policy :
> >
> > dnssec-policy "test" {
> >      keys {
> >          ksk lifetime P3D algorithm ecdsa256 2048;
> >          zsk lifetime P1D algorithm ecdsa256 2048;
> >      };
> >
> >      // Key timings
> >      purge-keys P4D;
> >
> >      // Signature timings
> >      signatures-refresh  PT50M;
> >      signatures-validity PT1H;
> >      signatures-validity-dnskey PT1H;
> >
> >      // Zone parameters
> >      max-zone-ttl PT1H;
> >      parent-ds-ttl PT1H;
> >
> > };
> >
> > I would like automaticly update new DS to my registar, to do it this my
> > logic :
> >
> > For each file en .state
> >      If is KSK with "DSState: rumoured" or "DSState: hidden"
> >          If not in my registar (dig ds <my_zone> +dnssec +multiline)
> >              Publish on my Registar(api register)
> >              Notify Bind(bind rndc dnssec -checkds -key <ID> published
> > <my_zone>)
>
> Only if KSK has DSState: rumoured. If the DSState is hidden it means
> that it is not expected to be in the parent (for example because the
> DNSKEY has not yet been fully propagated).
>
>
> > Do y need to withdraw the old key too immediatly ? anything else to do ?
>
> Do you mean withdraw the old DS?
>
> I would use similar logic but then use "unretentive" instead of
> "rumoured". Following the example above:
>
> For each file en .state
>        If is KSK with "DSState: unretentive"
>            If in my registar (dig ds <my_zone> +dnssec +multiline)
>                Withdraw on my Registar(api register)
>                Notify Bind(bind rndc dnssec -checkds -key <ID> withdrawn
>
>
> > ############# question 2 #############
> > If i want to unsigned a zone, i change my policy to "insecure" which is
> > default but file like <my_zone>.signed still exist, Bind doesn't remove
> it ?
>
> Correct. If all DNSSEC records have been removed, it is safe to remove
> the "dnssec-policy" configuration from your named.conf and then remove
> the .signed file.
>
> Unsigning your zone also takes time.
>
>
> > ############# question 3 #############
> >
> > In state file, when the remove date issue, can i just remove the key,
> > anything else to do ?
>
> When all states are "hidden" it is safe to remove the key.
>
> Best regards,
>
> Matthijs
>
>
> > Regards,
> > Adrien SIPASSEUTH
> >
> >
> >
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240529/4d19928a/attachment.htm>