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) ond...@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@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@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users
signature.asc
Description: Message signed with OpenPGP
-- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
