Subject: section 3.2 of protocol draft

From: Miek Gieben <[email-masked]>
Date: Mon, 8 Dec 2003 14:10:59 +0100

Hello,

I'm rereading the protocol draft again, and I'm wondering about the following
paragraph.

In section 3.2: Recursive Name Servers
2nd paragraph:

   A security-aware recursive name server MUST NOT attempt to answer a
   query by piecing together cached data it received in response 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.

I don't "get" the first sentence. does that really say: "don't use the cache"?
If i'm a cache and i've just validated a DNSKEY in response to another query,
I cannot use that validated DNSKEY?

Further more, if this question is answered negatively (A cache can still be used),
i'm wondering why is this put in a protocol draft? Isn't this bordering implementation
details?

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: [email-masked]
Date: Wed, 10 Dec 2003 00:03:08 +1100

> [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)
> 
> --
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]