Is Dreamhost blocking CNAME forwarding?


I thoroughly enjoy forwarding subdomains with CNAME records. It works very well and is incredibly easy. Just add a record like NEWSUBDOMAIN.MYDOMAIN.COM CNAME PAGE.OTHERSITE.COM and just like magic users who type in newsubdomain will see the contents of othersite.

This works everywhere except for ComicDish. If you try to add a CNAME record from any domain to forward to absolutely any page on, you will get a “bad_httpd_conf” error. Let’s use the default comic,, as an example. Create a CNAME record on any domain from any registrar to forward to this comic - or any other page on - and it will give you the same error. Why is this? CNAME records can forward any subdomain you can think of to any site you can think of…except for things on

GoDaddy (and the other registrars I’ve contacted) says they have nothing to do with this problem, and I should contact ComicDish. ComicDish says they have nothing to do with this problem, and suggested I contact Dreamhost. Does Dreamhost somehow block CNAME forwarding to sites it hosts? Is there any way we can get this working?

Thank you very much for hearing my concern, and I greatly appreciate any response.


You can’t use a CNAME to redirect to a site that’s on a shared IP address, because we can’t detect which of the (potentially many) sites on that IP you’re trying to load. This is not specific to DreamHost — it’s an inherent limitation of using a shared IP address.

If ComicDish wants to support this, they will need to add a unique IP to their site. If they do not, you will need to choose another way to redirect to their site.


Thanks for the quick response! :slight_smile: When I type “” into my browser it loads the correct page. Based on my observation that seemed to be what CNAME records were doing as I have to give them name instead of IPs.

I will look into other solutions for forwarding the subdomain, then. Thanks again!


Thank you, andrewf. Could you please tell the chaps in support about this?

I spent quite a few hours tearing my hair out to experiment with a poor man’s CDN by using CNAMES to point subdomains back to the original domain (e.g. -> I kept getting the dreaded [font=Courier]bad_httpd_conf[/font] page. I clicked the button to force the DNS changes to repropagate and waited and waited. I finally contacted support, told them what I was trying to do, and they just said ‘well, it looks good from here’. And the strange thing was, it would work from within DH. I could type [font=Courier]$ lynx[/font] and it would work fine from my shell account, but not from anywhere outside of DH.

After reading this post, I found that you can create a poor man’s CDN by creating a subdomain and hosting it in the directory you wanted to point to. So, for [font=Courier][/font], the directory to host it in is [font=Courier]/home/username/[/font]. Basically, this tricks the user agent to initiate more parallel downloads because there’s a limit of 2-6 (depending on the browser) parallel downloads from the same domain.

It requires a small amount of code tweaking because it seems that DH is implementing this through a hidden [font=Courier].htaccess[/font] file or something, so some paths will not return what you would expect in PHP, but it’s not to hard to get around it.

The unfortunate result, however, is that after all the time I put into it, various benchmark comparisons seem to show absolutely no improvement in page load speed and in some cases, it seems to actually increase page load times by a very small and insignificant amount (<100ms).

Granted, my pages for this test are not incredibly complex (~20 items in total), so it was mostly just an interesting test. I might try it on a blog which has a lot of pictures… Apparently Drupal has a CDN plugin which you can configure to point to a subdomain using this technique (or with CNAMEs).


S3 uses shared IPs, and tons of people are doing this right now…they have to be to not have every address end in

I mean hosting with S3 you could wake up one morning and owe Amazon a bag of cash too, so I guess there’s tradeoffs.[/quote]


Amazon keeps track of all the CNAMEs that are pointed to their IP address, and what buckets they map to. They also have the advantage of knowing that all CNAMEs pointed to their addresses are for S3.

We, on the other hand, don’t have that advantage. Our shared IP addresses have lots of unrelated web sites all hosted on them, so if someone points a random CNAME to one of those sites, we don’t really know which site they were trying to point to.


Hi, I just walked into the same CNAME trap that others appear to be falling into. Reading through this thread, I get the impression that some forms of CNAME forwarding don’t work, and some forms do. However, I couldn’t get a clear picture of each case. Could someone please give an example of a case that works and a case that doesn’t work.

Specifically, here is what I want to do:
[]I have a domain registered ( with Network Solutions, with DNSs pointing to Yahoo where our mail and website have been hosted.
]Now, we’re moving the website hosting to DreamHost (while keeping the mail hosting at Yahoo).
[*]I’d like to create a CNAME record at Yahoo to forward all web traffic to DreamHost, where the site will still be accessed as

On Yahoo, can I add a CNAME record for *, and direct traffic to NS1.DREAMHOST.COM, to map the domain name to the folder where the site files are stored?



I think what you want to do is point your DNS to DreamHost and then at DH, point your MX to Yahoo. That’s how it works when you use GMail for mail and DH for hosting.


Matthew, please be aware that in order to accomplish via CNAME entries as you have outlined you will need to pay for a unique IP at dreamhost.

bobocat’s suggestion to change your namesevers at network solutions to dreamhost, and then re-direct your MX records back to yahoo is also the approach that I would study further.


I appreciate your help.

In that case, I would set up an A record on the Yahoo side, right? And, I would set the A record to point to the unique IP that DreamHost gives me, right? (AND, furthermore, I can expect that that DreamHost will change that fixed IP address at some future date, which I can’t predict.)

Unfortunately, Yahoo Small Business claims to not support MX records.

If I can add insight of value to this conversation, it is: DON’T EVER USE YAHOO SMALL BUSINESS. Once they’ve got you using their email, you’re locked into their hosting. I’ve only had positive, intuitive experiences with DreamHost, on the other hand-- I just wish I could find a satisfactory solution for this CNAME business.


Let me agree with the latter. Yahoo! is no good at any Web or email service. Better to consider Google Apps, which integrates well with DH.


Interesting. I didn’t spend alot of time, but i did a few google searches and few searches in yahoo small business. With google, I found many threads about the net with the same issue, and no resolution.

There are always 3rd party solutions to view your current MX records, such as but that doesn’t guarantee those records will still work if you yank your DNS management away from yahoo.

shifting to your other question: The difference between using an A record or a CNAME record is whether you point to an IP address or to a name. You would use an A record if pointing to an IP, or a CNAME if pointing to a name. The difference as you have pointed out, is that IP’s (whether unique or shared) can change in the future.

If your using a CNAME where the DNS of the receiving side (dreamhost) is managed on the receiving side, the site is far less likely to break if and when dreamhost changes the IP (because they would update DNS of the receiving end).

On the other hand, the simplest and easiest approach is just use the A record to point to dreamhost (and you shouldn’t need a unique IP). The downside is that if the IP does change in the future the site will break until the IP is updated on the yahoo side. (this really doesn’t happen often tho) If you choose this route just make one of the first troubleshooting steps for site down, being check the IP and update if necessary.

Hope that helps.