45

We are trying to move all our websites we host to CNAMES as we are planning on moving servers in the new year and would like the ability to move some clients to one server and other clients somewhere else. We were planning on giving clients a unique CNAME which we can then change at a later date. (We have other reasons for doing this now but that is the main one)

We have been testing out this theory with a few of our own domains and it seemed to be fine. However when checking the MX records on a domain I got the CNAME value back rather than the MX record.

Sadly all of these domains are done via control panels, but I am guessing they are just writing zone files for me.

I want to create 2 CNAMEs for the company.com

company.com. IN CNAME client.dns.ourserver.com
www          IN CNAME client.dns.ourserver.com

The MX record is something like the following:

company.com  IN MX 10 mail.company.com

We have an A record for mail.company.com

Doing:

host -t mx company.com

Returns the CNAME value rather than the mx record.

Is this expected behaviour?

I have managed to get the above configuration working with the 123-reg.co.uk control panel, but not sure if that is more luck than anything.

Benoit
  • 3,499
  • 1
  • 18
  • 17
johnwards
  • 765
  • 1
  • 9
  • 13
  • This is a common question and has been asked many times before. See this link for an example: http://serverfault.com/questions/18000/dns-subdomains-that-require-both-an-mx-record-and-a-cname – Russell Heilling Dec 07 '09 at 16:11
  • I did spend a little while looking for an answer but couldn't figure out if I was doing something different. Especially as it is working fine with one domain provider. I have my answer so that is cool and hopefully it will be of some use to someone. – johnwards Dec 07 '09 at 18:02

6 Answers6

59

This is a common error. You cannot use a CNAME RR for your root domain (e.g. company.com) and define additional resource records for the same zone.

See Why can't I create a CNAME record for the root record? and RFC1034 section 3.6.2 for details:

If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.

Phillipp
  • 492
  • 1
  • 3
  • 12
joschi
  • 20,747
  • 3
  • 46
  • 50
7

RFC2181 section 10.3 says you can't point your MX record to a CNAME:

The domain name used as the value ... of a MX resource record must not be an alias.

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
nogginboink
  • 79
  • 1
  • 1
2

I just moved to Heroku which uses CNAMEs instead of A records and what I had to do was instead of making a CNAME with my_domain.com pointing to heroku, I did the CNAME with www.my_domain.com pointing to heroku, so the bare/root domain was not forwarding and my MX records would still work. Then I added a pointer to redirect my_domain.com to www.my_domain.com. It seems to work great. In my domain name provider the pointer was created using a 'pointers' setting which I set to 'standard' 'URL' and 'www.my_domain.com'

Jesse Adamson
  • 121
  • 2
0

I have found that SOME MX providers in tandem with SOME DNS providers will actually work alongside a bare CNAME, if you merely order the MX record ABOVE the CNAME in the top down record order.

It is working on Name.com registrar with Office 365 MX record and bare CNAME record directing HTTP to yet another domain. While testing MX queries I noticed my CNAME result came back first corresponding to my DNS entries order, so I figured why not try ordering MX first and see if that satisfied the MX provider. To my surprise Office 365 MX verification then passed and I can confirm inbound and outbound email is indeed flowing. And after testing several web clients, HTTP also indeed resolves desirably to specified CNAME destination host.

Caveat emptor - This is clearly going against the standard and therefore probably shouldn't be considered for anything critical. I'm assuming record order is not in the spec and therefore can't be officially relied upon... i.e. subject to change right after you forget about this hack.

Tip - MX Toolbox free page is very handy for checking the result of trying different DNS settings.

Shameless plug for my corresponding post.

Beej
  • 111
  • 2
  • 3
    Being undocumented behavior, this is definitely not something I'd want to count on. – ceejayoz Jun 25 '16 at 19:13
  • 3
    this behaviour can only be considered a bug, a caching nameserver may cache the CNAME response ans MDAs will never see the MX record https://tools.ietf.org/html/rfc5321#section-5.1 – Jasen May 06 '18 at 23:04
0

I have come to realize that these two can be separated entirely

mydomain.com. -  A Record  - 01.0.0.1
mydomain.com - CNAME - www.cname.eg.com

Unless you are using your server as the mail server it wont really affect anything. The mail will look for mydomain.com MX records. Its will only be affected if its like this 

mydomain.com - MX - mail.mydomain.com

but if its like this (meaning you are using a separate mail server) it wont be affected

mydomain.com - MX - mail.mycustommailserver.com

You can't use an IP for Mail Servers.

Ndeto
  • 101
  • 1
-3

You can use a CNAME on the root of the domain, however, those MX records must also be configured on the host record, so if you have mx1.mail.com configured on the zone for yourdomain.com, and the root of yourdomain.com is CNAME to thisrecord.cname.com, you must also make sure that mx1.mail.com is configured on that CNAME host; if not, all mail will be lost!

Matt
  • 9
  • 4
    The problem is, as per RFC1034, "if a CNAME RR is present at a node, no other data should be present" -- since the root needs to have NS records (to be useful, anyways), there will always be other data, which violates this section of the RFC. – Doktor J Sep 30 '13 at 23:05
  • In my opinion the answer is correct, except that the MX record should be *instead* on the CNAME host (not also). – Alexander Taubenkorb Aug 13 '15 at 05:26