KSK signing zone records
I've had an issue with my key rotation process on a couple of zones. I believe I've resolved that issue but it appears to me in several cases the KSKs rather than being used to sign the ZSK are being used to sign the zone records directly. https://dnsviz.net/d/testmenwu.com/dnssec/?rr=2&a=all&ds=all&ta=.&tk= I've checked the Publication/Activation dates on the KSKs and they seem to be right. The appropriate DS records should be available at the parent zone. The keys in question are clearly type 257 KSKs. Is there some kind of flag or something I need to add to the key to make it sign the ZSKs rather than the records directly? I'm running bind 9.16.16. -- Timothy A. Holtzen Campus Network Administrator Nebraska Wesleyan University Public PGP ECC Curve 25519 Key: 11A2 3FDB AD70 12CA D77D C7DD DFFB 7662 24E6 C30D Old Public PGP RSA key: CFB4 3AE8 B726 DEBF 00D9 CCFC 426E 76AF DABC B3D7 OpenPGP_signature Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: KSK signing zone records
What algorithm(s) are you using for ZSK and KSK? If they’re not the same algorithm, then both will be used to sign the entire zone. Regards, Chris Buxton > On Aug 30, 2021, at 9:08 AM, Timothy A. Holtzen via bind-users > wrote: > > Signed PGP part > I've had an issue with my key rotation process on a couple of zones. I > believe I've resolved that issue but it appears to me in several cases > the KSKs rather than being used to sign the ZSK are being used to sign > the zone records directly. > > https://dnsviz.net/d/testmenwu.com/dnssec/?rr=2&a=all&ds=all&ta=.&tk= > > I've checked the Publication/Activation dates on the KSKs and they seem > to be right. The appropriate DS records should be available at the > parent zone. The keys in question are clearly type 257 KSKs. Is there > some kind of flag or something I need to add to the key to make it sign > the ZSKs rather than the records directly? > > I'm running bind 9.16.16. > > > -- > > Timothy A. Holtzen > Campus Network Administrator > Nebraska Wesleyan University > Public PGP ECC Curve 25519 Key: 11A2 3FDB AD70 12CA D77D C7DD DFFB 7662 24E6 > C30D > Old Public PGP RSA key: CFB4 3AE8 B726 DEBF 00D9 CCFC 426E 76AF DABC B3D7 > > > signature.asc Description: Message signed with OpenPGP ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: KSK signing zone records
On Mon, Aug 30, 2021 at 10:13:05AM -0700, Chris Buxton wrote: > What algorithm(s) are you using for ZSK and KSK? If they’re not the > same algorithm, then both will be used to sign the entire zone. > > Regards, > Chris Buxton Just out of curiosity, why is that? Isn't having the KSK sign the ZSK enough? What difference does the nature of the thing being signed make? cheers, raf ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Does BIND support "conservative" (RFC 6781, sec 4.1.4) algorithm rollovers?
Hi,
I have, in the past, used the "conservative" approach to performing
algorithm rollovers for various domains. For many domains, this is
probably overkill, but I'd prefer to have the option of doing it,
especially for those mission-critical domains where you really don't
want to rely simply on the hope that nobody who needs to reach you (or
your org/company) is using a resolver that is still following the
strictest interpretation of RFC 4035, section 2.2.
In the past, I have handled this completely manually, signing the zone
using dnssec-signzone to sign the zone with keys of both algs before
(again manually) including the the new alg keys in the DNSKEY RRSET.
But for zones which I am inline-signing as a provider for someone else,
I would like to use a more automated method. It doesn't appear that
BIND currently supports this, either with dnssec-keymgr and
'inline-signing' or with KASP.
I did try the trick of setting the key metadata manually ('publish' in
the future and 'activate' in the past), but BIND 'inline-signing' would
not sign the zone prior with the key prior to its publication, despite
my timing metadata settings.
So I am assuming that only the "liberal" approach is supported. One
thing I thought of was trying a "moderate" approach, where the various
TTLs are manipulated so that the zone RRSIGs expire quickly before the
new alg is added and then flipping it so that the DNSKEY RRSET expires
quickly and the zone/RRSIG TTLs stay in cache longer. But that is still
a fairly tricky approach and I am not sure it would work...
michael
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Does BIND support "conservative" (RFC 6781, sec 4.1.4) algorithm rollovers?
Michael,
there has never been needed to pre-publish RRSIGs because the DNS is
a loosely coherent system and from outside you can’t determine which DNSKEY
RRset signed which other RRset. There is only one regularly lookup where you
can determine whether the RRset is signed by all the algorithms in the DNSKEY
RRset and that is for the DNSKEY RRset itself. For every other regular lookup
it is impossible to determine because you have a DNSKEY RRset and seperate
RRset that may or may not have come from the same instance of the zone. The
validation rules where designed to allow answers from different instances of
a zone to be validated.
It is this indeterminism that allows BIND to incrementally sign zones when
introducing new DNSKEY algorithms.
Supporting pre-publishing RRSIGs just complicates code for no good reason
so it is not supported.
Mark
> On 31 Aug 2021, at 10:39, Michael Sinatra wrote:
>
> Hi,
>
> I have, in the past, used the "conservative" approach to performing algorithm
> rollovers for various domains. For many domains, this is probably overkill,
> but I'd prefer to have the option of doing it, especially for those
> mission-critical domains where you really don't want to rely simply on the
> hope that nobody who needs to reach you (or your org/company) is using a
> resolver that is still following the strictest interpretation of RFC 4035,
> section 2.2.
>
> In the past, I have handled this completely manually, signing the zone using
> dnssec-signzone to sign the zone with keys of both algs before (again
> manually) including the the new alg keys in the DNSKEY RRSET. But for zones
> which I am inline-signing as a provider for someone else, I would like to use
> a more automated method. It doesn't appear that BIND currently supports
> this, either with dnssec-keymgr and 'inline-signing' or with KASP.
>
> I did try the trick of setting the key metadata manually ('publish' in the
> future and 'activate' in the past), but BIND 'inline-signing' would not sign
> the zone prior with the key prior to its publication, despite my timing
> metadata settings.
>
> So I am assuming that only the "liberal" approach is supported. One thing I
> thought of was trying a "moderate" approach, where the various TTLs are
> manipulated so that the zone RRSIGs expire quickly before the new alg is
> added and then flipping it so that the DNSKEY RRSET expires quickly and the
> zone/RRSIG TTLs stay in cache longer. But that is still a fairly tricky
> approach and I am not sure it would work...
>
> michael
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: KSK signing zone records
I honestly don’t remember the reasoning, only the outcome. Maybe Mark or someone else from ISC can shed some light? I couldn’t find the answer to this regular (but infrequent) question in the ISC KB. Regards, Chris Buxton > On Aug 30, 2021, at 3:40 PM, raf via bind-users > wrote: > > On Mon, Aug 30, 2021 at 10:13:05AM -0700, Chris Buxton > wrote: > >> What algorithm(s) are you using for ZSK and KSK? If they’re not the >> same algorithm, then both will be used to sign the entire zone. >> >> Regards, >> Chris Buxton > > Just out of curiosity, why is that? > Isn't having the KSK sign the ZSK enough? > What difference does the nature of the thing > being signed make? > > cheers, > raf > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users signature.asc Description: Message signed with OpenPGP ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: KSK signing zone records
The rules for what get signed by what are per algorithm. Additionally the SEP bit is hint to the signer as to what is desired. Named has controls to say whether to pay attention to the SEP bit or not. Additionally it will override those controls to pay attention to the SEP but if it believes that the zone won’t be correctly signed if it paid attention to the SEP bit. People have created zones where one algorithm has keys with and without the SEP bit for one algorithm but for a second algorithm there are only keys with (without) the SEP bit. If the signer has been told to honour the SEP bit then for the first algorithm it will be honoured and for the second algorithm the instruction will be overridden. See dnssec-dnskey-kskonly, update-check-ksk and the keys sub-clause of dnssec-policy. > On 31 Aug 2021, at 13:54, Chris Buxton wrote: > > I honestly don’t remember the reasoning, only the outcome. Maybe Mark or > someone else from ISC can shed some light? I couldn’t find the answer to this > regular (but infrequent) question in the ISC KB. > > Regards, > Chris Buxton > >> On Aug 30, 2021, at 3:40 PM, raf via bind-users >> wrote: >> >> On Mon, Aug 30, 2021 at 10:13:05AM -0700, Chris Buxton >> wrote: >> >>> What algorithm(s) are you using for ZSK and KSK? If they’re not the >>> same algorithm, then both will be used to sign the entire zone. >>> >>> Regards, >>> Chris Buxton >> >> Just out of curiosity, why is that? >> Isn't having the KSK sign the ZSK enough? >> What difference does the nature of the thing >> being signed make? >> >> cheers, >> raf >> >> ___ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> >> ISC funds the development of this software with paid support subscriptions. >> Contact us at https://www.isc.org/contact/ for more information. >> >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
