Re: section 3.2 of protocol draft #2

>>>>> "Miek" == Miek Gieben <miekg@atoom.net> writes:

    Miek> A security-aware recursive name server MUST NOT attempt to
    Miek> answer a query by piecing together non validated, cached
    Miek> data (i.e. glue) it received in response to previous queries
    Miek> that requested different QNAMEs, QTYPEs, or QCLASSes. 

Yes, it is clearer IMO. But I think the security aware server should
do that for all cached data, not just non-validated data. Suppose the
resolver gets a signed answer that says the next name after a.foo is
z.foo. Is it right for the server to infer that no other names exist
between a.foo and z.foo for as long it it caches that answer? If it
then gets a lookup for b.foo, should it respond with the already
cached answer or should it resolve b.foo and return the answer to that
to the client? [Suppose the authoritative servers for foo add b.foo
while the resolving server is still caching that NXT record for a.foo
pointing at z.foo.] There are valid arguments that either of these
options is correct (or wrong). A statement of what's the correct
behaviour for this scenario would be preferable to leaving this
undefined and ambiguous.

How about the text below?

	A security-aware recursive name server MUST NOT synthesise or
	augment responses, for instance to populate the Additional
	Section, using cached data from earlier lookups. Cached data
	MUST NOT be used in a response unless it results from a
	response to an earlier query that exactly matches the QNAME, 
	QTYPE and QCLASS for the current query.

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

12/9/2003 12:23:35 PM
comp.protocols.dns.std 2986 articles. 0 followers. Post Follow

0 Replies

Similar Articles

[PageSpeed] 30