Hi Pirawat,
thanks for your question :)
First of all, the signing routines, algorithms and DNSSEC configuration
only relate to your signer. All the secondaries (including your "primary
server") are supposed to work the same in any case (being they Knot or
not), treating the DNSSEC-related records as other records in the zone.
Secondly, the idea of separated "signed trees" is not viable in DNS. The
DNSKEY RRSet shall, in the end, contain all the public keys from both
algorithms, and this RRSet, as a whole, must be signed by each algorithm
used. In short, "cross-signing" the keys is a must in DNS.
Please note, that in DNSSEC, any change in keys must be performed in
several steps and with carefully measured delays between them. This is
because some of the secondaries might fall behind the others, and mostly
because the resolvers might keep otherwise unmatching DNSKEYs and RRSIGs
in their caches. For this reason, Knot DNS implements Automatic key
management feature (see e.g.
https://www.knot-dns.cz/docs/3.1/singlehtml/index.html#automatic-dnssec-sig…
and other parts of the doc), which is able to roll ZSKs and KSKs
automatically, while taking care of all the roll-over steps.
It is also able to roll the algorithms automatically, which includes
briefly using them simultaneously for some short time, and removing the
old one when finished. The background can be read here:
https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.4
Unfortunately, Knot DNS doesn't support permanent usage of two
algorithms in parallel with Automatic key management. My personal
opinion is that this setup would not be very useful. The obvious
drawback is the resulting size of signed zone and size of the answers,
which however might not be cruical in case of a small and sparsely
queried zone. Another quirk is that the resulting security is
potentially as weak as the weakest algorithm used. In current practice,
it tends to be recommended for general usage to just use ECDSA, which
has the best balance of supportedness, signature size and crypto
strength. While many important zones use it for some time already, the
number of unsupporting resolvers ought to be negligible.
However, if we are here to learn something, there are ways to achieve
this anyway. Any DNSSEC setup can be arranged by configuring the Manual
key management
https://www.knot-dns.cz/docs/3.1/singlehtml/index.html#manual (while
benefiting from Automatic DNSSEC signing) and carefully setting the up
the keys with Knot's Keymgr utility
https://www.knot-dns.cz/docs/3.1/singlehtml/index.html#document-man_keymgr
. That way you can set up all the keys you need, while loosing the
benefit of their automatic roll-over when they reach their lifetime.
They would need to be rolled manually by setting their so-called Timers.
Anyway, if you already use one of the algorithms for signing, then in
order to introduce the second one, you should in theory still perform a
part of the roll-over in RFC6781 style, that means, introducing the
signatures first (by setting the keys' Active timers to "now" and
Publish timers (propagation-delay + zone max TTL) later. However, in
this particular case, it's 99% not necessary.
Another, more tricky but easier way to achieve this setup is to actually
let Knot start the algorithm roll-over (by configuring Automatic key
management and setting the new algorithm in Policy), and in the exact
state when both are used, switch the key management to Manual. This
should leave you in the desired state. By the way, this trick can't be
used to add third algorithm ;)
I hope I helped you with some info. Please let me know what you do in
the end!
Cheers,
Libor
Dne 14. 10. 21 v 8:45 Pirawat WATANAPONGSE napsal(a):
Dear Guru(s),
If the following questions have already been asked, I do apologize and
would very much appreciate the pointers to where I can read the answer(s).
I am currently ‘running’ a DNSsec-signed zone using Alg-8 [RSA/SHA2-256].
However, I would very much like to DNSsec-sign and publish my zone
with two different algorithms (say, Alg-8 [RSA/SHA2-256] + Alg-13
[ECDSA-P256/SHA2-256]) *simultaneously*,
in case the client-validators out there cannot process one algorithm
or the other (never mind that they both are the ‘MUST’ in RFC 8624).
It also is an opportunity to train myself in case I need to ‘add’ the
third one (say, Alg-15 [ED25519]) or ‘migrate’ to the Alg-13 + Alg-15
combination in the future.
Background Information:
1. I have a ‘hidden server’ acting as ‘The Signer’.
2. ‘The Signer’ feeds the already-signed zone to the visible ‘Primary
Server’.
3. The ‘Primary Server’, in turn, feeds all other ‘Secondary Servers’,
some of which are not under my control.
4. Unfortunately, currently none of the above servers is a Knot, but I
am switching The Signer to Knot.
My questions are:
5. What will be the correct configuration for The Knot Signer? I don’t
mind maintaining two completely separated ‘Signed Trees’ of the same
zone, unless cross-signing (the keys) between algorithms is the best
practice.
6. Will there be any special configuration for the ‘Primary/Secondary
Servers’? If so, I will then need to inform admins of the servers
outside my control.
Thank you for any help you can offer, both on and off the mailing list.
Gratefully,
Pirawat.
--
_/_/ _/_/ _/_/ _/_/ Assist.Prof. Pirawat
WATANAPONGSE, Ph.D.
_/_/ _/_/ _/_/ _/_/ Department of Computer Engineering
_/_/ _/_/ _/_/ _/_/ Kasetsart University, Bangkhen
(Main) Campus
_/_/_/_/ _/_/ _/_/ Bangkok 10900, THAILAND
_/_/_/_/ _/_/ _/_/ eMail: Pirawat.W(a)ku.th
<mailto:Pirawat.W@ku.th> or Pirawat.W(a)ku.ac.th <mailto:Pirawat.W@ku.ac.th>
_/_/ _/_/ _/_/ _/_/ Tel: +66 2 797 0999 extension 1417
_/_/ _/_/ _/_/_/_/_/_/ Fax: +66 2 579 6245
_/_/ _/_/ _/_/_/_/
http://www.cpe.ku.ac.th/~pw/
<http://www.cpe.ku.ac.th/~pw/>