DNSSEC troubles (no valid NSEC) ?

[Casey Deccio]

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:

"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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120725/72833771/attachment.html>