Policy-dnssec timeline step by step

Nguyen Thi Minh Tam tamntm at vnnic.vn
Thu Feb 20 20:46:22 UTC 2025


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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20250220/ae25f27f/attachment-0001.htm>


More information about the bind-users mailing list