Strange tiny time limit RRSIG

[Paul Wouters]

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