Understanding DNS Load Balancing

A In-depth report on bGuard's 1.41 Update.

Updated by mochaaaa (Noelle Tasogare) on Sept. 16th, 2024. (1) (2)

Load balancing with DNS is, as it may sound, complicated. There are many things that have to go correctly for DNS Load balancing to work, amongst other factors, which play part into the servers that get millions, if not billions of requests per minute.

However, a very interesting experiment comes up with bGuard and its load-balancing technique, which didn't really exist whatsoever, up until the 1.41 update.

Pre 1.41 Load Balancing:

alt text

An example of three reqests being set at random intervals.



alt text

An example of three reqests being set at the same time.

Before 1.41, bGuard used to take socket requests synchronously, despite bGuard using event dispatchers which are async by nature, this was because bguard did NOT utilize async features which were available on node, which even if used, would NOT work asynchronously, mainly due to issues with usage on the dgram module, and how funtions were defined and used within the event dispatcher.

Server "on" event bGuard

The "on" event dispatcher.

This means that theoretically, since requests take anywhere from ~120-300ms to resolve, and ~40-90ms to recieve, we could theoretically handle 400 requests per second, which is not much, but should be enough to handle a small amount of users.

However, due to the recent DDOS attacks on bGuard, which totalled to ~4000 requests per second, we needed to increase the efficiency of the request processing and the request resolving.

This is where process spawning and distributing comes in.

Process Spawning, async, and Headaches.

Thankfully, nodejs (and many other high-level programming languages) support process spawning, and multithreading.

Basically, multithreading and process spawning helps us by allowing bGuard to create child processes (another script) to handle a function call, whilst letting the server handle more, this throws out the syncronous approach to bGuard, and theoretically, allows us to process infinite requests, given, they are under the PID limit.

New Server Diagram

The new server handler diagram, looks cool and explains bGuard.

The server structure for bGuard changed, from being a simple UDP4 / WS / Express server, to having a Database interface, with 1.41, the server interface changed, as the syncronous process caller changed to Async, whilst also maintaining request priority and requestor responses.

Current Load-Balancing, Real-World Implementation, Final Thoughts.

Current Load Balancing

Current Load Balancing under Same Request Timing.

Current Load Balancing, but with Variable Timing.

Current Load Balancing under Variable Request Timing.

To Summarize, bGuard can now handle a decent amount of requests, more than what a nodejs server should realistically be able to handle, which is quite impressive. using traceroute (SRV Records) to test the Load-Balancing on bGuard, we get impressive results:

CCU, RPM and other stats.

Impressive Concurrent Users and Requests per Minute Count.

1400 Requests per Second

1,400 Domain lookups! Impressive!

Alonside this, the server has increased stability, which makes it quite impressive to even be able to run, overall, load balancing bGuard was a very daunting task, yet, a very fun one to poke at.