Re: section 3.2 of protocol draft

[Mark.Andrews@isc.org]

> [On 08 Dec, @16:22, Jim wrote in "Re: section 3.2 of protocol dr ..."]
> > No, it doesn't say "don't use the cache". Well, not to this
> > mother-tongue English speaker anyway. It says "don't use cached data
> > to compose or fill out an answer to a query you've not resolved". I
> > think the intention here is to cover things like glue or partial
> > responses from an authoritative server. If the resolving server has
> > previously resolved and validated the glue or other stuff that might
> > be missing from the authoritative server's response, the resolving
> > server MUST NOT add these things to the reply it returns to its end
> > client. That's my interpretation of this bit of the draft.
> > 
> > Perhaps the language could be made less opaque?
> 
> Maybe the following is clearer:
> 
> A security-aware recursive name server MUST NOT attempt to answer a query by
> piecing together non validated, cached data (i.e. glue) it received in respon
> se
> to previous queries that requested different QNAMEs, QTYPEs, or QCLASSes.  A
> security-aware recursive name server MUST NOT use NSEC RRs from one negative
> response to synthesize a response for a different query.  A security-aware
> recursive name server MUST NOT use a previous wildcard expansion to generate 
> a
> response to a different query.

	Why are we arguing over what it currently says?  The current
	text is overly restrictive.  We should be trying to determine
	firstly what we are going recommend that every server SHOULD do.
	What they MAY do, what the SHOULD NOT and MUST NOT do.

	At a minimum negative answers against the same QNAME and QCLASS
	need to be allowed again "Name Error" to bring the draft into
	alignment with RFC 2308.  "Name Error" is independent of QTYPE.
	(SHOULD)

	Also at a minimum negative answers against the same QNAME and
	QCLASS need to be allowed against "NODATA".  This is a extention
	on RFC 2308.  The NSEC bitmap clearly allows a cache to determine
	which types do not exist when the query was made.  All of these
	would return the same authority section.
	(SHOULD)

	Both of these cases allow a internally consistant negative
	answer to be returned.

	NXDOMAIN requires the two proofs to be returned
	* QNAME does not exist
	* Wildcard does not exist
	
	NODATA require one or two proofs to be returned depending apon
	whether the answer is from a wildcard or not.
	non-wildcard:
	* QNAME exists but does not have type
	wildcard:
	* QNAME does not exist
	* wildcard exist but does not have type


	What get more interesting is should we allow a cache to to
	take the knowledge that a previous positive answer came
	from a wildcard and just query for the wildcard.  My feeling
	in this case is NO.  You still need to make a query to the
	server so we don't save anything there.  We would potentially
	save one proof (QNAME does not exist) in the answer, however
	you combining the two answers could give a internally
	inconsistant answer.
	(SHOULD NOT)

	Following a wildcard CNAME can also produce a internally
	inconsistant answer if the CNAME refers to the same zone.
	CNAME chains also have this problem if they go back to a
	previous zone.  I suspect that we just have to live with
	this one.

	Another case mention at MN is where the QNAME and QCLASS
	matches a existing NSEC and the type is not in the bitmap
	however the NSEC was not learnt via the NSEC ownername.
	e.g. as one of the proofs in a NXDOMAIN or QNAME does not
	exist for a wildcard.

	I think this case can also safely be returned.
	(MAY)

	Next comes names that are within a span of a NSEC record.
	Theoretically it is possible to constuct a response from 
	these provided you also have the answer to the corresponding
	wildcard (NXDOMAIN, NODATA and positive) answer.
	(SHOULD NOT, MUST NOT?)

> grtz
>       Miek
> --
> Serenity now!
> -- Frank Costanza (Seinfeld)
> 
> --
> 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/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org

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