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: [email-masked]
Date: Mon, 29 Sep 2003 09:59:03 +1000

> >>> One would hope as technical contact for those tld's that
> >>> 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?
> > 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} % 
> 
> 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.

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

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

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

---

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

kre;

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

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: 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
> with a domain name" in the paragraph quoted above, wildcards are uninvolved.

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: [email-masked]
Date: Mon, 29 Sep 2003 23:24:37 +1000

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

	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.

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

	Robert's description is correct.
	
> --Olaf