<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 16, 2015 at 11:34 AM, Stephane Bortzmeyer <span dir="ltr"><<a href="mailto:bortzmeyer@nic.fr" target="_blank">bortzmeyer@nic.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">With Unbound, I get a SERVFAIL:<br>
<br></blockquote><div>...<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But BIND accepts it (and so does Google Public DNS):<br>
<br></blockquote><div>... <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
DNSviz, like Unbound, says the domain is broken:<br><br><a href="http://dnsviz.net/d/cepn.asso.fr/VOGwhA/dnssec/" target="_blank"></a></blockquote><div><br></div><div>"Broken" is a loaded term.  There are definitely errors with <a href="http://cepn.asso.fr">cepn.asso.fr</a>, namely that because both algorithms 5 and 8 show up in the DS RRset, the zone MUST be signed with both, i.e., RRSIGs for each algorithm should be MUST accompany any RRset in the response.  This is specified in RFC 4035, Sec 2.2.<br><br>However, this requirement is clarified in RFC 6840, Sec. 5.11 as follows:<br><pre class="">   This requirement applies to servers, not validators.  Validators
   SHOULD accept any single valid path.  They SHOULD NOT insist that all
   algorithms signaled in the DS RRset work, and they MUST NOT insist
   that all algorithms signaled in the DNSKEY RRset work.</pre>Thus, as Mark pointed out, these particular errors should not affect the validation of <a href="http://cepn.asso.fr">cepn.asso.fr</a>, for validators that understand both algorithms 5 and 8.<br><br></div><div>Note that DNSViz handles such cases by displaying the errors (i.e., with the red error sign), but still showing the validation status of the RRsets as "secure" (denoted by the blue-ish color).<br><br>

<a href="http://dnsviz.net/d/cepn.asso.fr/VOGwhA/dnssec/" target="_blank">http://dnsviz.net/d/cepn.asso.fr/VOGwhA/dnssec/</a><br><br></div><div>However, you can "see" the reason for the requirement of the signer (i.e., that it contains RRSIGs for each algorithm in the DS) in the following example.  Suppose a validator does not support algorithm 5 (e.g., due to implementation deficiency, administrative policy, or because algorithm has been declared obsolete for some reason).  The chain of trust now looks like this:<br><br><a href="http://dnsviz.net/d/cepn.asso.fr/VOGwhA/dnssec/?rr=all&a=8&ds=all&ta=.&ta=dlv.isc.org.&tk=">http://dnsviz.net/d/cepn.asso.fr/VOGwhA/dnssec/?rr=all&a=8&ds=all&ta=.&ta=dlv.isc.org.&tk=</a><br><br></div><div>As far as the validator is concerned, there should be a secure path for both algorithms (as indicated by the algorithms in the DS records).  It can't choose one or the other because algorithm 5 is not an option.  So it turns to algorithm 8.  However, because there is no path for algorithm 8, the chain is broken.<br><br>Cheers,<br>Casey</div></div></div></div>