Subject: Re: DNSEXT WGLC: Wildcard Clarify

From: "Scott Rose" <[email-masked]>
Date: Wed, 24 Sep 2003 15:11:03 -0400

----- Original Message ----- 
From: <[email-masked]>
>
>
> > and thread starting at:
> > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01757.html
>
> I like the proposed wording changes for R4.1
>

I agree, but I think there is a typo:

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

I think it would read better if it read:  "...caches MAY cache the result of
a wildcard query but there MUST NOT be other special processing accorded
it."

Scott

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

--
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: Thu, 25 Sep 2003 13:48:25 +0700

Date:        Wed, 24 Sep 2003 15:11:03 -0400
    From:        "Scott Rose" <[email-masked]>
    Message-ID:  <010f01c382cf$9aab13d0$b9370681@barnacle>

  | I agree, but I think there is a typo:

Actually, I don't think that's a typo, just very bad wording.

  |   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 think it would read better if it read:  "...caches MAY cache the result of
  | a wildcard query but there MUST NOT be other special processing accorded
  | it."

Note that it is "MAY not" and not "MAY NOT" - what it is attempting to
say, is that unlike other queries, caches are permitted to fail to cache
wildcard queries (by which I believe it really means explicit queries for
a '*' name, there is no such thing really as a wildcard query).

It really has to say that, as 1034 suggested that behaviour (though, why
isn't clear to me).   Since the intent here isn't really to alter 1034 at
all, it has to permit 1034 mandated actions...

Failing to cache the query would be special processing for the '*' lookup
in the cache - they cache the results of lookups for every other name.
So, if that is permitted, caches are starting to do special things with
wildcard lookups - the main point of that sentence is to limit that
special processing to just "don't cache", nothing else magic about
wildcards at all - that is, if the cache does cache the thing, it isn't
then permitted to synthesise answers to other questions based upon the
wildcard it now knows exists.

Rewriting it the way you suggest makes it read much more sensibly, but
turns it into an explicit (rather than just implied) reversal of what
1034 said to do (said not to do), which I don't believe needs to happen here.

Perhaps we should just recognise that the 2119 MAY is a meaningless
term (using that magic upper case word never really achieves anything
in normal documents - but note, as used in 1122/1123 it did have a
purpose) and just rewrite the sentence to avoid it.

Maybe something like

	R4.1  A wild card domain name acting as a QNAME MUST be treated
	      as any other QNAME.   Caches are not required to cache the
	      results of such a lookup (see RFC1034 section 4.3.3), but
	      there MUST be no other special processing accorded it.

kre

---

From: Robert Elz <[email-masked]>
Date: Thu, 25 Sep 2003 14:02:06 +0700

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

  | 	e.g. multi-wildcard lable domains.

lable?   Really Bill!

  | 	this is a non-issue, although there is some disagreement between
  | 	R1.2 and R2.2 in the draft.

What is R1.2 ?   Do you mean section 1.2 ?

  |	R1.2 is -VERY- clear as to what
  | 	consitutes a wildcard lable, i.e. a single character. 

I don't think it says that, and it certainly can't mean that.

I believe you're saying that

	$ORIGIN example.com.
	@	IN SOA (whatever)
	*	IN MX	foo.example.com.

is a wildcard, whereas, continuing in the same zone file

	*.example.com. IN A 10.11.12.13

is not - which is utter nonsense.

All names in the label field, '*' or not, which don't end in '.'
have the current origin appended to them, before any other processing
happens.

If the name, within the current zone, is '*', then it is a wildcard,
regardless of how that got entered in the master zone file (assuming
there even is one).

Just think of how the zone gets transferred via AXFR ...

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

No, it shouldn't me moved elsewhere, it should just be ditched.   I thought
we had that covered already - it is nonsense.

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

Same for that, it just needs to go away.

kre

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 25 Sep 2003 10:32:08 -0400

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.

Scott

----- Original Message ----- 
From: "Robert Elz" <[email-masked]>