[bind10-dev] bind10-1.0.0-beta auth server answers SERVFAIL for an empty non-terminal due to "Unexpected covering NSEC3 found" error

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/22/2013 10:05 AM, fujiwara at jprs.co.jp wrote:
> 
> ERROR [b10-auth.auth/80537] AUTH_PROCESS_FAIL message processing
> failure: Unexpected covering NSEC3 found for c.c.tld.
> 
> BIND 9 answers empty, NO ERROR answer.
> 

Empty non-terminals. sigh.

The original RFC is contradicting itself on this specific case.

The relevant snippets from RFC5155:

section 7.1:
   o  Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
      the empty non-terminal is only derived from an insecure delegation
      covered by an Opt-Out NSEC3 RR.

section 7.2.3:
   The server MUST include the NSEC3 RR that matches QNAME.  This NSEC3
   RR MUST NOT have the bits corresponding to either the QTYPE or CNAME
   set in its Type Bit Maps field.

So the server MUST include something that does not have to exist :p

There was a discussion on what to do here recently on namedroppers,
which I'll be re-reading shortly; in general the choices are between
what bind 9 does, and what we now do, IIRC.

http://www.ietf.org/mail-archive/web/dnsext/current/msg12821.html

In terms of our code, we call addNSEC3ForName with the requirement
that the record is a matching one, not a covering one (query.cc line
306). But since the matching one is not required and not there, it
finds the covering one. We can't just flip the requirement since for
all other ENTs we do require a matching NSEC3 record.

Depending on what the errata will end up as, the fix may be 'works
according to spec', easy (treat it the same as DS no data proof), or
more involved (if we actually have to dive into the data below the ENT
to see what is there)... I'm not entirely sure how we should behave in
the mean time.

Jelte

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlD+cw8ACgkQ4nZCKsdOncW1EgCg2SVQebHJk9OU4Vk0LnFwEQw9
iUUAn2404BPtVrXyXEELQdCToQsD1Szm
=rSUk
-----END PGP SIGNATURE-----