Alessandro Vesely wrote:
The situation is cumbersome, since rfc1035 says nothing on MX semantics,
referring to rfc974. Indeed, the algorithm is explained in rfc974, but
it is "Obsoleted by: 2821", the SMTP being updated. However, rfc2181
updates rfc1035 and has a section 10.3 "MX and NS records" where it says
The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias. Not only is
the specification clear on this point, but using an alias in either
of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach. This
domain name must have as its value one or more address records.
Thus, it seems it is up to rfc2821bis to be "clear on this point."
I prefer the less "Mumbo Jumbo" version:
SMTP DNS Administration SHOULD|MUST NOT use CNAME resource records
in preparing MX domain hosting records.
SMTP and DNS client resolvers SHOULD|MUST be aware for the
possibility of CNAME resource records and handle it accordingly
during the MX query expansion process.
After all, is what it is. Most, if not all, professional DNS client
resolvers are already dealing with this long time possible issue. The
new document isn't going to change that, so at best it can only help the
administration side of operations not to use them, and in my view, a
insight on the growth on Web Based DNS Managers that is SO easy today to
use even the layman SMTP operator can use.
In the past, personally, I think the old Microsoft DNS manager, had
logic that didn't help the non-experience DNS people in "accidentally"
creating a CNAME for the MX record. For example, I recall a customer
first use a WWW.XYZ.COM CNAME record for their entry into the Web market
and then use this for the MX when adding the mail system.
My input on the matter.
Hector Santos, CTO