Subject: Re: [dnsext] Bundling of Domain Names and DNAME

From: Alfred Hönes <[email-masked]>
Date: Mon, 7 Dec 2009 21:19:46 +0100 (MEZ)

Edward and all,

the whole discussion on this thread seems to miss the most
important implication from an application and consistency
point of view, and please also note that the anchor posting for
this thread dealt with alias domain names in the _second_ level
(inside a TLD), not in the root zone.
The situation is a bit different in the second level since
it is much more likely that such domains (if the parent is
"registry-like") shall serve applications at their apex name.
I.e., <someservice> for tld is much more likely to be hosted at
say, "tld-nic.tld." than at "tld." directly, whereas such service
for example.tld is likely present at "example.tld." directly.
(Some specifications and practices even _forbid_ services at
single-label FQDNs.)

Some application protocols require (for various reasons
not subject to debate on this list) that the domain names
appearing in their 'reality' resolve _directly_ to the
proper resource records for the application, and they
explicitly forbid redirection by CNAME or DNAME during
the resolution process.

The most important and well-known example is [E]SMTP.

Assume   xn--12345.tld.  DNAME  example.tld.  ,
and assume mail for the mailbox  [email-masked] .
An MTA that has to deliver such mail must perform an MX lookup
for the rhs domain name in the mailbox name,  xn--12345.tld.
Whenever the MX lookup does not find an MX RR at the alias
domain name because these RRs are maintained in the 'primary'
zone "example.tld." and hence returns a DNAME and/or a
synthesized CNAME, the [E]SMTP mail address resolution process
immediately falls back to 'address' record DNS lookup, i.e.,
it tries  A and/or AAAA lookup at the same owner name.
This way, you loose the flexibility, resilience, and load
balancing properties of MX.

If there is/are such address records at the owner name of the
DNAME RR as well, and there is indeed an ESMTP server listening
on TCP port 25 there, the fallback will succeed.
But you need to have the address record in the .tld. zone
for this success, and there could be different A/AAAA RRs at
the target domain of the DNAME; so a lookup for the 'primary'
domain name in the 'alias' group might return a different
result, leading to another mail server.  This way, the content
of the primary domain and its alias domain(s) are not guaranteed
to be identical.
Similarly, MX RRs indeed present at the owner name of the DNAME
would run the risk of becoming inconsistent with the MX RRs at
the DNAME target.
But if that's possible, by definition the domains are not
identical and hence the domain names are not proper "aliases".

This consistency problem is the basic logical issue with
domain aliases in "registry-like" domains (e.g. TLDs and,
to a lesser extent, the root), where the zone servers and
operators of the child zone and the parent zone are most
likely different and synchronization of more than just
delegation information and glue at the parent with the child
zone poses new operational and responsibility challenges.

The only means *at a protocol level* to address this issue
in a hypothetical XNAME RR would be to have the server of the
zone containing the XNAME to operate as a recursive resolver
for exactly one step when encountering an XNAME RR and answer
with the authoritative data from the target zone.
But that would cause much more complications for DNSSEC and
would not be tolerable from an operational PoV.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 07 Dec 2009 18:17:36 -0500

> balancing properties of MX.
Alfred,
Are you sure about that? RFC 5321 (Section 5, second paragraph) says

The lookup first attempts to locate an MX record associated with the
   name.  If a CNAME record is found, the resulting name is processed as
   if it were the initial name. 

To me, this describes a "query restart". With the above in mind, in your 
example, after getting the synthesized CNAME, the SMTP client's next 
step would be to query example.tld/MX, -not- to fail over to a 
xn--12345.tld/A and/or xn--12345.tld/AAAA query. The benefits of MX 
records are thus preserved.

We don't see this in normal operation, of course, since resolvers will 
"chase" the CNAME and return the MX record(s) regardless. But in the 
pathological case where only a bare CNAME is returned, the above 
language suggests that the SMTP client should take on the responsibility 
of doing the "chasing" itself.

Alternatively, from a more conservative SMTP perspective, an "un-chased 
CNAME" response could be considered a resolver error, similar to a 
resolver timeout or a SERVFAIL. This would be a temporary error 
condition, so the SMTP client would queue and retry, hoping that the 
resolver will, at some point in the future, recover from its malady and 
regain the ability to chase CNAMEs.

Passing thought: perhaps someone should let the SMTP folks know about 
DNAME, since there is no mention of it in RFC 5321, and thus handling of 
a DNAME response remains undefined.

- Kevin

---

From: SM <[email-masked]>
Date: Mon, 07 Dec 2009 23:48:21 -0800

At 15:17 07-12-2009, Kevin Darcy wrote:
>Passing thought: perhaps someone should let the SMTP folks know 
>about DNAME, since there is no mention of it in RFC 5321, and thus 
>handling of a DNAME response remains undefined.

Please suggest text if you want to change that.

At 17:53 07-12-2009, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:
>RFC 5321 points to RFC 1035 and RFC 2181, Section 10.3 for these
>purposes.  RFC 5321 does not update these RFCs.  However, for MX,
>RFC 1035 normatively refers to RFC 974, which has been obsoleted
>by RFC 2821, which has been obsoleted by RFC 5321 ... :-)

RFC 5321 specifies how to locate the target host. :-)

>If you would like to have DNAME considerations in 5321bis, feel free
>to contact the YAM WG that currently works on an evaluation document
>for the IESG in order to get a sign-off for some changes the IESG
>might admit for a Full Standard successor to RFC 5321 -- or ask the

Such a change would have to be considered now if you want it to go in 
the pre-evaluation I-D.

Regards,
-sm