KSK rollover is one of Yeti experiments on Yeti DNS Root testbed. The purpose is to test the KSK rollover in large scale and to find any potential risks before the real KSK rollover to be performed in production network in future. The proposal of Yeti first KSK rollover experiment is documented in one GitHub page . The first rollover happened at the time stamp 20160830073746 (Tue Aug 30 07:37:46 2016 UTC). In the same while the old KSK was revoked, and removed after 30 days.
##DNSSEC Bug report
There is an issue spotted on one Yeti resolver (using BIND 9.10.4-p2) during Yeti KSK rollover.The resolver is configured with multiple views before the KSK rollover. DNSSEC failures are reported once we added new view for new users after rolling the key. (In Yeti KSK rollover plan, once new key become active the old key is revoked).
When we view secondfloor which is created before the KSK rollover.
$echo -n secondfloor|sha256sum b1629b86416e2208ce2492ea462475f77141a2c785e53d8cd64dbf9dabe9f01f - $ cat b1629b86416e2208ce2492ea462475f77141a2c785e53d8cd64dbf9dabe9f01f.mkeys $ORIGIN . $TTL 0 ; 0 seconds @ IN SOA . . ( 6490 ; serial 0 ; refresh (0 seconds) 0 ; retry (0 seconds) 0 ; expire (0 seconds) 0 ; minimum (0 seconds) ) KEYDATA 20160926180107 20150929074902 20160930050105 385 3 8 ( AwEAAaP3gGQ4db0tAiDEky0dcUNGeI1aTDYP5NFxzhbd pD60ZhKLVV4KyxPmoSNUpq5Fv5M0iBwK1Tyswsyq/9sM SoZ8zx8aT3ho1YnPsSqQeJfjTT1WsX6YZ5Kw6B2QkjRN a6OMGZ96Kn8AI/slqsw+z8hY49Sn3baeo9iJxHPzloNc 2dQkW4aLqzNEYxnuoJsthCfGrPSAXlUjY9m3YKIaEWR5 WFYQk770fT+gGWLk/54Vp0sG+Lw75JZnwhDhixPFaToT DNqbHQmkEylq1XJLO15uZ/+RZNRfTXZKO4fVR0tMEbMA ITqRmyP8xLXY4RXbS4J32gnenQbzABX8sQmwO7s= ) ; revoked KSK; alg = RSASHA256; key id = 56082 ; next refresh: Mon, 26 Sep 2016 18:01:07 GMT ; trusted since: Tue, 29 Sep 2015 07:49:02 GMT ; removal pending: Fri, 30 Sep 2016 05:01:05 GMT KEYDATA 20160926180107 20160809184103 19700101000000 257 3 8 ( AwEAAbA0lBT1aDxwoNl7d/fXqFFBtL+VwBLqgOYHgAqr nvhRvHs+GrTWZZ5gZu/0NeX4YGXmovT1nGpY/9oi30pD vbzPluQXOKSVP/xr1KyLPp8pxiVqGe973F55fX4iQOUM B2n2VXfIxSryTNYPz44Zltpa10WAVYzHpy3oxx0qZSeD sdPHMNB7Ym0hBMY92cifWyQWifHbcgbFGf2mpwF00vAL l92qhnvIORVZC/ihNNd7DvQtMLdUvSoQ0woC/EhqexXQ v0bLlPkG55d37JoaVbWCEnWLZ+CT+Eei5U4VCqH+xCEv OjT45ZQt0kfB3K4bwfh6D5EBleJ13z3pbUwBy0U= ) ; KSK; alg = RSASHA256; key id = 19444 ; next refresh: Mon, 26 Sep 2016 18:01:07 GMT ; trusted since: Tue, 09 Aug 2016 18:41:03 GMT
When we view 6plat which is created after the KSK rollover.
$ echo -n 6plat|sha256sum 1369c5fe9c97ce67fa0a4b3f25e6ceb86105045569eac55db54a6e85353d030b - $ cat 1369c5fe9c97ce67fa0a4b3f25e6ceb86105045569eac55db54a6e85353d030b.mkeys $ORIGIN . $TTL 0 ; 0 seconds @ IN SOA . . ( 4 ; serial 0 ; refresh (0 seconds) 0 ; retry (0 seconds) 0 ; expire (0 seconds) 0 ; minimum (0 seconds) ) KEYDATA 20160924170104 19700101000000 19700101000000 257 3 8 ( AwEAAaP3gGQ4db0tAiDEky0dcUNGeI1aTDYP5NFxzhbd pD60ZhKLVV4KyxPmoSNUpq5Fv5M0iBwK1Tyswsyq/9sM SoZ8zx8aT3ho1YnPsSqQeJfjTT1WsX6YZ5Kw6B2QkjRN a6OMGZ96Kn8AI/slqsw+z8hY49Sn3baeo9iJxHPzloNc 2dQkW4aLqzNEYxnuoJsthCfGrPSAXlUjY9m3YKIaEWR5 WFYQk770fT+gGWLk/54Vp0sG+Lw75JZnwhDhixPFaToT DNqbHQmkEylq1XJLO15uZ/+RZNRfTXZKO4fVR0tMEbMA ITqRmyP8xLXY4RXbS4J32gnenQbzABX8sQmwO7s= ) ; KSK; alg = RSASHA256; key id = 55954 ; next refresh: Sat, 24 Sep 2016 17:01:04 GMT ; no trust
It is found that mkeys file of the new view (6plat) only contains the old key which is inherited from the managed-keys (tag 56082) in global setting (named.conf). But it is not inherited the new key (tag 19444 )from the managed keys database which is valid for KSK operation in RFC5011 context. That is why DNSSEC is failed in new view because old key was inactive and revoked.
However, by checking the manual of BIND9.10.4-P2, it is said that unlike trusted-keys, managed-keys may only be set at the top level of named.conf, not within a view. It gives an assumption that for each view, managed-key can not be set per view in BIND. But right after setting the managed-keys of 6plat, the DNSSEC validation works for this view.
There are two preliminary suggestions for BIND users and developer.
1) Currently BIND multiple-view operation needs extra guidance for RFC5011. Right now ICANN decided to roll the KSK in 2017-10-112. The manage-keys should be set carefully during the KSK rollover for each view when the it is created.
2) It is recommended that in BIND implementation the new views should be operationally set to inherit the managed-keys from one managed keys database of a existing view. It is more natural way for Multiple-view model to adapted to RFC5011.
 Yeti KSK Rollover Plan, https://github.com/BII-Lab/Yeti-Project/blob/master/doc/Experiment-KROLL.md
 2017 KSK Rollover Operational Implementation Plan, https://www.icann.org/en/system/files/files/ksk-rollover-operational-implementation-plan-22jul16-en.pdf