Subject: Re: Q-23 Direct NSEC queries; specs for resolvers and servers.

From: Ólafur Guðmundsson<[email-masked]>
Date: Thu, 12 Feb 2004 23:23:05 -0500

At 15:32 2004-01-28, Paul Vixie wrote:
> > The proposed text therefore is: security aware resolvers MAY query for
> > missing security RRs; implementations that choose to do so must be
> > aware of the fact that the answers received may not be sufficient to
> > perform validation.
>
>this gives no guideance to server implementors, and is therefore inadequate.
>
>how about adding this text:
>
>     security aware responders who receive queries for security RRs which
>     match the content of more than one zone, for example above and below
>     a delegation point, are encouraged to behave self-consistently,
>     which could mean: always return an error; always return
>     above-delegation records; always return below-delegation records;
>     always return no records; always return both above- and
>     below-delegation records; or always something else entirely
>
>in other words, driving home the point that requestor implementors ought not
>depend on the results of queries for security RRs is only part of the story;
>the document should also clearly state that there is no standard behaviour
>for responders, and place a self-consistency requirement there instead.

While attempting to summarize what the consensus of the working group
is on this editors question and trying to interpret this block of text.
Does self-consistently apply to a name or the holy Q-trinity?

RFC103[45] specify NS is on both sides of delegation, and the
lower one be returned to queries, does this imply NSEC should be
handled the same way?

For the record the affected RR types by this text are NS, NSEC, RRSIG.
DS and DNSKEY are not affected as they can only be authoritative on
one side of the delegation.

Right now my read of the working group is that this text is an
improvement over what Olaf put forth as the default result, but
needs clarification on scope.

         Ólafur

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