[Yeti DNS Discuss] 答复: FW: Yeti KSK rollover: resolver BIND9 issue

Davey Song(宋林健) ljsong at biigroup.cn
Fri Oct 14 01:13:46 UTC 2016


I report it to Bind support team.  Only one response from Mark, not viewing
this as a problem.

 

Davey

发件人: discuss [mailto:discuss-bounces at lists.yeti-dns.org] 代表 Davey
Song(宋林健)
发送时间: 2016年9月27日 19:25
收件人: discuss at lists.yeti-dns.org; bind-bugs at isc.org
主题: [Yeti DNS Discuss] FW: Yeti KSK rollover: resolver BIND9 issue
重要性: 高

 

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 at 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/+RZNRfTXZKO4fVR0tMEbMAITqRmyP8xLXY4RXbS4J32gnenQbzABX8
sQmwO7s="; 

};

 

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yeti-dns.org/pipermail/discuss/attachments/20161014/98183bfe/attachment.html>


More information about the discuss mailing list