21

Let us say we own the zone mywebservice.com.

I would like each of my customers to get their own subdomain, such as customer.mywebservice.com.

customer.mywebservice.com needs to be a CNAME to a given server offsite. Since that site manages its own equipment and can change addresses at any point in time, the CNAME is a requirement.

People also need to be able to send email to inbox@customer.mywebservice.com, which would require a simple MX record.

However, and this is where I'd like some guidance:

According to RFC 1034:

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.

I have also verified that my DNS server will refuse to serve up anything but a CNAME for hosts that use them.

So, it seems that I may have a losing situation. If I want to use the MX record, I need to use an A instead of a CNAME.

Can anyone think of any workarounds? Thanks!

Community
  • 1
Michael Gorsuch
  • 2,358
  • 1
  • 21
  • 24
  • While it's not an official standard at the moment, many DNS providers now have an ANAME or ALIAS record which seems to cover this use case: https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/ – gsgx Sep 21 '22 at 17:45

8 Answers8

25

Unfortunately, what you're running into is a limitation of the DNS specification. Having an MX record for the same hostname as is defined as a CNAME record will fail in most DNS server implementations. Some older DNS servers will allow this, but they have been mostly phased out in favor of newer, more secure implementations.

Instead of using CNAME records, you will need to use 'A' records with the IP addresses of the customer sites directly instead of aliasing the names.

Justin Scott
  • 8,748
  • 1
  • 27
  • 39
  • Yeah, I guess I'm just going to face up to this one. Thanks! – Michael Gorsuch Jun 02 '09 at 23:25
  • 4
    I should also note, for those reading this down the road, that the reason for this limitation is that a CNAME is supposed to refer to the "canonical name" for the host being looked up. For example, if you have a host, x2.example.com which is a CNAME record pointing to x1.example.com, then any resolver looking up x2 should see the CNAME, replace whatever it's doing for x2 with x1, and start over. If you had an MX record for x2 in addition to the CNAME, then if x1 also had an MX there is a chance they would be different which is undesirable, so they simply disallow it. – Justin Scott Apr 28 '10 at 19:36
22

After a lot of work and research here, I have found an acceptable solution. First, it is important that we all follow the RFCs. I patched my DNS server to violate the RFC, and I discovered that several other major DNS servers would not respect the change.

The appropriate move is to put the MX on the host that the CNAME points to. So, if customer.mywebservice.com is a CNAME to the A record loadbalancer.mywebservice.com, it is proper to also build an MX record for loadbalancer.mywebservice.com. I have verified that this works with all major resolvers.

If a MX query is made for customer.mywebservice.com, the resolver library will follow the CNAME and get the proper MX for the final A record. Hurrah!

Michael Gorsuch
  • 2,358
  • 1
  • 21
  • 24
4

customer.mywebservice.com needs to be a CNAME to a given server offsite. Since that site manages its own equipment and can change addresses at any point in time, the CNAME is a requirement.

Can anyone think of any workarounds? Thanks!

You have a requirement that the customers must be able to change the address, have you considered allowing the customer to dynamically update their own record? With dynamic dns you could use the A record, and the customer could change the record as needed. It would take a bit of work, but you could each individual sub-domain as a separate zone so you can make sure a customer can only touch their own zone.

I haven't tried it but gnudip appears to be an open source tool for facilitating dynamic updates without having to deal with authentication and setting up lots of zones on your DNS server.

Zoredache
  • 128,755
  • 40
  • 271
  • 413
3

If your MX records will be the same for all of these records, then you could attempt to use a DNAME to redirect XYZ.mywebservice.com to hosting.mywebservice.com. Under hosting.mywebservice.com add your relavent MX and A records.

I must say that I have never utilized DNAME records in production, but you can read more about them in RFC2672.

Doug Luxem
  • 9,592
  • 7
  • 49
  • 80
  • I wanted to try using DNAME with some of our SSL domains, but I heard there are still problems with older DNS servers, etc. Is this relevant? Or is DNAME safe to use on production servers? – drybjed Jun 02 '09 at 18:31
  • If I had to guess, many applications don't expect DNAME records and probably break when using them. Do all mail servers follow DNAMEs to lookup MX records? I don't know, but they should. For your SSL issue, DNS servers that don't understand DNAME should instead receive a CNAME reference. I would thoroughly test this before implementing it. – Doug Luxem Jun 02 '09 at 18:37
  • The application certainly does NOT have to process DNAME records! It is done only in name servers. – bortzmeyer Jun 04 '09 at 09:24
3

Does the RHS of the customer.mywebservice.com CNAME have an MX entry?

If so, then the mail server will use that MX to find the mail server to use. Hopefully you can control that.

MikeyB
  • 38,725
  • 10
  • 102
  • 186
1

Michael Gorsuch's answer is largely correct, the CNAME -> A+MX chain does work... mostly. However, it does trigger some bad behavior in certain MTAs. What I've found running this solution at a decent amount of scale:

  • some MTAs will simply refuse to find the record.
  • others will incorrectly substitute the A record where the CNAME should be: ie I sent mail to "joe@foo.example.com", which CNAMES to web.example.com, which has an MX of mail.example.com, and the MTA rewrites the envelope header as "To: joe@web.example.com".

It's not clear yet how pervasive these issues are (google/hotmail/yahoo/etc all seem to deal with this correctly), but they certainly have us looking about for better solutions.

osheroff
  • 11
  • 1
  • 2
    This is correct; the documented behaviour for RFC5321-compliant SMTP servers is to first check for the existence of an MX record for the domain, and if that fails, check for the existence of an A record. This behaviour is the real, technical reason why the MX should not be a CNAME: it will stop resolving after the first usable answer. – adaptr Mar 12 '12 at 13:42
0

A possible and valid solution would be to create a basic hostname for all your customers and set it to the A and AAAA record of the the off-site webserver and your MX, then CNAME all your customers' domains to that single hostname. That way you will only have to change one record when the off-site's IP address changes.

It is the only valid and possible way, as CNAME is an alias for a complete set of records, not just A.

Bachsau
  • 101
  • 5
-4

MX and CNAME are completely separate records - first one determines the mail server for given domain, second gives the address for a domain. This should work:

@       IN      SOA     ns1.mywebservice.com. root.mywebservice.com. (
                        2009060201
                        12h
                        1h
                        1w
                        8h
)

                        NS      ns1.mywebservice.com.
                        NS      ns2.mywebservice.com.

customer                CNAME   offsite.host.
customer                MX 10   mail.server.
drybjed
  • 544
  • 2
  • 7
  • 4
    That may work, but it violates RFC1034 and RFC1219 which state that no other resource records may have the same name as a CNAME. – Doug Luxem Jun 02 '09 at 18:27
  • My DNS daemon is RFC strict, which just flat out refuses to send the response for the MX. I believe that there are some potential caching issues on the client side if we were to put this in place. – Michael Gorsuch Jun 02 '09 at 18:38
  • Which DNS daemon? I'm using BIND9 which should work with that configuration without a problem. Maybe it's time to upgrade? Big infrastructure, I presume? – drybjed Jun 02 '09 at 18:43
  • I'm using MyDNS. It's quite a large configuration, and this little daemon has been a blessing up until this point. I am considering patching it, but am not very interested in dealing with whatever side effects that gives birth to. If it goes against the RFC, it sounds like a bad idea. – Michael Gorsuch Jun 02 '09 at 19:06
  • @Maciej - sure, your authoritative server _might_ be able to host these records. They'll confuse the hell out of most any recursive server that queries them though. – Alnitak Jun 03 '09 at 07:30
  • 1
    After thinking about it for a while, I'm sure you guys are right. I've confused 'CNAME' record with 'A' record, which of course would work in combination with 'MX'. My mistake. – drybjed Jun 03 '09 at 09:08
  • this is just plain wrong, there's no point in discussing the details. CNAME for 'x' == no other records for 'x', and that's all. – Luke404 Nov 26 '10 at 08:59