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

Sun Aug 5 11:25:56 UTC 2018

Hey Oli

Thanks a lot again for your excellent support!

> * Replace DS records through the registrar, meaning add the new DS and remove all old DS at the same time.

Maybe switch.ch has more possibilities. My domain provider only gives the option to „update" a domain. Then in the background he pulls all keys from my nameserver and deliver them to the registrar.  So my only possibility to have only one DS in the .tld zone and  "add the new DS and remove all old DS at the same time“, is to remove the old KSK.

I have tested this schema with .me and .info domains without trouble:

* Add new ECDSA CSK and double sign the domain
	1. pdnsutil add-zone-key zone.tld ksk active 256 ECDSAP256SHA256
    	  1.1 pdnsutil rectify-zone zone.tld
    	  1.2 pdnsutil increase-serial zone.tld
    	2. Wait that zone is double signed with old KSK/ZSK and new CSK
	  2.1 Check nameserver (google, cloudflare etc.) with dig and consultate dnssec-debugger and dnsviz webservice.
* Replace DS records - delete old KSK and publish new ECDSA CSK
    	3. pdnsutil remove-zone-key zone.tld OLD-ID-KSK
    	  3.1 pdnsutil rectify-zone zone.tld
    	  3.2 pdnsutil increase-serial zone.tld
	  3.3 check zone master and slaves all is correct and in sync
    	4. PUBLISH TO REGISTRAR
* Delete old ZSK
        5. Wait that only ECDSA DS is used by recursors
	  5.1 Check nameserver (google, cloudflare etc.) with dig and consultate dnssec-debugger and dnsviz webservice.
    	6. pdnsutil remove-zone-key zone.tld OLD-ID-ZSK
    	  6.1 pdnsutil rectify-zone zone.tld
    	  6.2 pdnsutil increase-serial zone.tld

What I’m noticed is that if I delete the old KSK (step 3.) the notation for the old ZSK switches automatically from „ZSK“ to „CSK“ but flag „256“ is keeping.
e.g.
ID = 36 (CSK), flags = 256, tag = 52266, algo = 8, bits = 1024    Active ( RSASHA256 )
Some people discuss this behavior here: https://github.com/PowerDNS/pdns/issues/5330

Best wishes
Nicola

> Am 03.08.2018 um 14:32 schrieb Oli Schacher <oli.schacher at switch.ch>:
> 
> On 02.08.18 15:38, Nicola Tiling wrote:
>> 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...
>> 
> 
> There are two ways to perform an algorithm rollover, called
> "conservative" and "liberal" due to  RFC4035 section 2.2:
> 
> "There MUST be an RRSIG for each RRset using at least one DNSKEY of
>   each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
>   itself MUST be signed by each algorithm appearing in the DS RRset
>   located at the delegating parent (if any)."
> 
> A conservative rollover  takes these requirements into account very
> strictly, so you'd have to introduce RRSIGS first before you can add the
> DNSKEY. AFAIK you can't do this with PowerDNS live signing.
> 
> Current validating resolvers however do not enforce these rules, which
> enables liberal rollovers. These are basically the same as normal double
> signature rollovers. Your zone should validate as long as there is
> always at least one working combination of DS->matching DNSKEY->matching
> RRSIGS. TLDs mostly performed conservative rollovers historically, but
> recently .SE rolled using the liberal approach with no issues [1]
> 
> Using the liberal rollover you can simplify the plan quite a bit:
> 
> * Add new (active) key/rectify/increase-serial, the zone is now signed
> with both the old and new keys ("double signature rollover")
> * Wait at least "the largest TTL in the Zone" ( to make sure the new
> key and its RRSIGS are propagated )
> * Replace DS records through the registrar, meaning add the new DS and
> remove all old DS at the same time. In your playbook you mention two
> interactions with the parent zone (step 5 and 16) but this is a double
> signature rollover, not a double DS rollover, so you only need to update
> once. Having both DS published at the same time could actually cause
> problems, for example if they have inconsistent digest types [2]
> * When the new DS is visible at the parent, wait at least DS TTL + a
> little longer to account for replication delays
> * At that point all resolvers should validate using the new DS/KEY, so
> you can remove the old KSK/ZSK, there is no need to deactivate it first
> 
> I have personally never performed an algorithm rollover and change from
> split key to combined signing keys at the same time. Its certainly a
> good idea to go through this procedure first with a test zone before you
> do it with anything important.
> 
> Best regards
> Oli
> 
> [1]
> https://www.sidnlabs.nl/a/weblog/keep-m-rolling-monitoring-ses-dnssec-algorithm-rollover
> [2]
> https://indico.dns-oarc.net/event/28/contributions/521/attachments/489/797/Crippling_DS.pdf
> 

-------------- 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/20180805/de538cd7/attachment.sig>