Subject: WCARD-CLARIFY ISSUE: caching of !NAME=*.<something>

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 15 Sep 2003 09:47:28 +0200

name: Olaf Kolkman
email: olaf at ripe.net
Date: Sep 13, 2003
Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01670.html
Type: Text
Priority: Urgent

Document: draft-ietf-dnsext-wcard-clarify-01

Section: 4 Impact of a Wild Card Domain In a Query Message or in an
	 RDATA field

Rationale/Explanation of issue:

The issue is that the draft updates RFC1034 with respect to
*.<something> queries. Does the working group want this to happen.
  
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01670.html:
  >
  > | R4.1 A wild card domain name acting as a QNAME MUST be treated as any
  > |        other QNAME, there MUST be no special processing accorded it.
  > 
  >
  > This appear to be over-qualified; it isn't valid in the point of view
  > of a client.  Specifically: RFC 1034 section 4.3.3 says results from
  > wildcard queries should not be cached.  Hence there actually is
  > special processing accorded to wild card labels in a QNAME.

and (among others):
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01721.html

  > ....
  > I do not, however, understand why a cache shouldn't remember a response
  > to a "wildcard" (i.e. "*.<something>") query. Probably that was meant to
  > discourage synthesis of responses by (non-authoritative) caches. Wildcard
  > synthesis should of course only be performed by an authoritative server.
  > 

Proposed change:
 
Keep the existing text; thereby updating RFC1034, but allowing caches
to stick to 1034 behavior as specified by the text below:

  R4.1 A wild card domain name acting as a QNAME MUST be treated as any
       other QNAME, caches MAY not cache the result of a wildcard query but 
       there MUST be no other special processing accorded it.

  If a cache caches the result of a wildcard query it is by virtue of
  the above not allowed to use the data for synthesis of answers.  If a
  wild card domain name appears in the RDATA of a CNAME RR or any other
  RR that has a domain name in it, the same rule applies.  In the ...etc..

--
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: Robert Elz <[email-masked]>
Date: Mon, 15 Sep 2003 22:55:13 +0700

Date:        Mon, 15 Sep 2003 09:47:28 +0200
    From:        "Olaf M. Kolkman" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Proposed change:
  |  
  | Keep the existing text; thereby updating RFC1034, but allowing caches
  | to stick to 1034 behavior as specified by the text below:
  | 
  |   R4.1 A wild card domain name acting as a QNAME MUST be treated as any
  |        other QNAME, caches MAY not cache the result of a wildcard query but 
  |        there MUST be no other special processing accorded it.

I suspect that the document should be a bit more brutal than that.

That is, it should say, somewhere very early ...

	Wildcard processing for a zone is performed only at
	authoritative servers for the zone.   Resolvers, other
	servers, and caches, MUST NOT attempt to interpret wildcards.

There isn't any real need to say that caches aren't required to cache
the result of an explicit QNAME='*.domain' lookup - they're not required
to cache anything, that is the very nature of a cache.

I don't see any particular point in prohibiting the answer from being
cached however, so changing that bit of 1034 would be OK.   But nor do
I believe that this is an important change to make.

kre