Re: why did it take 26 hours for DSState to change to omnipresent?
On 16/05/22 21:34, Matthijs Mekking wrote: Hi Nik, On 16-05-2022 07:49, Nick Tait via bind-users wrote: Hi there. Ever since I updated my BIND configuration to use the new dnssec-policy feature (a year or so ago) my KSK/CSK rollovers have been a complete shambles. My problems stem from the inference (based documentation and examples) that running "rndc dnssec -checkds published" tells BIND that the DS record is now published in the parent zone? Based on that predicate, it would be my expectation that after running this command above, the DSState should immediately transition from "rumoured" to "omnipresent". This assumption is incorrect. Once the DS is in the parent, validators do not immediately know about the new DS record. That why it is rumoured. Being omnipresent means that every resolver will use the new DS record for validation purposes, whether they have it in the cache, or retrieve it from the parent zone. More importantly this means that any previous versions of the DS RRset are not known anywhere. In past rollovers, the DSState hasn't transitioned from "rumoured". And then I've thought "oh it must be a bug" and so I've set about trying to force the DSState to change to "omnipresent". And suffice to say that the shambles followed on from there... So anyway, since I'd recently upgraded to BIND 9.18.1 (as part of Ubuntu 22.04 upgrade), and thinking maybe these 'bugs' might now be fixed, I thought I'd have another look at it, but this time I'll pay more attention to what is going on, and try to be less impatient... Before I did anything the key state file looked like this: Algorithm: 15 Length: 256 Lifetime: 0 KSK: yes ZSK: yes Generated: 20211024221429 (Mon Oct 25 11:14:29 2021) Published: 20211024221429 (Mon Oct 25 11:14:29 2021) Active: 20211024221429 (Mon Oct 25 11:14:29 2021) PublishCDS: 20211025231929 (Tue Oct 26 12:19:29 2021) DNSKEYChange: 20211025001929 (Mon Oct 25 13:19:29 2021) ZRRSIGChange: 20211025231929 (Tue Oct 26 12:19:29 2021) KRRSIGChange: 20211025001929 (Mon Oct 25 13:19:29 2021) DSChange: 20211025231929 (Tue Oct 26 12:19:29 2021) DNSKEYState: omnipresent ZRRSIGState: omnipresent KRRSIGState: omnipresent DSState: rumoured GoalState: omnipresent As you can see the DSState was "rumoured" before I started. So the first thing I did was run "rndc dnssec -checkds published", and this added the following line to the state file: DSPublish: 20220515001647 (Sun May 15 12:16:47 2022) However the DSState value remained "rumoured". So then I thought, I'll wait a TTL or two (TTL for DS and DNSKEY are both 1 hour -- although I wouldn't expect BIND to know the DS TTL). But still nothing changed. So then I decided I'd leave it alone until the next day. When I checked after ~20 hours elapsed time, still nothing had changed. I checked again just now, and finally the DSState has changed to "omnipresent". Here are the lines in the state file that have changed: DSChange: 20220516021647 (Mon May 16 14:16:47 2022) DSState: omnipresent So my big question is this: Is it expected that the DSState won't change until 26 hours after the "rndc dnssec -checkds published" command is run? And if so why does it take so long? That depends on your dnssec-policy. BIND will/should move the DSState to omnipresent after an x amount of time, where: x = parent-ds-ttl + parent-propagation-delay + retire-safety By default these values are parent-ds-ttl: 24h parent-propagation-delay: 1h retire-safety: 1h So the 26 hours add up. Now these may be very conservative values, but for the default policy we rather wait a little longer than too short. Best regards, Matthijs Thanks so much for the explanation. Makes perfect sense now. :-) Nick. -- 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
Re: why did it take 26 hours for DSState to change to omnipresent?
Hi Nik, On 16-05-2022 07:49, Nick Tait via bind-users wrote: Hi there. Ever since I updated my BIND configuration to use the new dnssec-policy feature (a year or so ago) my KSK/CSK rollovers have been a complete shambles. My problems stem from the inference (based documentation and examples) that running "rndc dnssec -checkds published" tells BIND that the DS record is now published in the parent zone? Based on that predicate, it would be my expectation that after running this command above, the DSState should immediately transition from "rumoured" to "omnipresent". This assumption is incorrect. Once the DS is in the parent, validators do not immediately know about the new DS record. That why it is rumoured. Being omnipresent means that every resolver will use the new DS record for validation purposes, whether they have it in the cache, or retrieve it from the parent zone. More importantly this means that any previous versions of the DS RRset are not known anywhere. In past rollovers, the DSState hasn't transitioned from "rumoured". And then I've thought "oh it must be a bug" and so I've set about trying to force the DSState to change to "omnipresent". And suffice to say that the shambles followed on from there... So anyway, since I'd recently upgraded to BIND 9.18.1 (as part of Ubuntu 22.04 upgrade), and thinking maybe these 'bugs' might now be fixed, I thought I'd have another look at it, but this time I'll pay more attention to what is going on, and try to be less impatient... Before I did anything the key state file looked like this: Algorithm: 15 Length: 256 Lifetime: 0 KSK: yes ZSK: yes Generated: 20211024221429 (Mon Oct 25 11:14:29 2021) Published: 20211024221429 (Mon Oct 25 11:14:29 2021) Active: 20211024221429 (Mon Oct 25 11:14:29 2021) PublishCDS: 20211025231929 (Tue Oct 26 12:19:29 2021) DNSKEYChange: 20211025001929 (Mon Oct 25 13:19:29 2021) ZRRSIGChange: 20211025231929 (Tue Oct 26 12:19:29 2021) KRRSIGChange: 20211025001929 (Mon Oct 25 13:19:29 2021) DSChange: 20211025231929 (Tue Oct 26 12:19:29 2021) DNSKEYState: omnipresent ZRRSIGState: omnipresent KRRSIGState: omnipresent DSState: rumoured GoalState: omnipresent As you can see the DSState was "rumoured" before I started. So the first thing I did was run "rndc dnssec -checkds published", and this added the following line to the state file: DSPublish: 20220515001647 (Sun May 15 12:16:47 2022) However the DSState value remained "rumoured". So then I thought, I'll wait a TTL or two (TTL for DS and DNSKEY are both 1 hour -- although I wouldn't expect BIND to know the DS TTL). But still nothing changed. So then I decided I'd leave it alone until the next day. When I checked after ~20 hours elapsed time, still nothing had changed. I checked again just now, and finally the DSState has changed to "omnipresent". Here are the lines in the state file that have changed: DSChange: 20220516021647 (Mon May 16 14:16:47 2022) DSState: omnipresent So my big question is this: Is it expected that the DSState won't change until 26 hours after the "rndc dnssec -checkds published" command is run? And if so why does it take so long? That depends on your dnssec-policy. BIND will/should move the DSState to omnipresent after an x amount of time, where: x = parent-ds-ttl + parent-propagation-delay + retire-safety By default these values are parent-ds-ttl: 24h parent-propagation-delay: 1h retire-safety: 1h So the 26 hours add up. Now these may be very conservative values, but for the default policy we rather wait a little longer than too short. Best regards, Matthijs Thanks, Nick. -- 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
why did it take 26 hours for DSState to change to omnipresent?
Hi there. Ever since I updated my BIND configuration to use the new dnssec-policy feature (a year or so ago) my KSK/CSK rollovers have been a complete shambles. My problems stem from the inference (based documentation and examples) that running "rndc dnssec -checkds published" tells BIND that the DS record is now published in the parent zone? Based on that predicate, it would be my expectation that after running this command above, the DSState should immediately transition from "rumoured" to "omnipresent". In past rollovers, the DSState hasn't transitioned from "rumoured". And then I've thought "oh it must be a bug" and so I've set about trying to force the DSState to change to "omnipresent". And suffice to say that the shambles followed on from there... So anyway, since I'd recently upgraded to BIND 9.18.1 (as part of Ubuntu 22.04 upgrade), and thinking maybe these 'bugs' might now be fixed, I thought I'd have another look at it, but this time I'll pay more attention to what is going on, and try to be less impatient... Before I did anything the key state file looked like this: Algorithm: 15 Length: 256 Lifetime: 0 KSK: yes ZSK: yes Generated: 20211024221429 (Mon Oct 25 11:14:29 2021) Published: 20211024221429 (Mon Oct 25 11:14:29 2021) Active: 20211024221429 (Mon Oct 25 11:14:29 2021) PublishCDS: 20211025231929 (Tue Oct 26 12:19:29 2021) DNSKEYChange: 20211025001929 (Mon Oct 25 13:19:29 2021) ZRRSIGChange: 20211025231929 (Tue Oct 26 12:19:29 2021) KRRSIGChange: 20211025001929 (Mon Oct 25 13:19:29 2021) DSChange: 20211025231929 (Tue Oct 26 12:19:29 2021) DNSKEYState: omnipresent ZRRSIGState: omnipresent KRRSIGState: omnipresent DSState: rumoured GoalState: omnipresent As you can see the DSState was "rumoured" before I started. So the first thing I did was run "rndc dnssec -checkds published", and this added the following line to the state file: DSPublish: 20220515001647 (Sun May 15 12:16:47 2022) However the DSState value remained "rumoured". So then I thought, I'll wait a TTL or two (TTL for DS and DNSKEY are both 1 hour -- although I wouldn't expect BIND to know the DS TTL). But still nothing changed. So then I decided I'd leave it alone until the next day. When I checked after ~20 hours elapsed time, still nothing had changed. I checked again just now, and finally the DSState has changed to "omnipresent". Here are the lines in the state file that have changed: DSChange: 20220516021647 (Mon May 16 14:16:47 2022) DSState: omnipresent So my big question is this: Is it expected that the DSState won't change until 26 hours after the "rndc dnssec -checkds published" command is run? And if so why does it take so long? Thanks, Nick. -- 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
