Opened on 04/08/2014 at 10:00:26 AM

Closed on 04/14/2016 at 02:59:03 PM

Last modified on 04/25/2016 at 10:08:33 AM

#286 closed change (fixed)

Implement a better load balancing approach

Reported by: trev Assignee: matze
Priority: P1 Milestone:
Module: Infrastructure Keywords:
Cc: fhd, fred, darkue Blocked By: #1698
Blocking: #3540, #3981 Platform: Unknown
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):



Filter list downloads currently use DNS-based round robin load balancing. This doesn't distribute the load equally however. More importantly, it limits the number of servers that can be used due to limitations in size of DNS responses.

What to change

Move filter list downloads to their own domain and run our own DNS server. We could use Bind with geolocation capabilities for example ( or Even if all of our servers are currently in the same location, we could assign some servers to particular countries - so DNS servers in these countries wouldn't get the full list of servers in the response. Later we would move these servers to data centers close to the countries in question.

Attachments (0)

Change History (9)

comment:1 Changed on 04/11/2014 at 09:19:16 AM by trev

  • Cc fhd added

I checked out the information on Tinydns (part of djbdns tools) and so far it looks more promising than Bind.

  • Last release was in 2001. However, Ubuntu package (a fork named dbndns) contains some patches, in particular to add IPv6 support.
  • In total there were three vulnerabilities discovered in djbdns, one affecting Tinydns but only exploitable by specially crafted subdomain records (all have been patched in Ubuntu). That's a much better security track record than Bind.
  • The configuration files used by tinydns-data are unusual but still fairly straightforward. More importantly, generating this configuration file with Puppet should be trivial.
  • There is support for conditional responses based on client locations, we could generate locations from GeoIP databases automatically. However, unlike Bind it works with IP prefixes rather than network masks. Given that we don't need exact regions that shouldn't be an issue however.
  • Only UDP requests are supported by default. Answering to TCP requests requires setting up axfrdns tool (not sure whether we need it if we keep responses below 512 bytes).
  • There is no DNSSEC support. It exists as a patch but this one isn't included in Ubuntu packages yet.
Last edited on 04/11/2014 at 09:30:53 AM by trev

comment:2 Changed on 04/11/2014 at 10:22:07 AM by trev

The other option would be gdnsd which is a much more complex tool but with built-in advanced load balancing mechanisms. It also happens to be under active development. Downside here: it's not available for Ubuntu 12.04 but only Ubuntu 13.10.

comment:3 Changed on 07/08/2014 at 09:46:20 AM by matze

  • Platform set to Unknown

Another possible solution would be the migration to a more sophisticated DNS distribution method, e.g. Anycast.


  • Implemented on the registrar side, thus applicable quite easy and fast
  • No need for additional hard- or software
  • The consequences of many attack and overload scenarios are limited to a global region
  • Can become extended with custom setups (as mentioned in this ticket already) later


  • Would probably increase the volume of our payments / our plan with the registrar
  • Does not perform well when balancing an unexpected high load from one global region

comment:4 Changed on 07/10/2014 at 12:40:16 PM by trev

After reading up on Anycast, there seems to be two possibilities:

  1. We use Anycast to have a single IP address for all our download servers. This is rather complicated to set up and would be quite an overkill at this point.
  2. We use Anycast to distribute the tasks of our DNS server to many servers across the globe. These DNS servers could then serve different responses depending on their location.

I checked out a few providers of Anycast DNS hosting and it appears that they typically serve "regular" DNS responses (not dependent on client location). Only one provider mentioned GeoDNS and they didn't have any price tag on it which is a good indicator that the price will be very significant. In general, there doesn't seem to be a significant intersection between Anycast and GeoDNS, the latter being what we want.

Now we can look at hosted GeoDNS solutions of course, if there are some significant advantages. The clear disadvantage of this solution will be configuration (no longer possible via Puppet) - and the price should also be significant for our volumes.

comment:5 Changed on 12/15/2014 at 09:29:06 AM by matze

  • Blocked By 1698 added

comment:6 Changed on 03/14/2016 at 12:42:30 PM by matze

  • Blocking 3540 added

comment:7 Changed on 03/14/2016 at 12:47:45 PM by matze

  • Owner set to matze
  • Priority changed from P3 to P1
  • Tester set to Unknown

After excessive tests and evaluation in the last months, a pretty unproductive attempt to establish a better solution with our current provider, and some recent increasingly severe issues, we have decided to move our DNS zones to another service, which seems to not only solve current issues but also support most future tasks planned already or just seen as nice-to-haves. More details will follow.

comment:8 Changed on 04/14/2016 at 02:59:03 PM by matze

  • Cc fred darkue added
  • Resolution set to fixed
  • Status changed from new to closed

After we finally migrated our zone to our new DNS provider, this ticket is considered obsolete: The more sophisticated, but still primarily DNS-based balancing features fulfill our requirements as intended, and future improvements (incl. Geo-based casting) are supported as well.

comment:9 Changed on 04/25/2016 at 10:08:33 AM by matze

  • Blocking 3981 added

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from matze.
Note: See TracTickets for help on using tickets.