KSK signing all records; NSEC3 algorithm status?
bind-users+phil at spodhuis.org
Wed May 28 15:19:09 UTC 2014
On 2014-05-28 at 13:02 +1000, Mark Andrews wrote:
> In message <20140528012734.GA55903 at redoubt.spodhuis.org>, Phil Pennock writes:
> > 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.
> 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
> 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.
> 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!
> 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.
> > 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.
> That is the NSEC3 HASH algorithm, not the DNSKEY algorithm.
*blush* Thank you.
> DNSKEY algorithms 6, 7, 8 10, 12, 13, and 14 are all NSEC3
> capable. All future algorithms are supposed to be NSEC3
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.
More information about the bind-users