Florian,<br><br><div class="gmail_quote">On Tue, Mar 17, 2009 at 11:38 AM, Florian Weimer <span dir="ltr"><<a href="mailto:fw@deneb.enyo.de">fw@deneb.enyo.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* Keith Mitchell:<br>
<div class="im"><br>
> Thanks Michael for flagging this up. When specing DLV the possibility<br>
> that a TLD submitting trust anchors to DLV might use only NSEC3 for<br>
> signing it, when many servers out there do not support NSEC3, was<br>
> clearly overlooked.<br>
<br>
</div>I don't think it's a DLV issue.  It's required by RFC 4035:<br>
<br>
| 5.5.  Resolver Behavior When Signatures Do Not Validate<br>
|<br>
|    If for whatever reason none of the RRSIGs can be validated, the<br>
|    response SHOULD be considered BAD.  If the validation was being done<br>
|    to service a recursive query, the name server MUST return RCODE 2 to<br>
|    the originating client.  However, it MUST return the full response if<br>
|    and only if the original query had the CD bit set.  Also see Section<br>
|    4.7 on caching responses that do not validate.</blockquote><div><br><br>Nope.<br><br>See 5.2:<br><pre>   If the validator does not support any of the algorithms listed in an<br>   authenticated DS RRset, then the resolver has no supported<br>
   authentication path leading from the parent to the child.  The<br>   resolver should treat this case as it would the case of an<br>   authenticated NSEC RRset proving that no DS RRset exists, as<br>   described above.<br>
</pre> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
It's a rather philosophical question if this is the correct thing to<br>
do.  If you think that DNSSEC is just some protocol to resolve DNS<br>
cache poisoning on the public Internet, this section is clearly wrong.<br>
You should treat this situation as an insecure delegation.<br>
<br>
If you think that DNSSEC serves as some sort of hierarchical<br>
cryptographic key distribution framework, section 5.5 cleary makes a<br>
lot of sense.<br>
<br>
There is a simple test to tell your preference: Suppose your resolver<br>
has a defect which sometimes validates incorrect DSA signatures.<br>
Would you switch of DNSSEC validation as a workaround?<br>
<div><div></div><div class="h5">_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br> Ondrej Sury<br> technicky reditel/Chief Technical Officer<br> -----------------------------------------<br> CZ.NIC, z.s.p.o.  --  .cz domain registry<br> Americka 23,120 00 Praha 2,Czech Republic<br>
 mailto:<a href="mailto:ondrej.sury@nic.cz">ondrej.sury@nic.cz</a>  <a href="http://nic.cz/">http://nic.cz/</a><br> <a href="mailto:sip%3Aondrej.sury@nic.cz">sip:ondrej.sury@nic.cz</a> tel:+420.222745110<br> mob:+420.739013699     fax:+420.222745112<br>
 -----------------------------------------<br><br><br>