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