On 12/21/2012 6:42 PM, Evan Hunt wrote:
By setting dnssec-dnskey-kskonly, you are telling it to use the KSK as
a(mother) ZSK.
You're thinking of "update-check-ksk". "dnssec-dnskey-kskonly" tells
named not to use the ZSK when it signs the DNSKEY RRset, but it should
still use the ZSK (and not the KSK) for all the other data in the zone.
My guess is the ZSK is inaccessible (private key inactive, missing,
or has permissions set so that named can't read it). If named has an
active KSK it can work with, but no ZSK is available, then it'll use the
KSK for all data rather than let the zone go insecure.
Running "dnssec-settime -p all <key>" on the ZSK will show you what the
key timers are set to. If the key's Activation date is in the future or
the Inactive date is in the past, that's the problem.
I've double and triple checked these details, actually. named has access
to the keys (validated both file permissions and selinux contexts) and
the key metadata is fine with respect to timings. Additionally, the zone
is being signed with both the KSK and the ZSK (which is my primary
problem), so I know that the permissions and metadata are fine :)
--Kyle
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
