DNSSEC troubles (no valid NSEC) ?

[Frantisek Hanzlik]

Casey Deccio wrote:
> On Wed, Jul 25, 2012 at 10:07 AM, Frantisek Hanzlik <franta at hanzlici.cz <mailto:franta at hanzlici.cz>> wrote:
> 
>     I solve problem with delivering mail to address  "XY at br.ds.mfcr.cz <mailto: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 <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!