Strange tiny time limit RRSIG
paul at xelerance.com
Fri Aug 14 19:09:41 UTC 2009
On Fri, 14 Aug 2009, Evan Hunt wrote:
>> But I am getting the error that the signature is *expired*. Not that it is
>> being replaced because its only valid for 15 days - 1 hour in the future.
> It would look that way. I think the message you're seeing comes from here:
> vbprintf(2, "\trrsig by %s dropped - %s\n",
> expired ? "expired" :
> "failed to verify");
> Does that look right?
> "expired" is a boolean which is set earlier in the code:
> if (key != NULL && issigningkey(key))
> expired = isc_serial_gt(now + cycle, rrsig.timeexpire);
> expired = isc_serial_gt(now, rrsig.timeexpire);
> "cycle" is the -i interval, so in your case it's checking whether
> rrsig.timeexpire is less than fifteen days from now, and if it is, it
> will claim to be dropping the signature because it's expired.
> We could clarify the log message, I guess.
You could. however, in my case I do really see strange RRsigs that
have a validity period of less then one day when using the previosuly
discussed jitter/interval settings. for instance, in the most recent zone
file, generated within the last hour, running named-checkzone -i local, I get:
ca.zone.signed:2877010: signature has expired
That record shows:
047OV875AKMGO03O7GU9U08DN6GRQUK8.ca. 3600 IN NSEC3 1 0 1 AAAA 047P7L29EASJL6U4R8MMJJO93JRV58DG NS
3600 RRSIG NSEC3 7 2 3600 20090814174351 (
20090814174230 914 ca.
I don't think with using my parameters, a record should ever get created
using the time period 20090814174351 - 20090814174230. It's clearly not at
least 1w from expiring, as it has already expired.
>> But I want to re-use signatures and use jitter.
> That's fine, but the jitter window and cycle interval are both larger
> than they need to be.
I am still confused about the jitter window. I'm assuming the jitter
windows is spread between -s (now-1h) plus -i value up to -e value ?
> The default cycle interval is a 7.5 days (one
> quarter of 30 days, which is the default signature validity interval),
> so if you dropped the -i argument, you wouldn't be seeing this issue.
> There still might be a signature with an expiry time 15 days in the future,
> but it wouldn't be dropped until 7.5 days from now.
> Or, if you kept the -j option but scaled it down, to say 20 days instead
> of 30, then the earlist expiration times would be 20 days from now instead
> of 15, so the -i flag wouldn't hit them for five days.
I am still not understanding either the preference for the default
values nor the error of the values I picked..... I don't think the
interaction between -i, -s, -e and -j is very clear to me.
More information about the bind-users