Re: proposed text for 'direct nsec queries'

[Paul Vixie <paul@vix.com>]

>     Paul> there are too many corner cases to cover if we want to
>     Paul> define "proper" behaviour for queries at delegation points.
> 
> Sigh. I fear there may well be too many corner cases. But IMO that
> isn't justification for not documenting them.

it can be, though, if the corner case you didn't cover ends up being
the one that matters to somebody.  if you deliberately undefine it,
then noone will (sanely) depend on implementation-specific behaviour.

>     Paul> some servers may decide to issue SERVFAIL when queried for
>     Paul> NSEC "at" a delegation point.
> 
> This worries me. Something smells very bad -- more than DNSSEC usually
> smells bad -- if the spec leaves something so wide open that different
> implementations could return responses as far apart as NOERROR and
> SERVFAIL for the same query, all other things being equal.

it's not the only thing that's deliberately left undefined.  if you send
a query that makes no sense you will get an answer that makes no sense.
consider the "upward referral" problem, where an authority-only server
receives a query for a zone it doesn't carry.  correct answers range from
SERVFAIL to a list of root name servers (which an authority only server
might not even have).  sometimes the best thing to do is specify the part
you care about and explicitly note the unspecificity of the parts you don't
care about.  asking for NSEC RR's qualifies squarely in this category, and
we are indebted to miek for pointing this out.

> ...  So if the spec is going to say something is undefined, it should
> say why the behaviour is undefined.

i believe that miek's proposed text does that.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>