How Best to Use a CNAME

In previous bulletins, we recounted the sorry tale of the domain owner who made a common mistake when setting up his DNS entries. We also explained why it was a bad idea.

So what should he have done?

He had the right basic idea, but he got the CNAME in the wrong place. Instead of getting fixated on the roles of the different machines within his domain -- i.e., Web server, email server, and so on -- he needed to take a broader perspective. As ever in life, a little knowledge can be a dangerous thing.

Here's what he probably should have done:

example.com. A 1.2.3.4
www.example.com. CNAME example.com
mail.example.com. A 1.2.3.5
example.com. MX mail.example.com.

In other words, define an IP address for example.com and create an alias for it, called www. This can be counterintuitive for those of us who like to separate different server roles by machine name.

Arguably, this may expose the Web server to additional load generated by spammers, because we're now effectively advertising that the Web server is also a mail exchanger. However, in practice this isn't a problem, for two reasons:

  • Spammers often try to connect using A records, even in the presence of MX records -- so that load would already have been there.
  • Our anonymous friend isn't completely stupid -- he's already firewalled off the unused ports of all his externally facing servers.

... Richi Jennings

One Comment

  1. yogi patel
    Posted December 1, 2008 at 6:07 PM | Permalink

    What about when you’re dealing with multiple subdomains? For example, I have a server bar.foo.com that handles both web and email traffic for multiple subdomains a.foo.com, b.foo.com, c.foo.com, etc.

    I have a, b, c, etc setup as CNAMEs to bar. Unfortunately, and as you’ve pointed out, this causes some emails to bounce since the external SMTP server tries to deliver mail to bar.foo.com, and user@a.foo.com doesn’t necessarily exist as user@bar.foo.com.

    What do you suggest in that case? Use A and MX records for each of the subdomains? Seems like that defeats the purpose of CNAME records. Of course, that’s why you wrote an article to point out the vagueness of the spec.

    Thanks!

  2. Posted December 1, 2008 at 6:19 PM | Permalink

    I’m afraid so. For some sending mail servers a CNAME would effectively override the MX.

    However, I’m not sure how this is related to the issue of which subdomains the user is configured on. Different MTAs are configured in different ways, but you probably have to tell the MTA that it’s responsible for each of the domains — it probably won’t figure it out for itself.

  3. Posted June 29, 2009 at 2:52 AM | Permalink

    Hi Richi,
    I’m having to research this very issue now since my DNS provider just started to enforce no mixing of CNAME and MX records.

    The problem I’m having is that I can’t figure out a way around this where:
    (a) both your web services and mail services are hosted (by separate providers), and
    (b) you want to use the same domain name for mail and web.

    Specific example is using heroku.com for web hosting and google apps for mail. If my domain is “parasite.com”. I want people to be able to go http://example.com and user@example.com

    proxy.heroku.com. A 1.2.3.4 # managed/owned by heroku
    aspmx.l.google.com. A 1.2.3.5 # managed/owned by google

    Then it seems all I want/need to do is:

    example.com. CNAME proxy.heroku.com
    example.com. MX aspmx.l.google.com.

    However, that’s exactly what you are advising against, and what it seems the DNS providers are starting to come down hard on.

    So I am at a loss. How?

  4. Posted June 29, 2009 at 9:37 AM | Permalink

    Paul, hope you don’t mind me editing your example to make my reply clearer…

    Yes, you “must” not have a CNAME and an MX for your domain. You have to use another A record:

    example.com. A 1.2.3.4

    I realize this looks ugly, because you’re specifying the IP address in two places, but I’m afraid that’s life. If you don’t, you’ll losing email from some senders, as I said in my two previous posts.

Post a comment

You must be logged in to post a comment. To comment, first join our community.