DNS Round Robin Examples

A fast fat bird for more stability!

A fast fat bird for more stability!

If your site grows, you might want to deliver your pages from more than one server to uphold the speed and stability of your online estate. There are some simple ways to do that on a shoestring budget and in the past years I have repeatedly held presentations about it….

Let me show you, how easy it is to split your site on 2 or more servers – even if you run dynamic pages on PHP or other serverside languages with DNS round robin.

The implementation of a distributed site structure along this simple technology requires you to basically understand your site functionality. If you run a blog on WordPress of  if you have a content management system online, you might have to touch the config file for it.

DNS entries

But let us start with the basics:

  1. Whenever a user requests your domain name, a nameserver responds with the according IP number
  2. Round robin means in this case: you enter different IP numbers for the same domain.
  3. The DNS automatically shuffles through the list of IPs and gives one back randomly

The A records of your DNS do then look like this:

A records

where the same subdomain points to different IP numbers. You can do that on domain hosting companies like GoDaddy or rent your own DNS accounts with companies like widge.net or PowerDNS.net.

Once you have entered the “rotating subdomain”, you can also enter a CNAME for your site to match that rotation:


which makes a request to our example domain “www.tradebit.com” rotate randomly over the destination IPs from the list above. You may ALSO just enter the different IPs as single A records – that would also rotate then.

Application config

Keep in mind, that this splits your visitors randomly and evenly with no real rule between all the destinations your registered. As mentioned before, your application must support that a setup in the following ways:

  • Session handling: if you have user sessions, you need to have the session storage centralized. In PHP we do that with a central session memcache, which is supported by the language! It is most likely that the user will land on the same machine again, but you can not be sure about that.
  • Central files: Like this blog runs on such a setup, the pictures from this article are stored centrally on an image server, which is mounted via NFS into the many versions of the blog. For speed we then deliver the content via a CDN.
  • Development and deployment: If you change your code, you have to upload it to a server and multiply it to all the frontend servers. We have created some shell scripts for that.


Besides the improvement of speed, this setup also has the advantage that you can react much faster to server outages. For example: if one of our frontend servers fails, we remove it from the round robin entries of tx.tradebit.com and while it takes some time for the nameservers around the world to learn it, we only loose 1/6th of the traffic in that time frame.

Comments are closed.