[Yeti DNS Discuss] KROLL and trust/key file
keesm at monshouwer.eu
Mon Jul 25 10:44:32 UTC 2016
There is btw an other issue with the hold-down time.
The hold-down time should start after all signatures for the old DNSKEY
set (without the new KSK) are expired.
RFC5011 says in 2.2 "If the resolver ever sees the DNSKEY RRSet without
the new key but validly signed, it stops the acceptance process for that
key and resets the acceptance timer.
If there are still valid signatures for the old keyset around it is
possible to use them in a replay attack and reset the hold-down time in
So maybe add a few extra days to address this issue as well.
On 07/25/2016 11:18 AM, Shane Kerr wrote:
> At 2016-07-25 11:08:28 +0800
> dbgong <dbgong at biigroup.cn> wrote:
>> On 2016-07-23 17:15
>> Kees Monshouwer <keesm at monshouwer.eu> wrote:
>>> I wonder why the new KSK is not in
>>> (the recommended source of trust on the join page)
>>> If I a install a new RFC 5011 capable recursor today, based on this
>>> trust file. The hold-down will also start today.
>>> As a result of this the new key will not be valid when the old one is
>>> New key has the ADDPEND state.
>> We are doing the KROLL, So this is the right behavior.
>> The new key should be in the ADDPEND state.
>> and the new key is published at July 12, 2016.
>> Please adjust your resolver's hold down timer.
>> > Is this part of the experiment or it an overlooked detail?
>> Yes, it's a part of the experiment.
>> We suppose all the resolver support RFC 5011, and we will publish
>> the new KSK when it's in the VALID state.
> I didn't think about people configuring resolvers during the
> roll-over. :(
> We should probably update the github repository, and make something
> KSK.pub -> new version of the KSK
> KSK-prev.pub -> "current" version of the KSK
> KSK-YYYYmmdd.pub -> timestamped version including old & new KSK (for
> historical purposes)
> I think that we should re-start the RFC 5011 hold-down timer again, in
> case anybody configured using the old KSK. :(
> (Thanks Kees for spotting this oversight.)
> discuss mailing list
> discuss at lists.yeti-dns.org
More information about the discuss