Summary

  • During the BIND 10 rewrite, Mark Andrews and Evan Hunt remained co-maintainers of BIND 9; a declared successor did not remove the operational obligations attached to the installed server.
  • BIND 9's later refactoring shows that continuity was not stasis. The durable lesson is to separate roadmap intent, support, feature parity, workload readiness and completed operator migration.

In February 2013, Internet Systems Consortium announced BIND 10 1.0.0 as new DNS and DHCP software. The release notice made two claims that sound contradictory only if “ready” is treated as one state: the release was fully supported, yet not feature complete. Its DHCP component was described more narrowly still, as an experimental engineering snapshot.

That vocabulary matters. Software may have a support desk, pass tests for a defined role and still lack functions required by another operator. It may be installable without being a drop-in replacement. A version number can mark a release; it cannot prove that the installed base has crossed over.

Mark Andrews stated the boundary plainly in a bind-users exchange. BIND 10 was still some way from replacing BIND 9 and lacked many of its features. The same exchange preserved an important qualification: an operator needing authoritative service without BIND-managed DNSSEC signing could regard BIND 10 as production-ready then. This was not a verdict that the new system worked or did not work. It was a workload claim.

The ISC history of BIND places Andrews inside the harder organisational choice. BIND 10 began in 2009 as a ground-up rewrite on a new framework, intended to replace and improve BIND 9. It drew funding and technical participation largely from the ccTLD community. While most of ISC's DNS team pursued that next system, Andrews and Evan Hunt remained co-maintainers of BIND 9.

The phrase “remained co-maintainers” contains the unglamorous half of replacement. Existing operators still needed security response, release engineering, regression control and usable support. Packagers still needed maintained inputs. A successor team could accumulate capability only because someone else preserved the production option from which users might eventually migrate.

This is not a solitary-saviour story. ISC says more than 43 core developers made significant contributions to BIND 9, and warns that old commit history understates outside contributions. Its 2025 BIND report names a broad development team and external collaborators. Andrews's significance is not sovereign control over BIND. It is the clarity of the duty he and Hunt carried while institutional attention was split.

The programme ended differently from its original intention. ISC stopped BIND 10 development in 2014 and redirected investment to BIND 9. Shane Kerr, BIND 10's final project lead, gave “The Decline and Fall of BIND 10” at RIPE 68; the meeting's archive preserves the presentation and video. ISC notes that the familiar “second-system” label is probably too simple. Funding structure, scope, architecture, feature demand and adoption all belonged to the outcome.

Nor did returning focus to BIND 9 mean embalming it. ISC records later work to disentangle Response Policy Zones, simplify core functions and replace a home-grown network interface with libuv. Before refactoring, query_find() had a reported McCabe complexity score of 453. That is not evidence that old code deserved automatic protection. It is evidence that continuity can include deep internal change while preserving the external service and a controlled upgrade path.

The 2024 accomplishments report makes the operating system around the code visible: nine developers, five QA staff and two managers; 25 open-source releases and 12 supported previews that year. BIND 9.20 completed a multi-release move to libuv-based event loops, and specialised thread pools addressed long tasks that could block query resolution. A rewrite and an incremental refactor are not moral opposites. Both require tests, observed behaviour and recovery paths.

The 2021 annual report records Andrews's twentieth year at ISC and his designation as Distinguished Engineer. It also describes Stable and Extended Support Version cycles with overlap intended to permit graceful migration. That overlap is a governance mechanism: it gives operators time to compare, stage and reverse a change rather than converting a release calendar into an ultimatum.

ISC's current team page still identifies Andrews as Distinguished Engineer. A title can document institutional responsibility; it cannot prove what any nameserver runs. The production fact remains downstream, in packages, configurations, process state, query behaviour and operator records.

A credible replacement ledger therefore needs at least six columns. What capability is promised? Which workloads are supported now? Which features are missing? Who maintains the incumbent during the gap? What evidence authorises each operator's cutover? What rollback remains after it? Without those distinctions, a roadmap is easily mistaken for deployment and a release announcement for migration.