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: "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
_______________________________________________ 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