Subject: Re: DNSEXT WGLC: Wildcard Clarify

From: [email-masked]
Date: Wed, 24 Sep 2003 10:22:25 -0700 (PDT)

> Open Issues:
> thread starting at:
> http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01758.html

	e.g. multi-wildcard lable domains.

	this is a non-issue, although there is some disagreement between
	R1.2 and R2.2 in the draft.  R1.2 is -VERY- clear as to what
	consitutes a wildcard lable, i.e. a single character.  
	
	the note in R2.2 is confusing and should be removed to a document
	that clarifies the distinction between a domain lable (wildcard or no)
	and a host lable. 

	how would wildcard-clarify accomodate my new laptop, which I have named *
	and it sits in the domain example.com?

	*.example.com.	in a 192.0.2.2

	Same for appendix A.  this should be a companion document.

> and thread starting at:
> http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01757.html

	I like the proposed wording changes for R4.1

> -- Olaf
>    DNSEXT Co-Chair

--
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: Thu, 25 Sep 2003 16:34:41 +0000

> This is better text, in my opinion.  If the concensus is to allow
> caching of "*.example.com" queries, that's fine, but the strict
> restriction on further special processing should remain.  That's the
> important part after all.

this prohibition would have to be effected by having the authority server
set the TTL to 0 on any synthesized responses.  synthesis does not occur
at the caching server, and caching servers have no insight into whether
or not a wildcard exists, or whether a wildcard was used to synthesize the
data being cached (or not).  i think that the document should make this
clearer.

---

From: Robert Elz <[email-masked]>
Date: Fri, 26 Sep 2003 00:31:43 +0700

Date:        Thu, 25 Sep 2003 16:34:41 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | this prohibition would have to be effected by having the authority server
  | set the TTL to 0 on any synthesized responses.  synthesis does not occur
  | at the caching server, and caching servers have no insight into whether
  | or not a wildcard exists, or whether a wildcard was used to synthesize the
  | data being cached (or not).  i think that the document should make this
  | clearer.

No, Paul, you're misunderstanding the point.  1034 says that is a resolver
does an explicit lookup for '*', then the results "should not" be cached.

This has nothing at all to do with a lookup of some random other name that
happens to match a wildcard - for those, you're right, the cache simply has
no way to know.

But a cache can see a lookup where the QNAME happens to be "*.whatever.domain"
and do magic stuff with it - 1034 says not to cache the answer - but that's
the only special processing that the cache is to be allowed to do.

kre