Subject: Re: proposed text for 'direct nsec queries'

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Jan 2004 01:47:24 +0000

jim reid wrote:

> How about the text below?
> 
> Explicit Queries for NSEC Records at Delegation Points
> 
> Special consideration will be needed in the case of queries for an
> NSEC QTYPE when the QNAME is a delegation point and the server is
> authoritative for both the parent and child zones. In these
> circumstances the server will have two NSEC records with different
> RDATA matching the query. One will be from the parent zone for the
> delegation and the other will be from the child zone. These two NSEC
> records MUST NOT be treated as an RRset. The server SHOULD (MUST?)
> return both NSEC records in response to such queries. When NSEC
> records exist above and below a zone cut for some QNAME, a resolver
> making an explicit NSEC query cannot specify which of these two NSEC
> records it wants. Therefore, a resolver which makes an explicit query
> for an NSEC qtype MUST (SHOULD?) be prepared to receive a response
> containing both these NSEC records. It cannot know in advance that the
> QNAME is a delegation point or if the queried server is authoritative
> for both the parent and child zones.

miek's proposed text was better.  (note that miek said it was only draft
discussion quality, so it was unfair of jim to question its informality.)

there are too many corner cases to cover if we want to define "proper"
behaviour for queries at delegation points.  for example, what if the
reason were that the server had recursion enabled and had thusly cached
the above-the-cut NSEC RR?  for this reason, a proposal limited to servers
who are authoritative for both the parent and child is not useful.

miek's proposal is in my opinion the correct one in this circumstance.
since there is no protocol necessity for above-the-cut NSEC queries, it
is reasonable to specifically undefine them.  some servers may decide
to answer with delegation responses when queried for anything "at" a
delegation point (other than the DS RRset, which may be required due to
the grandparent problem).  some servers may decide to issue SERVFAIL
when queried for NSEC "at" a delegation point.  if we place a requirement
on it then we have to explain our reasoning and enumerate the cases where
our requirement applies.  if we just say it's undefined, then we're done.

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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Jan 2004 17:47:25 +0000

>     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.