wiki:Year4Ideas

High-Level Goals for Year 4

With Year 4, we want to focus on making BIND 10 something that people actually use.

The big goals for year 4 are:

  1. Make BIND 10 easy to use, including:
    1. Intuitive and powerful command-line administration tool
    2. Operational transparency, such as:
      1. listing zone status, including transfer details
      2. trace recursion
    3. Migration tools from BIND 9 and other DNS servers (configuration & zones)
    4. Support for traditional configuration files
    5. Support for configuration history, with restore (apply old configuration)
  1. Improve BIND 10's recursive resolution, including:
    1. Port randomization and other anti-Kaminsky measures
    2. DNSSEC validation (NSEC and NSEC3)
      1. RFC 5011 support
    3. EDNS(0) support, including fallback logic
    4. Server capability tracking (lameness, EDNS(0) support, and so on)
    5. Query tracing
    6. Cache as an object
      1. Cache control
      2. Cache persistence
      3. Cache migration
    7. Comprehensive functional test suite (as a standalone tool)
  1. DNSSEC zone management, including:
    1. Signing
      1. Automated, including re-signing
      2. "in-line signing"
    2. Key management
      1. Automated key rollover
      2. KSK rollover support
    3. Command-line tools for working with DNSSEC
  1. Other goals:
    1. Hooks/plugins
    2. BIND 9-style views
    3. Elegant network interface handling
    4. Additional data source support, including:
      1. LDAP
      2. MySQL
      3. PostgreSQL
      4. Berkeley database (BDB)
    5. IDN support in administrative tools
    6. Packages or installers or popular operating systems
    7. Performance
      1. Recursive no worse than BIND 9
      2. Efficient primary and secondary transfer efficiency

Review of Progress So Far

The goal for Year 3 was "production readiness", however that goal will likely only be partially met.

At the beginning of the year, two tactics were proposed to get the server production ready:

  1. Continuous addition of new features
  2. Steady introduction into production environments

There was some introduction of BIND 10 into production environments, but less than intended. Most of the focus of the year ended up being on adding missing features.

One problem is that BIND 9 provides a huge number of features, and that trying to implement a decade's worth of features in 3 years turned out to be a stretch. This difficulty was exacerbated by unknown issue with BIND 10's next-generation approach, and the necessity to guess at the best approaches throughout the design and implementation to date.

BIND 10 has not adopted a waterfall model for developing software, due to the well-understood problems with that approach. However, by avoiding this approach the advantages provided by that approach have also been lost. These includes:

  • A comprehensive list of the goals
  • Well-defined points to build requirements, design, code, and tests
  • The documentation produced as a side-effect of those artifacts
  • Detailed timelines

Ultimately BIND 10 needs to look at what can hopefully be a useful fusion of 20th and 21st century software engineering approaches, an "agile waterfall" as it were.

BIND 10 should have had some early adopters by the end of year 3, however it looks likely that this will not be the case. Hence the focus in year 4 on attempting to gain those users.

Recommendations

We need to shift slightly from our current approach of adding a user-visible feature every release. We want to make improvements for the users with each release, but new features do not necessarily move us towards our goal of making BIND 10 something people want to use. As an example, Mozilla Firefox was first released as a browser with *less* functionality than Mozilla's main browser. The idea is not that we can remove functionality, but rather that a well-designed feature that a user needs is better than several not-so-polished features.

One problem with this strategy is that it is difficult to know when to stop improving a given portion of a system. It also involves significant cost, as it means taking risks and experimenting; any experiment has a chance of failure, but a lot of BIND 10 is an attempt to do things differently from the past.

As discussed above, BIND 10 will try to embrace aspects of both waterfall and agile methodologies.

Stuff from Waterfall

  • List of requirements/deliverables
  • Defined times for written requirements, designs
  • Timelines
  • Customer sign-off

Stuff from Scrum

  • Timeboxed releases
  • Feature demos
  • Short sprints
  • Daily calls
  • Team estimates
  • User involvement

In order to mix these, we need to relax the requirements of both waterfall and scrum. So, for example, revising the deliverables/requirements is a core value of agile development , and MUST NOT be considered a problem or indeed a failure. Likewise, waterfall insists on requirements before coding begins.

Estimates are a problem, both for waterfall and scrum methodologies. Scrum development tries to define the problem away, but ultimately the people paying for development insist that they know how much it is gonig to cost, which means that estimates are important. The waterfall methodolgy proscribes a number of techniques to attempt to improve estimation, but it remains a weak point of that approach. In a combined model probably the best that can be said is that with more effort spent estimating perhaps some improved estimates can be made.

Proposed Strategy

We will split Year 4 into three semesters, each concentrating on one of the major goals. We will make three releases within each semester, on our current 6-week cycle. Requirements and design for subsequent releases will occur within the current semester though.

Suggested timetable:

Feature April July(-ish) December(-ish)
Usability Implementation Polishing Maintenance
Resolver Design Implementation Polishing
DNSSEC management Requirements Design Implementation

Increasing emphasis on written requirements and "traditional" project management will mean less time spent producing code. This is a trade-off taken to increase predictability of the project.

The rational for the ordering of the major goals is as follows:

  • Usability must come first. The technical excellence of the rest of the system is meaningless if it is difficult for administrators to get to.
  • The resolver work is long overdue, and must be completed for the large number of resolver operators to take advantage of BIND 10.
  • DNSSEC functionality needs a hard look, so simply implementing the feature set of existing DNS servers is not enough. A "back to the drawing board" approach will yield a big win, but needs time.

It is probable that 4 months is nowhere near enough time for implementing everything within a given feature area. That means we need to make decisions.

Proposed Timeline


Y4 release 1 (usability):

Here we release some handy tools for users.

  1. Usability (implemented)
    1. Operational transparency, such as:
      1. listing zone status, including transfer details
      2. trace recursion
    2. Migration tools from BIND 9 and other DNS servers (configuration & zones)
    3. Support for traditional configuration files

Y4 release 2 (usability):

Here we implement configuration history, and start the coding of our command-line administration tool.

  1. Usability (implemented)
    1. Intuitive and powerful command-line administration tool (begin)
    2. Support for configuration history, with restore (apply old configuration)

Y4 release 3 (usability):

Here we get our command-line administration tool into shape.

  1. Usability (implemented)
    1. Intuitive and powerful command-line administration tool (done)

Y4 release 4 (resolver): Alpha Release for authoritative-only

In this release, we have had our shiny new command-line administration tool and a set of helpful utilities for administrators since the last release. With these in place, and the usability goal enters the polishing phase. After 6 weeks of this, we should be able to declare the software in alpha state, that we can suggest for wider real-world testing.

The focus shifts to getting the resolver into shape, and we should have some improvements here, such as Kaminsky-resistance.

  1. Improve BIND 10's recursive resolution, including:
    1. Port randomization and other anti-Kaminsky measures
    2. DNSSEC validation (NSEC and NSEC3) (begun)
    3. EDNS(0) support, including fallback logic
    4. Query tracing
    5. Comprehensive functional test suite (as a standalone tool, begun)

Y4 release 5 (resolver):

The resolver work continues, the server should become more sophisticated. RFC 5011 support arrives.

  1. Improve BIND 10's recursive resolution, including:
    1. DNSSEC validation (NSEC and NSEC3) (continues)
      1. RFC 5011 support
    2. Server capability tracking (lameness, EDNS(0) support, and so on)
    3. Comprehensive functional test suite (as a standalone tool, continues)

Y4 release 6 (resolver):

At this point we should have a working resolver.

  1. Improve BIND 10's recursive resolution, including:
    1. DNSSEC validation (NSEC and NSEC3) (done)
    2. Comprehensive functional test suite (as a standalone tool, done)

Y4 release 7 (DNSSEC): Beta Release for authoritative-only

The server has had another 3 releases to address usability issues and problems with operating in an authoritative-only mode, and should be ready to enter beta phase. We do NOT begin an alpha phase for the recursive side, both because the code will be quite fresh, and also because we don't want overlapping alpha/beta for the same product.

We begin work on the DNSSEC support.

  1. DNSSEC zone management, including:
    1. Signing
      1. Automated, including re-signing
    2. Command-line tools for working with DNSSEC

Y4 release 8 (DNSSEC):

Work on DNSSEC continues. At this point existing DNSSEC functionality should be duplicated.

  1. DNSSEC zone management, including:
    1. "in-line signing"
  2. Key management
    1. Automated key rollover

Y4 release 9 (DNSSEC):

The final release of Year 4. It all comes together.

  1. DNSSEC zone management, including:
    1. KSK rollover support
Last modified 6 years ago Last modified on Feb 2, 2012, 2:48:43 PM