DNSSEC troubles (no valid NSEC) ?

[Mark Andrews]

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': 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: marka at isc.org