First Algorithm Rollover in lab environment

ECDSA and Algorithm rollover is listed in current agenda of Yeti experiment. ECC(Elliptic Curve Cryptography) is widely considered as a promising DNSSEC algorithm after RSA due to its property: ECC has much smaller keys and signatures with equivalent or better key strength. ECDSA P-256 and P-384 are standardized for use in DNSSEC in RFC 6605 (2012).

However, There are some uncertainties of ECC for DNSSEC. The major one is the uncertainty of impact of resolvers’ switching to ECC. ECC readiness of resolvers (due to Large installed base) and rollover to ECC are uncertain. There are some experience of algorithm rollover in second level domain and TLD level. RIPE NCC suggest to roll both ZSK and KSK (2015) and .SE Algo Roll experiment shown that liberal approach is widely acceptable (only 6 out of 10,000 fail). However, there is little experience for algorithm rollover in root level, the automated Algorithm rollover for trust anchors compliant to RFC5011.

Before proposed and tested in Yeti Root, Davey and Kevin built a lab testbed in BII lab which is introduce in a document in Yeti’s GitHub repo. The idea is to test potential rollover approaches as many as possible: 1) Conservative Vs. liberal approaches; 2)rolling KSK without ZSK Vs. rolling KSK&ZSK at the same time.Accordingly, we setup 4 tests with 4 root servers, with different rolling approaches and time lines:

  • Test 1: Republish KSK without signature as we rolled the key (like ICANN KSK rollover).
  • Test 2: Similar with Test 1 but republish KSK and its signature without rolling ZSK;
  • Test 3: Roll both ZSK and KSK in liberal approach;
  • Test 4: Roll both ZSk and KSK in conservative approach.

Test 1 is expected to fail because it is designed with intentional violation of RFC6781 with requires Key and signature should be published at the same time in zone or in zone & cache; Test 2 is a fix to Test 1 but it is uncertain because only KSK is rolled. Test 3 and Test 4 is expected to pass because it is compliant to RFC6781 with liberal and conservative respectively.

The finding is interesting and surprised that four approaches proceeded successfully for BIND (9.11.5-P1) and UNBOUND(1.8.3) resolver. Maybe the samples of resolver is too limited. It is proposed to call for more resolvers to join. It is worth mentioning that in test 2,3 and 4 there is an accidental mistake in configuring the ZSK’s inactive time which results no active signing key in the middle of the rollover and causes validation failure(we recovered it with a new ZSK but it still had impact on resolver). As a response to this failure, it is observed BIND restarts the Add Hold-Down Time of new key/algorithm for another 30 days when new valid signing key is available but Unbound continue the timer and trusted the KSK/Algorithm after the rfc5011-timer expired. It is inferred that BIND treat the failure as a signal to quite the existing rfc5011 timer, but UNBOUND treat it as a un-rfc5011 signal(like network failure). UNBOUND stops the timer and continues it after failure resolved.

Note the first Algo roll test was presented in Yeti DNS Workshop last March, the slides are here.

Second Algorithm Rollover and How to join

The Second Algorithm rollover in lab test is planned in this April. We are going to outreach more interested people and call for participation. Participants are invited to join part of tests or all of them(Test 1,2,3,4). The timeline and schedule will follow the document in Yeti’s GitHub repo as the first rollover.

Participates joining the test are required to configured their resolvers manually with a new Hint file (containing name and address of testing roots) and Trust anchor (initial RSA KSK ). The timeline and more detailed information will be delivered to Yeti discuss mailing list.

If you are reading this article and interested to contribute by participating this test, please send mail to You will be kept post during the experiment and receive immediate reply if you have any questions.