Trevor,
Who is right or wrong is a matter of historical perspective.
The fact is this:
All current/modern DNS clients will support the resolution of a CNAME as
part of a MX expansion process.
You can see it yourself, NSLOOKUP also resolves the CNAME reference. Is
NSLOOKUP wrong? No. It did the right thing as well as all current DNS
clients will do when they do a MX request and expand the result.
In short,
MX --> list of host names --> expansion
The expansion starts with a A record to obtain the IP addresses. If the
A record lookup returns a CNAME to another host name, you need to do A
record lookup again on this host to get the IPs.
If the DNS client does not do this, it will undoubtedly come across a MX
request that may fail or have be incomplete its in MX expansion.
PS: dnsstuff.com does not have a copyright on correctness. On two
occasions over the many years, I have pointed their own
misinterpretations or improper usages of their otherwise fine tools.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Trevor Paquette wrote:
I’m currently at odds with a few folks regarding the interpretation of
RFC 2821 and the case of MX records that resolve to CNAMEs. I’m hoping
that those here, who are authoritative when it comes to this RFC, can
shed some light.
Take the following case:
% nslookup -q=mx fleetpride.com
Non-authoritative answer:
fleetpride.com mail exchanger = 10 in.sjc.mx.trendmicro.com.
fleetpride.com mail exchanger = 20 mx-in01.mail-abuse.org.
fleetpride.com mail exchanger = 20 mx-in02.mail-abuse.org.
fleetpride.com mail exchanger = 20 mx-in03.mail-abuse.org.
Authoritative answers can be found from:
fleetpride.com nameserver = ns1-auth.sprintlink.net.
fleetpride.com nameserver = ns2-auth.sprintlink.net.
fleetpride.com nameserver = ns3-auth.sprintlink.net.
ns1-auth.sprintlink.net internet address = 206.228.179.10
ns2-auth.sprintlink.net internet address = 144.228.254.10
ns3-auth.sprintlink.net internet address = 144.228.255.10
% nslookup in.sjc.mx.trendmicro.com.
Non-authoritative answer:
in.sjc.mx.trendmicro.com canonical name =
in.mx.trendmicro-fail-over.akadns.net.
Name: in.mx.trendmicro-fail-over.akadns.net
Address: 216.99.131.15
Name: in.mx.trendmicro-fail-over.akadns.net
Address: 216.99.131.16
Name: in.mx.trendmicro-fail-over.akadns.net
Address: 216.99.131.1
Name: in.mx.trendmicro-fail-over.akadns.net
Address: 216.99.131.2
Name: in.mx.trendmicro-fail-over.akadns.net
Address: 216.99.131.3
Name: in.mx.trendmicro-fail-over.akadns.net
Address: 216.99.131.4
Name: in.mx.trendmicro-fail-over.akadns.net
Address: 216.99.131.13
Name: in.mx.trendmicro-fail-over.akadns.net
Address: 216.99.131.14
According to RFC 2181, this is invalid. You cannot have an MX record
that resolves to a CNAME.
However, in talking to TrendMicro, they say that this syntax is
perfectly valid and that RFC 2821 overrides the MX to CNAME limitation.
The following website is their stance on this:
http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1035667&id=EN-1035667
<http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1035667&id=EN-1035667>
However, in talking to others, they say that TrendMicro is
misinterpreting the RFC. I’ll admit after reading 2821, I could
interpret things both ways.
This is why I come to you folks who are responsible for this RFC. Who is
right? Is MX -> CNAME now allowed by 2821, or is TrendMicro in the wrong?
Would it also be possible to state directly within the next revision of
the RFC where or not this RFC overrides the provision 10.3 of RFC 2181.
I don’t want to leave things left to misinterpretation.
--
Trevor Paquette
Director, Information Technology and Systems
TeraGo Networks Inc.
300, 300 Manning Road NE
Calgary, Ab T2E 8K4
http://www.terago.ca <http://www.terago.ca/>
W: (403) 668-5321
C: (403) 703-8738