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

From: Olaf Kolkman <[email-masked]>
Date: Wed, 28 Jan 2004 14:20:22 +0100

This is related to the thread starting at:
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00053.html

The document currently requires a security aware resolver to
query for security related RRs needed to complete a validation. Given
that both parent and child have NSEC and RRSIG records for a
delegation, the logic for fetching those records is likely to be very
complicated, much as is the logic for fetching a DS record when the
grandparent situation exists. Since the authoritative server special
processing rules are supposed to deliver all records needed for
validation, it is safe to weaken this requirement.

(One must also note that the requirement (RFC2535 5.5) to serve the
NSEC from both the parent and the child if both are available will
lead to inconsistencies between answer from different authoritative
servers and answers from recursive nameservers. Therefore and because
of the argument about the special processing rules above the
requirement is consciously not copied into the DNSSECbis specs and
left unspecified).

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.

--Olaf

--
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, 28 Jan 2004 20:32:33 +0000

> aware of the fact that the answers received may not be sufficient to

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.

---

From: Miek Gieben <[email-masked]>
Date: Thu, 29 Jan 2004 10:07:02 +0100

[On 28 Jan, @21:32, Paul wrote in "Re: Q-23 Direct NSEC queries;  ..."]
> in other words, driving home the point that requestor implementors ought not

I like this text more than the one provided by Olaf,

grtz Miek