BIND Contributors Guide

Last modified: July 20, 2014

Technical Advice for Submitters

Those wanting to write code for BIND may be interested in the developer information page, which includes information about BIND design and coding practices, including discussion of internal APIs and overall system architecture. (This is a work in progress, and still quite preliminary.)

Every patch submitted will be reviewed by ISC engineers following our code review process before it is merged.

It may take considerable time to review patch submissions, especially if they don’t meet ISC style and quality guidelines. If the patch is a good idea, we can and will do additional work to bring them up to par, but if we’re busy with other work, it may take us a long time to get to it.

To ensure your patch is acted on as promptly as possible, please:

  • Try to adhere to the BIND 9 coding style.
  • Run make check to ensure your change hasn’t caused any functional regressions.
  • Document your work, both in the patch itself and in the accompanying email.
  • In patches that make non-trivial functional changes, include system tests if possible; when introducing or substantially altering a library API, include unit tests. See Testing for more information.

Changes to configure

If you need to make changes to configure, you should not edit it directly; instead, edit configure.in, then run autoconf. Similarly, instead of editing config.h.in directly, edit configure.in and run autoheader.

When submitting your patch, it is fine to omit the configure diffs. Just send the configure.in diffs and we’ll generate the new configure during the review process.

 

Documentation

All functional changes should be documented. There are three types of documentation in the BIND source tree:

  • Man pages are kept alongside the source code for the commands they document, in files ending in .docbook; for example, the named man page is bin/named/named.docbook.
  • The BIND 9 Administrator Reference Manual is mostly in doc/arm/Bv9ARM-book.xml, plus a few other XML files that are included in it.
  • API documentation is in the header file describing the API, in Doxygen-formatted comments.

It is not necessary to edit any documentation files other than these; the PDF, HTML, and nroff-format files will be generated automatically from the docbook and XML files by a script whenever a documentation change is merged to a release branch.

Contrib code

The software in the contrib directory of the BIND 9 tar archive is not formally supported by ISC, but is included for the convenience of users. These are things we consider useful or informative, but are not able to support at the same level as BIND.

contrib includes some useful DNS-related open source tools such as zktnslint, and the idnkit library for internationalized domain name support; useful scripts such as nanny.pl and mkdane.sh; performance testers including queryperf and perftcpdns; and drivers and modules for DLZ.

If you have code with a BSD-compatible license that you would like us to include in contrib, please send it to bind-suggest@isc.org or dhcp-suggest@isc.org with “[CONTRIB]” in the subject header.