KSK signing all records; NSEC3 algorithm status?

[Phil Pennock]

The registrar for my zone "xn--qck5b9a5eml3bze.jp" required a DNSSEC
KSK update; good practice on their part. My first rollover, though.
I've ended up with all records being signed by the new KSK, apparently
through an algorithm mismatch, and I'm not seeing how to handle this --
I'm wondering if I've run into a current Bind limitation?

I'm using Bind 9.10, and the zone statement includes:

auto-dnssec maintain;
inline-signing yes;

I had originally set up the signing for the zone with:

rndc signing -nsec3param 1 0 100 $(openssl rand -hex 8) $zone

For this rollover, I generated a new key, and perhaps stupidly took the
opportunity to bump the hash algorithm:

dnssec-keygen -3 -a RSASHA256 -b 2048 -f KSK xn--qck5b9a5eml3bze.jp

and deployed to the host; while checking man-pages to figure out how to
tell Bind to start using the new key, I noticed that it had in fact
picked it up. ZSK being signed with both old and new KSK -- fantastic!
Alas: <http://dnsviz.net/d/xn--qck5b9a5eml3bze.jp/dnssec/>
Which shows the id=53065 SEP-flagged KSK being used to sign non-DNSKEY
records within the zone.

List archives led me to Kyle Brantley's post:
Subject: Re: auto-dnssec maintain: KSK being used as a ZSK as well?
Date: Fri, 21 Dec 2012 19:50:43 -0700
Message-ID: <***@averageurl.com>
which clued me in with:
} 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.

The rndc manual page states:
- ----------------------------8< cut here >8------------------------------
rndc signing -nsec3param sets the NSEC3 parameters for a zone. This
is the only supported mechanism for using NSEC3 with inline-signing
zones. Parameters are specified in the same format as an NSEC3PARAM
resource record: hash algorithm, flags, iterations, and salt, in
that order.

Currently, the only defined value for hash algorithm is 1,
representing SHA-1. The flags may be set to 0 or 1, depending on
whether you wish to set the opt-out bit in the NSEC3 chain.
iterations defines the number of additional times to apply the
algorithm when generating an NSEC3 hash. The salt is a string of
data expressed in hexadecimal, a hyphen (`-') if no salt is to be
used, or the keyword auto, which causes named to generate a random
64-bit salt.
- ----------------------------8< cut here >8------------------------------

I do not really want to move away from inline-signing/maintain -- it's a
great feature which automates something which should be automated. I
know that in theory, there's nothing requiring the KSK/ZSK split but I'd
still like to get back to a more traditional setup.

(1) Have I put myself into a bad situation where my only way out is to
generate a new DNSKEY KSK, this time back with the default SHA1,
add it to the zone, then get the registrar to update the DS
records?

(2) Is it the case that the problem is that given a hash algorithm X
and a second algorithm Y, with X used for the KSK and Y used for
the ZSK, if inline-signing sees such a situation with no ZSK using
algorithm X, then it will sign the entire zone with the KSK, as
suggested by Kyle's debugging in 2012? Is this intentional? I can
see a rationale -- keep one consistent set of signing algorithms,
reduce potential for interop tangles. However, since IANA appears
to only have SHA-1 registered for NSEC3:
<http://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml>
this seems to be an unfortunate interplay.

(3) Anyone have any constructive suggestions or advice to guide me out?
Even if it's just "go route 1, at this time don't bother touching
other hash algorithms while using NSEC3"?

Guidance appreciated, thanks,
- -Phil

[Mark Andrews]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
The registrar for my zone "xn--qck5b9a5eml3bze.jp" required a DNSSEC
KSK update; good practice on their part.

For most zones you never need to roll DNSSEC keys. Even for high
value zones where someone would be willing to spend the resources
to break the public keys once a decade would be fine.

The only reason higher frequency rollovers to occur is to practice them.

My first rollover, though.
I've ended up with all records being signed by the new KSK, apparently
through an algorithm mismatch, and I'm not seeing how to handle this --
I'm wondering if I've run into a current Bind limitation?
auto-dnssec maintain;
inline-signing yes;
rndc signing -nsec3param 1 0 100 $(openssl rand -hex 8) $zone
For this rollover, I generated a new key, and perhaps stupidly took the
dnssec-keygen -3 -a RSASHA256 -b 2048 -f KSK xn--qck5b9a5eml3bze.jp

This is not a KSK key rollover in the usual sence of the expression.
This is rolling to a new DNSKEY algorithm and you should have
generated both a KSK and ZSK for this algorithm.

If you want to finish transitioning to RSASHA256 just generate a
zone signing key RSASHA256. Named will sort things out. You may
end up with 3 sets of signatures for a while. Don't worry about
it.

Once that is done you need to add a DS record for the KSK. You can also
remove the old DS if twelve hours have elasped since you started the process.

After the maxmium of (12 hours (DS ttl), the maximum TTL in the
zone (at least 12 hours)) after the DS change to remove the old DS
you can tell mark the old keys as inactive and not to be published
using dnssec-settime. All the keys for the algorithm need to stop
being used and published at the same time.

and deployed to the host; while checking man-pages to figure out how to
tell Bind to start using the new key, I noticed that it had in fact
picked it up. ZSK being signed with both old and new KSK -- fantastic!
Alas: <http://dnsviz.net/d/xn--qck5b9a5eml3bze.jp/dnssec/>
Which shows the id=53065 SEP-flagged KSK being used to sign non-DNSKEY
records within the zone.
Subject: Re: auto-dnssec maintain: KSK being used as a ZSK as well?
Date: Fri, 21 Dec 2012 19:50:43 -0700
} 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 gre
at
} now.
- ----------------------------8< cut here >8------------------------------
rndc signing -nsec3param sets the NSEC3 parameters for a zone. Thi
s
is the only supported mechanism for using NSEC3 with inline-signin
g
zones. Parameters are specified in the same format as an NSEC3PARA
M
resource record: hash algorithm, flags, iterations, and salt, in
that order.
Currently, the only defined value for hash algorithm is 1,
representing SHA-1. The flags may be set to 0 or 1, depending on
whether you wish to set the opt-out bit in the NSEC3 chain.
iterations defines the number of additional times to apply the
algorithm when generating an NSEC3 hash. The salt is a string of
data expressed in hexadecimal, a hyphen (`-') if no salt is to be
used, or the keyword auto, which causes named to generate a random
64-bit salt.
- ----------------------------8< cut here >8------------------------------
I do not really want to move away from inline-signing/maintain -- it's a
great feature which automates something which should be automated. I
know that in theory, there's nothing requiring the KSK/ZSK split but I'd
still like to get back to a more traditional setup.
(1) Have I put myself into a bad situation where my only way out is to
generate a new DNSKEY KSK, this time back with the default SHA1,
add it to the zone, then get the registrar to update the DS
records?
(2) Is it the case that the problem is that given a hash algorithm X
and a second algorithm Y, with X used for the KSK and Y used for
the ZSK, if inline-signing sees such a situation with no ZSK using
algorithm X, then it will sign the entire zone with the KSK, as
suggested by Kyle's debugging in 2012? Is this intentional?

Yes. Named enforces the signing rules that every record is
signed with every algorithm. When you add a new DNSKEY algorithm
it will ensure that every RRset gets signed with it. It does
this incrementally then updates the private type records to
say that it has completed the operation so you can then add the
DS records. If there isn't a ZSK for that algorithm it will
use a KSK.

I can
see a rationale -- keep one consistent set of signing algorithms,
reduce potential for interop tangles. However, since IANA appears
<http://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-
parameters.xhtml>
this seems to be an unfortunate interplay.

That is the NSEC3 HASH algorithm, not the DNSKEY algorithm.

DNSKEY algorithms 6, 7, 8 10, 12, 13, and 14 are all NSEC3
capable. All future algorithms are supposed to be NSEC3
capable.

For DNSKEY algorithms 252, 253 and 254 you need to look at
the individual algorithms encoded at the start of the key
field.

Algorithms 1, 3, and 5 are not NSEC3 capable and their
presence in the DNSKEY RRset will stop attempts to use NSEC3
with the zone.

(3) Anyone have any constructive suggestions or advice to guide me out?
Even if it's just "go route 1, at this time don't bother touching
other hash algorithms while using NSEC3"?
Guidance appreciated, thanks,
- -Phil
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJThTt4AAoJEKBsj+IM0duFFq4IAJ+dn1+0Vkm7XnN+r70QDWmD
fgEN0G9D72TRJ0lYqkd19W/qwctfKDkCUaTt3BIjRwBDV3bQXxqLQkXxH7jWFNXK
czZEEm6mOKCQWcBEKAMtfWM5cGKGAjSjfvbA2ZOAvuUIkDfYN0s4kcWYFTre7Zyk
SSnZi909xs1ZPiuz447dmUBr3gg5wNJAuUNiNJJP9DHriu6542DdRzUtbu3zmABG
rBAjS/budz/nr3INHYvTCyR1PJ7RtzxtVT5PcnQ0GnP1H92Zspk3rDrqc8CWDSUA
5UUV0D8qSE8xvzwcW6qiaJO7OkYoaUgxjgsS0rsceOoLWLriIZuVsV8NgT8SNMw=
=hRKl
-----END PGP SIGNATURE-----
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

[Phil Pennock]

Post by Mark Andrews

Post by Phil Pennock
The registrar for my zone "xn--qck5b9a5eml3bze.jp" required a DNSSEC
KSK update; good practice on their part.

For most zones you never need to roll DNSSEC keys. Even for high
value zones where someone would be willing to spend the resources
to break the public keys once a decade would be fine.
The only reason higher frequency rollovers to occur is to practice them.

That was my understanding; however, "TLD registrar establishing a
mandate" is another good reason.

Post by Mark Andrews
This is not a KSK key rollover in the usual sence of the expression.
This is rolling to a new DNSKEY algorithm and you should have
generated both a KSK and ZSK for this algorithm.
If you want to finish transitioning to RSASHA256 just generate a
zone signing key RSASHA256. Named will sort things out. You may
end up with 3 sets of signatures for a while. Don't worry about
it.
Once that is done you need to add a DS record for the KSK. You can also
remove the old DS if twelve hours have elasped since you started the process.

The DS record is already in place for the KSK.

Post by Mark Andrews
After the maxmium of (12 hours (DS ttl), the maximum TTL in the
zone (at least 12 hours)) after the DS change to remove the old DS
you can tell mark the old keys as inactive and not to be published
using dnssec-settime. All the keys for the algorithm need to stop
being used and published at the same time.

Perfect, thanks for that!

Post by Mark Andrews
Yes. Named enforces the signing rules that every record is
signed with every algorithm. When you add a new DNSKEY algorithm
it will ensure that every RRset gets signed with it. It does
this incrementally then updates the private type records to
say that it has completed the operation so you can then add the
DS records. If there isn't a ZSK for that algorithm it will
use a KSK.

Ah, I hadn't considered how the KSK/ZSK being an operational distinction
rather than an algorithm distinction would play into the requirements
around key consistency -- as far as verifiers are concerned, the
validation of KSK is not a distinct step and does not introduce a "cut"
for record signing algorithm requirements. Thanks.

Post by Mark Andrews

Post by Phil Pennock
I can
see a rationale -- keep one consistent set of signing algorithms,
reduce potential for interop tangles. However, since IANA appears
<http://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-
parameters.xhtml>
this seems to be an unfortunate interplay.

That is the NSEC3 HASH algorithm, not the DNSKEY algorithm.

*blush* Thank you.

Post by Mark Andrews
DNSKEY algorithms 6, 7, 8 10, 12, 13, and 14 are all NSEC3
capable. All future algorithms are supposed to be NSEC3
capable.

And of course, this is why I'd chosen to use the "-3" option to
dnssec-keygen, to ensure I remained NSEC3 capable, but by the end of
chasing the information paths I was on, I'd forgotten this.

Okay, I think that I'm on track to recovery. Thanks.
-Phil

[Mark Andrews]

Post by Phil Pennock

Post by Mark Andrews

Post by Phil Pennock
The registrar for my zone "xn--qck5b9a5eml3bze.jp" required a DNSSEC
KSK update; good practice on their part.

For most zones you never need to roll DNSSEC keys. Even for high
value zones where someone would be willing to spend the resources
to break the public keys once a decade would be fine.
The only reason higher frequency rollovers to occur is to practice them.

That was my understanding; however, "TLD registrar establishing a
mandate" is another good reason.

In general TLD's should butt out of this other than to register DS
records. No TLD's don't need to see DNSKEY records or generate DS
records.

Post by Phil Pennock

Post by Mark Andrews
This is not a KSK key rollover in the usual sence of the expression.
This is rolling to a new DNSKEY algorithm and you should have
generated both a KSK and ZSK for this algorithm.
If you want to finish transitioning to RSASHA256 just generate a
zone signing key RSASHA256. Named will sort things out. You may
end up with 3 sets of signatures for a while. Don't worry about
it.
Once that is done you need to add a DS record for the KSK. You can also
remove the old DS if twelve hours have elasped since you started the process.

The DS record is already in place for the KSK.

Post by Mark Andrews
After the maxmium of (12 hours (DS ttl), the maximum TTL in the
zone (at least 12 hours)) after the DS change to remove the old DS
you can tell mark the old keys as inactive and not to be published
using dnssec-settime. All the keys for the algorithm need to stop
being used and published at the same time.

Perfect, thanks for that!

Post by Mark Andrews
Yes. Named enforces the signing rules that every record is
signed with every algorithm. When you add a new DNSKEY algorithm
it will ensure that every RRset gets signed with it. It does
this incrementally then updates the private type records to
say that it has completed the operation so you can then add the
DS records. If there isn't a ZSK for that algorithm it will
use a KSK.

Ah, I hadn't considered how the KSK/ZSK being an operational distinction
rather than an algorithm distinction would play into the requirements
around key consistency -- as far as verifiers are concerned, the
validation of KSK is not a distinct step and does not introduce a "cut"
for record signing algorithm requirements. Thanks.

Post by Mark Andrews

Post by Phil Pennock
I can
see a rationale -- keep one consistent set of signing algorithms,
reduce potential for interop tangles. However, since IANA appears
<http://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-
parameters.xhtml>
this seems to be an unfortunate interplay.

That is the NSEC3 HASH algorithm, not the DNSKEY algorithm.

*blush* Thank you.

Post by Mark Andrews
DNSKEY algorithms 6, 7, 8 10, 12, 13, and 14 are all NSEC3
capable. All future algorithms are supposed to be NSEC3
capable.

And of course, this is why I'd chosen to use the "-3" option to
dnssec-keygen, to ensure I remained NSEC3 capable, but by the end of
chasing the information paths I was on, I'd forgotten this.
Okay, I think that I'm on track to recovery. Thanks.

No problem. Just remember when you generate the keys in the future
to pick the correct DNSKEY algorithm.

Post by Phil Pennock
-Phil
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

[Phil Pennock]

Post by Mark Andrews
If you want to finish transitioning to RSASHA256 just generate a
zone signing key RSASHA256. Named will sort things out. You may
end up with 3 sets of signatures for a while. Don't worry about
it.

The new DNSKEY had id=33768 and when I deployed it, Bind signed the SOA
with it but nothing else.

$ rndc -s 127.0.0.5 signing -list xn--qck5b9a5eml3bze.jp
Done signing with key 53065/RSASHA256

$ host -lva xn--qck5b9a5eml3bze.jp nsauth | fgrep 33768
xn--qck5b9a5eml3bze.jp. 43200 IN RRSIG DNSKEY 8 2 43200 20140627144436 20140528134436 33768 xn--qck5b9a5eml3bze.jp. BnKhdfy6/nGSEBnOo8EUJvHkzi+5NASKEHRTXE4R1abZprxSuuf2LFUhxzMsrZuvhsj/v7+8p0t5hQJx98Zvph+ddmFy5NfMBo/68OHtvuYPsquKuAQWLJtlykzj8C1MmMlute7tmxcZRaCMO7f26AqI/Pa4aa1JmmIyRtUo+Dg=
xn--qck5b9a5eml3bze.jp. 43200 IN RRSIG SOA 8 2 43200 20140627144436 20140528134436 33768 xn--qck5b9a5eml3bze.jp. R7tyfea3OvFxnwgqL4xseUIAMfbIJsJywYn8hP8zYmTQqD6/31/ysNxVSJ8bnyGA1AwfcBrdjlD8NlDbzZRqMiM6avNF0PWIA8HMfvaB7AJ1aUjeGPLp3lR2zxTGdUpcpfY+Ge2fD2L7jB5hJYvCLEqCK8zDXC6EFYyZJFm0F+A=

It's been almost 14 hours, so anything that was going to slow roll,
should have completed.

Ran:

$ rndc -s 127.0.0.5 signing -nsec3param 1 0 100 $(openssl rand -hex 8) xn--qck5b9a5eml3bze.jp

(If I'd thought, I could have used the same seed as before by looking up
NSEC3PARAM type in DNS; ah well, the change should be harmless, right?)

I'm seeing a very incomplete set of records signed with id=33768.

To make it easier for others to see, and because I didn't want to
reconfig or further perturb bind9.10 on the authoritative master, I just
set one of the secondaries to open zone transfer for this zone. The
`us0ns.globnix.net` server, which gets NOTIFY updates, has
`allow-transfer { any; };` enabled for `xn--qck5b9a5eml3bze.jp`.

$ host -lva xn--qck5b9a5eml3bze.jp us0ns.globnix.net

There's various bits going into the logfile from default channel. In
`logging {}` I do have `category "dnssec" { "dnssec_log"; };` but the
file taking that channel is, and always has been, empty.

It's hard to see anything about progress or decisions in signing in the
stuff which is going to the default log stream; there's:

----------------------------8< cut here >8------------------------------
28-May-2014 09:44:36.735 general: info: zone xn--qck5b9a5eml3bze.jp/IN (signed): reconfiguring zone keys
28-May-2014 09:44:36.739 general: info: zone xn--qck5b9a5eml3bze.jp/IN (signed): next key event: 28-May-2014 10:44:36.735
28-May-2014 10:34:20.108 general: info: received control channel command 'reload xn--qck5b9a5eml3bze.jp'
28-May-2014 10:34:20.110 general: info: zone xn--qck5b9a5eml3bze.jp/IN (unsigned): ixfr-from-differences: unchanged
28-May-2014 10:44:36.737 general: info: zone xn--qck5b9a5eml3bze.jp/IN (signed): reconfiguring zone keys
28-May-2014 10:44:36.902 general: info: zone xn--qck5b9a5eml3bze.jp/IN (signed): next key event: 28-May-2014 11:44:36.737
28-May-2014 10:44:36.903 notify: info: zone xn--qck5b9a5eml3bze.jp/IN (signed): sending notifies (serial 2014011540)
28-May-2014 10:59:28.035 general: info: zone xn--qck5b9a5eml3bze.jp/IN (signed): reconfiguring zone keys
28-May-2014 10:59:28.040 general: info: zone xn--qck5b9a5eml3bze.jp/IN (signed): next key event: 28-May-2014 11:59:28.035
[...]
28-May-2014 23:59:28.446 general: info: zone xn--qck5b9a5eml3bze.jp/IN (signed): reconfiguring zone keys
28-May-2014 23:59:28.451 general: info: zone xn--qck5b9a5eml3bze.jp/IN (signed): next key event: 29-May-2014 00:59:28.446
29-May-2014 00:14:03.818 general: info: received control channel command 'signing -list xn--qck5b9a5eml3bze.jp'
29-May-2014 00:20:51.947 general: info: received control channel command 'signing -list xn--qck5b9a5eml3bze.jp'
29-May-2014 00:28:51.777 general: info: received control channel command 'signing -list xn--qck5b9a5eml3bze.jp'
29-May-2014 00:31:43.724 general: info: received control channel command 'signing -nsec3param 1 0 100 018150bbcb496fae xn--qck5b9a5eml3bze.jp'
29-May-2014 00:31:43.815 general: info: zone xn--qck5b9a5eml3bze.jp/IN (signed): zone_addnsec3chain(1,REMOVE,100,AFAC2F795254DCC2)
29-May-2014 00:31:43.815 general: info: zone xn--qck5b9a5eml3bze.jp/IN (signed): zone_addnsec3chain(1,CREATE,100,018150BBCB496FAE)
29-May-2014 00:31:43.860 notify: info: zone xn--qck5b9a5eml3bze.jp/IN (signed): sending notifies (serial 2014011542)
29-May-2014 00:31:48.871 notify: info: zone xn--qck5b9a5eml3bze.jp/IN (signed): sending notifies (serial 2014011544)
----------------------------8< cut here >8------------------------------

The TZ is America/New_York -- it's a mistake, I know why it has
happened, I'm not changing it back to UTC until this issue has been
resolved.

Any thoughts as to what I've messed up, and how, please?

[Phil Pennock]

Post by Phil Pennock
The new DNSKEY had id=33768 and when I deployed it, Bind signed the SOA
with it but nothing else.

Bind 9.10 ARM (PDF-only??):
"However, if the new key is replacing an existing key of the same
algorithm, then the zone will be re-signed incrementally, with
signatures from the old key being replaced with signatures from the new
key as their signature validity periods expire. By default, this
rollover completes in 30 days, after which it will be safe to remove the
old key from the DNSKEY RRset."

This is the cause, isn't it? The KSK/ZSK distinction again is
irrelevant here. I'm not seeing any way to fix this, while keeping the
current id=53065 KSK.

Is there a way to transition in a timely manner while keeping current
keys?

If not, if I were to use dnssec-settime to set the 53065 key to be
retired in two days and generate a new KSK of same algorithm, what would
the timing be on switching to the new key and getting all the records
updated? I have a two hour TTL on the DS records in the parent, which
are currently for 53065.

Thanks,
-Phil