CNAME on a domain root does work, and it isn't evil | Hacker News Reader

CNAME on a domain root does work, and it isn't evil

pzxc.com

33 pointspzxc14 comments

RFC 1912 (Common DNS Operational and Configuration Errors) section 2.4 is unambiguous: A CNAME record is not allowed to coexist with any other data.

http://tools.ietf.org/html/rfc1912

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.

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.

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.

It doesn't work everywhere, it's not expected to work robustly anywhere, 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!

Specifically, it doesn't work with Comcast's DNSSEC-enabled recursive nameservers, which Comcast will eventually move all of its customers to:

  % dig +noall +comments +stats pzxc.com. 
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14316
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
  
  ;; Query time: 161 msec
  ;; SERVER: 75.75.75.75#53(75.75.75.75)
  ;; WHEN: Sat May 28 02:38:43 2011
  ;; MSG SIZE  rcvd: 26

joyeur.com, Joyent's blog, has the same problem:

  % dig +noall +comments +stats joyeur.com.
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57255
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

  ;; Query time: 133 msec
  ;; SERVER: 75.75.75.75#53(75.75.75.75)
  ;; WHEN: Sat May 28 02:40:38 2011
  ;; MSG SIZE  rcvd: 28

Both pzxc.com and joyeur.com have CNAME records.

So, yeah, using CNAMEs on your domains works great, except for all those times it doesn't work at all, like with the largest residential ISP in the United States.

Using a cname for a root domain is just a bad idea.

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.

    dig pzxc.com soa +short
    lwebs.com.
    ns1.widge.net. postmaster.lwebs.com. 1304101336 16384 2048 1048576 2560

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...

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 http://aws.typepad.com/aws/2011/05/moving-ahead-with-amazon-...

There's another work-around I've been using for 6+ months now. A cronjob which resolves the CNAME target (i.e., the ELB hostname) to an IP, then dynamically updates the A record(s) for the zone. It's a hack, but it does the job.

The uncoolness in most hacks like this is they can accidentally create a single point of catastrophic failure. If your cron job fails to run for a while, your entire website will go down.

That first sentence makes me cringe hard.

Yeah this is the kind of imprecise descriptions of technical things I hate. If it were an article written for the average person I might let it slide, but if you're setting up DNS records you should have a clearer understanding of what DNS is, rather than something that "allows you to route all traffic from one domain to another".

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.

I can put all many gigs of email in a flat file called 'mbox' -- that doesn't mean it's a good idea.

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.

slashdot.org has been doing it for years as 'proof' though, so, congrats?

slashdot.org has been doing it for years as 'proof' though, so, congrats?

Regardless, Slashdot isn't doing it now:

;; ANSWER SECTION: slashdot.org. 1704 IN A 216.34.181.45

Good luck doing that with HTTPS.

Reply on news.ycombinator.com