FAQ: Can an MX record reference a CNAME
John Navas
<http://www.cis.ohio-state.edu/hypertext/faq/usenet/internet/tcp-ip/domains-faq/part2/faq.html>
states in "Question 6.5. MX records, CNAMES and A records for MX targets":
The letter of the law is that an MX record should point to an A record.
While it may be desirable to avoid the indirection of a CNAME, it's really
just recommended practice, not the "letter of the law." My analysis:
RFC 974 <http://www.rfc-editor.org/rfc/rfc974.txt> states ("Issuing a
Query"):
The first step for the mailer at LOCAL is to issue a query for MX RRs
for REMOTE. ...
...
There is one other special case. If the response contains an answer
which is a CNAME RR, it indicates that REMOTE is actually an alias
for some other domain name. The query should be repeated with the
canonical domain name.
That seems to clearly indicate that MX records can point to CNAME
records.
RFC 1034 <http://www.rfc-editor.org/rfc/rfc1034.txt> (3.6.2) suggests
avoiding MX indirection:
Domain names in RRs which point at another name should always point
at the primary name and not the alias. This avoids extra indirections
in accessing information.
but does not prohibit it:
Of course, by the robustness
principle, domain software should not fail when presented with CNAME
chains or loops; CNAME chains should be followed ...
Then there's RFC 1912 <http://www.rfc-editor.org/rfc/rfc1912.txt>, which
states (2.4):
Don't use CNAMEs in combination with RRs which point to other names
like MX, CNAME, PTR and NS. (PTR is an exception if you want to
implement classless in-addr delegation.) For example, this is
strongly discouraged:
podunk.xx. IN MX mailhost
mailhost IN CNAME mary
mary IN A 1.2.3.4
[RFC 1034] in section 3.6.2 says this should not be done, and
That's "should not" not "cannot". To continue:
[RFC
974] explicitly states that MX records shall not point to an alias
defined by a CNAME.
But it doesn't, as noted above; in fact, just the opposite.
Finally, there's RFC 2181 <http://www.rfc-editor.org/rfc/rfc2181.txt>
(10.3):
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.
Currently those will be A records, however in the future other record
types giving addressing information may be acceptable. It can also
have other RRs, but never a CNAME RR.
The problem is that the "specification" is not "clear on this point" as
noted above; hence there is no real basis for "never." RFC 2181 goes on to
state:
Searching for either NS or MX records causes "additional section
processing" in which address records associated with the value of the
record sought are appended to the answer. This helps avoid needless
extra queries that are easily anticipated when the first was made.
Additional section processing does not include CNAME records, let
alone the address records that may be associated with the canonical
name derived from the alias. Thus, if an alias is used as the value
of an NS or MX record, no address will be returned with the NS or MX
value. This can cause extra queries, and extra network burden, on
every query. It is trivial for the DNS administrator to avoid this
by resolving the alias and placing the canonical name directly in the
affected record just once when it is updated or installed.
This suggests that this is an issue of "goodness" (avoiding the extra
lookup) rather than a real error. Continuing:
In some
particular hard cases the lack of the additional section address
records in the results of a NS lookup can cause the request to fail.
No real evidence is presented to support this claim.
To be clear, even though this does not appear to be "the letter of the
law," I would still recommend not using CNAME in an MX record given that
some people will probably take RFC 2181 at face value, with the result that
some implementations may fail to properly resolve MX queries that return a
CNAME.
--
Best regards,
John mailto:jna...@aimnet.com http://www.aimnet.com/~jnavas/
Jim Britain
(John Navas) wrote:
>That's "should not" not "cannot". To continue:
That is most easily translated to: "Doesn't work about half the time."
Regardless of the letter of the law(specifications).
Re: MX record points to CNAME
John Navas
jbri...@home.com (Jim Britain) wrote:
FWIW, before posting I ran quite a few tests without encountering such a
failure.
Barry Margolin
John Navas <spamf...@navasgrp.dublin.ca.us> wrote:
>comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ)
><http://www.cis.ohio-state.edu/hypertext/faq/usenet/internet/tcp-ip/domains-faq/part2/faq.html>
>states in "Question 6.5. MX records, CNAMES and A records for MX targets":
>
> The letter of the law is that an MX record should point to an A record.
>
>While it may be desirable to avoid the indirection of a CNAME, it's really
>just recommended practice, not the "letter of the law." My analysis:
>
>RFC 974 <http://www.rfc-editor.org/rfc/rfc974.txt> states ("Issuing a
>Query"):
>
>
> The first step for the mailer at LOCAL is to issue a query for MX RRs
> for REMOTE. ...
> ...
> There is one other special case. If the response contains an answer
> which is a CNAME RR, it indicates that REMOTE is actually an alias
> for some other domain name. The query should be repeated with the
> canonical domain name.
>
>That seems to clearly indicate that MX records can point to CNAME
>records.
Later in that RFC ("Minor Special Issues") it says:
Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
a alias and the alias is listed in the MX records for REMOTE. (E.g.
REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This
can be avoided if aliases are never used in the data section of MX
RRs.
The result of violating this can be a mail loop.
Recent versions of sendmail deal with this by allowing you to include all
the aliases in class "w" -- when removing irrelevant RR's it will treat any
names in this class as if they were LOCAL. But if you add an alias and
don't inform the sendmail administrator, he won't know to update Cw. I
don't know if or how other mailers deal with this issue.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
glen herrmannsfeldt
one MX. (Even more technically, it works if there is more than one,
under certain conditions, but I forget the condition.)
The problem comes when a machine wants to remove itself from the MX
list and doesn't recognize the CNAME as itself. The highest preference
must accept the mail. Lower (larger number) if they don't accept it will
try to forward it to the real destination. To do this, they must know
whichh MX point to themself, so they don't send to themself.
But even this case still leaves the possibility that someone will change
the configuration later. So, don't do it.
However, it might be that enough sendmail or named now check for this
and refuse it, that even that won't work.