DNSSEC troubles (no valid NSEC) ?
marka at isc.org
Wed Jul 25 23:05:11 UTC 2012
In message <CAEKtLiRm=OpnRzATDTnHzCGJpoL10o9mnjXb_mVkuGMuKrkMtg at mail.gmail.com>, Casey Deccio writes:
> On Wed, Jul 25, 2012 at 10:07 AM, Frantisek Hanzlik <franta at hanzlici.cz>wrote:
> > I solve problem with delivering mail to address "XY at 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': 18.104.22.168#53
> > error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN': 22.214.171.124#53
> > error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN': 126.96.36.199#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:
> $ 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
> 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.
> +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]" .
> 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
>  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: marka at isc.org
More information about the bind-users