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
