Shane: bind10 was intended to be a 5 year plan

  • 1st year goal: authoritative name server (acheived)
  • first quarter of year 2: fixing problems from year 1
  • 2nd year goal: recursive resolver; this changed midstream to
    • recursive resolver and
    • production-ready authoritative
    • this was a mistake; we split our team and reduced productivity, but we learned from it: not to try too many things at once (though we've gotten away from that again lately)
  • end of year 2 we did have a recursive resolver, but no validation, incorrect root priming, etc.
  • year 2 we also switched to scrum, which reduced performance temporarily

focus in year 3 was intended to be "make the server production-ready", but reality was so many things were missing we ended up just backfilling

focus in year 4 was supposed to be usability, UI, plus improving recursive also, filling in features such as DNSSEC inline signing, key management, etc we didn't do any of that. wanted to move away from scrum toward more formal requirements; didn't do that either we don't have anyone dedicated to that role (no product owner, etc).

we did in year four get a version 1.0 release out. the team has mixed feelings about it; it has rough edges. but it is usable in production, we have real world users, quality is much higher than before. new functionality: zone loading doesn't block queries; better zone parser, smaller memory footprint...

year 5 plan:

  • take off the rough edges that affect our sponsors
  • shared memory model for in-memory data source
    • lock-free model using a "writer" process to handle all updates to the memory images
  • rewrite zone-transfer in/out code for performance
    • robustness
    • multiprocess, not multithreaded
    • replace sqlite3 for underlying data storage?
  • finish bind10 extensibility
    • we can now create a new module fairly straightforwardly
      • adding new commands is done in spec files, pretty easy
      • adding data sources fairly easy and will get easier
      • RESTful interface
    • big missing piece is the hook functionality (callouts at specific points)
    • this is important now because ISC is pursuing subscription services
      • we continue to provide open-source BIND forever, but extra functionality (for people who pay us) could be delivered as extra modules
      • most extra functionality would eventually become open source as well
      • should not affect basic functionality or the richness of BIND 10; other companies must be able to make products based on BIND as well.
  • re-implement recursive resolver
    • make it fast!
    • improve QA for both functionality and performance
    • given time available, we're only just going to be able to start on this in year 5
    • we've promised comcast that we'll deliver architecture and design documents soon
    • comcast has specific QPS needs and would like to switch away from nominum in favor of BIND (9 or 10)

discussion of packaging, distribution, installation, configuration:

background: we decided when we started to use existing external libraries whenever possible (e.g., sqlite, boost, botan, log4cplus, readline, procfile...)

this has been good for us mostly, but the downside is it's difficult to manage all the dependencies. people are used to downloading bind9 and having it Just Work; bind10 is much more cumbersome

in the past year we've worked to make this easier, adding an "Installation Quick Start" page to the website and working with distribution maintainers to ensure that all the pre-requisites are available as packages so that a single command can prepare the system to be able to build BIND 10. BIND 10 packages are being developed for experimental repositories. fedora plans to have BIND 10 available as a package in fedora 19. jeremy is working on bsd ports. macosx is still murky -- they don't have a package manager per se. we could perhaps provide a binary through the apple store, or a DMG file.

maintaining our own repositories for DEB/RPM/YUM packages would be handy for most people and essential for enterprise. might be a forum/subscription service only.

discussion of bind10 windows port/install:

  • two parts: porting and installing
  • installing could be outsourced
  • porting is something we should hire for

installation and configuration has gotten better lately

  • we no longer have a default user account
  • documentation isn't bad

msgq/message bus status

  • mechanism for processes in bind10 to communicate with each other
  • primarily used for configuration and signaling, not intended for large amounts of traffic
  • only perimeter security; bind10 processes don't authenticate to each other
  • gateway (cmdctl) handles access control at the edge. this is the RESTful interface
  • msgq is ported from a perl-based message bus originally written for openreg
  • we've always wanted to replace it, and have considered several alternatives
    • dbus (rejected because didn't support multi-system, and because of library issues)
    • none of the others we've found meet requirements or has an incompatible license
    • looks like we probably won't replace it (at least not any time soon)
  • we have a backlog of bugs against it that we've ignored, because we thought we'd be replacing it, but now we need to address them
  • we also have some missing functionality; for instance, until recently there was no way to know that the intended recipient of a message was not running
Last modified 5 years ago Last modified on Apr 16, 2013, 8:29:41 PM