[Yeti DNS Discuss] Theoretical DoS attack during KSK roll
shane at biigroup.cn
Mon Sep 5 03:30:47 UTC 2016
RFC 5011 DoS
Recently Wed Hardaker and Warren Kumari submitted a draft describing a
denial-of-service attack on zones using RFC 5011:
The basic problem is that an attacker can replay an earlier version of
the signed DNSKEY RRset until the signatures expire. A resolver that
sees the old DNSKEY RRset will re-start the 30-day RFC 5011 hold-down
This means that an authority server has to add the DNSKEY RRset
signature validity time to the 30-day timer (along with the TTL),
otherwise when it starts using the new KSK the resolver will not have
accepted the KSK, and validation will fail.
RFC 5011 DoS & Yeti
In our current Yeti KSK roll we ARE VULNERABLE to this DoS. We have a
1-month signature validity period (!!), and have already revoked our
old KSK after only a 32-day wait.
We did not extend the current experiment for a few reasons. It would add
another 28 days (or more?) to an already long experiment, plus we would
be changing the experiment in the middle. Also, the risks of the attack
are real but low - they require either an on-path attacker or something
like a Kaminsky attack. The damage of the attack would be a Yeti
resolver stops working, which would be unfortunate but since Yeti
resolvers are opt-in we hope that they are generally run by clueful
operators who can fix it quickly (either by updating the KSK manually
from the Yeti website, converting to the IANA KSK, or by disabling
Signature Validity and the Root
I think that we (Yeti) should reduce our signature validity period. We
generate a new version of the zone 2 times per day, and we have a 1 day
TTL. There is no reason for a signature validity period of longer than
2 days, or maybe 3 days to allow for clock drift on resolvers.
This would require the Distribution Masters (DM) change their signing
parameters, and we may want to consider changing the expire time on the
root zone SOA record (currently 1 week).
Note that the IANA root has a 2-week signature validity. This is also
longer than it has to be, because of the IANA root is also generated 2
times per day and has a 2 day TTL. While not vulnerable to the RFC 5011
DoS described (because of the long rolling periods for the IANA root),
a longer signature validity than necessary does open some window of
vulnerability to replay attacks, and perhaps this should be reduced.
Certainly for the IANA root a 1-week signature validity is completely
safe and would cut the replay window in half. The expire time on the
IANA root zone SOA record may need to be changed here too.
Possible RFC 5011 DoS Experiment
We should be able to test the DoS on Yeti. The proposal is basically
that we replay some old DNSKEY records to specific resolvers in order
to reset their hold-down timers. This means that we would leave the
Yeti KSK vulnerable for a period during the next KSK roll as well.
For the next KSK roll we can DoS specific test resolvers by re-playing
the old DNSKEY during the first 3 days after the experiment starts,
which should reset their RFC 5011 hold-down timer, and then we can
observe them failing resolution when we roll to the new KSK at the end.
For future KSK roll we will extend the time before using the new KSK to
also account for the signature validity period, removing the
More information about the discuss