DNSSEC key rollover failure

[Phil Mayers]

On 06/17/2011 09:25 PM, Spain, Dr. Jeffry A. wrote:

> Our zone has 115 records, not counting DNSSEC-related records. I
> originally signed it by specifying the zone file and key directory
> along with "auto-dnssec maintain" in the configuration file. Looking
> at all the RRSIGs, they expire for the most part over a period of a
> couple of hours on July 9, so I think that the resigning process will
> not be a resource utilization problem.

Even if they all expired at the same time, a couple of hundred signings 
is not very expensive.

>
>> Bind will re-sign it at ~0.75 of that window if memory serves, so
>> it'll get re-signed at or about July 1st.
>
> Given what you are saying, if the resigning starts on July 1, that is
> a couple of days after the original DNSKEY is due to be deleted based

In which case you're going to have a serious problems I think. You can't 
delete a DNSKEY which has any extant RRSIGs until $MAX_TTL *after* those 
RRSIGs finally disappear.

There's an RFC describing the key rotation schedules you must use in a 
lot of detail. I can't find the link off-hand, but I will dig into it.

> on its metadata. Hopefully bind will either resign the remaining
> records early or keep the DNSKEY around after its deletion date. I
> will watch it carefully to see what happens.

 From what I recall, bind will immediately re-sign the zone when you 
remove one ZSK, but:

  a. it was a bit weird when I was testing, and
  b. you'll still have problems (see below)

The problem is that a remote caching DNS server might have:

  zone.com DNSKEY id=100 = 100 seconds left in-cache
  www.zone.com RRDIG id=100 = 200 seconds left in cache

...when the DNSKEY expires, the record+RRSIG will still be valid for 
another 100 seconds, but it will be impossible to validate them because 
the DNSKEY will have gone.

Seriously: you need to readjust the key deletion time.