Known Problems in the Y1 release and upcoming plans

The Y1 prototype release of BIND 10 contains various known problems and features that need to be implemented. This page summarizes several of these so users can understand BIND 10's upcoming direction over the next few months. This doesn't list all future additions (like the recursive, validating DNS resolver) for BIND 10 during the FiveYearPlan.

As of April 27, 2010 at the f2f meeting these are being moved into the feature backlog at:

b10-auth and data source backend

  • Use multiple different data sources, such as MySQL, Berkeley DB, or in memory DB.
  • Store rdata in the database as binary blobs instead of text.
  • Probably change the name of libauth to libdatasrc or similar.
  • Drop privileges.
  • Default port used.
  • ACLs. (And ACLs need TSIG.)
  • Writable data sources for updates. (This requires major additions to the current data source API in libauth.)
  • In-memory data source
  • Read cache for upper-level data source
  • SQL data source optimization.

b10-cfgmgr and libcfgmgr

  • Configuration for configuration manager itself.
  • Maybe change the messaging protocol, but an admin should not notice.
  • Add "expect failure" tests to the unit tests.
  • Maybe c++ version use recvmsg() with a sequence number.


  • Add value type check according module specification.
  • Add return code for RESTful API.
  • Add more unit tests.
  • Add id to each command, so the receiver knows if the response is what it wants.
  • Configurable through bindctl.
  • Improve error messages.
  • Maybe choose different default port number?


  • Known problem is that it can load broken/bad zone data.
  • Use updated data source API for writing to data source (which will support beyond SQLite3).
  • Support optional origin in $INCLUDE.
  • Support optional comment in $INCLUDE.
  • Support optional comment in $TTL.
  • Use python library binding for libdns to parse data for sanity.
  • Maybe check for . top level.
  • Verbose and check option.


  • Support IXFR.
  • Add "refresh" command.
  • Process zone NOTIFY message from auth server.
  • Schedule zone maintenance for all zones (determined by Refresh/Expire? time in SOA record).
  • Use new configuration when config data is changed.


  • Read configurations from configuration manager. Use .spec file to define comands.
  • Provide more administrator options: Get process list, Get information on a process (returns list of times started & stopped, plus current information such as PID), Add a component, Stop a component, Force-stop a component.
  • Mechanism to wait for child to start before continuing
  • Rename "c-channel" stuff to msgq for clarity
  • Maybe reply to shutdown message?
  • Privileges for modules.


  • Run a command from the Unix command line arguments (instead of just at interactive prompt).
  • New design or interface usage for the control and configuration (maybe a different tool). Possibly create a new control language.

msgq and libcc

  • Refactor code to have a Client class to hold per-client data.
  • Maybe Unix domain sockets?.
  • Maybe adapt lib/cc/session to boost::asio.
  • Maybe choose different default port number.


  • Some RDATA implementations, especially those for DNSSEC related RR types like RRSIG, NSEC and NSEC3, are very immature, not fully tested for reviewed, but is provided for reference purpose. This implementation could trigger a serious bugs. In some worst cases those bugs may lead to a catastrophic result like arbitrary code execution. Care must be taken before using them (and it should also be noted that even a non DNSSEC applications may receive a message that contains such types of RRs, which can be parsed by this library).
  • Same for base32 decoder and encoder.
  • More documention for Message class implementation. More test cases.
  • Overall API design is still in flux. Any of them can change. In particular, RRset and Message design is quite immature. It's very likely to be revised, probably in a non compatible manner.
  • RDATA API design may also change, possibly due to performance concerns.
  • The RRsetList class may be removed. Or at least heavily redesigned, including class name change.
  • The current library includes classes not directly related to DNS, e.g., base64/base32/hex encoder/decoder, a generic "buffer" class to handle wire-format data, and SHA1 interface. These may be moved to other part of the package, or simply replaced with external library such as crypto++.
  • As for extension, we'll probably support the notion of "RR" for the convenience of application development (RRsets represent the protocol notion better, but often it's not convenient to deal with them directly).
  • TXT RDATA implementation is incomplete in that it can only handle a single "character string".
  • Many RR types are still not supported, and currently handled as "unknown type of RRs". Hopefully this will be improved soon.


  • Friendly web-based configuration and control interface.
  • Logging implementation / debugging framework.
  • Per-module statistics.
  • XFRout module.
  • Optimize performance.
Last modified 8 years ago Last modified on Apr 28, 2010, 10:35:16 AM