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",
sigstr,
expired ? "expired" :
"failed to verify");
Does that look right?
Yes.
"expired" is a boolean which is set earlier in the code:
if (key != NULL && issigningkey(key))
expired = isc_serial_gt(now + cycle, rrsig.timeexpire);
else
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.
oBUyuuXACq+NbrRqYY7FDhX608/DrvaUVgQH
xqzsHiiGgUC9jyJ4vm0C7DVIT0l2Q91TXqvW
u1aqRBRxsM4NraCqkahUDFNZgwpXdkk4/Coi
8LTwz3HgTPDy5+tk1qnyCuH+5sOAdkZaNXxC
YNITHgY6Q7QNH2Xw/6iost4IxC4= )
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.
Paul
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users