Background

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 [1]. 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.

Some thoughts

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.

Reference

[1] Yeti KSK Rollover Plan, https://github.com/BII-Lab/Yeti-Project/blob/master/doc/Experiment-KROLL.md

[2] 2017 KSK Rollover Operational Implementation Plan, https://www.icann.org/en/system/files/files/ksk-rollover-operational-implementation-plan-22jul16-en.pdf