Subject: Re: wcard-clarify's change

From: Randy Bush <[email-masked]>
Date: Sun, 28 Sep 2003 10:53:36 -0700

> this section
> 	6.3 CNAME RR's at a Wild Card Domain Name
> specifies a change to rfc1034 behaviour, whereby a cname at a
> wildcard will be followed.

could you point us to the specific text(s) from rfc 1034 which
proscribes following wildcard cnames?

randy

--
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: 28 Sep 2003 19:45:15 +0000

> proscribes following wildcard cnames?

according to the wcard-clarify draft:

	The issue of CNAME RR's owned by wild card domain names has
	prompted a suggested change to the last paragraph of step 3c of the
	algorithm in 4.3.2.  The changed text is this:

...it's section 4.3.2.  my own reading shows that this is indeed the case.
-- 
Paul Vixie

---

From: Randy Bush <[email-masked]>
Date: Sun, 28 Sep 2003 12:59:10 -0700

> ...it's section 4.3.2.  my own reading shows that this is indeed

which says

    If the "*" label does exist, match RRs at that node
    against QTYPE.  If any match, copy them into the answer
    section, but set the owner of the RR to be QNAME, and

so, if qtype == cname then it would seem that a response would be
appropriate.  though admittedly this is not a very interesting or
sorely needed use.

if qtype != cname, then it would seem to say return no answer.

so please clue me in on how this makes the presence of a wildcard
label on a cname illegal in the data?

randy

---

From: Randy Bush <[email-masked]>
Date: Sun, 28 Sep 2003 13:08:30 -0700

> label on a cname illegal in the data?

whoops!  got it.  it may be present in the data, and may indeed be
returned if qtype == cname.  but the cname rr will not be returned
if qtype != cname, which is what wcard-clarify was seeming to
fumble toward.

therefore, i can see that wcard-clarify is indeed a change not a
clarification.  and i can see that bind's current behavior is a
bug.  thanks.

what i am not firmly sure of is whether, in the abstract, the
proposed change would be good for the internet or not.  could you
amplify if i send a jpg of a root beer?

oh, and would the same theses hold for wildcard dnames?

randy

---

From: Robert Elz <[email-masked]>
Date: Mon, 29 Sep 2003 03:13:24 +0700

Date:        Sun, 28 Sep 2003 10:53:36 -0700
    From:        Randy Bush <[email-masked]>
    Message-ID:  <[email-masked]>

  | could you point us to the specific text(s) from rfc 1034 which
  | proscribes following wildcard cnames?

There is none.

But, if you follow the algorithm in section 4.3.2 precisely (exactly as
it is written, with no latitude for common sense) then a wildcard would
match a CNAME only for a lookup of type CNAME, and no other.

That's because 4.3.2 (3) c says...

	    If the "*" label does exist, match RRs at that node  
            against QTYPE.  If any match, ...

So, if the '*' is of type CNAME, and QTYPE is A (or AAAA or MX or
whatever), then no data gets copied into the answer, and the "goto 6"
doesn't happen.

Of course, in this case, since nothing says "set an authoritative name error"
(as it does if the '*' doesn't exist), one must presume that the correct
answer is NODATA (no answer, no error code).

An alternative is to assume that this is just dumb, and that having the
CNAME exist when you do a CNAME type lookup - which answer can then be cached
at a cache, and used to produce an answer there to a later A (or other)
lookup of the same name - but not used when the authoritative server
generates the same answer is just plain crazy - and that most likely the
real intent (had anyone seriously considered it) would have been for "match"
in that section to have included the normal CNAME processing
(as in 4.3.2 (3) a).

I disagree with Paul's suggestion though - I don't think it is rational
to simply leave 1034 unchanged here - either CNAME at a '*' label needs
to simply be made invalid, or 4.3.2 (3) c needs to be fixed to allow
CNAME processing to take place there.

Of those, I think I'd prefer the latter, it follows the principle of
least astonishment.    While a wildcard CNAME would be a pretty stupid
thing do do (most uses of wildcards are pretty stupid things to do),
I can't think of any really good reason to outlaw it.

kre

ps: Paul, I won't be in Minneapolis, so if you want to give the longer
rant as to why a better change would be to make "* IN CNAME ..." illegal
rather than making it effective, you have better do it on the list.
I think this is one area however where a fix is essential - and this is
a fix to wildcard processing, so this draft is where it should happen.

---

From: Randy Bush <[email-masked]>
Date: Sun, 28 Sep 2003 15:15:09 -0700

a useful application of wildcard cnames was just pointed out to me.

i often get folk asking me 
  o is foo.{gn,lr,ng,...} taken?
  o if not, how do i register it?

and i could simply do
   *.gn.    cname	no-domain.psg.com.
   *.lr.    cname	no-domain.psg.com.
   *.ng.    cname	no-domain.psg.com.
   ...

and use a name-based virtual server to tell them the name is not in
use and point them to the forms and procedures to register in the
domain(s).

otoh, admittedly, i could use up an ip address, and not use a
name-based virtual server.  but this is still a valid use of

randy

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 29 Sep 2003 14:27:53 +0200

Namedroppers,

Let's try to remain in scope, blocking sitefinder is not, I think.
Allow me to try to focus the discussion.

The proposal at hand (paraphrased) is:

  should the suggested change in wcard-clarify ( * CNAME will be
  processed as a cname-chain irrespective of QTYPE) be adopted or
  should we stick to the 1034 behaviour ( once at step 4.2.3.c of the
  algorithm one should only return a match if QTYPE==CNAME and return
  a nameerror for QTYPE!=CNAME ).

Few open questions I could isolate in the thread.

- How do caches deal with the two scenarios.

- Is the proposed change good, or harmful for the Internet. (harmful
  behavior being prohibitive for a change, good being an argument in
  favor of the change)

- How about wildcard DNAMEs?

I have not seen a counter argument against Roberts statement that
caches and authoritative servers will behave differently when a cache
has previously stored the result of a QTYPE=CNAME query. 

--Olaf