[Pdns-users] Migrate from zsk/ksk/rsa to csk/ecdsa

Nicola Tiling nti at w4w.net
Thu Aug 2 13:38:01 UTC 2018

Hi Oli

Thanks a lot for your answer. Unfortunately there is no documentation for an algorithm rollover in pdns documentation and it is hard to find something about it with google...

But in RFC 6781 a "Single-Type Signing Scheme Algorithm Rollover“ is described. It says RRSIG and DNSKEY have to be published and removed separately.
But how can I produce separat publishing and removing with pdnsutil?

With a TTL of 1h for the zone.tld and TTL 1d on the .tld zone:

     1. pdnsutil add-zone-key zone.tld ksk active 256 ECDSAP256SHA256
     2. pdnsutil rectify-zone zone.tld
     3. pdnsutil increase-serial zone.tld

Then - should I wait >1h before publishing it to the TLD registrar - or should it be published immediately?

(?)  4. WAIT >1h for publishing zone to TLD registrar (check slaves and also and for new RRSIG is shown)
     6. WAIT that zone is double signed with old KSK/ZSK and new CSK - check with dnsviz

And then ? Deactivate or remove old zone key-id at that point?
Is a deactivation step necessary? Or how can I remove old DNSKEY before old RRSIG as postulated in RFC6781?

(?)  7. pdnsutil deactivate-zone-key zone.tld OLD-ID-ZSK
(?)  8. pdnsutil deactivate-zone-key zone.tld OLD-ID-KSK
(?)  9. pdnsutil rectify-zone zone.tld
(?) 10. pdnsutil increase-serial zone.tld
(?) 11. WAIT >1d for TTL of .tld zone

    12. pdnsutil remove-zone-key zone.tld OLD-ID-ZSK
    13. pdnsutil remove-zone-key zone.tld OLD-ID-KSK
    14. pdnsutil rectify-zone zone.tld
    15. pdnsutil increase-serial zone.tld (check slaves that all is correct and in sync)


Kind regards

From RFC 6781:
==============  Single-Type Signing Scheme Algorithm Rollover
   If one key is used that acts as both ZSK and KSK, the same scheme and
   figure as above (Figure 8 in Section 4.1.4) applies, whereby all
   DNSKEY_Z_* records from the table are removed and all RRSIG_Z_* are
   replaced with RRSIG_S_*.  All DNSKEY_K_* records are replaced with
   DNSKEY_S_*, and all RRSIG_K_* records are replaced with RRSIG_S_*.
   The requirement to sign with both algorithms and make sure that old
   RRSIGs have the opportunity to expire from distant caches before
   introducing the new algorithm in the DNSKEY RRset is still valid.

   This is shown in Figure 12 in
Appendix C.
Appendix C.  Transition Figures for Special Cases of Algorithm Rollovers

   The figures in this appendix complement and illustrate the special
   cases of algorithm rollovers as described in
Section 4.1.4

    initial              new RRSIGs           new DNSKEY
    SOA_0 -------------------------------------------------------->
    RRSIG_par(SOA) ----------------------------------------------->
    DS_S_1 ------------------------------------------------------->
    RRSIG_par(DS_S_1) -------------------------------------------->

    SOA_0                SOA_1                SOA_2
    RRSIG_S_1(SOA)       RRSIG_S_1(SOA)       RRSIG_S_1(SOA)
                         RRSIG_S_2(SOA)       RRSIG_S_2(SOA)

    DNSKEY_S_1           DNSKEY_S_1           DNSKEY_S_1
                         RRSIG_S_2(DNSKEY)    RRSIG_S_2(DNSKEY)

    new DS               DNSKEY removal       RRSIGs removal
    SOA_1 ------------------------------------------------------->
    RRSIG_par(SOA) ---------------------------------------------->
    DS_S_2 ------------------------------------------------------>
    RRSIG_par(DS_S_2) ------------------------------------------->

    -------------------> SOA_3                SOA_4
    -------------------> RRSIG_S_1(SOA)
    -------------------> RRSIG_S_2(SOA)       RRSIG_S_2(SOA)

    -------------------> DNSKEY_S_2           DNSKEY_S_2
    -------------------> RRSIG_S_1(DNSKEY)
    -------------------> RRSIG_S_2(DNSKEY)    RRSIG_S_2(DNSKEY)

           Figure 12: Single-Type Signing Scheme Algorithm Roll

   Also see

> Am 02.08.2018 um 08:08 schrieb Oli Schacher <oli.schacher at switch.ch>:
> On 29.07.18 17:12, Nicola Tiling wrote:
>> "Publish the CDS records: pdnsutil set-publish-cds example.com, these records will tell the parent zone to update its DS records. Now wait for the DS records to be updated in the parent zone."
> For CDS/CDNSKEY rollovers the parent zone has to support RFC8078 (
> https://tools.ietf.org/html/rfc8078 ) . Currently, .cz is the the only
> TLD supporting this mechanism. Other TLDs working on it. To add/update
> DS records for a domain in the .net zone you'll have to update it
> manually through your registrar's interface.
>> If I publish the DS keys for a .net domain, will there be two DS hashes in the .net root zone after the TTL from 86400 runs off? And after that  I can switch active/inactive keys? Or should the DS be immediately be found on a.gtld-servers.net? Or what should happen?
> After adding the new DS it will eventually be published(I don't know how
> often .net is reloaded) and both DS records will be visible after DS TTL
> has expired.
> Best regards
> Oli
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20180802/c6c9bcf2/attachment.sig>

More information about the Pdns-users mailing list