The current release of ISC BIND, version 9, has been under development for a decade. Throughout this time, it has been a powerful and trustworthy platform on which to base any DNS service. BIND 9 was a huge leap forward from earlier versions in several areas, in particular, security and the trustworthiness of the code base. It is also a major improvement in terms of adherence to RFCs. In some areas, however, BIND 9 did not deliver the full potential that it promised. The most commonly cited shortcoming is the poor use that BIND 9 makes of multiprocessors. Today it is common to deploy servers with 8 or 16 or 32 processors; BIND 9 was designed in an era when almost no production server had more than 1 or 2 processors.
In the last decade, there have been many significant changes in the Internet operations environment, in software engineering techniques, in computer architecture, and in user expectations. BIND 9's core architecture is increasingly coming against requirements that were not even imagined when the development of BIND 9 began.
This trend will only increase in the future, so ISC is undertaking the design of the next version of BIND (BIND 10), to produce a new code base, partly based on the current BIND 9, that will be able to meet the needs of the next decade as well as BIND 9 met the needs of its predecessor.
Here are major areas that are being redesigned:
- Modularity: clearly defined points at which to interface with the backbone of BIND, allowing (for instance) the selection of a variety of back-ends for data storage, be it the current in-memory database, a traditional SQL-based server, an embedded database engine or back-ends for specific applications such as a high performance, pre-compiled answer database.
- Customizability: the ability to select the functionality to be enabled in a given binary build, e.g. the selection of caching-only or authoritative-only functionality. This would enable the generation of light-footprint images of BIND suitable for embedded or small dedicated applications.
- Clusterization: the ability to run on multiple but related systems simultaneously, using a pluggable, open-source architecture to enable backbone communications between individual members of the cluster. These coordination services will enable a server farm to maintain consistency and coherence.
- Integration with customer workflow: ISC recognizes that flat text configuration and data files, while adequate for most purposes, are not a very flexible way of integrating with the ever more sophisticated back-end systems that customers use for process management. BIND must provide new forms of interaction with (and interfaces to) monitoring and configuration environments. This ability for workflow integration would enable, for example, closer coupling between BIND and DHCP without the need to combine them into a single service or server.
- BIND 10 must recover from failure and continue operation, reducing the impact of software errors and denial-of-service attacks on the availability of the service.
- Better runtime control: BIND 9 was designed to use configuration-file reloads as a means to alter configuration. Today's operational environments require a finer-grained approach to configuration changes. This will is an explicit design goal for BIND 10
BIND 10's full-scale development is limited by the availability of funding, but ISC internal funding is moving it forward somewhat.
