[dns-operations] What's wrong with my domain?

[Brett Carr]

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 <ml623 at georgetown.edu<mailto:ml623 at georgetown.edu>> 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 <Brett.Carr at nominet.org.uk<mailto:Brett.Carr at nominet.org.uk>> 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 <ml623 at georgetown.edu<mailto:ml623 at georgetown.edu>> 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 <bortzmeyer at nic.fr<mailto:bortzmeyer at nic.fr>> wrote:
On Wed, Jul 02, 2014 at 12:08:36PM +0100,
 Tony Finch <dot at dotat.at<mailto:dot at dotat.at>> 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
dns-operations at lists.dns-oarc.net<mailto:dns-operations at lists.dns-oarc.net>
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20140702/de988cae/attachment.html>