[dns-operations] [DNSSEC] A "lame" DS record: operational problem or not?

[Olafur Gudmundsson]

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
> <http://dnsviz.net/d/be/dnssec/>).
>
> 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 
that validates.

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.

>
> <http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-02#section-3.3.2>
> mentions pre-publishing DS, so .BE seems legal.
>
> Advices?

Educate at the tool writers.

	Olafur