[dns-operations] [DNSSEC] A "lame" DS record: operational problem or not?
Rose, Scott W.
scott.rose at nist.gov
Tue Sep 14 13:57:08 UTC 2010
The text in RFC 4035 really deals with algorithms, not multiple DS RR's with the same algorithm. The goal was to avoid a downgrade attack.
I don't really see a problem with this - it would be "better" for the child to wait until the DS is removed, then remove the KSK (after waiting the TTL of the DS RRset), but it works either way - there is still one secure link with a particular algorithm. The only problem would be if the the KSK was removed as soon as the new DS was published, instead of waiting for the old DS RRset to be purged from caches, but that's hard to tell if that happened.
This is something that should be (and is, I believe) addressed in best-common-practices documents.
On Sep 14, 2010, at 9:18 AM, Stephane Bortzmeyer wrote:
> I recently saw a "lame" DS record in the root (a DS which goes to a
> non-existing key):
> be. 73924 IN DS 3961 8 1 30FC582FE64CA122064D92FF6DF3EC8383A1E987
> be. 73924 IN DS 3961 8 2 72863CE93E5D4CEFE529D32BE7484056442DEA804D8F0769522CDB18 1C86F0E5
> Key 3961 is not published (see it graphically at
> I've reported and discuted the issue with the .BE people but I have
> doubts: could it be a real operational problem? Unbound and BIND
> apparently can validate .BE just fine. Section 2.4 of RFC 4035 is not
> clear about what a validating resolver should do in that case.
> mentions pre-publishing DS, so .BE seems legal.
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
scottr at nist.gov
Google Voice: +1 571-249-3671
More information about the dns-operations