"Fossies" - the Fresh Open Source Software Archive
As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard
) with prefixed line numbers.
Alternatively you can here view
the uninterpreted source code file.
See also the latest Fossies "Diffs"
side-by-side code changes report for "CONTRIBUTING": 9.16.6_vs_9.16.7
3 BIND 9 Source Access and Contributor Guidelines
5 May 28, 2020
9 1. Access to source code
10 2. Reporting bugs
11 3. Contributing code
15 Thank you for using BIND 9!
17 BIND is open source software that implements the Domain Name System (DNS)
18 protocols for the Internet. It is a reference implementation of those
19 protocols, but it is also production-grade software, suitable for use in
20 high-volume and high-reliability applications. It is very widely used DNS
21 software, providing a robust and stable platform on top of which
22 organizations can build distributed computing systems with the knowledge
23 that those systems are fully compliant with published DNS standards.
25 BIND is and will always remain free and openly available. It can be used
26 and modified in any way by anyone.
28 BIND is maintained by Internet Systems Consortium, a public-benefit 501(c)
29 (3) nonprofit, using a "managed open source" approach: anyone can see the
30 source, but only ISC employees have commit access. In the past, the source
31 could only be seen once ISC had published a release; read access to the
32 source repository was restricted just as commit access was. That has
33 changed, as ISC now provides a public git mirror to the BIND source tree
34 (see below).
36 At ISC, we're committed to building communities that are welcoming and
37 inclusive: environments where people are encouraged to share ideas, treat
38 each other with respect, and collaborate towards the best solutions. To
39 reinforce our commitment, ISC has adopted a slightly modified version of
40 the Django Code of Conduct for the BIND 9 project, as well as for the
41 conduct of our developers throughout the industry.
43 Access to source code
45 Public BIND releases are always available from the ISC FTP site.
47 A public-access GIT repository is also available at https://gitlab.isc.org
48 . This repository is a mirror, updated several times per day, of the
49 source repository maintained by ISC. It contains all the public release
50 branches; upcoming releases can be viewed in their current state at any
51 time. It does not contain development branches or unreviewed work in
52 progress. Commits which address security vulnerablilities are withheld
53 until after public disclosure.
55 You can browse the source online via https://gitlab.isc.org/isc-projects/
58 To clone the repository, use:
60 $ git clone https://gitlab.isc.org/isc-projects/bind9.git
62 Release branch names are of the form v9_X, where X represents the second
63 number in the BIND 9 version number. So, to check out the BIND 9.12
64 branch, use:
66 $ git checkout v9_12
68 Whenever a branch is ready for publication, a tag is placed of the form
69 v9_X_Y. The 9.12.0 release, for instance, is tagged as v9_12_0.
71 The branch in which the next major release is being developed is called
74 Reporting bugs
76 Reports of flaws in the BIND package, including software bugs, errors in
77 the documentation, missing files in the tarball, suggested changes or
78 requests for new features, etc., can be filed using https://gitlab.isc.org
81 Due to a large ticket backlog, we are sometimes slow to respond,
82 especially if a bug is cosmetic or if a feature request is vague or low in
83 priority, but we try at least to acknowledge legitimate bug reports within
84 a week.
86 ISC's GitLab system is publicly readable; however, you must have an
87 account to create a new issue. You can either register locally or use
88 credentials from an existing account at GitHub, GitLab, Google, Twitter,
89 or Facebook.
91 Reporting possible security issues
93 If you think you may be seeing a potential security vulnerability in BIND
94 (for example, a crash with REQUIRE, INSIST, or ASSERT failure), please
95 report it immediately by emailing to email@example.com. Plain-text
96 e-mail is not a secure choice for communications concerning undisclosed
97 security issues so please encrypt your communications to us if possible,
98 using the ISC Security Officer public key.
100 Do not discuss undisclosed security vulnerabilities on any public mailing
101 list. ISC has a long history of handling reported vulnerabilities promptly
102 and effectively and we respect and acknowledge responsible reporters.
104 ISC's Security Vulnerability Disclosure Policy is documented at https://
107 If you have a crash, you may want to consult "What to do if your BIND or
108 DHCP server has crashed."
110 Contributing code
112 BIND is licensed under the Mozilla Public License 2.0. Earlier versions
113 (BIND 9.10 and earlier) were licensed under the ISC License
115 ISC does not require an explicit copyright assignment for patch
116 contributions. However, by submitting a patch to ISC, you implicitly
117 certify that you are the author of the code, that you intend to relinquish
118 exclusive copyright, and that you grant permission to publish your work
119 under the open source license used for the BIND version(s) to which your
120 patch will be applied.
122 BIND code
124 Patches for BIND may be submitted directly via merge requests in ISC's
125 GitLab source repository for BIND.
127 Patches can also be submitted as diffs against a specific version of BIND
128 -- preferably the current top of the master branch. Diffs may be generated
129 using either git format-patch or git diff.
131 Those wanting to write code for BIND may be interested in the developer
132 information page, which includes information about BIND design and coding
133 practices, including discussion of internal APIs and overall system
136 Every patch submitted is reviewed by ISC engineers following our code
137 review process before it is merged.
139 It may take considerable time to review patch submissions, especially if
140 they don't meet ISC style and quality guidelines. If a patch is a good
141 idea, we can and will do additional work to bring it up to par, but if
142 we're busy with other work, it may take us a long time to get to it.
144 To ensure your patch is acted on as promptly as possible, please:
146 * Try to adhere to the BIND 9 coding style.
147 * Run make check to ensure your change hasn't caused any functional
149 * Document your work, both in the patch itself and in the accompanying
151 * In patches that make non-trivial functional changes, include system
152 tests if possible; when introducing or substantially altering a
153 library API, include unit tests. See Testing for more information.
155 Changes to configure
157 If you need to make changes to configure, you should not edit it directly;
158 instead, edit configure.in, then run autoconf. Similarly, instead of
159 editing config.h.in directly, edit configure.in and run autoheader.
161 When submitting a patch as a diff, it's fine to omit the configure diffs
162 to save space. Just send the configure.in diffs and we'll generate the new
163 configure during the review process.
167 All functional changes should be documented. There are three types of
168 documentation in the BIND source tree:
170 * Man pages are kept alongside the source code for the commands they
171 document, in files ending in .rst: for example, the named man page is
173 * The BIND 9 Administrator Reference Manual is in the .rst files in doc/
174 arm/; the PDF and HTML versions are automatically generated from the
175 .rst files.
176 * API documentation is in the header file describing the API, in
177 Doxygen-formatted comments.
179 Patches to improve existing documentation are also very welcome!
183 BIND is a large and complex project. We rely heavily on continuous
184 automated testing and cannot merge new code without adequate test
185 coverage. Please see the "Testing" section of doc/dev/dev.md for more
190 Thank you for your interest in contributing to the ongoing development of
191 BIND 9.