...
 
Commits (525)
This diff is collapsed.
......@@ -63,10 +63,12 @@
- [ ] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [ ] ***(Marketing)*** Write blog article (if a major release).
- [ ] ***(QA)*** Ensure all new tags are annotated and signed.
- [ ] ***(SwEng)*** Push tags for the published releases to the public repository.
- [ ] ***(SwEng)*** Merge the automatically prepared `prep 9.X.Y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_X`).
- [ ] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check:sid:amd64` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [ ] ***(SwEng)*** Push tags for the published releases to the public repository.
- [ ] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [ ] ***(QA)*** Prepare empty release notes for the next set of releases.
- [ ] ***(QA)*** Sanitize all confidential issues assigned to the release milestone and make them public.
- [ ] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
......
5411. [cleanup] Refactoring of TCP accept code to use a single accept()
and pass the accepted socket to child threads for
processing. [GL !3320]
5473. [func] Netmgr server-side TLS layer and internal server-side
DoT support, currently unused. [GL #1840]
5410. [func] Add the ability to specify per-type record count
limits in an "update-policy" statement, which
are enforced when adding records via UPDATE.
[GL #1657]
5472. [func] The statistics channel has been updated to use the
new network manager. [GL #2022]
5409. [performance] When looking up NSEC3 data in a zone database, skip
the check for empty non-terminal nodes; the NSEC3
tree doesn't have any. [GL #1834]
5471. [bug] The introduction of KASP support broke whether the
second field of sig-validity-interval was treated as
days or hours. (Thanks to Tony Finch.) [GL !3735]
5470. [port] illumos: only call gsskrb5_register_acceptor_identity
if we have gssapi_krb5.h. [GL #1995]
5469. [port] illumos: SEC is defined in <sys/time.h> which
conflicted with our use of SEC. [GL #1993]
5468. [bug] Address potential double unlock in process_fd().
[GL #2005]
5467. [func] The control channel and the rndc utility have been
updated to use the new network manager. To support
this, the network manager was updated to enable
wthe initiation of client TCP connections. Its
internal reference counting has been refactored.
Note: As side effects of this change, rndc cannot
currently be used with UNIX-domain sockets, and its
default timeout has changed from 60 seconds to 30.
These will be addressed in a future release.
[GL #1759]
5466. [bug] Addressed an error in recursive clients stats reporting.
[GL #1719]
5465. [func] Fallback to built in trust-anchors, managed-keys, or
trusted-keys if the bindkeys-file (bind.keys) cannot
be parsed. [GL #1235]
5464. [bug] Specifying saving more than 128 files when rolling
dnstap / log files would cause buffer overflow.
[GL #1989]
5463. [placeholder]
5462. [bug] Move LMDB locking from LMDB itself to named. [GL #1976]
5461. [bug] The header STALE attribute was not being updated with
the write lock being held leading to incorrect
statistics. Convert the header attributes to use atomic
operations. [GL #1475]
5460. [cleanup] tsig-keygen was previously an alias for
ddns-confgen and was documented in the ddns-confgen
man page. This has been reversed; tsig-keygen is
now the primary name. [GL #1998]
5459. [bug] Bad isc_mem_put() size when an invalid type was
specified in a update-policy rule. [GL #1990]
--- 9.17.3 released ---
5458. [bug] Prevent a theoretically possible NULL dereference caused
by a data race between zone_maintenance() and
dns_zone_setview_helper(). [GL #1627]
5457. [placeholder]
5456. [func] Added "primaries" as a synonym for "masters" in
named.conf, and "primary-only" as a synonym for
"master-only" in the parameters to "notify", to bring
terminology up-to-date with RFC 8499. [GL #1948]
5455. [bug] named could crash when cleaning dead nodes in
lib/dns/rbtdb.c that were being reused. [GL #1968]
5454. [bug] Address a startup crash that occurred when the server
was under load and the root zone had not yet been
loaded. [GL #1862]
5453. [bug] named crashed on shutdown when a new rndc connection was
received during shutdown. [GL #1747]
5452. [bug] The "blackhole" ACL was accidentally disabled for client
queries. [GL #1936]
5451. [func] Add 'rndc dnssec -status' command. [GL #1612]
5450. [placeholder]
5449. [bug] Fix a socket shutdown race in netmgr udp. [GL #1938]
5448. [bug] Fix a race condition in isc__nm_tcpdns_send().
[GL #1937]
5447. [bug] IPv6 addresses ending in "::" could break YAML
parsing. A "0" is now appended to such addresses
in YAML output from dig, mdig, delv, and dnstap-read.
[GL #1952]
5446. [bug] The validator could fail to accept a properly signed
RRset if an unsupported algorithm appeared earlier in
the DNSKEY RRset than a supported algorithm. It could
also stop if it detected a malformed public key.
[GL #1689]
5445. [cleanup] Disable and disallow static linking. [GL #1933]
5444. [bug] 'rndc dnstap -roll <value>' did not limit the number of
saved files to <value>. [GL !3728]
5443. [bug] The "primary" and "secondary" keywords, when used
as parameters for "check-names", were not
processed correctly and were being ignored. [GL #1949]
5442. [func] Add support for outgoing TCP connections in netmgr.
[GL #1958]
5441. [placeholder]
5440. [placeholder]
5439. [bug] The DS RRset returned by dns_keynode_dsset() was used in
a non-thread-safe manner. [GL #1926]
--- 9.17.2 released ---
5438. [bug] Fix a race in TCP accepting code. [GL #1930]
5437. [bug] Fix a data race in lib/dns/resolver.c:log_formerr().
[GL #1808]
5436. [security] It was possible to trigger an INSIST when determining
whether a record would fit into a TCP message buffer.
(CVE-2020-8618) [GL #1850]
5435. [tests] Add RFC 4592 responses examples to the wildcard system
test. [GL #1718]
5434. [security] It was possible to trigger an INSIST in
lib/dns/rbtdb.c:new_reference() with a particular zone
content and query patterns. (CVE-2020-8619) [GL #1111]
[GL #1718]
5433. [placeholder]
5432. [bug] Check the question section when processing AXFR, IXFR,
and SOA replies when transferring a zone in. [GL #1683]
5431. [func] Reject DS records at the zone apex when loading
master files. Log but otherwise ignore attempts to
add DS records at the zone apex via UPDATE. [GL #1798]
5430. [doc] Update docs - with netmgr, a separate listening socket
is created for each IPv6 interface (just as with IPv4).
[GL #1782]
5429. [cleanup] Move BIND binaries which are neither daemons nor
administrative programs to $bindir. [GL #1724]
5428. [bug] Clean up GSSAPI resources in nsupdate only after taskmgr
has been destroyed. Thanks to Petr Menšík. [GL !3316]
5427. [placeholder]
5426. [bug] Don't abort() when setting SO_INCOMING_CPU on the socket
fails. [GL #1911]
5425. [func] The default value of "max-stale-ttl" has been changed
from 1 week to 12 hours. [GL #1877]
5424. [bug] With KASP, when creating a successor key, the "goal"
state of the current active key (predecessor) was not
changed and thus never removed from the zone. [GL #1846]
5423. [bug] Fix a bug in keymgr_key_has_successor(): it incorrectly
returned true if any other key in the keyring had a
successor. [GL #1845]
5422. [bug] When using dnssec-policy, print correct key timing
metadata. [GL #1843]
5421. [bug] Fix a race that could cause named to crash when looking
up the nodename of an RBT node if the tree was modified.
[GL #1857]
5420. [bug] Add missing isc_{mutex,conditional}_destroy() calls
that caused a memory leak on FreeBSD. [GL #1893]
5419. [func] Add new dig command line option, "+qid=<num>", which
allows the query ID to be set to an arbitrary value.
Add a new ./configure option, --enable-singletrace,
which allows trace logging of a single query when QID is
set to 0. [GL #1851]
5418. [bug] delv failed to parse deprecated trusted-keys-style
trust anchors. [GL #1860]
5417. [cleanup] The code determining the advertised UDP buffer size in
outgoing EDNS queries has been refactored to improve its
clarity. [GL #1868]
5416. [bug] Fix a lock order inversion in lib/isc/unix/socket.c.
[GL #1859]
5415. [test] Address race in dnssec system test that led to
test failures. [GL #1852]
5414. [test] Adjust time allowed for journal truncation to occur
in nsupdate system test to avoid test failure.
[GL #1855]
5413. [test] Address race in autosign system test that led to
test failures. [GL #1852]
5412. [bug] 'provide-ixfr no;' failed to return up-to-date responses
when the serial was greater than or equal to the
current serial. [GL #1714]
5411. [cleanup] TCP accept code has been refactored to use a single
accept() and pass the accepted socket to child threads
for processing. [GL !3320]
5410. [func] Add the ability to specify per-type record count limits,
which are enforced when adding records via UPDATE, in an
"update-policy" statement. [GL #1657]
5409. [performance] When looking up NSEC3 data in a zone database, skip the
check for empty non-terminal nodes; the NSEC3 tree does
not have any. [GL #1834]
5408. [protocol] Print Extended DNS Errors if present in OPT record.
[GL #1835]
......@@ -17,13 +234,13 @@
5407. [func] Zone timers are now exported via statistics channel.
Thanks to Paul Frieden, Verizon Media. [GL #1232]
5406. [func] Added a new logging category, "rpz-passthru". It allows
RPZ passthru actions to be logged into a separate
channel. [GL #54]
5406. [func] Add a new logging category, "rpz-passthru", which allows
RPZ passthru actions to be logged in a separate channel.
[GL #54]
5405. [bug] 'named-checkconf -p' could include spurious text
in server-addresses statements due to an uninitialized
DSCP value. [GL #1812]
5405. [bug] 'named-checkconf -p' could include spurious text in
server-addresses statements due to an uninitialized DSCP
value. [GL #1812]
5404. [bug] 'named-checkconf -z' could incorrectly indicate
success if errors were found in one view but not in a
......@@ -57,7 +274,12 @@
UV_UDP_RECVMMSG flag to enable recvmmsg() support in
libuv. [GL #1797]
5395. [placeholder]
5395. [security] Further limit the number of queries that can be
triggered from a request. Root and TLD servers
are no longer exempt from max-recursion-queries.
Fetches for missing name server address records
are limited to 4 for any domain. (CVE-2020-8616)
[GL #1388]
5394. [cleanup] Named formerly attempted to change the effective UID and
GID in named_os_openfile(), which could trigger a
......@@ -77,7 +299,9 @@
from the Git repository, run "autoreconf -fi" first.
[GL #4]
5390. [placeholder]
5390. [security] Replaying a TSIG BADTIME response as a request could
trigger an assertion failure. (CVE-2020-8617)
[GL #1703]
5389. [bug] Finish PKCS#11 code cleanup, fix a couple of smaller
bugs and use PKCS#11 v3.0 EdDSA macros and constants.
......
......@@ -8,8 +8,8 @@
- See the COPYRIGHT file distributed with this work for additional
- information regarding copyright ownership.
-->
## BIND Source Access and Contributor Guidelines
*Feb 22, 2018*
## BIND 9 Source Access and Contributor Guidelines
*May 28, 2020*
### Contents
......@@ -19,12 +19,12 @@
### Introduction
Thank you for using BIND!
Thank you for using BIND 9!
BIND is open source software that implements the Domain Name System (DNS)
protocols for the Internet. It is a reference implementation of those
protocols, but it is also production-grade software, suitable for use in
high-volume and high-reliability applications. It is by far the most
high-volume and high-reliability applications. It is very
widely used DNS software, providing a robust and stable platform on top of
which organizations can build distributed computing systems with the
knowledge that those systems are fully compliant with published DNS
......@@ -33,20 +33,20 @@ standards.
BIND is and will always remain free and openly available. It can be
used and modified in any way by anyone.
BIND is maintained by the [Internet Systems Consortium](https://www.isc.org),
BIND is maintained by [Internet Systems Consortium](https://www.isc.org),
a public-benefit 501(c)(3) nonprofit, using a "managed open source" approach:
anyone can see the source, but only ISC employees have commit access.
Until recently, the source could only be seen once ISC had published
a release: read access to the source repository was restricted just
as commit access was. That's now changing, with the opening of a
In the past, the source could only be seen once ISC had published
a release; read access to the source repository was restricted just
as commit access was. That has changed, as ISC now provides a
public git mirror to the BIND source tree (see below).
At [Internet Systems Consortium](https://www.isc.org), we're committed to
building communities that are welcoming and inclusive; environments where people
At ISC, we're committed to
building communities that are welcoming and inclusive: environments where people
are encouraged to share ideas, treat each other with respect, and collaborate
towards the best solutions. To reinforce our commitment, the [Internet Systems
Consortium](https://www.isc.org) has adopted the Contributor Covenant version
1.4 as our Code of Conduct for BIND 9 project, as well as for the conduct of our
towards the best solutions. To reinforce our commitment, ISC
has adopted a slightly modified version of the Django
[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
developers throughout the industry.
### <a name="access"></a>Access to source code
......@@ -76,7 +76,7 @@ branch, use:
> $ git checkout v9_12
Whenever a branch is ready for publication, a tag will be placed of the
Whenever a branch is ready for publication, a tag is placed of the
form `v9_X_Y`. The 9.12.0 release, for instance, is tagged as `v9_12_0`.
The branch in which the next major release is being developed is called
......@@ -86,16 +86,16 @@ The branch in which the next major release is being developed is called
Reports of flaws in the BIND package, including software bugs, errors
in the documentation, missing files in the tarball, suggested changes
or requests for new features, etc, can be filed using
or requests for new features, etc., can be filed using
[https://gitlab.isc.org/isc-projects/bind9/issues](https://gitlab.isc.org/isc-projects/bind9/issues).
Due to a large ticket backlog, we are sometimes slow to respond,
especially if a bug is cosmetic or if a feature request is vague or
low in priority, but we will try at least to acknowledge legitimate
low in priority, but we try at least to acknowledge legitimate
bug reports within a week.
ISC's ticketing system is publicly readable; however, you must have
an account to file a new issue. You can either register locally or
ISC's GitLab system is publicly readable; however, you must have
an account to create a new issue. You can either register locally or
use credentials from an existing account at GitHub, GitLab, Google,
Twitter, or Facebook.
......@@ -105,26 +105,26 @@ If you think you may be seeing a potential security vulnerability in BIND
report it immediately by emailing to security-officer@isc.org. Plain-text
e-mail is not a secure choice for communications concerning undisclosed
security issues so please encrypt your communications to us if possible,
using the [ISC Security Officer public key](https://www.isc.org/downloads/software-support-policy/openpgp-key/).
using the [ISC Security Officer public key](https://www.isc.org/pgpkey/).
Do not discuss undisclosed security vulnerabilities on any public mailing list.
ISC has a long history of handling reported vulnerabilities promptly and
effectively and we respect and acknowledge responsible reporters.
ISC's Security Vulnerability Disclosure Policy is documented at [https://kb.isc.org/article/AA-00861/0](https://kb.isc.org/article/AA-00861/0).
ISC's Security Vulnerability Disclosure Policy is documented at [https://kb.isc.org/docs/aa-00861](https://kb.isc.org/docs/aa-00861).
If you have a crash, you may want to consult
[‘What to do if your BIND or DHCP server has crashed.’](https://kb.isc.org/article/AA-00340/89/What-to-do-if-your-BIND-or-DHCP-server-has-crashed.html)
["What to do if your BIND or DHCP server has crashed."](https://kb.isc.org/docs/aa-00340)
### <a name="contrib"></a>Contributing code
BIND is licensed under the
[Mozilla Public License 2.0](http://www.isc.org/downloads/software-support-policy/isc-license/).
Earier versions (BIND 9.10 and earlier) were licensed under the [ISC License](http://www.isc.org/downloads/software-support-policy/isc-license/)
[Mozilla Public License 2.0](https://www.mozilla.org/en-US/MPL/2.0/).
Earlier versions (BIND 9.10 and earlier) were licensed under the [ISC License](https://www.isc.org/licenses/)
ISC does not require an explicit copyright assignment for patch
contributions. However, by submitting a patch to ISC, you implicitly
certify that you are the author of the code, that you intend to reliquish
certify that you are the author of the code, that you intend to relinquish
exclusive copyright, and that you grant permission to publish your work
under the open source license used for the BIND version(s) to which your
patch will be applied.
......@@ -132,7 +132,7 @@ patch will be applied.
#### <a name="bind"></a>BIND code
Patches for BIND may be submitted directly via merge requests in
[ISC's Gitlab](https://gitlab.isc.org/isc-projects/bind9/) source
[ISC's GitLab](https://gitlab.isc.org/isc-projects/bind9/) source
repository for BIND.
Patches can also be submitted as diffs against a specific version of
......@@ -142,10 +142,9 @@ be generated using either `git format-patch` or `git diff`.
Those wanting to write code for BIND may be interested in the
[developer information](doc/dev/dev.md) 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.)
APIs and overall system architecture.
Every patch submitted will be reviewed by ISC engineers following our
Every patch submitted is reviewed by ISC engineers following our
[code review process](doc/dev/dev.md#reviews) before it is merged.
It may take considerable time to review patch submissions, especially if
......@@ -156,7 +155,7 @@ 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](doc/dev/style.md).
* Run `make` `check` to ensure your change hasn't caused any
* 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.
......@@ -182,28 +181,23 @@ 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.
they document, in files ending in `.rst`: for example, the
`named` man page is `bin/named/named.rst`.
* The *BIND 9 Administrator Reference Manual* is in the .rst files in
`doc/arm/`; the PDF and HTML versions are automatically generated from the `.rst` files.
* 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;
all PDF, HTML, and `nroff`-format man page files will be updated
automatically from the `docbook` and `XML` files after merging.
Patches to improve existing documentation are also very welcome!
##### Tests
BIND is a large and complex project. We rely heavily on continuous
automated testing and cannot merge new code without adequate test coverage.
Please see [the 'Testing' section of doc/dev/dev.md](doc/dev/dev.md#testing)
Please see [the "Testing" section of doc/dev/dev.md](doc/dev/dev.md#testing)
for more information.
#### Thanks
Thank you for your interest in contributing to the ongoing development
of BIND.
of BIND 9.
......@@ -6,8 +6,20 @@ BUILT_SOURCES = bind.keys.h
CLEANFILES = bind.keys.h
bind.keys.h: bind.keys Makefile
${PERL} ${top_srcdir}/util/bindkeys.pl < ${top_srcdir}/bind.keys > $@
${PERL} ${top_srcdir}/util/bindkeys.pl ${top_srcdir}/bind.keys > $@
dist_sysconf_DATA = bind.keys
.PHONY: doc
EXTRA_DIST = \
util/bindkeys.pl \
contrib \
CHANGES \
COPYRIGHT \
LICENSE \
*.md
dist-hook:
find $(distdir) -type f -name .gitignore -delete
git rev-parse --short HEAD | cut -b1-7 > $(distdir)/srcid
......@@ -3,7 +3,7 @@
AM_CPPFLAGS += \
$(CMOCKA_CFLAGS) \
-DTESTS=\"$(abs_srcdir)\" \
-DTESTS_DIR=\"$(abs_srcdir)\" \
-DNAMED_PLUGINDIR=\"$(libdir)/named\"
LDADD = \
......
......@@ -42,6 +42,16 @@ LIBDNS_CFLAGS = \
LIBDNS_LIBS = \
$(top_builddir)/lib/dns/libdns.la
if HAVE_DNSTAP
LIBDNS_CFLAGS += \
$(DNSTAP_CFLAGS)
endif HAVE_DNSTAP
if HAVE_LMDB
LIBDNS_CFLAGS += \
$(LMDB_CFLAGS)
endif HAVE_LMDB
LIBNS_CFLAGS = \
-I$(top_srcdir)/lib/ns/include
......
......@@ -42,16 +42,16 @@ offer support on a "best effort" basis for some.
### Regularly tested platforms
As of Mar 2020, BIND 9.17 is fully supported and regularly tested on the
As of Jul 2020, BIND 9.17 is fully supported and regularly tested on the
following systems:
* Debian 9, 10
* Ubuntu LTS 16.04, 18.04
* Fedora 31
* Ubuntu LTS 16.04, 20.04
* Fedora 32
* Red Hat Enterprise Linux / CentOS 7, 8
* FreeBSD 11.3, 12.1
* OpenBSD 6.6
* Alpine Linux
* FreeBSD 11.4, 12.1
* OpenBSD 6.7
* Alpine Linux 3.12
The amd64, i386, armhf and arm64 CPU architectures are all fully supported.
......
......@@ -28,9 +28,9 @@
### <a name="intro"/> Introduction
BIND (Berkeley Internet Name Domain) is a complete, highly portable
implementation of the DNS (Domain Name System) protocol.
implementation of the Domain Name System (DNS) protocol.
The BIND name server, `named`, is able to serve as an authoritative name
The BIND name server, `named`, can act as an authoritative name
server, recursive resolver, DNS forwarder, or all three simultaneously. It
implements views for split-horizon DNS, automatic DNSSEC zone signing and
key management, catalog zones to facilitate provisioning of zone data
......@@ -42,9 +42,9 @@ administrative tools, including the `dig` and `delv` DNS lookup tools,
`nsupdate` for dynamic DNS zone updates, `rndc` for remote name server
administration, and more.
BIND 9 began as a complete re-write of the BIND architecture that was
BIND 9 began as a complete rewrite of the BIND architecture that was
used in versions 4 and 8. Internet Systems Consortium
([https://www.isc.org](https://www.isc.org)), a 501(c)(3) public benefit
([https://www.isc.org](https://www.isc.org)), a 501(c)(3) US public benefit
corporation dedicated to providing software and services in support of the
Internet infrastructure, developed BIND 9 and is responsible for its
ongoing maintenance and improvement. BIND is open source software
......@@ -65,19 +65,19 @@ For information about supported platforms, see [PLATFORMS](PLATFORMS.md).
### <a name="help"/> Reporting bugs and getting help
To report non-security-sensitive bugs or request new features, you may
open an Issue in the BIND 9 project on the
open an issue in the BIND 9 project on the
[ISC GitLab server](https://gitlab.isc.org) at
[https://gitlab.isc.org/isc-projects/bind9](https://gitlab.isc.org/isc-projects/bind9).
Please note that, unless you explicitly mark the newly created Issue as
"confidential", it will be publicly readable. Please do not include any
Please note that, unless you explicitly mark the newly created issue as
"confidential," it will be publicly readable. Please do not include any
information in bug reports that you consider to be confidential unless
the issue has been marked as such. In particular, if submitting the
contents of your configuration file in a non-confidential Issue, it is
advisable to obscure key secrets: this can be done automatically by
contents of your configuration file in a non-confidential issue, it is
advisable to obscure key secrets; this can be done automatically by
using `named-checkconf -px`.
If the bug you are reporting is a potential security issue, such as an
If you are reporting a bug that is a potential security issue, such as an
assertion failure or other crash in `named`, please do *NOT* use GitLab to
report it. Instead, send mail to
[security-officer@isc.org](mailto:security-officer@isc.org) using our
......@@ -86,11 +86,12 @@ to our key can be found at
[https://www.isc.org/pgpkey](https://www.isc.org/pgpkey).) Please do not
discuss the bug on any public mailing list.
For a general overview of ISC security policies, read the Knowledge Base
For a general overview of ISC security policies, read the Knowledgebase
article at [https://kb.isc.org/docs/aa-00861](https://kb.isc.org/docs/aa-00861).
Professional support and training for BIND are available from
ISC at [https://www.isc.org/support](https://www.isc.org/support).
ISC. Contact us at [https://www.isc.org/contact](https://www.isc.org/contact)
for more information.
To join the __BIND Users__ mailing list, or view the archives, visit
[https://lists.isc.org/mailman/listinfo/bind-users](https://lists.isc.org/mailman/listinfo/bind-users).
......@@ -102,7 +103,7 @@ may also want to join the __BIND Workers__ mailing list, at
### <a name="contrib"/> Contributing to BIND
ISC maintains a public git repository for BIND; details can be found
at [http://www.isc.org/git/](http://www.isc.org/git/).
at [https://www.isc.org/sourceaccess/](https://www.isc.org/sourceaccess/).
Information for BIND contributors can be found in the following files:
- General information: [CONTRIBUTING.md](CONTRIBUTING.md)
......@@ -112,16 +113,15 @@ Information for BIND contributors can be found in the following files:
Patches for BIND may be submitted as
[merge requests](https://gitlab.isc.org/isc-projects/bind9/merge_requests)
in the [ISC GitLab server](https://gitlab.isc.org) at
at [https://gitlab.isc.org/isc-projects/bind9/merge_requests](https://gitlab.isc.org/isc-projects/bind9/merge_requests).
on the [ISC GitLab server](https://gitlab.isc.org).
By default, external contributors don't have ability to fork BIND in the
GitLab server, but if you wish to contribute code to BIND, you may request
By default, external contributors do not have the ability to fork BIND on the
GitLab server; if you wish to contribute code to BIND, you may request
permission to do so. Thereafter, you can create git branches and directly
submit requests that they be reviewed and merged.
If you prefer, you may also submit code by opening a
[GitLab Issue](https://gitlab.isc.org/isc-projects/bind9/issues) and
[GitLab issue](https://gitlab.isc.org/isc-projects/bind9/issues) and
including your patch as an attachment, preferably generated by
`git format-patch`.
......@@ -130,14 +130,14 @@ including your patch as an attachment, preferably generated by
BIND 9.17 is the newest development branch of BIND 9. It includes a
number of changes from BIND 9.16 and earlier releases. New features include:
* New option "max-ixfr-ratio" to limit the size of outgoing IXFR responses
* The new option `max-ixfr-ratio` to limit the size of outgoing IXFR responses
before falling back to full zone transfers.
* "rndc nta -d" and "rndc secroots" now include "validate-except" entries
* `rndc nta -d` and `rndc secroots` now include `validate-except` entries
when listing negative trust anchors.
### <a name="build"/> Building BIND
### <a name="build"/> Building BIND 9
Minimally, BIND requires a UNIX or Linux system with an ANSI C compiler,
At a minimum, BIND requires a Unix or Linux system with an ANSI C compiler,
basic POSIX support, and a 64-bit integer type. BIND also requires the
`libuv` asynchronous I/O library, and a cryptography provider library
such as OpenSSL or a hardware service module supporting PKCS#11. On
......@@ -148,15 +148,15 @@ for details on other libraries that may be required to support
optional features.
Successful builds have been observed on many versions of Linux and
UNIX, including RHEL/CentOS, Fedora, Debian, Ubuntu, SLES, openSUSE,
Unix, including RHEL/CentOS, Fedora, Debian, Ubuntu, SLES, openSUSE,
Slackware, Alpine, FreeBSD, NetBSD, OpenBSD, macOS, Solaris,
OpenIndiana, OmniOS CE, HP-UX, and OpenWRT.
BIND is also available for Windows Server 2012 R2 and higher. See
BIND 9 is also available for Windows Server 2012 R2 and higher. See
`win32utils/build.txt` for details on building for Windows
systems.
To build on a UNIX or Linux system, use:
To build on a Unix or Linux system, use:
$ autoreconf -fi (if you are building in the git repository)
$ ./configure
......@@ -165,7 +165,7 @@ To build on a UNIX or Linux system, use:
If you're planning on making changes to the BIND 9 source, you should run
`make depend`. If you're using Emacs, you might find `make tags` helpful.
Several environment variables that can be set before running `configure` will
Several environment variables, which can be set before running `configure`,
affect compilation. Significant ones are:
|Variable|Description |
......@@ -182,21 +182,21 @@ command: