Subject: [ietf-smtp] MX pointing to CNAME

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 13 Aug 2016 16:19:50 +0530

Hi,

I’ve just run across a biggish sender that insists that MX records point to A/AAAA records and therefore cannot send mail to a site whose MX points to a CNAME (which in turn points to an A).

The sending site’s FAQ says this is due to applicable FAQs, without citing chapter and verse. Ahem. I found a question on serverfault which claims 1123 forbids pointing to CNAME in MX, but don’t see any applicable text in 1123. I do see something in 974... but I’d like to hear your opinion on the issue.

Arnt

---

From: Paul Smith <[email-masked]>
Date: Sat, 13 Aug 2016 12:18:16 +0100

I'm on my iPhone at the moment so can't write in too much detail, but they're right according to my understanding.

See this page which has more info about it

http://exchangepedia.com/2006/12/should-mx-record-point-to-cname-records-aliases.html

Sent from my iPad

> On 13 Aug 2016, at 11:49, Arnt Gulbrandsen <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 13 Aug 2016 18:25:46 +0530

Thanks.

I suppose it has to happen someday: This is the first time i 
have heard someone use a generic term like "applicable RFCs" instead of 
a specific RFC and still been right.

Arnt

---

From: George Schlossnagle <[email-masked]>
Date: Sat, 13 Aug 2016 07:46:11 -0400

He is correct, MX records must not point to CNAMEs.  See section 10.3 RFC
2181 for details.

On Sat, Aug 13, 2016 at 6:49 AM, Arnt Gulbrandsen <[email-masked]>
wrote:

> Hi,
>
> I’ve just run across a biggish sender that insists that MX records point
> to A/AAAA records and therefore cannot send mail to a site whose MX points
> to a CNAME (which in turn points to an A).
>
> The sending site’s FAQ says this is due to applicable FAQs, without citing
> chapter and verse. Ahem. I found a question on serverfault which claims
> 1123 forbids pointing to CNAME in MX, but don’t see any applicable text in
> 1123. I do see something in 974... but I’d like to hear your opinion on the
> issue.
>
> Arnt
>

-- 
*GEORGE SCHLOSSNAGLE*
cto
www.sparkpost.com
(tel) +1.443.656.3318
(email) [email-masked]

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 13 Aug 2016 18:42:49 +0530

Hmmm... upon reading 2182 10.3, that section seems to forbid NS that 
points to CNAME and merely caution against using MX that points to 
CNAME. I do not see a ban regarding MX.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 13 Aug 2016 18:52:44 +0530

No, I am wrong, 2181 clearly bans MX->CNAME. The heat must be too much 
for me. Next summer I shall go to Iceland on vacation.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 17 Aug 2016 13:14:19 +0530

I noticed this today:

$ dig _submission._tcp.gmail.com srv

…
;; ANSWER SECTION:
_submission._tcp.gmail.com. 86400 IN	SRV	5 0 587 smtp.gmail.com.
…

$ dig smtp.gmail.com a

…
;; ANSWER SECTION:
smtp.gmail.com.		242	IN	CNAME	gmail-smtp-msa.l.google.com.
gmail-smtp-msa.l.google.com. 242 IN	A	74.125.136.109
gmail-smtp-msa.l.google.com. 242 IN	A	74.125.136.108
…

</semirelevant>

Arnt

---

From: Tony Finch <[email-masked]>
Date: Wed, 24 Aug 2016 12:18:13 +0100

Arnt Gulbrandsen <[email-masked]> wrote:
>
> but I’d like to hear your opinion on the issue.

MX -> CNAME is not allowed according to the RFCs but sensible
implementations support it in the obvious way. There was a massive
flamewar on this topic during the work on RFC 5321 leading to some
awkward verbiage in section 5.1:

   Any other response, specifically including a value that will return a
   CNAME record when queried, lies outside the scope of this Standard.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Southeast Biscay: Variable 3 or 4. Slight or moderate. Mainly fair. Good.

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Aug 2016 11:41:44 -0400

--On Wednesday, August 24, 2016 12:18 +0100 Tony Finch
<[email-masked]> wrote:

>> but I'd like to hear your opinion on the issue.
> 
> implementations support it in the obvious way. There was a
> massive flamewar on this topic during the work on RFC 5321
> leading to some awkward verbiage in section 5.1:
> 
>>    Any other response, specifically including a value that
>> will return a    CNAME record when queried, lies outside the
>> scope of this Standard.

In defense (or at least explanation) of that awkwardness (and
several similar cases), what, IMO, 5321 really should have said
is that am implementation utilizing, rather than refusing to
follow, such a MX -> CNAME -> <something> set of DNS entries was
not conforming to the standard and that anyone who did it anyway
needed to be extra careful to be sure they didn't get tangled up
in DNS entry loops (e.g., MX -> CNAME1 -> CNAME2 -> CNAME1) or
other weirdnesses (e.g.,  MX1 -> CNAME1 -> MX2 -> ???) and to
have good diagnostics if they did.

An AD or two were determined to not let us say the first
(inconsistent with the 2119 normative statements/position) and
sorting out exactly how to say the second would have taken a lot
of time and might have produced another flame war.    So the
position taken in 5321 is "outside the scope of the Standard"
or, less politely, "we aren't going to tell you what the issues
are with that stupid and risky thing or how to do it if you
decide to, so, if you do, you are on your own".

And yes, this too is on the list of reasons I've had trouble
getting motivated about 5321bis.

    john

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Aug 2016 09:00:20 -0700

On 8/24/2016 8:41 AM, John C Klensin wrote:
> IMO, 5321 really should have said

I've been noting some tendency for specs to try to make substantive 
statements about behaviors that are out of scope.

A spec needs to be explicit about 'interesting' behaviors that are out 
of scope.  It might benefit from explaining why it is out of scope. 
What it should /not/ do is make any substantive statements or statements 
that imply substance -- such as guidance to be careful (whatever that 
means) -- since that effectively makes the topic /in/ scope.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Ned Freed <[email-masked]>
Date: Wed, 24 Aug 2016 09:11:35 -0700 (PDT)

> have good diagnostics if they did.

As I recall, the approach I recommended at the time was one of "MUST
support, for historical reasons SHOULD NOT use".

> decide to, so, if you do, you are on your own".

Indeed. At that time there were more important battles to fight. And
here we are.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Wed, 24 Aug 2016 12:44:34 -0400

> getting motivated about 5321bis.

On a related note, lately I've been seeing more MX records pointing to 
"Localhost"  and "No.Longer.available" exchange host names.   At least 
with LocalHost, it resolves to something but you have to watch for the 
internal SMTP loop backs.  I don't see RFC5321 guidance to best handle 
the LocalHost MX exchanges.  Loop Detection (via Received lines) is 
the suggested way, but I noticed a major DKIM signing loop as well so 
I added code to skip the MX "LocalHost" exchange on the outbound side 
and force a bounce.

I prefer the NXDOMAIN approach if people are going to be creating 
"fake" "Stub" MX exchange records rather than getting rid of them.

-- 
HLS

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 24 Aug 2016 22:36:27 +0530

The right way to do that is MX 0 ., ie the root of the DNS is the sole 
mail server.

Arnt

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Aug 2016 14:26:50 -0400

--On Wednesday, August 24, 2016 12:44 -0400 Hector Santos
<[email-masked]> wrote:

> On a related note, lately I've been seeing more MX records
> pointing to "Localhost"  and "No.Longer.available" exchange
> host names.   At least with LocalHost, it resolves to
> something but you have to watch for the internal SMTP loop
> backs.  I don't see RFC5321 guidance to best handle the
> LocalHost MX exchanges.  Loop Detection (via Received lines)
> is the suggested way, but I noticed a major DKIM signing loop
> as well so I added code to skip the MX "LocalHost" exchange on
> the outbound side and force a bounce.
> 
> I prefer the NXDOMAIN approach if people are going to be
> creating "fake" "Stub" MX exchange records rather than getting
> rid of them.

As you might remember, there was a proposal (or several) that
5321 contain explicit instructions for a DNS way to say "no SMTP
service here".  While I remember the "foo MX 0 ." approach that
Arnt suggests as being among the least obnoxious of the
proposals, I also remember another food fight with no
conclusions and, IIR, some people arguing that is was not the
role of the SMTP standard to specific how to deny support for
SMTP without a connection being open.

If anyone considers it important enough, I'd recommend a
separate draft to specify the DNS entry to indicate "that
service not supported for this domain".  It might reasonably
specify that for assorted SRV records or the like as well as MX.
Should such a draft get through the system and show a reasonable
level of deployment, I'd think it would be reasonable to include
a reference to it in 5321bis should we ever get around to that.

    john

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Aug 2016 14:48:55 -0400

--On Wednesday, August 24, 2016 09:00 -0700 Dave Crocker
<[email-masked]> wrote:

>> follow, such a MX -> CNAME -> <something> set of DNS entries
>> was not conforming to the standard and that anyone who did it
>> anyway needed to be extra careful to be sure they didn't get
>> tangled up in DNS entry loops (e.g., MX -> CNAME1 -> CNAME2
>> -> CNAME1) or other weirdnesses (e.g.,  MX1 -> CNAME1 -> MX2
>> -> ???) and to have good diagnostics if they did.

> I've been noting some tendency for specs to try to make
> substantive statements about behaviors that are out of scope.
> 
> A spec needs to be explicit about 'interesting' behaviors that
> are out of scope.  It might benefit from explaining why it is
> out of scope. What it should /not/ do is make any substantive
> statements or statements that imply substance -- such as
> guidance to be careful (whatever that means) -- since that
> effectively makes the topic /in/ scope.

Dave,

First, and most important, 5321 is not pretty old, at least in
Internet time.  I was trying to report on what happened and why
that "awkward" text is the way it is and not to suggest that we
should have done anything different, even though my personal
preference at the time lay much closer to either the proposal
Ned mentioned or explicitly forbidding MXs whose DATA resolved
to something with a CNAME record.  The disadvantage of the
latter was the there were a lot of examples of that being done
and working fine; the group was reluctant to try to
retroactively ban such a practice, and Ned's proposal was the
nearest reasonable compromise.

I have little option about evolving trends about such statements
and no opinion at all as to whether we would make the same
situation today.  I am, however, fairly confident that, if we
made a serious effort to start work on a full Standard version
of 5431bis, we would reopen and rehash all of those arguments.
Again, that is another reason, perhaps the primary one, that I
haven't pushed that work -- so far, I have been convinced me
that the community has higher priorities.

As to the general principle, I agree with you, but note that, at
least since RFC 2821 replaced 974, SMTP really is the primary
spec for the MX RRTYPE, what is allowed in the DATA and how the
latter is interpreted.  It seems to me to be is as reasonable
for such a document to specify what should be done if the stated
requirements are not met as to say "if you encounter that
situation, you are on your own" (we certainly make that type of
statement elsewhere) so, at least for that example, whether a
more explicit requirement is in or out of scope is a consensus
judgment call rather than any matter of broad principle about
the scope of the specification.

best,
     john

---

From: Tony Finch <[email-masked]>
Date: Wed, 24 Aug 2016 19:51:20 +0100

> The right way to do that is MX 0 ., ie the root of the DNS is the sole

RFC 7505 :-)

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--
  zr8h punycode

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Aug 2016 14:57:12 -0400

--On Wednesday, August 24, 2016 19:51 +0100 Tony Finch
<[email-masked]> wrote:

>> The right way to do that is MX 0 ., ie the root of the DNS is
>> the sole mail server.
> 
> RFC 7505 :-)

Whoops.  Forgot that one.
    john

---

From: Hector Santos <[email-masked]>
Date: Wed, 24 Aug 2016 21:58:50 -0400

> The right way to do that is MX 0 ., ie the root of the DNS is the sole

I suppose they didn't get the new RFC 7505 availability newsletter. 
Maybe their "DNS MX Editor" doesn't support the RFC7505 NULL MX Entry, 
i.e. can't make the exchange a dot.

-- 
HLS