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.
pgpZEMUNgm18G.pgp
Description: PGP signature
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp