4 ms·

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

33 points by pzxc 15y ago

stock_toaster 15y ago
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.
js2 15y ago
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 http://tools.ietf.org/html/rfc1912
shubber 15y ago
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.
dlsspy 15y ago
That first sentence makes me cringe hard.
- tlrobinson 15y ago
  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".
smosher 15y ago
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!
- rwg 15y ago
  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.
tybris 15y ago
It is, but thankfully some of us now have a solution http://aws.typepad.com/aws/2011/05/moving-ahead-with-amazon-route-53.html http://aws.typepad.com/aws/2011/05/moving-ahead-with-amazon-...
- js2 15y ago
  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.
  - kennu 15y ago
    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.
dsl 15y ago
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.
abofh 15y ago
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?
- oasisbob 15y ago
  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
figital 15y ago
Good luck doing that with HTTPS.

33 points by pzxc 15y ago

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.

js2 15y ago

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 http://tools.ietf.org/html/rfc1912

shubber 15y ago

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.

dlsspy 15y ago

That first sentence makes me cringe hard.

tlrobinson 15y ago
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".

smosher 15y ago

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!

rwg 15y ago
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.

tybris 15y ago

It is, but thankfully some of us now have a solution http://aws.typepad.com/aws/2011/05/moving-ahead-with-amazon-route-53.html http://aws.typepad.com/aws/2011/05/moving-ahead-with-amazon-...

js2 15y ago
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.
- kennu 15y ago
  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.

dsl 15y ago

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.

abofh 15y ago

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?

oasisbob 15y ago
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

figital 15y ago

Good luck doing that with HTTPS.