[dns-operations] [DNSSEC] A "lame" DS record: operational problem or not?
Ed.Lewis at neustar.biz
Tue Sep 14 14:51:13 UTC 2010
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.
>mentions pre-publishing DS, so .BE seems legal.
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.
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...
More information about the dns-operations