DNAME understanding

[John C Klensin]

--On Friday, December 04, 2009 19:48 +0000 Shawn Steele
<Shawn.Steele at microsoft.com> wrote:

> It was stated that DNAME doesn't solve mail.
> 
> Which makes me wonder if I do have two forms of a string I
> think users might enter (say X & Y), then is there any way of
> making sure that http://X works and http://Y works too?

   X. CNAME Y.

Unless you think that "X" and "Y" are abbreviations for
something that need to be searched for.  At that point, all bets
are off, and DNAMEs may not work where Andrew would expect from
looking at the DNS alone.

>  And
> that mail to me at X<mailto:me at X> works as well as mail to
> me at Y<mailto:me at Y>?

For reasons that are somewhat analogous to the use and handling
of the HOST command to HTTP, mail servers need to know their own
names and really need to know the names by which users know
them.  While I'd expect implementations to force names into ACE
forms and then recognize those, there are some interesting
nightmares there, especially if the mail server can be addressed
using both "internal" and "public" name spaces.  

So one problem is that, if Y is handled as some sort of DNS
alias to X, the server(s) associated with X's MX records has to
also be configured to recognize that name -- and to recognize it
in all of the forms it can take.  If Y is handled as a separate
mail host, with MX records identical to the MX records for X,
the servers still have to know all of the forms of the names for
both X and Y, but some of the issues may be a little different.
Remember too that email addresses are generally case-sensitive
in the local parts, which raises another set of subtle issues...
and we won't know how well the EAI version of handling those
issues works until we get more deployment experience.

Protocols are different and interpret identifier names and
namespaces differently.   Inferring that the right solutions for
the web are the right solutions for email --much less for the
protocol that will be invented next week-- is the path to big
trouble.

> I'm concerned that there are some International cases where
> this is necessary.  Some languages have alternate spellings
> that are common within the country. (Norwegian I think does
> this?  But I don't know how users behave in that environment.)

I'll let Harald address Norwegian if he has the time and
inclination, but...

> Eg: color and colour, though often the variation in English
> isn't that interesting to DNS.

But, as Andrew has pointed out, there are places in Canada where
the two must be treated interchangeably.    In that context, I
don't know what "isn't that interesting to DNS" means: if one is
going to make allowances for the Norwegian situation to which
you refer (really two separate languages), it is not clear to me
how one justifies not recognizing Torbjörn and Torbøjrn as the
same name (a topic about which both Harald and Patrik have
reason to be sensitive), recognizing "color" and "colour" as
having the same meaning/intent, and even routing mail to
Sean.Steele at microsoft.com to your address (which the real Sean
Steel (sic) might not like).

The DNS just doesn't do the sorts of things that are needed to
support things like that.  And we just introduce confusion for
users by supporting some of them while ones that seem even more
natural to a given group of users are not supported.  Registries
may know enough about their own environments, or see significant
enough revenue opportunities or risks, to want to figure out how
to bind some names together.  But the slope is both steep and
slippery if we start mandating much of anything.

     john