The Internet Systems Consortium is looking for a few more good programmers to bring the next generation of its open source BIND DNS server software to fruition.
"The goal is to move away from having BIND a heavily sponsored corporate product," said Shane Kerr, ISC's BIND 10 engineering manager. "ISC will always maintain ownership of the code, but we would like there to be more of a community around it."
Friday, the ISC is holding a BIND Open Day near San Francisco, during which Kerr and other ISC engineers will discuss ISC's vision of getting contributions to BIND (The Berkeley Internet Name Domain) from a wider range of developers and users.
With more developers examining and working on BIND, bugs will be found and fixed more quickly, Kerr reasoned. "If other people are working on the code, they are more likely to solve the problems they have," Kerr said. And interested parties will be able to implement the features they want to see in the software.
BIND is the world's most widely used DNS server software. ISC estimates about 80 percent of the DNS servers globally run BIND. Previous versions of BIND were developed through a relatively small number of corporate and government sponsors. The software was first developed at the University of California, Berkeley, in the early 1980s, under a US DARPA (Defense Advanced Research Projects Agency) grant. It was subsequently maintained by Digital Equipment Corp.
BIND 10 to be done by end of 2012
One DEC engineer Paul Vixie, assumed maintenance of the software after he left DEC, and subsequently helped start ISC, which maintains the software now. ISC contracted out further development of the software, and various Unix vendors and government agencies contributed as well. ISC currently maintains several software products critical for Internet infrastructure, such as BIND and an open source implementation of DHCP.
BIND implements DNS (Domain Name System) protocols that allow computers to return an Internet address when given a domain name. If BIND cannot resolve a name using its own resources, it can consult other servers.
The developers hope to have a production version of BIND 10 ready by the end of 2012. This is the first major rewrite of BIND since BIND 9, which was released in 2000. Parties interested in following the progress of BIND 10 can join a low-volume announcements list, or high traffic developers list, both available on the BIND 10 site.
BIND 10 will be architecturally different from BIND 9, Kerr explained. BIND 10 will use different components of BIND 9, though the project is developing much of the software from scratch. BIND 9 is monolithic, meaning that all the features are run from a single daemon, or process. In contrast, BIND 10 will operate as a set of stand-alone but cooperating processes, with each process offering a separate service.
This modular approach will be handy in a number of ways, Kerr said. It will make it easier for outside developers to contribute, because they won't have to understand the entire operation to contribute one particular feature. The modular approach will allow different parties to develop specific functions as optional modules that might not be needed by all users. It will also make it easier to run the software on multicore processors, with different services running on different cores.
More resilient to coding bugs
Finally, the new architecture should make the software more reliable, Kerr said. BIND 9 has gotten a fair amount of criticism for the way it handles bugs. "We expect [the new approach] to be a lot more resilient with coding bugs, which has been the source of most of the security problems with BIND 9," Kerr said.
BIND 9 was engineered so that when its operations were disrupted by a bug, it would immediately shut down. Though a safe move, this approach, as it turned out, not a very practical one for mission-critical operations. "It was quite frustrating for administrators," he said. Kerr offered an example: In BIND 9, "there was a bug in our Dynamic DNS code, and it would end up being a security issue, because it would cause the server to crash, even if you were not using Dynamic DNS," Kerr said.
With the new design, if a bug mucks up operations, only the particular service with the bug will cease operating. So if you were not running Dynamic DNS, you would not be vulnerable to that exploit, and if you were running Dynamic DNS, the bug would only affect that service. Also, the new version can automatically restart services that crash.
ISC has not worked out all of the details of how it will handle outside contributions, Kerr said. The development and maintenance has been transparent thus far. The code is freely available as a download and anyone can join the developer mailing list. Going forward, the ISC would like to retain control of the overall direction in which the software is developed, to keep the development in line with serving the wide ranging needs of the Internet. But ISC has not yet specified a governance process to guide which features developed by others get added. "It's still new to us," Kerr said.