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

[Edward Lewis]

At 15:18 +0200 9/14/10, Stephane Bortzmeyer wrote:

>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.
>
><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?

Good thing to bring up.

In some recent discussions about recovery scenarios, over the point 
that it takes longer to get a DS record added to your parent than 
adding a DNSKEY to your zone, it was proposed to pre-publish DS 
records.  This can speed up time to recovery.

This also highlights the need to be less strict in validating data. 
"Any chain" is more beneficial than "all chains" or even trying to 
prefer one chain over another (e.g., shorter vs. longer).  The reason 
DNS operates on such a large scale is that it is loose, DNSSEC isn't 
supposed to disrupt that.

In 4035/2.4, I think it's pretty clear here:

    DS RRs that fail to meet these
    conditions are not useful for validation, but because the DS RR and
    its corresponding DNSKEY RR are in different zones, and because the
    DNS is only loosely consistent, temporary mismatches can occur.

"Not useful for validation" mean validators ought to ignore them. 
And, note the "DNS is only loosely conherent."

"Temporary" is subjective term.  A validator, in the heat of 
validation, cannot determine if the inconsistency has existed for 1 
second or 1 year and should not attempt to do so.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20100914/ba0d0ef6/attachment.html>