However it states "and you have seven days” but doesn’t really say what happens after the seven days (although i think we know) or how you can delay that. Certainly in the case of a TLD where you have to interact with IANA and your own admin and tech contacts getting this done in seven days can be a real challenge.
Brett On 2 Jul 2014, at 14:04, Mohamed Lrhazi <[email protected]<mailto:[email protected]>> wrote: Yeah, it looks like it is the case, as the F5 docs say: Providing DS records to the parent domain Each time a new generation of a key-signing key is created, you must provide the updated DS record to the administrators of the parent zone. For example, in Figure 10.1<https://support.f5.com/kb/en-us/products/big-ip_gtm/manuals/product/gtm_config_10_2/gtm_dnssec.html?sr=38618833#1016065>, the value of the Rollover Period of the key is 30 days, and the value of the Expiration Period of the key is 37 days. In the case of a key-signing key, a new generation of the key is created every 30 days, and you have seven days before the old generation of the key expires to provide the new DS record to the administrators of the parent zone. These administrators sign the new DS record with their own key and upload it their zone. On Wed, Jul 2, 2014 at 8:44 AM, Brett Carr <[email protected]<mailto:[email protected]>> wrote: It would seem bad that the DNSSEC Implementation in f5’s would complete a KSK rollover (IE remove the old key) without some confirmation that the DS had been seen in the parent. Automation gone too far. Brett On 2 Jul 2014, at 12:56, Mohamed Lrhazi <[email protected]<mailto:[email protected]>> wrote: So many useful tips, thank you all. gu.edu<http://gu.edu/> is, luckily, a test domain, and not production. I had enabled DNSSec in our F5 GTM front ending DNS, and forgot about it. Seems I have to learn that after a while keys are rolled over and I need to do some work about it.... It makes DNSsec easy, but not that easy.... Thanks, Mohamed. On Wed, Jul 2, 2014 at 7:46 AM, Stephane Bortzmeyer <[email protected]<mailto:[email protected]>> wrote: On Wed, Jul 02, 2014 at 12:08:36PM +0100, Tony Finch <[email protected]<mailto:[email protected]>> wrote a message of 25 lines which said: > Your DS record doesn't match your DNSKEY records. The OP could also use the excellent DNSviz: http://dnsviz.net/d/gu.edu/U7Pp0g/dnssec/ which rightly says: gu.edu/DNSKEY:DS<http://gu.edu/DNSKEY:DS> RRs exist for algorithm(s) 7 in the edu zone, but no matching DNSKEYs of algorithm(s) 7 were used to sign the gu.edu<http://gu.edu/> DNSKEY RRset. _______________________________________________ dns-operations mailing list [email protected]<mailto:[email protected]> https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
