On 21 Nov 2020, at 17:40, Nils Trampel <nils(a)trampel.org> wrote: Hello, as I plan to migrate an existing DNS setup to Knot, not only for deploying DNSSEC but also for synthesizing some records using mod-synthrecord, I am not sure as how to setup online signing when having multiple public authoritative name servers. My uncertainty is, if it is necessary to give them the same ZSKs and do the key rollover from the outside, or if the chain of trust isn't severed when they generate their own ZSKs based from a common KSK or even their distinct KSKs, and therefore provide different signatures. Best regards and thanks, Nils -- Nils Trampel GPG: 0x012BADD8 -- https://lists.nic.cz/mailman/listinfo/knot-dns-users

Hello Ulrich, thanks for your remarks. So if I understand it correctly, you have to have the same resource record set of ZSKs (the public parts of the keys) on all authoritative's with the signature from the KSK, maybe in an offline fashion, but the servers can use a key which private part is only known to them. Is there a special place on the public side where to store both KSKs and ZSKs with the signature of it by the KSK, or should this simply be put in the zone file which knot uses to serve the rest of the zone? Best regards Nils On 24.11.20 14:55, Ulrich Wisser wrote: > Hi Nils, > > Multi-signer setups are not trivial, in-fact that is the cutting edge of DNSSEC right now. > Please have a look at Shumons excellent RFC https://tools.ietf.org/html/rfc8901 <https://tools.ietf.org/html/rfc8901> for exactly that use-case. > > In-short: > - Same algorithm on all instances > - You absolutely need to synchronize ZSK between instances > - KSK can be shared or separate > > My recommendation would be to use ECDSA and not bother with the ask roll overs. > Same ZSK on all instances. Depending on your security requirements I would > consider offline KSK. > > /Ulrich > > >> On 21 Nov 2020, at 17:40, Nils Trampel &lt;nils(a)trampel.org&gt; wrote: >> >> Hello, >> >> as I plan to migrate an existing DNS setup to Knot, not only for deploying DNSSEC but also for synthesizing some records using mod-synthrecord, I am not sure as how to setup online signing when having multiple public authoritative name servers. My uncertainty is, if it is necessary to give them the same ZSKs and do the key rollover from the outside, or if the chain of trust isn't severed when they generate their own ZSKs based from a common KSK or even their distinct KSKs, and therefore provide different signatures. >> >> Best regards and thanks, >> >> Nils >> >> -- >> Nils Trampel >> GPG: 0x012BADD8 >> -- >> https://lists.nic.cz/mailman/listinfo/knot-dns-users >

Thanks Libor! That is good input. Although I believe the offline KSK is a good way to secure your KSK if you use online ZSK signing. Nils, yes you understood correctly. Every name server has to have a full list of ZSK and sign it with its KSK. Every name server publishes the DNSKEY set in the zone it’s serving. The keyset contains the KSK used by the server and the full ZSK list. Attention! This prevents you from using automatic key rollovers. All key management must be manual. /Ulrich > On 30 Nov 2020, at 09:32, libor.peltan &lt;libor.peltan(a)nic.cz&gt; wrote: > > Gentlemen, > > this brainstorming is inspirative, but please keep the feet on the ground. > > Before designing any such deployment, experiments must forego to verify its viability. > > I'm not sure if Onlinesign works with Offline KSK. I've never thought about that. > > BR, > > Libor > > Dne 29. 11. 20 v 23:11 Nils Trampel napsal(a): >> Hello Ulrich, >> >> thanks for your remarks. So if I understand it correctly, you have to have the same resource record set of ZSKs (the public parts of the keys) on all authoritative's with the signature from the KSK, maybe in an offline fashion, but the servers can use a key which private part is only known to them. Is there a special place on the public side where to store both KSKs and ZSKs with the signature of it by the KSK, or should this simply be put in the zone file which knot uses to serve the rest of the zone? >> >> Best regards >> >> Nils >> >> On 24.11.20 14:55, Ulrich Wisser wrote: >>> Hi Nils, >>> >>> Multi-signer setups are not trivial, in-fact that is the cutting edge of DNSSEC right now. >>> Please have a look at Shumons excellent RFC https://tools.ietf.org/html/rfc8901 <https://tools.ietf.org/html/rfc8901> for exactly that use-case. >>> >>> In-short: >>> - Same algorithm on all instances >>> - You absolutely need to synchronize ZSK between instances >>> - KSK can be shared or separate >>> >>> My recommendation would be to use ECDSA and not bother with the ask roll overs. >>> Same ZSK on all instances. Depending on your security requirements I would >>> consider offline KSK. >>> >>> /Ulrich >>> >>> >>>> On 21 Nov 2020, at 17:40, Nils Trampel &lt;nils(a)trampel.org&gt; wrote: >>>> >>>> Hello, >>>> >>>> as I plan to migrate an existing DNS setup to Knot, not only for deploying DNSSEC but also for synthesizing some records using mod-synthrecord, I am not sure as how to setup online signing when having multiple public authoritative name servers. My uncertainty is, if it is necessary to give them the same ZSKs and do the key rollover from the outside, or if the chain of trust isn't severed when they generate their own ZSKs based from a common KSK or even their distinct KSKs, and therefore provide different signatures. >>>> >>>> Best regards and thanks, >>>> >>>> Nils >>>> >>>> -- >>>> Nils Trampel >>>> GPG: 0x012BADD8 >>>> -- >>>> https://lists.nic.cz/mailman/listinfo/knot-dns-users

libor.peltan> ...and (if I understand this idea correctly) since every libor.peltan> server would have different KSK, you would need multiple libor.peltan> DS in the parent zone (the parent must allow it). This has to be allowed or you can't roll the KSK yourself.

libor.peltan> ...and (if I understand this idea correctly) since every libor.peltan> server would have different KSK, you would need multiple libor.peltan> DS in the parent zone (the parent must allow it). ebersman> This has to be allowed or you can't roll the KSK yourself. tis> You only need one DS record at time for that. You replace old DS tis> with new one when you do roll over. You need to have both there with overlap time to allow for caches to expire old DS and put in new DS or there is risk of validation failure. This is especially important with DS, since many registries/registrars have 48 hour TTLs for DS but only 24 hour or less for NS.