[dns-operations] [DNSSEC] A "lame" DS record: operational problem or not?
ogud at ogud.com
Tue Sep 14 14:11:03 UTC 2010
On 14/09/2010 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.
There is NO ISSUE here, there is a second key referred to by the DS set
I have on number of times recommended that people pre-publish the DS
record of standby KSK rather than add the key to the DNSKEY set as, then
the only delay in bringing the new key into use is on the child sign and
does not involve the parent, except to remove the DS record when the
roll is complete.
> mentions pre-publishing DS, so .BE seems legal.
Educate at the tool writers.
More information about the dns-operations