On Wed, Jul 25, 2012 at 10:07 AM, Frantisek Hanzlik <span dir="ltr"><<a href="mailto:franta@hanzlici.cz" target="_blank">franta@hanzlici.cz</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I solve problem with delivering mail to address "<a href="mailto:XY@br.ds.mfcr.cz">XY@br.ds.mfcr.cz</a>".<br>
MTA obviously isn't able resolve MX records for this domain.<br>
"dig @localhost -t MX <a href="http://br.ds.mfcr.cz" target="_blank">br.ds.mfcr.cz</a>" ends with SERVFAIL error:<br>
<br>...<br>
<br>
and in BIND (v9.7.4 i686) log are after this query three records:<br>
<br>
error (no valid NSEC) resolving '<a href="http://br.ds.mfcr.cz/MX/IN" target="_blank">br.ds.mfcr.cz/MX/IN</a>': 80.95.254.4#53<br>
error (no valid NSEC) resolving '<a href="http://br.ds.mfcr.cz/MX/IN" target="_blank">br.ds.mfcr.cz/MX/IN</a>': 193.86.123.22#53<br>
error (no valid NSEC) resolving '<a href="http://br.ds.mfcr.cz/MX/IN" target="_blank">br.ds.mfcr.cz/MX/IN</a>': 193.86.123.21#53<br>
<br></blockquote><div><br></div><div>The result for <a href="http://br.ds.mfcr.cz/MX">br.ds.mfcr.cz/MX</a> is an expansion of a wildcard (*.<a href="http://ds.mfcr.cz/MX">ds.mfcr.cz/MX</a>). Signed responses that include expanded wildcards require that NSEC(3) RRs are included in the authority section to show that the QNAME (e.g., <a href="http://br.ds.mfcr.cz">br.ds.mfcr.cz</a>) doesn't exist, so the wildcard expansion is legitimate. The NSEC3 for the closest encloser of the QNAME is not necessary because it can be inferred from the RRSIG, so only a single NSEC3 is sufficient. However, earlier versions of BIND both served the superfluous NSEC3 and expected it. See this thread, for example:</div>
<div><br></div><div><a href="http://dnssec-deployment.org/pipermail/dnssec-deployment/2011-October/005486.html">http://dnssec-deployment.org/pipermail/dnssec-deployment/2011-October/005486.html</a></div><div><div><br class="Apple-interchange-newline">
<div>$ dig +dnssec +noall +authority @<a href="http://ns1.mfcr.cz">ns1.mfcr.cz</a> <a href="http://br.ds.mfcr.cz">br.ds.mfcr.cz</a> mx</div><div><a href="http://mfcr.cz">mfcr.cz</a>.<span class="Apple-tab-span" style="white-space:pre"> </span>10800<span class="Apple-tab-span" style="white-space:pre"> </span>IN<span class="Apple-tab-span" style="white-space:pre"> </span>NS<span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://ns1.mfcr.cz">ns1.mfcr.cz</a>.</div>
<div><a href="http://mfcr.cz">mfcr.cz</a>.<span class="Apple-tab-span" style="white-space:pre"> </span>10800<span class="Apple-tab-span" style="white-space:pre"> </span>IN<span class="Apple-tab-span" style="white-space:pre"> </span>NS<span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://ns3.mfcr.cz">ns3.mfcr.cz</a>.</div>
<div><a href="http://mfcr.cz">mfcr.cz</a>.<span class="Apple-tab-span" style="white-space:pre"> </span>10800<span class="Apple-tab-span" style="white-space:pre"> </span>IN<span class="Apple-tab-span" style="white-space:pre"> </span>NS<span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://ns2.mfcr.cz">ns2.mfcr.cz</a>.</div>
<div><a href="http://mfcr.cz">mfcr.cz</a>.<span class="Apple-tab-span" style="white-space:pre"> </span>10800<span class="Apple-tab-span" style="white-space:pre"> </span>IN<span class="Apple-tab-span" style="white-space:pre"> </span>RRSIG<span class="Apple-tab-span" style="white-space:pre"> </span>NS 7 2 10800 20120812074507 20120712074507 14339 <a href="http://mfcr.cz">mfcr.cz</a>. NGNS8CkP5Gg/cvUTsTrxoDuRiGeaoixJ5+optBhK1gRYinpHZ3cx9y/i w5WOAKYy/uOpMhvAiOIzA59yDnGOhG/2ewH/S/G8+TcISBk0//KcYSuf xs7bkBm+YFzVG8YEqwESvKklAkdplraWHH2uxMX4NYBWKeOyjG+PgyW2 AdM=</div>
<div><a href="http://R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz">R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz</a>. 3600 IN NSEC3<span class="Apple-tab-span" style="white-space:pre"> </span>1 1 10 BDD515FB9B1238C4 RF50NKKASDGSBSRGBI8T72N9EEH5KBIO A RRSIG</div>
<div><a href="http://R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz">R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz</a>. 3600 IN RRSIG<span class="Apple-tab-span" style="white-space:pre"> </span>NSEC3 7 3 3600 20120812074507 20120712074507 14339 <a href="http://mfcr.cz">mfcr.cz</a>. 2VXv7Hudu2iHjwp75fxv9wwH5CZx35upl/iYfe8HZDHj3badkQbi6CH4 IAyJuOA9gUttoRogXtwCNJV0BwTl5iPlpl/QqEeTu1B7e2oWr829CweK +v42sHh5SuBmaB5rlJS+GhVm6MQe+nqZMe1nG48O1VV2PPGEvETYBI+V SzI=</div>
</div><div><br></div><div>Note that only a NSEC3 RR is returned above. This is correct behavior (though an extra NSEC3 RR shouldn't matter), but the older resolver doesn't handle it well.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I tried find some info about this error message, but without luck.<br>Problem will be perhaps something with DNSSEC. What is interesting,<br>BIND v9.9.1, essentially with the same configuration (relevant<br>"options" paragraph part of named.conf is in both:<br>
</blockquote><div> </div></div><div>I don't know what versions it has been fixed in, but I assume at least that this is the bug fix referred to in the changelog for 9.9.0:</div><div><br></div><div>"named now correctly validates DNSSEC positive wildcard responses from NSEC3 signed zones. [RT #26200]" [1].</div>
<div><br></div><div>Of course, now there is some mix of older validating BIND resolvers that expect the extra NSEC3 RR and BIND (and other) authoritative server implementations that don't send it. So, this issue might show itself occasionally.</div>
<div><br></div><div>Casey</div><div><br></div><div>[1] <a href="https://kb.isc.org/article/AA-00631/0/BIND-9.9.0-Release-Notes.html">https://kb.isc.org/article/AA-00631/0/BIND-9.9.0-Release-Notes.html</a></div></div>