<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [dns-operations] [DNSSEC] A "lame" DS
record: operatio</title></head><body>
<div>At 15:18 +0200 9/14/10, Stephane Bortzmeyer wrote:</div>
<div><br></div>
<div>>I've reported and discuted the issue with the .BE people but
I have<br>
>doubts: could it be a real operational problem? Unbound and
BIND<br>
>apparently can validate .BE just fine. Section 2.4 of RFC 4035 is
not<br>
>clear about what a validating resolver should do in that case.<br>
><br>
><http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timi<span
></span>ng-02#section-3.3.2><br>
>mentions pre-publishing DS, so .BE seems legal.<br>
></div>
<div>>Advices?</div>
<div><br></div>
<div>Good thing to bring up.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>In 4035/2.4, I think it's pretty clear here:</div>
<div><br></div>
<div> DS RRs that fail to meet these<br>
conditions are not useful for validation, but because the
DS RR and<br>
its corresponding DNSKEY RR are in different zones, and
because the<br>
DNS is only loosely consistent, temporary mismatches can
occur.</div>
<div><br></div>
<div>"Not useful for validation" mean validators ought to
ignore them. And, note the "DNS is only loosely
conherent."</div>
<div><br></div>
<div>"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.</div>
<div><br></div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<span
></span>-=-=-=-</div>
<div>Edward
Lewis <span
></span> <br>
NeuStar <span
></span> You can
leave a voice message at +1-571-434-5468</div>
<div><br></div>
<div>Spouses, like Internet protocols, lack necessary troubleshooting
tools. Sigh.</div>
</body>
</html>