DNSSEC key rollover failure

[Spain, Dr. Jeffry A.]

> And now, as July 1 has passed and July 9 approaches, can you share a 
> summary of what you found? Thanks.
> -- 
>     Offlist mail to this address is discarded unless
>     "/dev/rob0" or "not-spam" is in Subject: header

On June 10, our zone countryday.net running on a bind 9.8.0 server began an automatic key rollover process, the zone having been configured with "auto-dnssec maintain." The two original ZSKs 02750 and 33722 had been published on March 12. ZSK 02750 became active on March 16, and the zone was automatically signed with it. The third ZSK 26522 was published on June 10, but is not due to become active until September 12. The second ZSK 33722 became active on June 14, and the first ZSK 02750 became inactive on June 15. Checking the zone on June 17 showed that ZSK 33722 had signed the SOA record but nothing else. Signatures from ZSK 02750 were on the other records and due to expire on July 9. However, ZSK 02750 was scheduled to be deleted on June 29. To avoid deleting ZSK 02750 before all of its signatures had been removed and replaced by those from ZSK 33722, I used dnssec-settime to change the deletion date of ZSK 02750 to July 14. On July 1, as Phil Mayers had predicted, bind resigned the entire zone with ZSK 33722, and those signatures are valid until July 31. The only signature remaining from ZSK 02750 is on the DNSKEY RRSet, and it is due to expire on July 14. From checking the zone periodically over the past couple of weeks, it appears that DNSSEC remained intact. The current status is shown at http://dnsviz.net/d/countryday.net/dnssec/.

When I originally set up DNSSEC, I referred to the web site "Practical DNSSEC Setup: How to Implement DNSSEC" at http://www.dnssec.net/practical-documents. One of the referenced documents is "Good Practices Guide for Deploying DNSSEC" at http://www.enisa.europa.eu/act/res/technologies/tech/gpgdnssec. On page 12 of this PDF document, the authors make recommendations for key rollover timing, including a recommendation of a two-week interval between the inactivation and deletion dates (retirement time) for ZSKs.

I had adopted this two-week recommendation, but it now appears that this isn't long enough. As I now understand the behavior of bind 9.8.0, it would be possible for an RRSet to be signed using a certain key just prior to its inactivation date. That RRSIG would be valid for 30 days, and resigning with a different, currently active key would normally occur after 3/4 of that interval or 22.5 days. Thus the original key must not be deleted for 22.5 days plus the TTL of the RRSIG records (one hour in my case).

I don't know if the signature validity interval of 30-days or the resigning fraction of 3/4 is configurable when auto-dnssec maintain is in effect. The only statement about this issue that I could find in the bind reference manual is the "-e"  and "-i" parameters of dnssec-signzone. What do others know about this issue?

Phil Mayers referred me to the document "DNSSEC Key Timing Considerations" at http://tools.ietf.org/pdf/draft-ietf-dnsop-dnssec-key-timing-02.pdf. Section 3.2.1 on the Pre-Publication Method for ZSK rollover is relevant here, in particular the description of Event 8 on page 11. It refers to the "delay needed to ensure that all existing RRSets have been re-signed with the new key," but does not quantify this. From what I understand, it is 30 days * 3/4 = 22.5 days for bind 9.8.0.

It seems to me that there is no harm in having a retirement time a little too long and major problems in having it too short. My plan at this point is to use 35 days. I would certainly welcome further advice from the DNSSEC experts on the list. Thanks. Jeff.