Subject: wcard-clarify's change

From: Paul Vixie <[email-masked]>
Date: Sun, 28 Sep 2003 15:03:22 +0000

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.  i consider this change to be ill considered, and would
like to see the document progress without it.  wcard-clarify should only
clarify, and not change anything.

a longer rant about why this change is not only ill considered but also
ill advised will be available for the price of one beer (in minneapolis.)

note that bind8 and bind9 both follow cnames at wildcards, in violation
of rfc1034, and that i would rather we patch the code than change the spec.

--
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: Randy Bush <[email-masked]>
Date: Sun, 28 Sep 2003 10:53:36 -0700

> 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

---

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: Paul Vixie <[email-masked]>
Date: Sun, 28 Sep 2003 22:58:56 +0000

> match a CNAME only for a lookup of type CNAME, and no other.

i consider that the correct, and sensible, interpretation.  clarification
is needed only because it's astonishing to some, not because it's unclear
as written.

> whatever), then no data gets copied into the answer, and the "goto 6"

right.  cname processing happens earlier than, and exclusive of, wildcarding.

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

i think if someone puts a wildcard cname into their zone, then noerror/nodata
is the correct answer.  (the workaround is, don't put in a wildcard cname.)

> CNAME processing to take place there.

then at least our disagreement requires no clarification.

> rather than making it effective, you have better do it on the list.

i don't expect that we'd entertain anybody by such ranting.  let's see if
anyone else has a view on this topic.

> a fix to wildcard processing, so this draft is where it should happen.

at a minimum, i think that this draft should only clarify, not "fix" things.
separately, we can rant about whether rfc1034 needs to be "fixed".

---

From: [email-masked]
Date: Mon, 29 Sep 2003 09:03:56 +1000

> name-based virtual server.  but this is still a valid use of

	One would hope as technical contact for those tld's that
	you would actually dissuade this use.

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

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

> you would actually dissuade this use.

perhaps you would care to go beyond hope into technical or social
reasons why this is damaging to the internet?

randy

---

From: [email-masked]
Date: Mon, 29 Sep 2003 09:31:57 +1000

> >> name-based virtual server.  but this is still a valid use of

	You can still use a name-based virtual server with IP addresses.

> reasons why this is damaging to the internet?

	I actually like to get error messages when I mistype a address.

bsdi:src 09:17 {1899} % date; telnet xxx.yy.uk ; date
Mon Sep 29 09:18:10 EST 2003
xxx.yy.uk: No address associated with hostname
Mon Sep 29 09:18:10 EST 2003
bsdi:src 09:18 {1900} % date; telnet this-name-doesnt-exist.com ; date
Mon Sep 29 09:18:18 EST 2003
Trying 64.94.110.11...
telnet: connect to address 64.94.110.11: Operation timed out
telnet: Unable to connect to remote host
Mon Sep 29 09:19:33 EST 2003
bsdi:src 09:18 {1901} % 

	Lots of traffic for no real benefit on other techniques for
	finding out if a name exists or not.  Verisign don't even
	send RST with their sitefinder service.

09:22:03.743383 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 202454889 0> (DF) [tos 0x10] 
09:22:06.739395 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 202455189 0> (DF) [tos 0x10] 
09:22:09.939438 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 202455509 0> (DF) [tos 0x10] 
09:22:13.139500 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460> (DF) [tos 0x10] 
09:22:16.339581 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460> (DF) [tos 0x10] 
09:22:19.539617 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460> (DF) [tos 0x10] 
09:22:25.739726 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460> (DF) [tos 0x10] 
09:22:37.939919 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460> (DF) [tos 0x10] 
09:23:02.140393 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460> (DF) [tos 0x10]

---

From: Randy Bush <[email-masked]>
Date: Sun, 28 Sep 2003 16:42:56 -0700

> Mon Sep 29 09:19:33 EST 2003

yep.  but not one of the folk who ask me "is domain name foo taken"
would know an error message if windows 95 gave it to them.  and they
think dig is something done with a shovel, unless they're over 50 and
still think they're pretty hep.

end users seem to use dns for web lookup and for email addresses.
but duane wessels's environmental impact statement is relevant to
this as well <http://www.packet-pushers.net/tld-wildcards/>.  so,
while i don't think i will do it, i suspect other will, and i am
not sure i should tell them they absolutely shouldn't.

have you tried <http://no-domane.museum/>?

randy

---

From: [email-masked]
Date: Mon, 29 Sep 2003 09:59:03 +1000

> still think they're pretty hep.

	This is a education process.  The still need to learn how
	to interpert error messages unless you make adding wildcards
	MANDITORY below every non-wildcard node in the DNS and
	remove empty nodes.
 
> have you tried <http://no-domane.museum/>?

	But does what museum does work for general tlds verses the
	very narrow focus of museum?

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 29 Sep 2003 08:56:09 +0859 ()

Randy;

> use and point them to the forms and procedures to register in the

You can do it better (the web server can know the domain name
desired) with

>    *.gn.    ns	no-domain-ns0.psg.com.
>    *.gn.    ns	no-domain-ns1.psg.com.
>    *.lr.    ns	no-domain-ns0.psg.com.
>    *.lr.    ns	no-domain-ns1.psg.com.
>    *.ng.    ns	no-domain-ns0.psg.com.
>    *.ng.    ns	no-domain-ns1.psg.com.

which is why delegation-only of BIND does not work.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 29 Sep 2003 09:19:14 +0859 ()

kre;

> answer is NODATA (no answer, no error code).

That is the best possible interpretation of 4.3.2.

However, it is also written in rfc1034 that:

   CNAME RRs cause special action in DNS software.  When a name server
   fails to find a desired RR in the resource set associated with the
   domain name, it checks to see if the resource set consists of a CNAME
   record with a matching class.

And it can be said that a domain name matching a wildcard CNAME
is associated with the CNAME but no other RRs.

							Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Mon, 29 Sep 2003 03:00:35 +0000

> >    *.ng.    ns	no-domain-ns1.psg.com.

not with bind you won't.  perhaps there is software somewhere that
misreads and misimplements 1034 in that way, but this once, bind isn't
it.  it's dimly possible that dname is supposed to work like this, but
not NS.

> which is why delegation-only of BIND does not work.

that being a separate issue, i'll address it anyway.  the official
position of verisign with regard to their wildcard labels under .com
and .net is "users are free to block sitefinder if they want, we're
only doing it as a service to the internet community."  before they
(or indeed the .tk people or any of the others) could hack their
name servers to respond with an extra set of NS RRs for this, they
would have to make a public statement, "we just want to monetize
eyeballs and we'll crush anyone who gets in our way" which i think
is a statement they won't make.

therefore root-delegation-only is not BIND's answer to a prolonged
conflict but rather a way to let people "opt out" of something that
at least one gtld administrator has said "opting out of" is okay.

had this been an actual "final solution to wildcards" it would likely
have been implemented very differently.  this is a layer 9 problem,
and root-delegation-only is essentially a layer 9 solution to it.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 29 Sep 2003 03:05:34 +0000

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

> is associated with the CNAME but no other RRs.

what 1034 calls a "resource set" is a "set of rrsets" by modern terminology,
that is, "all rrsets at a node" or even "all rrs at a node".  by "associated
with a domain name" in the paragraph quoted above, wildcards are uninvolved.

there is no incoherency (on this point) in 1034.  wildcard cnames aren't in.
the fact that any version of bind ever pretended or still pretends to support
this unspecified behaviour is an embarrassment to me personally and to isc.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Sep 2003 03:20:49 -0000

Paul Vixie writes, paraphrasing VeriSign:
> "users are free to block sitefinder if they want, we're
> only doing it as a service to the internet community."

Spammers say ``Users are free to delete our messages if they want.''

They nevertheless work around every _automated_ anti-spam mechanism as
soon as the mechanism becomes popular---making the mechanism useless.

That's exactly what VeriSign is going to do to your ``delegation-only''
mechanism if that mechanism becomes popular. They will, of course,
continue saying that users are free to block sitefinder.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Robert Elz <[email-masked]>
Date: Mon, 29 Sep 2003 15:18:23 +0700

Date:        Sun, 28 Sep 2003 22:58:56 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | i consider that the correct, and sensible, interpretation.

Yes, but it is your opinion of what is the correct interpretation.
It isn't necessarily the only one.

  | at a minimum, i think that this draft should only clarify, not "fix" things.
  | separately, we can rant about whether rfc1034 needs to be "fixed".

I agree with that where "fix" means "we don't like this behaviour" or
"we really should change this because ...".

But not where "fix" is applied to "what is stated is logically inconsistent,
we have to choose one or the other".

In your reply you completely dropped the issue of the activities at caches,
and how (assuming your interpretation of 1034 is correct) we end in a state
where caches are giving out different answers, depending upon what queries
they happen to have processed earlier.    That's an absurd state, that I don't
believe can be permitted to exist.

I don't much care which correction is made, but here I believe a correction
is vital, we simply cannot knowingly publish a document that undermines
correct DNS operations (makes them impossible).

kre

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 29 Sep 2003 20:53:55 +0859 ()

Paul;

> what 1034 calls a "resource set" is a "set of rrsets" by modern terminology,

"rrsets"?

Wrong.

In mathematical terminlogy of set theory, which should be used
also in all the RFCs, "resource set" is "set of resourcees" or
"set of RRs".

You should distinguish a "set of RRs" and a "set of sets of RRs",
which are mathematically different.

"integer set" is "set of integers", not "set of integer sets".

"{1, 2, 3, 4}" is a "set of integers", while "{{1}, {2}, {3, 4}}" is a
"set of integer sets".

> that is, "all rrsets at a node" or even "all rrs at a node".

"node"?

Wrong again.

In the quoted paragraph, it is not a "node", but a "domain name", though
the mistake is not so serious.

> by "associated

Unfounded statement.

A natural interpretation of rfc1034 is that a domain name matching a
wildcard is associated with a set of RRs of the wildcard.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 29 Sep 2003 21:04:19 +0859 ()

Paul;

> not with bind you won't.

Haven't you read draft-ietf-dnsext-wcard-clarify-01.txt stating:

   6.2 NS RR's at a Wild Card Domain Name

   Is it not a protocol error to have a NS RR owned by a wild card domian name,
   complimentary to the case of a SOA RR.  However, for this to work, an
   implementation has to know how to synthesize a zone.

?

> perhaps there is software somewhere that
> it.

Hmmm.

> it's dimly possible that dname is supposed to work like this, but
> not NS.

Can we obsolete dname?

						Masataka Ohta

---

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

---

From: [email-masked]
Date: Mon, 29 Sep 2003 23:24:37 +1000

>   behavior being prohibitive for a change, good being an argument in

	RFC 1034's behaviour is broken.  Either change (outlaw or make
	work) is better than the current.  Neither change is harmful
	to the net.  A wildcard CNAME is no worse than a wildcard A.

> - How about wildcard DNAMEs?

	Wildcard DNAMES don't make sence.  They only have a impact
	in a cache.

	*.example.net DNAME example.com

	Qname a.b.c.example.net

	After expansion you have "a.b.c.example.net DNAME example.com"
	This does not result in DNAME processing occuring as it is not
	above the qname.

	If the qtype however is DNAME it will be returned and affect
	subsequent queries to this cache.

	A qname of presented to the cache of e.f.a.b.c.example.net
	will become

	a.b.c.example.net DNAME example.com
	e.f.a.b.c.example.net CNAME e.f.example.com

	At the same time you could also have a different cache returning

	c.example.net DNAME example.com
	e.f.a.b.c.example.net CNAME e.f.a.b.example.com
 
	and to answer Masataka Ohta
	
	I think DNAME should remain.  It is useful.

> has previously stored the result of a QTYPE=CNAME query. 

	Robert's description is correct.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 29 Sep 2003 16:45:11 +0000

> has previously stored the result of a QTYPE=CNAME query. 

i think the clarification that bears on that point is that
wildcard-synthesized data should have TTL=0 to prevent caching.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 30 Sep 2003 06:26:38 +0859 ()

> wildcard-synthesized data should have TTL=0 to prevent caching.

The only recommended behaviour for wildcarded CNAME is, just
like other wildcarded RRs, that raw wildcard data should not be
cached to prevent faulty implementations use it for synthesis.

Wildcard-synthesized data is just as valid as non-synthesized ones.

							Masataka Ohta

---

From: Robert Elz <[email-masked]>
Date: Tue, 30 Sep 2003 08:58:39 +0700

Date:        Mon, 29 Sep 2003 16:45:11 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | i think the clarification that bears on that point is that
  | wildcard-synthesized data should have TTL=0 to prevent caching.

That would certainly not be a clarification, that would be a change,
without doubt.

Making the algorithm explicitly handle wildcard CNAMES can be seen
as a clarification (or what was intended) - forcing TTL=0 certainly
cannot.

Alternatively, if the common view is that wildcard CNAME shouldn't work,
then simply outlawing it could also be seen as a clarification (since the
algorithm doesn't work, it must have been intended not to be allowed),
forcing TTL=0 certainly cannot...

kre