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

[Evan Hunt]

> 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.

Yes, it's looking at the activation time.

It thinks you've published the key for the first time (having no prior
zone data to tell it otherwise), and it sees that the activation time is
less than $dnskey_ttl seconds in the future.  If the activation time were
further away, it would not warn you.  If it were in the past, it would use
the key to sign the zone, and again it would not warn you.  There's only a
window of $dnskey_ttl seconds in which you'd ever see this.

And actually, in the case of dnssec-signzone, it's a pointless message
and should probably be suppressed.  Where this issue comes into play is in
automatic signing:  if named loads a brand new key whose activation time is
less than $dnskey_ttl seconds in the future, then named will delay the
activation time to accomodate resolver caches, and that message gets
logged so you know about it.  It happens that dnssec-signzone uses the same
function to load keys that named does, so you saw the same warning message,
but there's no reason you need to care.

-- 
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.