Casey Deccio wrote: > On Wed, Jul 25, 2012 at 10:07 AM, Frantisek Hanzlik <fra...@hanzlici.cz > <mailto:fra...@hanzlici.cz>> wrote: > > I solve problem with delivering mail to address "x...@br.ds.mfcr.cz > <mailto:x...@br.ds.mfcr.cz>". > MTA obviously isn't able resolve MX records for this domain. > "dig @localhost -t MX br.ds.mfcr.cz <http://br.ds.mfcr.cz>" ends with > SERVFAIL error: > > ... > > and in BIND (v9.7.4 i686) log are after this query three records: > > error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN > <http://br.ds.mfcr.cz/MX/IN>': 80.95.254.4#53 > error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN > <http://br.ds.mfcr.cz/MX/IN>': 193.86.123.22#53 > error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN > <http://br.ds.mfcr.cz/MX/IN>': 193.86.123.21#53 > > > The result for br.ds.mfcr.cz/MX <http://br.ds.mfcr.cz/MX> is an expansion of > a wildcard (*.ds.mfcr.cz/MX <http://ds.mfcr.cz/MX>). Signed responses that > include expanded wildcards require that NSEC(3) RRs are included in the > authority section to show that the QNAME (e.g., > br.ds.mfcr.cz <http://br.ds.mfcr.cz>) 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: > > http://dnssec-deployment.org/pipermail/dnssec-deployment/2011-October/005486.html > > $ dig +dnssec +noall +authority @ns1.mfcr.cz <http://ns1.mfcr.cz> > br.ds.mfcr.cz <http://br.ds.mfcr.cz> mx > mfcr.cz <http://mfcr.cz>.10800INNSns1.mfcr.cz <http://ns1.mfcr.cz>. > mfcr.cz <http://mfcr.cz>.10800INNSns3.mfcr.cz <http://ns3.mfcr.cz>. > mfcr.cz <http://mfcr.cz>.10800INNSns2.mfcr.cz <http://ns2.mfcr.cz>. > mfcr.cz <http://mfcr.cz>.10800INRRSIGNS 7 2 10800 20120812074507 > 20120712074507 14339 mfcr.cz <http://mfcr.cz>. > NGNS8CkP5Gg/cvUTsTrxoDuRiGeaoixJ5+optBhK1gRYinpHZ3cx9y/i > w5WOAKYy/uOpMhvAiOIzA59yDnGOhG/2ewH/S/G8+TcISBk0//KcYSuf > xs7bkBm+YFzVG8YEqwESvKklAkdplraWHH2uxMX4NYBWKeOyjG+PgyW2 AdM= > R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz > <http://R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz>. 3600 IN NSEC31 1 10 > BDD515FB9B1238C4 RF50NKKASDGSBSRGBI8T72N9EEH5KBIO A RRSIG > R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz > <http://R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz>. 3600 IN RRSIGNSEC3 7 3 > 3600 20120812074507 20120712074507 14339 mfcr.cz <http://mfcr.cz>. > 2VXv7Hudu2iHjwp75fxv9wwH5CZx35upl/iYfe8HZDHj3badkQbi6CH4 > IAyJuOA9gUttoRogXtwCNJV0BwTl5iPlpl/QqEeTu1B7e2oWr829CweK > +v42sHh5SuBmaB5rlJS+GhVm6MQe+nqZMe1nG48O1VV2PPGEvETYBI+V SzI= > > 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. > > I tried find some info about this error message, but without luck. > Problem will be perhaps something with DNSSEC. What is interesting, > BIND v9.9.1, essentially with the same configuration (relevant > "options" paragraph part of named.conf is in both: > > > 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: > > "named now correctly validates DNSSEC positive wildcard responses from NSEC3 > signed zones. [RT #26200]" [1]. > > 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. > > Casey > > [1] https://kb.isc.org/article/AA-00631/0/BIND-9.9.0-Release-Notes.html > !DSPAM:501073e416141991854194!
Many thanks for detailed explanation and references. I now compile for my Fedora box version 9.8.2 for Centos 6.3 (including 50 other RedHat patches;) and all seems be OK. Thanks to all for quick responses! _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
