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-signing 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

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@ku.th or Pirawat.W@ku.ac.th

   _/_/  _/_/     _/_/       _/_/ Tel: +66 2 797 0999 extension 1417

  _/_/    _/_/    _/_/_/_/_/_/ Fax: +66 2 579 6245

_/_/      _/_/      _/_/_/_/    http://www.cpe.ku.ac.th/~pw/