[Yeti DNS Discuss] 答复: Thoughts about the next Yeti KSK roll
ljsong at biigroup.cn
Sun Jan 22 09:16:13 UTC 2017
I think we can do what ICANN monitoring plan is going to do. Observe the traffic to capture "response size effects" and "stale key effects".
发件人: discuss [mailto:discuss-bounces at lists.yeti-dns.org] 代表 Shane Kerr
发送时间: 2017年1月18日 15:17
主题: [Yeti DNS Discuss] Thoughts about the next Yeti KSK roll
It's time to think about the next Yeti KSK roll!
Davey pointed out to me that the latest IANA KSK roll document does not have the "KSK publish with a twist" where the KSK is published, removed, and then added back in later with the revoked bit set. So there is no need to test this. This is good, because it was weird, but it also means that we need to figure out what exactly we do want to test.
Firstly, we can implement the attack-on-resolver DoS that Kees Monshouwer pointed out. The IANA root zone is not vulnerable to this, because of the timings, but it would still be interesting to test this in a live environment like Yeti. We should:
1. Make the Yeti signature validity periods the same as IANA. Right now we have a 30-day validity period but Verisign uses a 14-day validity period on the root.
2. Deliberately DoS a resolver we run in a lab by issuing a replay. We can build an "on the wire" tool to do this, which runs on the same machine. It will see the outgoing query then send the reply back with the old signatures. We should then observe the RFC 5011 hold-down timer get reset, and the machine fail after the KSK roll. (This requires Unbound, as BIND 9 does not use the hold-down timer.)
Secondly, we can look at exploring the "key tag" draft:
This provides a way to learn what trust anchors the validators have configured. It actually documents 2 different ways to do this:
1. Using a new EDNS option, or
2. Using a well-known, but normal, query.
The first method requires support from the validator, the second method might not necessarily.
We can do a number of things for this:
* Survey popular validators (both resolvers, forwarders, and stub resolvers) to see what the current and planned support is.
* See if vendors are willing to accept patches to implement one or both of these techniques and then implement them.
* Build an external utility to implement method #2 from the draft.
All of these can be done before the next KSK roll experiment, if the Yeti participants think it makes sense. Certainly if anyone wants to help that would be cool (maybe Kees wants to do that for PowerDNS, for example, since he has already done a lot of work on that software).
For the external utility, my idea is:
* Watch for DNSKEY packets going to the root.
* Look for the NULL query with "_ta-" to the root.
* If no NULL query appears in a short while (100 msec maybe?) then we can send it.
Once we have some of these tools in place we can perform the actual KSK roll.
Please let me know what you think. It's slightly larger scope than previous Yeti experiments, but not too much so.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss