Stork 2.0: Open Source DHCP Management Tool
ISC launched the Stork management application almost exactly five years ago, in November 2019, as an experimental tool.
Read post
The first lines of code for BIND 9 were produced in 1998, which means that the original BIND 9 architecture is 25 years old! Happy birthday!
It’s been a long time, so let’s refresh our memory on the state of the world back then. In 1998, top-notch off-the-shelf server hardware was something akin to the Compaq Proliant 5500 model: up to four Intel Xeon CPUs with clock speeds around 500 MHz, up to 4 GB of RAM, a network interface speed of 100 Mbps, and a price tag well above $10,000 USD.
In 2023, for roughly the same money, it is entirely possible to build servers with 256 CPU threads, all steadily ticking at 2 GHz, complemented with outrageous amounts (read: terabytes) of RAM, and connected to a network using 10 Gbps or even 100 Gbps interfaces.
| Component | 1998 | 2023 |
|---|---|---|
| CPU threads | 4 | 256 |
| CPU clock (MHz) | 500 | 2000 |
| RAM size (GiB) | 4 | 1024 |
| Network interface (Mbps) | 100 | 10000 |
The operating system landscape has changed a lot as well! In 1998, the operating system market share was way more fragmented. AIX, HP-UX, Linux, NetWare, OS/2, Solaris, Unix in many other flavors, and Windows NT all had significant market share, with no clear winner. And each of them had its own set of bugs which needed workarounds. Last but not least, software engineering practices and computer science have also progressed quite a bit!
To sum it up, it’s clear that any software architecture designed in 1998 needs a serious overhaul to use the hardware available in 2023 - and that’s what we at ISC have been doing since 2017.
To give you a better idea about the scale of the changes, let’s imagine that this is what BIND 9.11 looked like:
Here’s what we wish it looked like today, but it’s not quite there:
As you can imagine, the architectural differences between reality and fantasy are quite large. We all know how BIND 10 ended up, so rebuilding the software from scratch is not an option. But rebuilding it piece by piece is certainly possible …
BIND 9.16
In BIND 9.16, we replaced half of the old networking stack with the libuv library. In effect, the code for talking to DNS clients was brand new, and the part for talking to other servers was the old code from 1998. Essentially, we had something like this:
Please note the smoke still coming out of the front; both engines are running at the same time. It works - but certainly is not optimal. Obviously, half-implemented architectural changes can have negative side effects, too.
BIND 9.18
The next step was to finish transition of the networking engine to use the libuv library whenever possible. This is essentially what BIND 9.18 is:
Please note there is no chimney at the front anymore - all the networking is powered by the new libuv code. But it still looks like a steam engine! Why is that?
Because all the old 1998 plumbing is still mostly where it was. For example, cache and zone data are stored in our own Red-Black Tree database implementation, which requires obtaining and releasing a lock every time a data access is made. This worked okay in 1998 with four CPU cores, but it’s not going to perform very well with 256 parallel accesses …
BIND 9.20
For BIND 9.20, we hope to rework lots of internal plumbing and replace the venerable Red-Black Tree database used for cache and zone data with a brand new data strucure, which will avoid the need to lock the whole thing every time we access it. With that change in place, BIND 9.20 will become something like this:
It’s still not a rocket, but much closer than it used to be!
Outlook
We will continue to modernize BIND 9 and chase the ideal, fast-moving target of contemporary engineering and computer science:
