"Key <foo>: Delaying activation to match the DNSKEY TTL."

[Paul B. Henson]

On Wed, Jul 06, 2011 at 06:56:57PM -0700, Evan Hunt wrote:
 
> Apparently it thought this was the first time it was being published,
> anyway.  That information doesn't come from the publication date but
> from before-and-after comparison of the DNSKEY RRset.
> 
> If this message came from dnssec-signzone, I guess maybe you were
> signing the raw zone, rather than re-signing a zone that was already
> signed?

Yes; our zone data is stored in a subversion repository, when it
changes, a process generates a bind format zone file from the raw data,
feeds it through named-compilezone, then through dnssec-signzone,
and then finally copies it into place and reloads the zone via rndc
reload.

I only saw this message when the key first became active, I haven't seen
it since. However, based on your description, and given I'm always
signing a fresh zone rather than resigning one, it seems I'd always see
this message, as dnssec-signzone would never have an existing DNSKEY
RRset to compare to, and would always think the key was being published
for the first time? So there must be some consideration of the times set
in the key that affects this decision.

Is there any way to make dnssec-signzone not try to be smarter than it
should be? If I have a key that should be active, I want it used to
sign. Part of our key rolling process is forcing an update after new
keys are generated, to get them published and so that the last published
but not yet used keys are brought into play. If dnssec-signzone
doesn't use the keys that should be active, and there are no updates for
a month (which would result in another signing), I'll end up with
invalid signatures before the next scheduled key generation :(.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson at csupomona.edu
California State Polytechnic University  |  Pomona CA 91768