Priocept has recently been implementing and evaluating CloudFlare, a CDN service. We thought we would write up our findings for the benefit of other prospective CloudFlare users.

Introduction to CloudFlare

CloudFlare is a content delivery network (CDN) that acts as a reverse proxy sitting between your end user’s web browser, and your website’s web server(s).

When a web browser requests some content on your site, it is actually requesting it from CloudFlare, thanks to some DNS changes. CloudFlare will either then serve the content itself (if the content is static and if CloudFlare has the content in its cache), or it will make a downstream request to your web server to get the content, and then serve it to the user.

Benefits

CloudFlare (and other CDN services) provide many benefits:

1. Caching of content reduces load on your own web servers, and serves content from CloudFlare’s own high performance infrastructure, reducing response times.
2. CloudFlare serves the content from one of its servers that is geographically nearest to the user, ensuring consistent website performance from most global locations, regardless of where your web server is hosted.
3. CloudFlare also processes and optimises the content before sending it to the user. For example it can “minify” HTML, CSS and JavaScript, removing redundant parts of the code (or source code structure) and reducing file sizes without affecting functionality.
4. Provides a security and protection layer in front of your web server. If, for example, you website is subject to a distributed denial-of-service (DDoS) attack, CloudFlare will experience the attack, not your underlying website, and CloudFlare has systems in place to deal with this to ensure your website continues to function normally during the attack.

CloudFlare Setup

The best feature of CloudFlare is its super-easy provisioning. No technical changes are required to configure your website. The CDN can be set up solely via the CloudFlare web interface simply by registering and paying for the appropriate package.

The process works as follows:

1. DNS changes – The default model is to have your entire DNS managed and served by CloudFlare, which requires a change to use their nameservers. We are not a fan of this approach, so use the alternative CNAME implementation. You simply change the DNS entry for your website to point (say) www.company.com to www.company.com.cdn.cloudflare.net rather than to the IP address of your own website. Then all requests will go to CloudFlare first.
2. CloudFlare configuration – Via their web interface, you tell CloudFlare how to find the underlying website. So in the example above, you provide the IP address for www.company.com, like you would for a DNS entry.

That’s it! Requests to your website will go to CloudFlare not to your own webserver, and CloudFlare will do its stuff, requesting content from your webserver when it needs it.

The “Root Domain” or “Zone Apex” Issue

However, things are never that easy!

The problem lies with the use of a zone apex, without the “www”, as your website address, eg: http://priocept.com/ rather than http://www.priocept.com/ – who wants to use “www” these days? It’s redundant and it’s old school.

However, DNS RFC1033 doesn’t allow a CNAME for the root domain. So the model described above doesn’t work. Only an A record is allowed, but that wouldn’t work as you’d have to explicitly set CloudFlare IP addresses, and if CloudFlare changes these, your site would break. Using a CNAME to point your site to xyz.cdn.cloudflare.net leaves CloudFlare to worry about what IP addresses this resolves to.

You have few alternatives here:

1. Move your entire DNS to CloudFlare. Then they are responsible for resolving http://priocept.com/ directly, no CNAME required and problem avoided. We are not keen on this solution – we already have a DNS provider we are happy with that provides features that CloudFlare doesn’t. Most importantly, we like the separation of concerns between the two. Companies rely on DNS for all sorts of things (like email) that have nothing to do with their website – so why hand that over to CloudFlare if you don’t need to? CloudFlare also has a major limitation in that it only allows a single admin login. So if the person in your organisation that manages your DNS is not the same as the person that manages your webservers, they are going to have to share a single CloudFlare login, which is messy and insecure.
2. Only serve your media via CloudFlare. This way, you set up say cdn.companyname.com. Then you implement URL rewriting on your webserver so that any references to images, Javascript, CSS and so on are modified to reference cdn.companyname.com. For example: <img src=”/images/x.jpg”> Would become: <img src=”http://cdn.companyname.com/images/x.jpg”>
3. This way, you can keep the address of your website, as presented to the user, as http://companyname.com/ (without the www.) but behind the scenes, all media will be served via CloudFlare. You simply need to CNAME cdn.companyname.com to cdn.companyname.com.cdn.cloudflare.net and you can do this with your existing DNS servers – no need to move DNS to CloudFlare. The disadvantage of this technique is that your page content (HTML) is not being served by CloudFlare. So you lose the performance gains and security protection for everything except “media” on the site.
4. Fancy DNS features. At Priocept we use DNSMadeEasy as our DNS provider. They provide a feature called “ANAME” records. This is not part of the DNS RFC but is a DNSMadeEasy proprietary extension. You specify an ANAME record like you would a CNAME, but behind the scenes it is treated like an A record, and directly returns an IP address rather than another hostname. For example, you point companyname.com companyname.com.cdn.cloudflare.net as an ANAME (this would not be allowed as a CNAME companyname.com is the apex). Behind the scenes, DNSMadeEasy goes off and looks up the IP address(es) for companyname.com.cdn.cloudflare.net, and returns these directly whenever a lookup for companyname.com is performed. The ANAME configuration is continually updated to reflect any changes in the IP addresses associated with the A record for the hostname specified.
5. This way, you can run your website at the root domain, but still have it running via CloudFlare. If CloudFlare change their IP addressing, DNSMadeEasy will detect this and automatically accommodate the change.

Website Availability Improvements

CloudFlare also provides sophisticated features to ensure availability of your website, were possible, in the event of an outage of your webservers. For static (cacheable) content, you can specify a validity period for cached content, and you can configure CloudFlare to serve content from the cache in the event that your downstream webserver is unavailable. This way you can ensure that much of your website achieves high availability even if you do not have high availability web server infrastructure. For websites that consist largely of static content, this feature is invaluable, as it means that you can use very low cost hosting infrastructure, and then rely instead on CloudFlare to ensure your website is reliable, in addition to being fast and secure.

Conclusion

The CloudFlare service provides access to extremely sophisticated infrastructure with powerful features, at relatively low cost and with super-simple setup that requires barely anything more than registration on their website, creating a payment plan and entering your website details. This makes the performance and security benefits of a CDN available for all websites, including small and medium scale sites where enterprise solutions such as Akamai may not be suitable.