ISC released BIND 9.0 in September. After several years of BIND 8 advisories, the new release is a substantial rewrite intended to address the structural issues with the BIND 8 codebase. I have been running it on my secondary nameserver for a fortnight.
This is a first-impressions writeup. The architectural improvements are real and the operational migration is manageable. The detail is interesting enough to be worth writing.
What BIND 9 is
BIND 9 is essentially a rewrite. The codebase shares almost no source with BIND 8; the protocols implemented are the same but the implementation is different.
The stated goals of the rewrite:
Multi-threaded operation. BIND 8 is single-threaded; under high query load it cannot effectively use multi-CPU machines. BIND 9 is multi-threaded with proper locking. On a 2-CPU machine the throughput improvement is roughly 1.7x.
Better authentication and authorisation. BIND 9 supports TSIG (transaction signatures) for authenticated zone transfers and updates, DNSSEC for zone-data integrity, and finer-grained access control on individual operations.
Cleaner code structure. The codebase is organised more modularly than BIND 8. The various subsystems — DNS protocol, zone management, configuration, logging — are more clearly separated. The intent is to make the code more maintainable and to reduce the rate of new bugs in the future.
Better operational features. Improved logging, better statistics, support for views (different responses to different clients), incremental zone transfers, and a few quality-of-life improvements.
What I have observed running it
A fortnight of operation:
Memory footprint is larger. BIND 9 uses substantially more RAM than BIND 8 for the same zone data. On my secondary, the BIND 9 process is using about 60MB versus 25MB for BIND 8 on the same data. This is fine for my modest hardware but is worth noting for memory-constrained deployments.
Performance is good. Query response times are similar to BIND 8 for typical loads. Under burst load, BIND 9 handles the burst more gracefully due to threading. For a small DNS server like mine, the improvement is invisible; for a busy resolver, it would matter.
Configuration is broadly compatible. My BIND 8 named.conf worked with BIND 9 with minor adjustments. The differences:
- A few directive names changed (mostly minor renamings).
- Some defaults are different.
- The new features (views, TSIG, DNSSEC) are not configured by default; if you do not need them, the configuration does not need to change.
The migration was a one-evening exercise. For more complex configurations it would be longer; the BIND 9 administrator's reference manual is good and the changes are documented.
The new features are real and useful. TSIG-authenticated zone transfers are now configured between my primary and secondary; the key configuration is straightforward. The transfers are now both authenticated and (optionally) encrypted, replacing the previous IP-based trust model.
Where BIND 9 stands relative to BIND 8
For operators choosing between them:
For new deployments, BIND 9. The improved architecture, better feature set, and cleaner code are clear advantages. The operational maturity is now sufficient for production use.
For existing BIND 8 deployments, migrate gradually. No urgent reason to rip-and-replace. The plan I am following: secondary nameservers first (now done), then primary nameservers as they come up for normal maintenance, then any specialised services (DNSSEC-signed zones, internal views) once the basic migration is done.
For legacy systems where BIND 8 is heavily customised, plan carefully. The configuration translation is mostly straightforward but specific behaviours (zone-update semantics, certain logging formats, some less-common options) are subtly different. Test thoroughly in a staging environment.
What this means for the long story of BIND advisories
A hopeful but cautious assessment.
BIND 9 is, by design, a fresh start. The categories of bug that produced the BIND 8 advisory drumbeat were largely structural — memory-management mistakes, parsing errors, race conditions in the single-threaded design. BIND 9's architecture should produce fewer of these.
Should. Not will. Several things to be cautious about:
The codebase is new but uses the same language. BIND 9 is still C. The same classes of memory-corruption bug remain possible. The discipline applied to the rewrite is good, but C without compiler-level guarantees still produces bugs of these classes.
Multi-threading introduces its own bug class. BIND 8's single-threaded design avoids race conditions. BIND 9's multi-threaded design has to handle them correctly. The first year of BIND 9 deployment is likely to surface threading-related bugs that did not exist in BIND 8.
The new features add new attack surface. Each of TSIG, DNSSEC, dynamic updates, views — adds code that could have bugs. The addition of capabilities is not free in security terms.
Adoption will be slow. Most operators will continue to run BIND 8 for several years. The aggregate population of BIND deployments will be a mix; the BIND 8 portion will continue to produce advisories.
My expectation: BIND 9 will be less buggy per line of code than BIND 8, but the absolute number of advisories may not decrease much in the next 1-2 years because the deployed code base now includes both versions.
What I am doing
For my own infrastructure: continuing the gradual migration. Secondary is on BIND 9, primary will follow in early 2001, the various small services after that.
For friends running BIND: I am recommending BIND 9 for new deployments and gradual migration for existing ones. The migration cost is low; the architectural benefits are real.
For my own writing: I expect to write less about BIND advisories specifically as the migration proceeds. The structural shift to BIND 9 is the more interesting story; the individual advisories become less salient.
A closing reflection
The BIND 9 rewrite is a substantial achievement. ISC has invested years in it; the result is a meaningful improvement on a piece of critical internet infrastructure. The discipline to rewrite a widely-deployed system rather than continue patching it is harder than it looks; ISC has done it.
For the broader open-source security ecosystem, the BIND 9 release is a quiet milestone. The pattern — established codebase reaches end-of-life, fresh rewrite addresses structural issues — is one we are likely to see more of over the next several years. Sendmail, Apache, perhaps eventually the Linux kernel itself, are candidates for similar transitions.
The maturation of the open-source security infrastructure is steady, slow, and largely invisible from outside the projects themselves. The cumulative effect is significant. We are in better operational shape, structurally, than we were three years ago. The trajectory continues.
More as 2000 wraps up.