Hi colleagues,
There is an issues spotted when we use Yeti resolver(BIND 9.10.4-p2) during Yeti KSK rollover. The resolver is deployed in BII’s 6Plat network which help IPv4 users connect to IPv6 using tunnels. The resolver is configured with different views. Bugs are reported once we added new views for new users after KsK rolling (In Yeti KSK rollover plan, once new key become active the old key is set revoked).
We found that the new views’ mkeys files only contains the old key which is inherited from the managed-keys in global setting (named.conf). But it is not inherited from the managed keys database where is ideal to be inherited in RFC5011 context. That’s why DNSSEC is failed in new views because old key was revoked. I check the manual for 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, it cannot set managed-key. Later we try to set the managed-keys for new views, it works.
So we have some observations and preliminary suggestions :
1) Currently BIND multiple-view operation needs extra guidance for RFC5011. Otherwise it may have problems.
2) The manage-keys should be set for each view when the it is ceated. Especially for RFC5011, it is a MUST requirement .
3) It is recommended that in BIND implementation the new views should inherit the managed-keys from managed keys database of a existing view. It is more natural way for Multiple-view model to adapted to RFC5011. It much preferable to have a global managed keys database which follows the RFC5011’s life circle.
Davey
发件人: dbgong [mailto:dbgong@biigroup.cn]
发送时间: 2016年9月26日 16:52
收件人: ShaneKerr; Davey Song
抄送: yeti_maintain
主题: Yeti KSK rollover: resolver BIND9 issue
重要性: 高
Hi Davey and Shane,
One of our recursive server(REC1, BIND9) have problems after the revoke action.
Before the revoke action REC1 have three views.
the configuration of REC1:
options {
#...
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside no;
};
view secondfloor {#xxx};
view yyy {};
view zzz {};
managed-keys {
. initial-key 257 3 8 "AwEAAaP3gGQ4db0tAiDEky0dcUNGeI1aTDYP5NFxzhbd pD60ZhKLVV4KyxPmoSNUpq5Fv5M0iBwK1Tyswsyq/9sM SoZ8zx8aT3ho1YnPsSqQeJfjTT1WsX6YZ5Kw6B2QkjRN a6OMGZ96Kn8AI/slqsw+z8hY49Sn3baeo9iJxHPzloNc 2dQkW4aLqzNEYxnuoJsthCfGrPSAXlUjY9m3YKIaEWR5 WFYQk770fT+gGWLk/54Vp0sG+Lw75JZnwhDhixPFaToT DNqbHQmkEylq1XJLO15uZ/+RZNRfTXZKO4fVR0tMEbMAITqRmyP8xLXY4RXbS4J32gnenQbzABX8sQmwO7s=";
};
REC1 works well after the revoke action.
But when we add another three views at 2016-09-12.
There are some servfails, about 3-5/qps.
Then I checked the managed-keys, and I found that the new added view which don't have valid managed-keys.
And the view created be for KSK rollover have valid managed-keys.
eg, 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
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
There are no trust anchor for view 6plat.
And try dig with '+dnssec' from client which is in view 6plat.
I got the answer , but no AD flag.
at 2016-09-22, some users in view 6plat report that they can't resolve domain name.
then I try dig with CD option, then got answers, but without CD option, got SERVFAIL.
and i checked dnssec log of BIND9.
I found some failure log:
22-Sep-2016 10:25:18.149 dnssec: debug 3: validating com/DS: starting
22-Sep-2016 10:25:18.150 dnssec: debug 3: validating com/DS: attempting positive response validation
22-Sep-2016 10:25:18.150 dnssec: info: validating com/DS: no valid signature found
22-Sep-2016 10:25:18.150 dnssec: debug 3: validating com/DS: falling back to insecurity proof
22-Sep-2016 10:25:18.150 dnssec: debug 3: validating com/DS: checking existence of DS at 'com'
22-Sep-2016 10:25:18.150 dnssec: debug 3: validating com/DS: continuing validation would lead to deadlock: aborting validation
22-Sep-2016 10:25:18.150 dnssec: debug 3: validating com/DS: deadlock found (create_fetch)
2-Sep-2016 10:25:18.833 dnssec: debug 3: validating ./NS: starting
22-Sep-2016 10:25:18.833 dnssec: debug 3: validating ./NS: attempting positive response validation
22-Sep-2016 10:25:18.833 dnssec: info: validating ./NS: no valid signature found
22-Sep-2016 10:25:18.833 dnssec: debug 3: validating ./NS: falling back to insecurity proof
22-Sep-2016 10:25:18.833 dnssec: debug 3: validating ./NS: insecurity proof failed
22-Sep-2016 10:25:22.996 dnssec: debug 3: validating cn/DS: starting
22-Sep-2016 10:25:22.996 dnssec: debug 3: validating cn/DS: attempting positive response validation
22-Sep-2016 10:25:22.996 dnssec: info: validating cn/DS: no valid signature found
22-Sep-2016 10:25:22.996 dnssec: debug 3: validating cn/DS: falling back to insecurity proof
22-Sep-2016 10:25:22.996 dnssec: debug 3: validating cn/DS: checking existence of DS at 'cn'
22-Sep-2016 10:25:22.996 dnssec: debug 3: validating cn/DS: continuing validation would lead to deadlock: aborting validation
22-Sep-2016 10:25:22.996 dnssec: debug 3: validating cn/DS: deadlock found (create_fetch)
What do you think about this behavior? BIND9 bug? or because of wrong configuration of BIND9?
Regards,
---
Kevin