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

[JINMEI Tatuya / 神明達哉]

At Wed, 23 Jan 2013 09:26:00 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > In any case we probably overlooked something in implementing it as
> > we generally tried to port BIND's behavior for NSEC/NSEC3 handling.
> > I've not yet checked whether the errata discussion at dnsext affects
> > this case and (if it does) when it's sorted out, but unless it's fixed
> > by the next sprint I think we should make it compatible with BIND 9 in
> > the next sprint.
> 
> I don't know if „it's compatible with bind9“ is a very good reason
> here, as we the discussion suggests, it's not clear what is
> correct. We have many bugs for sure, and we are not sure this one is
> a bug, so why the hurry? I could probably name 5 places where we are
> not acting the same as bind9 without much thinking and these places
> would be happening more often.

In this case, it's not just about "it's (not) compatible with BIND
9".  In this case we intentionally tried to be compatible with BIND 9,
so if there's a gap that means we did (not) something we intended
(not) to do.  Whether that something is "being compatible with BIND 9"
or "compliant to some protocol spec" or something else, that's clearly
bad.  It also means we may have overlooked some other things around
here, and suggests we should inspect it.  It's totally different from
the situation of "being different from BIND 9 without much thinking".

That said, I see the point of urgency and what eventually we have to
do.  I admit it was not clear what we should return in the end and how
soon we do it at the time I made the above comment, but on taking
closer look at the issue, my conclusion is not so different.

First, as Fujiwara-san already pointed out an errata on this was
already submitted: http://www.rfc-editor.org/errata_search.php?rfc=5155&eid=3441
and, according to the discussion at dnsext this generally seems to be
based on the wg consensus.  So "what to do" now seems pretty clear to
me: correct it as the errata says.  And, if I understand it correctly,
it also happens to be the same as BIND 9's behavior.

The urgency can be discussed.  Whether it's SERVFAIL or normal
negative response with NSEC3 as the errata specifies, the end result
of the caching (validating) server and the ultimate client wouldn't be
much different (the proof with NSEC3 is quite weak in this case
anyway).  And, it's not a bug like ones making b10-auth crash.
But, hitting an exception with a validly constructed zone and a valid
query is not really good, considering the cost of exception handling,
so I personally think it's better to fix sooner.  Assuming we have
another sprint between a release candidate and the real release,
there's a chance to fix it in the release version if we do it in the
next spring.  I think it's worth doing.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.