In message <CAEKtLiRm=opnrzatdtnhzcgjpol10o9mnjxb_mvkugmukrk...@mail.gmail.com>, Casey Deccio writes: > > On Wed, Jul 25, 2012 at 10:07 AM, Frantisek Hanzlik <fra...@hanzlici.cz>wrote: > > > I solve problem with delivering mail to address "x...@br.ds.mfcr.cz". > > MTA obviously isn't able resolve MX records for this domain. > > "dig @localhost -t MX 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': 80.95.254.4#53 > > error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN': 193.86.123.22#53 > > error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN': 193.86.123.21#53 > > > > > The result for br.ds.mfcr.cz/MX is an expansion of a wildcard (*. > 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) 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 br.ds.mfcr.cz mx > mfcr.cz. 10800 IN NS ns1.mfcr.cz. > mfcr.cz. 10800 IN NS ns3.mfcr.cz. > mfcr.cz. 10800 IN NS ns2.mfcr.cz. > mfcr.cz. 10800 IN RRSIG NS 7 2 10800 20120812074507 20120712074507 14339 > mfcr.cz. NGNS8CkP5Gg/cvUTsTrxoDuRiGeaoixJ5+optBhK1gRYinpHZ3cx9y/i > w5WOAKYy/uOpMhvAiOIzA59yDnGOhG/2ewH/S/G8+TcISBk0//KcYSuf > xs7bkBm+YFzVG8YEqwESvKklAkdplraWHH2uxMX4NYBWKeOyjG+PgyW2 AdM= > R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz. 3600 IN NSEC3 1 1 10 > BDD515FB9B1238C4 RF50NKKASDGSBSRGBI8T72N9EEH5KBIO A RRSIG > R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz. 3600 IN RRSIG NSEC3 7 3 3600 > 20120812074507 20120712074507 14339 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:
And it is fixed in 9.6-ESV-R6, 9.7.5, 9.8.2 so the fix is to upgrade. > "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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ 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
