KSK signing all records; NSEC3 algorithm status?

Phil Pennock bind-users+phil at spodhuis.org
Wed May 28 01:27:34 UTC 2014

Hash: SHA256

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: <50D52003.4010508 at 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

 (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:
     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


More information about the bind-users mailing list