Re: [ietf-smtp] MTS-STS validation when MX host points to a CNAME, violating RFC 2181 § 10.3

[Sam Varshavchik <[e-mail]>]

John C Klensin writes:

> in5321 as just a clarification.  My memory of that part of the
> discussion in the late 1980s is very vague, but I think that it
> includes some concern about the combination of performance, what
> action should be taken on a CNAME loop if one were detected, and

CNAME loops can happen on any lookup: MX, A, AAAA, or any other RR. When  
searching various DNS-related documentation I saw no exceptions for MX RRs,  
that distinguish their processing. I can't find anything explicitly  
mentioned in RFC 1035 regarding CNAME loops that occur in the process of  
doing MX lookups. What should happen is the same thing what should happen  
when getting a CNAME loop for any other query. Even PTR. In fact, at least  
at one point, CNAME aliases for PTR records were quite popular, in certain  
use cases.

RFC 1035 defines CNAMEs as follows:

# CNAME RRs cause no additional section processing, but name servers may
# choose to restart the query at the canonical name in certain cases.  See
# the description of name server logic in [RFC-1034] for details.

RFC 1035 then states:

#  If recursive service is requested and available, the recursive response
#  to a query will be one of the following:
#
#   - The answer to the query, possibly preface by one or more CNAME
#     RRs that specify aliases encountered on the way to an answer.

This is not qualified in any further way. If a recursive query for an MX  
record is received by a DNS server, it will resolve any CNAME alias. The  
next paragraph further cements this point. Section 4.3.2 then provides more  
color:

#         a. If the whole of QNAME is matched, we have found the
#            node.
#
#            If the data at the node is a CNAME, and QTYPE doesn't
#            match CNAME, copy the CNAME RR into the answer section
#            of the response, change QNAME to the canonical name in
#            the CNAME RR, and go back to step 1.
 
So, if an SMTP server uses a generic DNS resolver to look up MX records, an  
MX that's pointing to a CNAME will resolve just fine.

Following the cite to RFC 1034, over there we find the following:

# CNAME RRs cause special action in DNS software.  When a name server
# fails to find a desired RR in the resource set associated with the
# domain name, it checks to see if the resource set consists of a CNAME
# record with a matching class.  If so, the name server includes the CNAME
# record in the response and restarts the query at the domain name
# specified in the data field of the CNAME record.  The one exception to
# this rule is that queries which match the CNAME type are not restarted.

Finally:

#                                 Of course, by the robustness
# principle, domain software should not fail when presented with CNAME
# chains or loops; CNAME chains should be followed and CNAME loops
# signalled as an error.

It is clear that a generic DNS resolver will handle CNAMEs in the context of  
MX RRs no differently than any other RR. Earlier, I wrote:

> So, if an SMTP server uses a generic DNS resolver to look up MX records, an  
> MX that's pointing to a CNAME will resolve just fine.

Now, whether the SMTP server will accept this result is, of course, a  
different story. Prior to the current standard this wasn't clearly defined,  
and now it is prohibited. However, this distills this issue to the following;

The specification's audience is mostly SMTP implementations. But the onus on  
complying to this requirement is on the owners and operators who configure  
their domains. And in the context of setting up and installing their DNS  
records, there's nothing wrong with installing a CNAME for an MX target.  
They'll run

dig example.com mx

They'll get an MX record for mail.example.com, then

dig mail.example.com a

they'll get a CNAME and and A record, and for all intents and purposes, DNS  
is set up correctly.

Even better is that older DNS servers will helpfully include CNAME and A  
records automatically in the "additional data" part of the DNS response to  
an MX query. No additional DNS queries will be needed, to locate the actual  
MX, if the implementation is smart enough to check that part of the DNS  
response. I don't see this happening any more, but this used to happen more  
often than not.