Feature suggestion: add CNAME capability

Currently, DreamObjects only retrieves content stored on buckets of the form <bucketname.objects.dreamhost.com>, or perhaps also <objects.dreamhost.com/bucketname> (I haven’t tried that).

It would be nice if we could add a CNAME to that, e.g. myobjects.mydomainname.tld (if you do that, DreamObjects will complain about a Bad Request), like Amazon S3 does.

It’s not just a question of “having nice names”. It has two advantages:

  1. Google’s ranking algorithm will prefer things that come from the same domain, specially if there are a lot of “things” (why, I don’t know).
  2. More important than that: DreamHost is a CloudFlare partner. If static content is served from the same domain name, then CloudFlare can act as a CDN for DreamHost objects. Why is this important? Because CloudFlare is able to distribute content among their 14 data servers, providing better service (shorter round-trip time in delivering content) to the whole world. Of course, if your DreamObjects-enabled web app is targeted only at people living in cities near DH’s own data centers, this will be mostly irrelevant (even though CloudFlare will add lots of additional functionality, like dealing with spammers/scammers/security breaches, etc.). For the rest of us, though, having CloudFlare on top of DreamObjects is a cool extra bonus (for free).

Is this somehow also on DH’s list of upcoming features when DreamObjects gets out of Beta?

Hey Gwyneth, I completely understand and agree. It’s a feature that we must be provided by the RADOS gateway in Ceph and I know it’s on the to-do list. Right now if you have a CNAME configured for your bucket, it’ll resolve to objects.dreamhost.com. The ordinary calling format <objects.dreamhost.com/bucketname> will work. This means you could create a CNAME and call refer to it in the ordinary calling format of <cname.yoursite.com/bucketname>. This is an ugly hack but could work for you until we have proper CNAME capability.

And for the CDN, it’s definitely our top priority once we’re out of beta. We are investigating a few providers for that now.

Hmm! I will have to figure out how to implement that on the hacked W3TC plugin for WordPress. It might work…

Thanks for the tip!

justinlund, I have implemented your suggestion! It certainly works well :slight_smile:

The updated hack is described on the Wiki: Using WordPress with W3TC and DreamObjects

It’s a very quick & dirty hack, and only bothers with the first CNAME on the list. W3TC actually allows different CNAMEs so that WP users can place JS, CSS, images, etc. on different buckets (which in theory would allow sharing similarly-named resources across several WP installs). I didn’t bother to be so thorough, since you mentioned that CNAME support will become standard on DreamObjects sooner or later, so, well, it seemed pointless to waste too much time :slight_smile:

I wonder how much progress has been done in implementing this. For some reason, my hack for WT3C doesn’t work any more, and I’ve been having some problems in figuring out what to tweak to get it working again…

Hey Gwyn, CNAME support is included in the next version of Ceph. We have been testing various builds over the last month and the CNAME feature works very well. There are still a few bugs to squash in other aspects of the release though, but we hope to bring the update to you soon. I’ll definitely post an update once CNAME support is available.

Any update on this feature?

Hey artb, we’re still working on it! On the operations side, we’ve been doing scale testing on the Ceph release to ensure stability. On the development side, we are nearing completion on both the UI and the backend work. No ETA just yet, but we’re working hard on this since it’s probably the most requested feature.


Just to give you some feedback on the WordPress side of things. The W3 Total Cache developers seem to be willing to do better support for DreamObjects, by lifting the “restriction” of using only Amazon S3, but allowing any S3-API-compliant object cache to be used.


We’ll see if that makes CNAME support superfluous, at least for W3 Total Cache.

Hi anu update on the feature? CNAME is very importnat, infect, I’m considering to move a large archive and static pages to objects. I need CNAME support to do so. Please update?

I’m happy to say that I have good news for you! We will begin upgrading our cluster this week for the necessary changes for CNAME support. We’ll roll out CNAME support in the panel once the upgrades are complete and we’ve been able to verify the functionality. I know it’s been longer than expected, but not much longer!

I wanted to give you all some advanced notice about CNAME support. Our team upgraded the cluster and it now supports CNAMEs. The pretty UI is not available in the DreamObjects section of the panel yet, but you can still configure it in the Manage Domains section of the panel.

Go to the DNS settings for your domain.

Set the Name and choose CNAME as the Type.

Set the Value (using your bucket name) to my-bucket.objects.dreamhost.com

That’s it!

One helpful tip - make sure your Content-Type headers are set properly or browsers may try to download images instead of display them.

Thanks for update.

Just to check, if in case domain are hosted with other nameservers than dreamhosting than it just need CNAME as records, nothing would be require as additional config.

nilayparikh: Correct. The CNAME record just needs to point to your bucket’s DNS name (e.g, yourbucketname.objects.dreamhost.com).

This is good for now, I would request via versa feature too, also try to add permanent 301 redirection configuration in your system.

i.e. suppose some one want to host static or archive site with SEO in mind, in case of CNAME the content would be considered as duplicate as it is accessible via two various hostname. But if you allow us to configure FQDN into your system and your system perm redirect 301 from yourbucketname.objects.dreamhost.com to cdn.mydomain.com than it would be excellent valued feature. Than your system can support hosting large static archive or text sites like Amazon S3 Static sites.


Just curious
How you know that which request belong to which bucket?

I just
$ dig [my bucket name].objects.dreamhost.com @ns1.dreamhost.com
$ dig objects.dreamhost.com @ns1.dreamhost.com
and found out that it use the same IP address
both point to

so the browser just connect to
and sent somethingnotrelate.example.com as Host header
to the server.
and no more info sent.

How you know that somthingnotrelate.example.com
belong to [my bucket name].objects.dreamhost.com ?

One possibility is that you perform internal DNS Lookup
to somethingnotrelate.example.com and read the CNAME record
but then what about latency and redundancy thing?
Does it also depend on original DNS server?
(I mean this way the DNS server will be queried 2 times
by normal client and by dreamobjects this will add more latency to the request.)

[quote]One possibility is that you perform internal DNS Lookup
to somethingnotrelate.example.com and read the CNAME record
but then what about latency and redundancy thing?
Does it also depend on original DNS server?[/quote]

Correct, that’s exactly how it works — we take the Host header on the request and do a DNS lookup to figure out what bucket it’s pointed to. It does require one extra DNS query, as you’ve noted, but I believe the result is cached pretty aggressively, so it’s only required for the first request we handle.

another disadvantage of this method is that
you can’t use cloudflare(or other origin pull CDN) as a CDN
because cloudflare will override the CNAME record

If you really want to go this DNS path (for dreamobjects)
I suggest that you implement it by TXT record.

this add some more advantage.

  • independent control over DNS record because DreamObjects use dedicated record just for its purpose. (this way the user can also use cloudflare and also can set TTL of dreamobjects separate from normal client TTL)
  • you can add another feature you want you can set anything (ie.someconfig) in TXT record. (because it has no standard)

The danger of pointing to IP means, in case of dreamobject failover your site CDN will go down. Pointing IP is very bad idea in any case. It must come from 2-way DNS config.

I don’t think you got what I said.
I’m not oppose using the CNAME
but I against the way it work behind the scene

with this trick origin pull CDN (such as cloudflare) won’t work with the mapped CNAME
also DreamObjects will use same TTL as client who visit your site.