Policy-dnssec timeline step by step

[Ondřej Surý]

Have you read:

https://kb.isc.org/docs/dnssec-key-and-signing-policy

and

https://bind9.readthedocs.io/en/latest/dnssec-guide.html

This RFC should give you some background too: https://datatracker.ietf.org/doc/html/rfc6781


Ondrej
--
Ondřej Surý (He/Him)
ondrej at isc.org

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 20. 2. 2025, at 21:46, Nguyen Thi Minh Tam via bind-users <bind-users at lists.isc.org> wrote:
> 
> Hi,
> I'm trying out DNSSEC policy for the first time, and I am so confused about the time states—how they calculate the time for the state of the records to change. I really need help because I have a ton of questions (I'm using BIND 9.18.31, btw). I want to understand how it works step by step, so I'm checking out everything.
> 1. When BIND 9 first starts signing DNSSEC, the record states go like this:
> DNSKEY (KSK):
>     • publish = rumoured
>     • rumoured → omnipresent = dnskey-ttl + zone delay + publish safety (1)
> DS:
>     • publish = hidden
>     • hidden → rumoured = ??? (2) (3)
>     • rumoured (DSpublish) → omnipresent = ds-ttl + parent-zone-delay + retire safety (4)
> Key RRSIG:
>     • publish = rumoured
>     • rumoured → omnipresent = dnskey-ttl + zone delay + publish safety (1)
> DNSKEY (ZSK):
>     • publish = rumoured
>     • rumoured → omnipresent = dnskey-ttl + zone delay + publish safety (1)
> Zone RRSIG:
>     • publish = rumoured
>     • rumoured → omnipresent = ?? (5)
> Here are my questions:
> (1) Since this is the first key, I guess the formula should be zone delay + publish safety?
> (2) I have no idea how this works.
> (3) Same with PublishCDS. What is the formula, and why? Must I wait for CDS to be published before submitting DS to the parent zone?
> (4) This only makes sense when rolling a key. Should the formula be parent-delay + publish safety (of the parent zone)?
> (5) I have absolutely no idea, but it looks like it changes at the same time as when the DS goes from hidden to rumoured.2. Then I tried a ZSK rollover, which turned out to be a bit weird.
>     • If the KSK is omnipresent, ZSK will roll using the pre-publish method.
>     • If the KSK is not omnipresent, ZSK will roll using the double-signing method.
>     • The new ZSK is published and starts signing at the same time, but it initially only signs the SOA record.
>     • When I query the SOA record, two RRSIGs (from both ZSKs) are returned.
>     • The rest of the zone remains signed with the old ZSK.
>     • After a while, the entire zone switches to the new ZSK RRSIGs.
>     • Then, named removes the old ZSK DNSKEY.
> The timeline is even weirder than I expected.
> Is this normal? Should i avoid this situation in reality?
> 
> -- 
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20250220/39ac4864/attachment.sig>