NSEC3 wildcard validation failures [was: Wrong NSEC3 for wildcard cname]

[Graham Clinch]

Hi Folks,

I think we can wrap this up thanks to assistance from the reporting site - they're running BIND 9.8.1-P1 (stock package in Ubuntu 12.04 LTS).

This means they don't have the following fix, which appeared in 9.8.2b1.

3175.   [bug]           Fix how DNSSEC positive wildcard responses from a
                        NSEC3 signed zone are validated.  Stop sending a
                        unnecessary NSEC3 record when generating such
                        responses. [RT #26200]

I can recreate the problem with a validating resolver running 9.8.1-P1 (Ubuntu 12.04), and the problem is not present using 9.8.2rc1 (stock package in CentOS 6), so I'm fairly sure it's this bug.  (For posterity, validation fails with "validating @0x7f4b44014fe0: foo.cnametest.lancs.ac.uk A: noqname proof not found", whilst "validating @0x7f2b3c0008b0: foo.cnametest.lancs.ac.uk A: closest encloser from wildcard signature 'cnametest.lancs.ac.uk'" is *not* logged)

The stock Ubuntu configuration is to enable validation (this is good), unfortunately 12.04 LTS is supposedly being (security?) supported into 2017, so it could be quite a while before sites (even the ones who perform package updates regularly) advance into a situation of being able to resolve our wildcard entries.  The most recent Ubuntu LTS (14.04) is not affected.  I have logged an Ubuntu bug[1] to request this fix is 'back ported' into 12.04.

To give a sizing hint on the probabilistic risk of being affected, lancs.ac.uk (an affected zone) has ~50,000 unique owner names, whilst palatine.ac.uk (unaffected), has ~10.  We signed lancs.ac.uk in early/mid September, and this is the first real report of DNSSEC-related issues I've seen.

>     delv +vtrace continues to report "NSEC3 at super-domain" only for
>     foo.cnametest2.palatine.ac.uk <http://foo.cnametest2.palatine.ac.uk>
>     records, and not for
>     foo.cnametest2.lancs.ac.uk <http://foo.cnametest2.lancs.ac.uk>.  Is
>     this a similar
>     miscalculating-the-owner-name as for DNSViz?
> 
> 
> Don't know, but I would guess that this is simply recognizing the fact
> that in addition to covering the non-existent name, the NSEC3 record
> also happens to correspond to palatine.ac.uk <http://palatine.ac.uk>.

delv reports the validation as succeeding, so after further reflection I believe this additional message is merely a helpful (?to whom?) diagnostic.  Unfortunately there's no obvious (to me, at least) distinction between 'debug', 'interesting' and 'this is where it's gone wrong' log levels in delv +vtrace's output (but I'm not really complaining that much).

Graham

[1] https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1395216