DNAME understanding

John C Klensin klensin at jck.com
Sun Dec 6 15:54:31 CET 2009



--On Saturday, December 05, 2009 02:56 +0000 John Levine
<johnl at taugh.com> wrote:

>> 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.
> 
> It seems to me that the issues with mail servers are
> essentially the same as the ones with virtual named web hosts,
> in which a single server on a single IP has multiple names
> that are semantically different, and if the host gets traffic
> for a name it's not expecting it won't know what to do with
> it.  This isn't specific to DNAMEs or CNAMEs, of course, since
> you can create the same problems with a few A or MX records.

Well, the option of doing it with MX records introduces some
small additional complexity and HOST is still not required in
practice while I don't know of any production mail client that
will accept a RCPT command from the public Internet without a
domain name.  But I'd probably agree with "essentially the same".

> Isn't this more a management than a technical issue?  Surely
> there's no hope of folding together all the world's equivalent
> spellings no matter what hacks we use to serve the DNS.

Those are exactly the points I was trying to make.   There is no
DNS magic --either extant or possible to propose-- that will
make multiple spelling forms of the same word automagically
equivalent.  One can identify the equivalent forms and do things
in the applications, possibly with DNS support (most likely by
having all variations on spelling registered to the same party),
but there is no magic.

The EAI work adds an additional layer of importance to U-label
<-> A-label symmetry.  That work assumes that mailboxes will be
expressed in Unicode (UTF-something form; UTF-8 on  the wire)
without any requirement for conversion to ACE / A-label form
until/ unless one actually needs to do a DNS lookup.  Although
many readers of this list may not be, you are familiar enough
with how email servers and associated systems are structured to
understand why I'm concerned that, if domain names containing
U-labels can't be tested to determine whether a mailbox domain
actually matches a given server, we are likely to see big
implementation problems: lots of pieces of the system that try
to match (including filtering, queue-sorting, or categorizing
on) names may be 8bit-clean enough to handle internationalized
UTF-8 addresses without difficulty but don't have nearly enough
clue about the DNS or IDNA to do IDNA2003 (mandatory conversion
to ACE) matching.   Even worse, the resolution context issues
discussed during the Hiroshima plenary apply to email too: if
one needs to know the resolution context in order to know how to
compare _in an application_ one is in even worse shape than
having to know it in order to figure out how to code something
to look it up and where to look it up.

    john



More information about the Idna-update mailing list