Strange tiny time limit RRSIG

[Chris Thompson]

On Aug 14 2009, Paul Wouters wrote:

>On Fri, 14 Aug 2009, Chris Thompson wrote:
>
>>> I'm running into a strange issue where when signing a zone with
>>> re-using signatures, that sometimes 1 RRSIG record ends up with
>>> a validity time of almost nothing. This happens for instance when
>>> signing (and re-using sigs) using "-i 1296000  -e +2592000 -j 2592000"
>>> as part of the dnssec-signzone command.
>>
>> If you set the jitter equal to the relative end time, you are spreading
>> the expiry times uniformly between now and then, so you should expect
>> a few of them to be be "almost nothing". You should be setting jitter
>> so that the earliest expiry time is (comfortably) later than the next
>> time you expect to resign the zone in the same way. (I am assuming that
>> you are using offline signing only.)
>
>Im signing more or less hourly. My -i interval says "at least 1296000 seconds
>in the future" from start date "now - minus 1 hour" (because I don't use "-s")
>
>So as far as I can tell, I should always be more then fine on the lower
>time limit. That's why I'm suspecting a bug in the jitter code.

I think you misunderstand what -i does (or else I do!). If a signature expires
more than 15 days into the future (with your settings) it is left alone. But
if it expires sooner than that, it is replaced, using -s, -e, -j. There's
nothing that stops the new expiry time being *earlier* than it was previously,
if -j is set as large as you are. Obviously, that's not a sensible choice of
options. I would suggest that -j should be no more than 648000 (say), and
certainly no more than 1296000.

For testing the uniform distribution, and seeing just how many new signatures
are almost due to expire when created, I suggest

   awk '{$4=="RRSIG"){print $9}' zone-file.signed | sort | more

assuming that the output of dnssec-signzone is in text rather than raw format.

-- 
Chris Thompson
Email: cet1 at cam.ac.uk