Switching to CloudFlare

For more than a decade, I've run my own BIND-based DNS server, using FreeDNS for a free secondary DNS service. There has been quite some to do about a large-scale DDoS attack perpetrated against Spamhaus recently. One significant aspect of this attack was that the DDoS used so-called DNS amplification. This makes use of misconfigured DNS servers ("open recursors") to greatly increase the amount of traffic sent to a victim. One fellow server administrator wrote about this and it made me wonder about being an open resolver. Fortunately, my own server was properly configured and could not be used as an accessory in such an attack, but what if it had been? That's where CloudFlare comes in.

What is CloudFlare?

CloudFlare is so named because originally, it was conceived as something of a cloud-based firewall. Not the kind of firewall you probably have integrated into your router at home, but the kind that protects large websites from things like DDoS attacks or other unauthorised access. The service grew to be much more than that. CloudFlare is now effectively a firewall, cache, CDN and DNS provider all in one. Amazingly (and I don't know how they do it), their basic plan is remarkably full-featured and free! And when they say it only takes a few minutes to sign up, they're not kidding. It really is quite simple.

How does it work?

To make use of the services CloudFlare provides, you transfer your domain's zone data onto CloudFlare's DNS servers, which are globally distributed around the world for extremely quick response from anywhere on the planet. Now, when CloudFlare's DNS servers receive a request to resolve the hostname for my webserver, CloudFlare does its thing. It no longer responds with the IP address of my actual server (85.214.89.27) but with the IP addresses of some of their proxy servers (for example, 108.162.197.203 and 108.162.196.203 is what I'm getting). Effectively, all HTTP (and, for paid plans, HTTPS) passes through these proxy servers.

You might think the extra step might slow things down. And yes, there is some slight overhead as requests pass through another server. But in practice, visitors to a CloudFlare enabled site will get a much faster response. How? The proxy servers are in datacenters with extremely high-bandwidth connections and administered by CloudFlare's own team, so I benefit from their infrastructure as well as their knowhow. The CloudFlare system will serve the many requests for images, JavaScript and CSS from their globally distributed caches, significantly reducing the load on my server, leaving it to deal with the more important task of rendering dynamic content. So, if somebody were to attempt to DDoS my site or even if it were to suffer a huge peak in traffic such as from Slashdot, Reddit or Hacker News, it would be those proxy servers that bear the brunt of the attack, with very little, if any of it trickling down to my rather modest webserver.

In addition to serving as a shield this way, there are many options available even to users of the Free plan to improve performance of the website, such as on-the-fly optimisation/minification of HTML, JavaScript and CSS, as well as automatic GZIP compression. While the dynamically generated HTML might be delivered to the visitor's browser ever so slightly slower, all of the other, static resources are likely to be served much faster. Also, as the webserver has less load serving these static resources, dynamic content may be rendered quicker too. The net result can be a handsome speedup, improved security and a not insignificant saving in bandwidth.

How was the setup?

As I mentioned before, signing up for CloudFlare is simplicity itself. It only takes a few minutes to be up and running. When you enter a domain name, CloudFlare takes a minute (literally: 60 seconds) scanning the existing DNS records as best it can and copies them onto its own servers. You can then correct those if needed. The scan works well, though the process is not entirely flawless — it missed some for me and added in some that weren't supposed to be in there too. A really cool feature is that it is possible to enter multiple domain names at once and the 60-second-scans take place in parallel, which was nice as I added 7 domain names simultaneously.

After verifying the DNS records are correct and making any necessary changes, CloudFlare assigns you two DNS servers for each domain. It is then a matter of setting up your domain with your registrar as being managed by those servers. How easy this is and how long it takes depends on your domain registrar. In my case, it took less than 5 minutes for all 7 domains.

By default, CloudFlare will then enable its proxy/caching service on the root domain (shdon.com) and on the www hostname (www.shdon.com). This also means these names will now only accept HTTP(S) traffic. If you connected to your root domain using ssh or ftp, you can no longer do this. Fortunately, the CloudFlare system takes this into account and creates extra DNS entries that allow for direct access without passing through CloudFlare. Additionally, it literally only takes a single click to enable or disable the service for any hostname.

What's different?

So, having switched over to being completely self-managed to CloudFlare, what are the pros and cons for me? There's upsides as well as downsides. To me, the benefits far outweigh the drawbacks.

Pro: more robust

Although I've never suffered any downtime due to load issues, even with large traffic numbers, I'm now much more confident that my sites will be able to handle a sudden peak in traffic beyond what I've previously experienced. Additionally, since I will be able to switch off my own BIND server, that closes off an attack vector to my server as well as makes it impossible to abuse any configuration issues I might unknowingly have.

Pro: easy DNS management

The DNS management panel provided by CloudFlare is definitely the most user friendly and responsive one I've ever worked with in over a decade of domain management. It certainly beats the pants off editing BIND zone files manually. One important side effect of the proxying is that to change from one physical server to another, it suffices to change the IP address. Only CloudFlare's proxies will hit the server directly and the change takes effect pretty much immediately. No more setting your DNS records' TTL to a short time a day in advance, performing a switchover and then re-upping the TTL. Just change the IP address and you're done.

Pro: cool security features

CloudFlare makes it easy to block or trust individual IP addresses, ranges or even entire countries. I'll admit I've been toying with the idea of blocking all of China and Russia from accessing certain sites. They are not in my target market anyway, yet the dominant sources of spam and attacks.

Pro: free!

Did I mention it's free? You just can't get a better deal than that! Even the paid plans are reasonably priced. The "Pro" plan costs a mere $20/mo, with $5/mo for additional sites in the same account. It is even possible to have different tiered plans for individual sites combined in a single account. The $200/mo Business and $3000/mo Enterprise plans are far beyond my price range or needs, as I'm not exactly running a Alexa top 500 site, but those prices seem quite reasonable for what they offer to those who need such plans.

Pro/con: SSL

With a Pro plan, you can make use of SSL through CloudFlare and it is as easy to use and set up as everything has been. To me, this is the major reason I could have for setting up a Pro plan (as I have done for my employer). With the free plan, you'd have to disable the proxying service to your HTTPS server and thus lose many of the benefits CloudFlare provides. If you did this, it would probably be best to have different hostnames for your HTTP traffic and your HTTPS traffic so that the non-SSL version can still benefit from the caching. This may take some doing.

Con: visitor IP addresses

Because all requests to the webserver now come from CloudFlare's proxies, only the IP addresses of the proxies would show up in the logs. More importantly, this would negate certain IP blockades I have set up against spammers or hacking attempts. A simple .htaccess rule allowing access to only certain IP addresses would no longer work. This only applies to hostnames for which CloudFlare's proxying service is enabled and thus by extension to HTTP(S) traffic only. Fortunately, if you have full (shell) access to your webserver, and are running Apache, you can simply install mod_cloudflare and it restores the proper IP address to whatever needs it. Solutions for IIS are available from the same page and if you are running nginx, they've also got you covered. If none of these options are available to you, there is at least still the possibility to read the CF-Connecting-IP header through your scripting language of choice, though this obviously won't affect the logs or .htaccess rules.

Con: extra point of failure

Not even CloudFlare is immune to outages. In fact, they had one lasting about an hour recently. With the free plan or the cheapest paid plan, you do not get an SLA. These are available for the Business and Enterprise plans (a 100% and 2500% uptime guarantee, respectively — that means CloudFlare is so confident of their ability to keep you online that they'll reimburse you 25 times your fee for any downtime you suffer if they fail). Still, the extra point of failure is not a really big deal when I consider that I have much more confidence in the abilities of the professional team managing the CloudFlare infrastructure to keep things up and running than in my own or that of many small scale or part time system admins.

Anything else?

You'd think I've heaped enough praise on CloudFlare by now, but I'm not quite done yet. There's a few other things I feel I should mention:

Despite being on the free plan, when I did contact tech support with some questions I had, I got a reply very quickly and it was not just a canned response, but a proper answer that indicated the support person had read and understood my enquiry (kudos to Justin at CloudFlare support).

For anyone interested in some of the things you never knew were going on when you get to the kind of scale and infrastructure that CloudFlare deal with, they write some pretty good blog posts. Admittedly, sometimes the posts can have a self-congratulatory undertone or be a bit over the top, but on the whole they are quite interesting. Check out the CloudFlare blog.

Oh, and did I mention it's free?