The BIND 10 engineering process begins with formalization of the software architecture, followed by programming. Its core and edge modules will be targeted for years three through five of development.
The architecture of BIND 10 concentrates on these technical aspects: modularity, customizability, clusterization, integration, resilience, and runtime control.
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 what is included in a given binary build, e.g. the selection of caching-only or authoritative-only functionality. This would enable the generation of lighter-footprint BIND images suitable for embedded or mobile applications.
Clusterization: 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 would 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.
Resilience: BIND 9, like most services of its era, responds to many errors by logging and exiting. This has the potential to turn minor problems into Denial of Service attacks. We believe that it will usually be possible for BIND 10 to reset itself and continue operation, but it will require both careful design and careful testing to ensure that reset-and-continue is the usual response to attacks.
Runtime control: BIND 9 reconfigures itself by re-reading its configuration file. Primitive control has been possible with the rndc program. Today's operational environments require a faster, more interactive, and finer-grained approach to configuration and operational changes. BIND 10 will have much more sophisticated and interactive runtime monitoring and control.