Why it's a bad idea to put a CNAME record on your root domain

[toomuchtodo]

Using AWS' A record ALIAS concept does away with this problem. It does mean you have to use Route 53 though.

Alternatively, use an ALIAS record for your apex (domain.com) that is an S3 bucket that redirects to www.domain.com (which you'd proxy through Cloudflare).

EDIT: The ALIASing that Amazon does are internal health checks that are abstracted away. In the event of a failure, Amazon will update the A record with a new functional IP route extremely quickly (or rather, that's how its supposed to work). Also, you aren't charged for ALIAS queries, while you are for CNAME queries (which can add up depending on your traffic).

[joshstrange]

Yes, I don't go into detail in the blog but I link to the AWS Blog where they explain how to do just that. I didn't know about the health checks that's quite nice!

[rgj]

This actually makes sense, since the CNAME does not only replace A records, but any record. Not just MX but your NS and SOA records as well.

Much less intuitive is the fact that a MX record cannot refer to a record that is a CNAME itself. http://www.exchangepedia.com/blog/2006/12/should-mx-record-p...

Many soho routers performing DNS forwarding give very weird and unpredictive results if you do this.

[lamby]

Neat. I'd always filed the "CNAME screws with MX" away in my mind but I never knew the underlying reason beyond "because the RFC says so and it doesn't work IRL".

[joshstrange]

Yeah, neither did I, I just assumed it was just a rule no one followed.... As you can see I was wrong. I'm just glad I finally tracked down the issue before it drove me crazy.

[jakobe]

TLDR: CNAME doesn't just forward A records, but MX records and others as well.

[larrys]

Just verified that this is not the case with dns records done through the domain manager at mediatemple.net

May be the case elsewhere (just no time right now to test this).

I would have started this reply by saying "not true" but don't know if the particular dns manager at mediatemple.net is setup in a way to be not compliant with the RFC.

Update: Upon further testing it does return a MX record but can't resolve the host name for the MX record.

[ghayes]

Then couldn't you then add your MX records under 'www' and all will be well? Does this affect DKIM?

[vertis]

As other people have noted, the solution to this is quite simple. Several DNS hosts support using an ALIAS record. The ALIAS record is then replaced with an A record when actually queried.

Not sure which other companies support it, but http://dnsimple.com does.

[eastdakota]

Hi: I'm the co-founder and CEO of CloudFlare. This can be a problem with some mail servers (especially Exchange, in our experience). Good news is we have a solution. We have a feature called CNAME Flattening which dynamically turns a CNAME at the root into an IP address. This solves the issue. We've beta tested this for the last few months and it works great. We haven't exposed in our UI yet but if you write to our support team we'll enable it. We're offering it to all our customers, even as the free tier. We plan to roll it out in our UI soon. Functionally, it's very similar to services that have an "Alias" record without requiring users to learn a new, non-standard DNS record type.

Matthew Prince (@eastdakota) Co-founder & CEO, CloudFlare

[colmmacc]

The problem doesn't have much to do with particular mail servers, but rather with the order in which queries may be made. Let's say the following two records are allowed to co-exist:

    example.com 60 IN MX mail.example.com
    example.com 60 IN CNAME foo.example.org

and that the MX record takes precedence over the CNAME when queried. Imagine a client, C, behind resolver R, and it makes the following queries;

    1. C looks up qname=example.com qtype=MX, R returns the MX record
    2. C Looks up qname=example.com qtype=A, R follows the CNAME
    3. C looks up qname=example.com qtype=MX, R follows the CNAME

The resolver will first resolve the MX record, and cache that correctly, passing the result back to the client. The second query though will result in a CNAME, which will likely invalidate the cached MX record, and the resolver will then follow the CNAME and chase that. The third query may now also follow the CNAME, even though there may not be an MX record at the CNAME target (foo.example.org).

Any non-MX query behind resolver R effectively poisons R's cache, and the MX becomes unreachable. If R gets no queries other than MX queries, or if the MX and CNAME target answers are cacheable for identical periods of time, then it can sometimes work - but it's a tenuous and non-deterministic stroke of luck. If there's even one lookup behind R - from any of its clients for a non-MX, things break again. Some mail servers do perform an A lookup before an MX lookup (which is valid RFC822) and so things never work for those mail servers, as they always poison the cache, but that correlation isn't really the cause of the problem. The configuration is unreliable even in the best of circumstances.

Full disclosure: I work on Route 53.

[xxdesmus]

For those curious to see CloudFlare's CNAME flattening in action (it's seamless, so it's not sexy to look at though): https://gist.github.com/xxdesmus/9202356

root and WWW for shiftyplatypus.com are both CNAMEs (pointing at Heroku).

[crooksey]

The correct way todo this is setup a load balancer, then use route 53 to manage the dns, set the root domain to your load balancer I'D then map the www cname to the root domain, this solves all problems and takes under 5 minutes to configure.

[joeframbach]

www.domain.com and domain.com should not just silently duplicate the same content. If you want one to be "canonical", then the other should respond 301 Moved Permanently with the correct address. Duplicate content across domains is a mess for SEO.

[lingben]

very happy client of DNSmadeeasy, imho the best DNS provider bar none, they were the first to have ANAME records:

http://www.dnsmadeeasy.com/services/aname-records/

[eli]

I found them to be kinda expensive at moderate scale. But maybe I was doing something wrong.

[inopinatus]

We should not be using A records for websites. I'm hoping HTTP/2.0 will drag itself into this century and commit to using SRV records or something very like them instead, so that problems like this can go away with a general solution.

See: https://github.com/http2/http2-spec/issues/381

[workhere-io]

The article points to an AWS article on how to set up the whole thing correctly - but once you've done that, there's still another problem: You really shouldn't host public stuff with S3 at all, unless you use CloudFront in front of it. Try benchmarking it with Apache Bench: S3 is extremely slow, whereas CloudFront is fast and can take a large number of hits.

[colinbartlett]

DNSimple has a similar service that lets you create a CNAME-like record for your root domain.

[cooperx]

I came here to add this exact statement. DnsMadeeasy is terrific and one of e few that support ANAME records

[joshstrange]

Thanks! I'll have to check that out.

[nmjohn]

I'm a little confused by why this was even an issue.

Why couldn't he just setup an A record for both domain.com and www.domain.com, and in his apache/nginx/pick your server config file 301 redirect www.domain.com to domain.com.

Is that not the best practice?

[shaggy]

Yes it is and has been for a long time. What this article really boils down to is a terribly poor understanding of how DNS works and why certain records are use for certain serivces. A CNAME doesn't "redirect" anything at any level outside of a resolver. In the case of www.example.com and example.com you use a web server to achieve the desired result. Even then it's not a redirect, it's a replacement the resolver determines the record is a CNAME, inserts the value the CNAME points to, then resolves the A record. In the case of the MX record for a domain a CNAME is a problem because in the absence of a MX record, the A RR record is used, in this case a CNAME. Would protocol specific SRV records be better? Yes, but since that change isn't happening quickly do what's right now and change in the future.

[kelnos]

Because he's not self-hosting his website. He's using a S3 bucket, and the "normal" way of doing that is to CNAME to a S3-owned hostname, so Amazon can then mess with the IP address behind the scenes without telling you to update your A record.

[erikcw]

I'd love for CloudFlare to add the equivalent of an ALIAS record to their DNS service. To the best of my knowledge one cannot use Route 53 and also take advantage of CloudFlare's services.

[joshstrange]

Yes, unfortunately I had to choose between the two. I like CloudFlare a lot but without that I was unable to stay.

[sneak]

I'm surprised that so many of the comments in this thread are about dns hosting services and not dns server software support for these so-called "alias records".

I was making a list of "why on Earth doesn't this simple software exist?" items the other day and "simple server-side CNAME support" was on the list. Does any common DNS server package provide this support easily out of the box? It seems like one of the most common uses cases possible.

[t0mas88]

Small warning: CNAME at apex is commonly used for pointing traffic to a CDN or load balancing kind of service. These services tend to use DNS for part of their traffic orchestration (e.g. different DNS response based on user region) which gets less than optimal or even plain wrong results if your DNS server software resolves the CNAME instead of the end-user.

If they weren't using DNS as part of their strategy they could've given you a simple IP instead of a CNAME, saving your clients some lookup time.

[axiak]

A lot of DNS providers provide "ANAME" records. Which are essentially services which do the lookup and update A records in a cron.

[TuxLyn]

I've always used only one "A" record for main domain like "domain.com" then everything else goes throught "CNAME", like "www.domain.com" or any oher sub-domain like "blog.domain.com" then have sepeate "MX" record for email. In Nginx I redirect useless (www) to (non-www) using permanent redirect (301) Never had any problems both with CloudFlare and NameCheap ^_^

[js2]

Before Amazon introduced the ALIAS record the workaround I had in place was a cronjob which queried for the A records of our Amazon ELB and replicated those to the root of our domain, which at the time was hosted with DNS Made Easy. It was an easy decision to move to Route 53 once the ALIAS record was introduced and retire my hack.

[blueskin_]

>I started to look for solutions and was expecting to have to start using my domain with the "www" until I stumbled across this AWS Blog on how to do exactly what I was wanted. The only "problem" was I would have to use Route 53 instead of CloudFlare for it to work.

This is why rewriting exists.

[dav-]

So, I have a question: Would the following be safe? Specifically the "* CNAME @" rule.

https://gist.github.com/dav-/eaa487032588efc0b4a3

[joshstrange]

I'm fairly certain that is fine, it's not "on the root" because it's *.root.com not root.com, you have an A record on the root which is expected and correct.

[wut42]

Also it seems that some DNS resolvers with DNSSEC enabled will not resolve APEX on CNAME (returning a SERVFAIL). I've disabled DNSSEC on my home resolver (unbound) because of this (damn heroku).