RFC 1912 (Common DNS Operational and Configuration Errors) section 2.4 is unambiguous: <i>A CNAME record is not allowed to coexist with any other data.</i><p><a href="http://tools.ietf.org/html/rfc1912" rel="nofollow">http://tools.ietf.org/html/rfc1912</a>
I gotta say, this reads like a web developer commenting on a networking issue. The big red flag is "some DNS servers let you do this." In the web world, that's what a standard looks like - some browsers implement a feature, and it has a pretty fair chance of becoming a standard.<p>The rest of the network, everyone has to agree, and we manage that consensus by following standards, which tend to look ambiguous when they say something you wish they didn't.
Yes it will work, for your current view of working. It's not the CNAME that breaks when you do this, it's all the other records.<p>You can't return a CNAME and something else. So your MX, NS, TXT, etc. records will be in an unknown state based on the client resolver/software. You'll see 40%-60% of your inbound email fail.
Not this again. Why does this get dug up repeatedly? I've seen this show up off and on every year for the past 10 years.<p>It doesn't work everywhere, it's not expected to work robustly <i>anywhere</i>, even if your server supports it not all clients will and there's just no need to do it. No matter how many out of date RFCs you quote. This hasn't changed in the past 10 years!
Using a cname for a root domain is just a bad idea.<p>A base domain cname record will (I believe) alias any query type to an alternate domain (like a dname) in at least the dig resolver.<p><pre><code> dig pzxc.com soa +short
lwebs.com.
ns1.widge.net. postmaster.lwebs.com. 1304101336 16384 2048 1048576 2560
</code></pre>
That isn't exactly what I would expect for an soa record (cname reference to another soa). Could cause problems with secondary servers and serial numbers...<p>Note: Edited post, as I was (for a while) unable to view the site in chrome, but it worked in safari. Could have just been a timing/propagation issue though as it is working now.
It is, but thankfully some of us now have a solution <a href="http://aws.typepad.com/aws/2011/05/moving-ahead-with-amazon-route-53.html" rel="nofollow">http://aws.typepad.com/aws/2011/05/moving-ahead-with-amazon-...</a>
The only reason it 'doesnt' work is that you then have to handle mail on the same hosts as web and https; Many consider that to be bad practice.<p>I can put all many gigs of email in a flat file called 'mbox' -- that doesn't mean it's a good idea.<p>The 'traditional' way to handle this without doing all kinds of nasty, is to simply use the standard A/MX combo and either proxy/redirect back to the 'www' version.<p>slashdot.org has been doing it for years as 'proof' though, so, congrats?