Subject: proposed text for 'direct nsec queries'

From: Miek Gieben <[email-masked]>
Date: Tue, 20 Jan 2004 22:04:53 +0100

Hello,

Following up on some discussions on the (tiny) subject of direct queries for
NSEC I propose something like the following text to be included in the drafts.

[this mail is sent to provoke some discussion]

proposed text for protocol-05

Direct Queries for NSEC Records at Delegation Points

When the qtype equals NSEC and the qname equals the delegation point of a zone,
a problem can pop up when a server is both authoritative for the parent and
child. RFC 2535 said that in this case both NSEC's should be returned. It failed
to specify how a resolver should treat these two NSEC's. These two records are
identical except in their rdata. The child NSEC has the SOA bit set, while the
parent has not. Unlike any other RR these two are not a RRset and a resolver
must treat them differently from any other RR type. 

The current spec (2535bis) is silent on this topic and we want to avoid opening
a can of worms when specifying this behavior. The current thinking is that
direct NSEC queries are never required for the normal operation of the DNS (ie
resolving). 

Another problem is correlated to caches. Depending on the server behavior a
cache would either have a child's NSEC or parental NSEC or both. The client can
not specify which NSEC it wants. This is also not specified in 2535.

For these reasons direct queries for NSEC can not be relied upon, therefor the
reply from the server is not specified in this document. Resolvers cannot depend
on the data returned in the answer.

grtz
      Miek

--
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: Jim Reid <[email-masked]>
Date: Wed, 21 Jan 2004 00:31:43 +0000

Miek, I have a couple of comments on your proposed text.

Since we're supposed to be superseding RFC2535, I think the draft
should not refer back to something that's effectively dead. This is
even more important when we know a corner case is being left
unspecified that was also left unspecified in 2535. If 2535 got this
wrong, we should take this opportunity to fix it. As part of the
overall DNSSEC tidy-up and rewrite, I think some clarity is needed
here on (a) what the server should and shouldn't do; and (b) what a
resolver is expected to do with that response. If there's a corner
case because a server is authoritative for the parent and child, the
draft should eliminate it by clearly documenting what the server and
resolver should do and shouldn't do for that case. Or at the very
least the draft should say what the preferred behaviour is. [And why.]
IMO some clarity is needed here: the draft should say what it means
and mean what it says. Your proposed text is too fluffy IMO. It could
be misinterpreted. That might lead to inconsistences in implementation
because it leaves enough wiggle room for a server to do one thing while
a resolver does the other.

Some of the language you suggested looks bad. It's inappropriate for a
standards-track RFC to use phrases like "a can of worms" or "a problem
can pop up". Y'know, like, this doesn't read well, man. Know what I
mean, dude? Sure, 2535 is a can of worms. But it's one that should get
a bullet in the head, if I can mix metaphors.

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.

---

From: Jim Reid <[email-masked]>
Date: Wed, 21 Jan 2004 13:08:07 +0000

>>>>> "Paul" == Paul Vixie <[email-masked]> writes:

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

Maybe so. But that discussion would/should lead to agreed text for the
draft that goes to last call. More formal language would be needed
eventually. That process might as well start as the proposed text is
discussed and refined.

    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.

    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.

    Paul> if we place a requirement on it then we
    Paul> have to explain our reasoning and enumerate the cases where
    Paul> our requirement applies.  if we just say it's undefined,
    Paul> then we're done.

But we'll have done a sloppy job and could well be revisiting the
problem in 5-10 year's time. By which time everyone will have
forgotten what those cases and requirements were. [And then they'll
pop up wackamole-style again, just as they've been doing for the last
umpteen years of DNSSEC development.] If the corner cases are known
about now, they should at the very least be enumerated and
documented. So if the spec is going to say something is undefined, it
should say why the behaviour is undefined.

---

From: Miek Gieben <[email-masked]>
Date: Wed, 21 Jan 2004 14:47:18 +0100

[On 21 Jan, @02:47, Paul wrote in "Re: proposed text for 'direct  ..."]
> jim reid wrote:
> 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.)

it was indeed alpha quality :-)

The reason to define explicit server behavior would be: "give back what you've
got" - property of DNS. But this leads to weird corner cases that also need to
be documented, which could lead to even more corner cases. We don't want to 
go there for these weirdo nsec queries.

Therefor I think it is best to define it to 'undefined'. Direct queries for nsec
are not part of the normal resolving process. If a resolver _needs_ an nsec it
will get the nsec in the answer (as part of a nxdomain respons, for instance).

> 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

or a 'REFUSED'. The only thing resolvers need to know is that nsec queries are
special and that answers to those queries can not relied up on. And that nsec's
are always alone in a RRset.

regards,
Miek