[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 8.8.8.8 and 1.1.1.1 for new RRSIG is shown)
5. PUBLISH TO REGISTRAR
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)
16. PUBLISH TO REGISTRAR
Kind regards
Nicola
From RFC 6781:
==============
4.1.4.1. 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
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_S_1 ------------------------------------------------------->
RRSIG_par(DS_S_1) -------------------------------------------->
Child:
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
DNSKEY_S_2
RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY)
RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
----------------------------------------------------------------
new DS DNSKEY removal RRSIGs removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_S_2 ------------------------------------------------------>
RRSIG_par(DS_S_2) ------------------------------------------->
Child:
-------------------> 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
Section 4.1.4.1.
> 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