-----BEGIN PGP SIGNED MESSAGE-----
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.4010...@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
-----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
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
