auto-dnssec maintain: KSK being used as a ZSK as well?

[Kyle Brantley]

I've generated a KSK as well as a ZSK and configured bind to maintain
the keys.

# named.conf
options {
[...]
dnssec-enable yes;
dnssec-validation yes;
dnssec-secure-to-insecure yes;
dnssec-dnskey-kskonly yes;
}

[...]

zone "averageurl.com." IN {
type master;
file "data/averageurl.com.zone";
allow-transfer { key inter-server-key; };
update-policy {
grant local-ddns zonesub any;
};
key-directory "keys/averageurl.com";
auto-dnssec maintain;
};


However, when bind goes through and does the actual zone signing, it
appears as if the KSK is signing the ZSK(s) and the actual zone data as
well (see: http://dnsviz.net/d/averageurl.com/dnssec/).

Am I missing something obvious here? I would like the KSK to sign just
the ZSKs... but aside from setting dnssec-dnskey-kskonly (which I've
done) I can't see anything that I'm missing here.

OS and bind versions:
# rpm -qa | grep bind
bind-libs-9.8.2-0.10.rc1.el6_3.6.x86_64
bind-utils-9.8.2-0.10.rc1.el6_3.6.x86_64
bind-9.8.2-0.10.rc1.el6_3.6.x86_64
# uname -a
Linux 2.6.32-279.14.1.el6.x86_64 #1 SMP Tue Nov 6 23:43:09 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux

Any help would be appreciated...
--Kyle

[Alan Clegg]

On Dec 22, 2012, at 9:52 AM, Kyle Brantley <ky...@averageurl.com> wrote:

> # named.conf
> options {
> [...]
> dnssec-enable yes;
> dnssec-validation yes;
> dnssec-secure-to-insecure yes;
> dnssec-dnskey-kskonly yes;
> }

By setting dnssec-dnskey-kskonly, you are telling it to use the KSK as a(mother) ZSK.

Don't do that. Also, unless you are planning on deleting the DNSKEY resource records, get rid of the "secure-to-insecure" as well.

AlanC
--
Alan Clegg | +1-919-355-8851 | al...@clegg.com

[Alan Clegg]

On Dec 22, 2012, at 9:56 AM, Alan Clegg <al...@clegg.com> wrote:
>
> By setting dnssec-dnskey-kskonly, you are telling it to use the KSK as a(mother) ZSK.

Stupid autocorrect. a(nother) not anything about anyone's mother.

[Kyle Brantley]

On 12/21/2012 3:56 PM, Alan Clegg wrote:
> On Dec 22, 2012, at 9:52 AM, Kyle Brantley <ky...@averageurl.com> wrote:
>
>> # named.conf
>> options {
>> [...]
>> dnssec-enable yes;
>> dnssec-validation yes;
>> dnssec-secure-to-insecure yes;
>> dnssec-dnskey-kskonly yes;
>> }

> By setting dnssec-dnskey-kskonly, you are telling it to use the KSK as a(nother) ZSK.

>
> Don't do that. Also, unless you are planning on deleting the DNSKEY resource records, get rid of the "secure-to-insecure" as well.
>
> AlanC

Initially I didn't have the directive in there at all and it was still
doing this. I added it in to see if it would help resolve the problem.
I've flipped it to no and resigned the zone... but it's still using the
ZSK as a KSK. I also re-tried it without the directive at all, and it is
still using the ZSK as a KSK.

re: secure-to-insecure: I'll be removing this statement once I get these
keys working properly. At the moment, that's how I'm resigning the zone:
delete the DNSKEY records via nsupdate and then re-add them.

--Kyle

[Alan Clegg]

On Dec 22, 2012, at 10:03 AM, Kyle Brantley <ky...@averageurl.com> wrote:

> On 12/21/2012 3:56 PM, Alan Clegg wrote:
>> On Dec 22, 2012, at 9:52 AM, Kyle Brantley <ky...@averageurl.com> wrote:
>>
>>> # named.conf
>>> options {
>>> [...]
>>> dnssec-enable yes;
>>> dnssec-validation yes;
>>> dnssec-secure-to-insecure yes;
>>> dnssec-dnskey-kskonly yes;
>>> }
>> By setting dnssec-dnskey-kskonly, you are telling it to use the KSK as a(nother) ZSK.
>>
>> Don't do that. Also, unless you are planning on deleting the DNSKEY resource records, get rid of the "secure-to-insecure" as well.

> Initially I didn't have the directive in there at all and it was still doing this. I added it in to see if it would help resolve the problem. I've flipped it to no and resigned the zone... but it's still using the ZSK as a KSK. I also re-tried it without the directive at all, and it is still using the ZSK as a KSK.

BIND won't sign with the KSK in the way shown unless that directive was there (or it was a static zone and it was signed with the KSK instead of the ZSK (and then, only when forced).

> re: secure-to-insecure: I'll be removing this statement once I get these keys working properly. At the moment, that's how I'm resigning the zone: delete the DNSKEY records via nsupdate and then re-add them.

That's not resigning a zone, that's destroying a zone and rebuilding on the rubble.

I haven't watched it, but you may find the presentation link on this page useful:

http://www.nanog.org/meetings/nanog50/abstracts.php?pt=MTY3NSZuYW5vZzUw&nm=nanog50

[Evan Hunt]

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

--
Evan Hunt -- ea...@isc.org
Internet Systems Consortium, Inc.

[Kyle Brantley]

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

[Alan Clegg]

On Dec 22, 2012, at 12:42 PM, Evan Hunt <ea...@isc.org> 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.

Eh, yep. Thanks for that catch, Evan.

I think we may have found the problem "off-list" and it may be another thing for the signer to look into... more in a bit.

[Kyle Brantley]

Aye. Thanks, Alan, for the help. The problem was that I was generating a
RSASHA512 for my KSK, but I was using NSEC3RSASHA1 for my ZSKs. I
generated a temporary ZSK that was also RSASHA512 to match my KSK and it
is working great now.

Now to go decimate the entropy on my box for a bit to generate some more
RSASHA512 keys...

--Kyle