On Fri, 14 Aug 2009, Evan Hunt wrote:
The truth is that E is a hard limit, so the range you get is E-J to E.
So, given E = S + 30d, and J = 30d, you're getting expiry times ranging
from S to E.
S, in this case, is an hour in the past. I guess that accounts for the
already-expired signatures y
> 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 ?
I have been corrected by my colleague Mark Andrews: I apparently misread
both the code and the doc. Apologies for the confusion.
I *thought* the jitter
In message , Paul Wou
ters writes:
> 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
> >> s
On Aug 14 2009, Evan Hunt wrote:
Your -j flag says, use a 30 day jitter window for the expiry times. So now
it's 30 days in the future, plus or minus 15 days.
Are you sure about this? The OP is talking about 9.6.1 and as I read the
source of isc_random_jitter() in lib/isc/random.c, jitter onl
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, "\t
> 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",
On Fri, 14 Aug 2009, Chris Thompson wrote:
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
On Fri, 14 Aug 2009, Evan Hunt wrote:
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")
Your -i flag says: if you're re-signing a zone that's already signed, any
RRSIGs whose expiry times
> 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")
Your -i flag says: if you're re-signing a zone that's already signed, any
RRSIGs whose expiry times are less than 15 days in the future
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
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
On Aug 14 2009, Paul Wouters 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 2592
Hi,
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-signz
13 matches
Mail list logo
