BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-03-16T11:03:08Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1672Stop leaking external headers and symbols to the public API2023-03-16T11:03:08ZOndřej SurýStop leaking external headers and symbols to the public APIThere are several places where we leak the external headers and libraries to the public library API. We should stop doing that as it forces any user of the library to add correct `CFLAGS` and `LDFLAGS` to the compiler and linker.
This ...There are several places where we leak the external headers and libraries to the public library API. We should stop doing that as it forces any user of the library to add correct `CFLAGS` and `LDFLAGS` to the compiler and linker.
This is placeholder bug and I will add individual merge requests for every occurrence:
- <isc/safe.h> leaks OpenSSL header and symbols (!3215)
- <isc/md.h> leaks OpenSSL header and types (!3218)
- <isc/hmac.h> leaks OpenSSL header and types (!3216)
- ...April 2020 (9.11.18, 9.16.2, 9.17.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1682dighost.c: idn_output_filter has off by one error2022-04-26T13:05:53ZMark Andrewsdighost.c: idn_output_filter has off by one error```
4413#ifdef HAVE_LIBIDN2
4414static isc_result_t
4415idn_output_filter(isc_buffer_t *buffer, unsigned int used_org) {
4416 char src[MXNAME], *dst;
4417 size_t srclen, dstlen;
4418
4419 /*
4420 * Copy name ...```
4413#ifdef HAVE_LIBIDN2
4414static isc_result_t
4415idn_output_filter(isc_buffer_t *buffer, unsigned int used_org) {
4416 char src[MXNAME], *dst;
4417 size_t srclen, dstlen;
4418
4419 /*
4420 * Copy name from 'buffer' to 'src' and terminate it with NULL.
4421 */
4422 srclen = isc_buffer_usedlength(buffer) - used_org;
1. Condition srclen > 1024UL /* sizeof (src) */, taking false branch.
2. cond_at_most: Checking srclen > 1024UL implies that srclen may be up to 1024 on the false branch.
4423 if (srclen > sizeof(src)) {
4424 warn("Input name too long to perform IDN conversion");
4425 return (ISC_R_SUCCESS);
4426 }
4427 memmove(src, (char *)isc_buffer_base(buffer) + used_org, srclen);
CID 281493 (#1 of 1): Out-of-bounds write (OVERRUN)
3. overrun-local: Overrunning array src of 1024 bytes at byte offset 1024 using index srclen (which evaluates to 1024).
4428 src[srclen] = '\0';
```
Note: MXNAME is 1024 which is larger than the presentation format of any domain name.April 2020 (9.11.18, 9.16.2, 9.17.1)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1138From Bugs (#43718) : extend nsip-wait-recurse or add nsdname-wait-recurse2022-01-17T13:24:02ZCathy AlmondFrom Bugs (#43718) : extend nsip-wait-recurse or add nsdname-wait-recurseFrom [BUGS feature request #43718](https://bugs.isc.org/Ticket/Display.html?id=43718)
tl;dr - we should expect there to be similar need with NSDNAME triggers
as there was with NSIP triggers, even if no one has asked for it yet.
On 2016...From [BUGS feature request #43718](https://bugs.isc.org/Ticket/Display.html?id=43718)
tl;dr - we should expect there to be similar need with NSDNAME triggers
as there was with NSIP triggers, even if no one has asked for it yet.
On 2016-11-23 08:41, vjs wrote:
>>>> On the other hand, NSDNAME wasn't requested and I don't think I've ever
>>>> seen an NSDNAME rule outside of an example..
>>>
>>> What about many of the wildcards in rpz.spamhaus.org?
>>
>> The only rpz.spamhaus.org zone I've seen in detail is dbl, and it didn't
>> have any at the time.
>
> The Spamhaus RPZ zone published as the rpz.spamhaus.org contains about
> 3.8 million pairs of domains and wildcards. While none of those records
> are NSDNAME RPZ triggers, they all seem to me prime candidates for
> being additionally written as NSDNAME triggers.
>
> It would be unconfortable to double the current 192 MByte text size
> of that zone by adding all of those NSDNAME RPZ rules. However, Fastrpz
> supports two directives that help. "ip-as-ns yes_or_no" and especially
> "qname-as-ns yes_or_no" do what I hope their names suggest.
> As might be guessed, I think those two directives should be added
> to BIND RPZ.
>
> I should also mention that I did not invent NSDNAME, but added it
> at the explicit request of RPZ users. Maybe over the years those who
> asked have stopped using NSDNAME, but I doubt it.
DO we need this?
( Interest expressed in Support ticket [#14957](https://support.isc.org/Ticket/Display.html?id=14957) )April 2020 (9.11.18, 9.16.2, 9.17.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/1706Changing from auto-dnssec maintain to dnssec-policy x immediately deletes exi...2021-06-16T10:03:34ZHåkan LindqvistChanging from auto-dnssec maintain to dnssec-policy x immediately deletes existing keys<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
Trying to migrate an already signed zone from `auto-dnssec maintain` to `dnssec-policy x` leads to immediate replacement of all keys (not even doing a normal rollover).
Also discussed on bind-users: https://lists.isc.org/pipermail/bind-users/2020-March/102817.html
### BIND version used
```
$ named -V
BIND 9.16.1 (Stable Release) <id:d497c32>
running on Linux x86_64 5.3.0-42-generic #34-Ubuntu SMP Fri Feb 28 05:49:40 UTC 2020
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--libexecdir=/usr/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-libjson-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-4Ash1G/bind9-9.16.1=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.2.1 20191008
compiled with OpenSSL version: OpenSSL 1.1.1c 28 May 2019
linked to OpenSSL version: OpenSSL 1.1.1c 28 May 2019
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.3.2
compiled with protobuf-c version: 1.3.1
linked to protobuf-c version: 1.3.1
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
$
```
### Steps to reproduce
* Change `auto-dnssec maintain;` to `dnssec-policy x;`.
* Restart/reload.
### What is the current *bug* behavior?
All existing keys (including KSK) are immediately deleted and replaced with new keys.
### What is the expected *correct* behavior?
Existing keys continue to be used if compatible. If not compatible, I would think that some rollover procedure should be initiated?
### Relevant configuration files
Policy for test purposes (named to keep track of what is what while testing):
```
dnssec-policy alg13-ksk-unlimited-zsk-60day {
keys {
ksk key-directory lifetime unlimited algorithm ECDSAP256SHA256;
zsk key-directory lifetime P60D algorithm ECDSAP256SHA256;
};
};
```
(Existing keys are separate KSK+ZSK, ECDSAP256SHA256)
Zone configuration (pretty typical):
```
zone "zone.example" {
notify yes;
type master;
allow-transfer { x; };
also-notify { x; };
file "/var/lib/bind/dynamic/zone.example/db.zone.example";
update-policy { grant local-ddns zonesub any; grant edit-x. zonesub any; };
key-directory "/var/lib/bind/dynamic/zone.example";
# auto-dnssec maintain;
dnssec-policy alg13-ksk-unlimited-zsk-60day;
};
```
Existing keys only have the normal timings:
```
; Created:
; Publish:
; Activate:
```
### Relevant logs and/or screenshots
Debug level DNSSEC log from starting BIND with this configuration change:
```
zone zone.example/IN (signed): reconfiguring zone keys
keymgr: keyring: dnskey zone.example/ECDSAP256SHA256/20481 (policy alg13-ksk-unlimited-zsk-60day)
keymgr: keyring: dnskey zone.example/ECDSAP256SHA256/12506 (policy alg13-ksk-unlimited-zsk-60day)
keymgr: DNSKEY zone.example/ECDSAP256SHA256/20481 (ZSK) matches policy alg13-ksk-unlimited-zsk-60day
keymgr: DNSKEY zone.example/ECDSAP256SHA256/12506 (KSK) matches policy alg13-ksk-unlimited-zsk-60day
keymgr: no active key found for zone.example (policy alg13-ksk-unlimited-zsk-60day)
keymgr: DNSKEY zone.example/ECDSAP256SHA256/56446 (KSK) created for policy alg13-ksk-unlimited-zsk-60day
keymgr: no active key found for zone.example (policy alg13-ksk-unlimited-zsk-60day)
keymgr: DNSKEY zone.example/ECDSAP256SHA256/64179 (ZSK) created for policy alg13-ksk-unlimited-zsk-60day
keymgr: examine ZSK zone.example/ECDSAP256SHA256/20481 type DNSKEY in state HIDDEN
keymgr: ZSK zone.example/ECDSAP256SHA256/20481 type DNSKEY in stable state HIDDEN
keymgr: examine ZSK zone.example/ECDSAP256SHA256/20481 type ZRRSIG in state HIDDEN
keymgr: ZSK zone.example/ECDSAP256SHA256/20481 type ZRRSIG in stable state HIDDEN
keymgr: examine KSK zone.example/ECDSAP256SHA256/12506 type DNSKEY in state HIDDEN
keymgr: KSK zone.example/ECDSAP256SHA256/12506 type DNSKEY in stable state HIDDEN
keymgr: examine KSK zone.example/ECDSAP256SHA256/12506 type KRRSIG in state HIDDEN
keymgr: KSK zone.example/ECDSAP256SHA256/12506 type KRRSIG in stable state HIDDEN
keymgr: examine KSK zone.example/ECDSAP256SHA256/12506 type DS in state HIDDEN
keymgr: KSK zone.example/ECDSAP256SHA256/12506 type DS in stable state HIDDEN
keymgr: examine KSK zone.example/ECDSAP256SHA256/56446 type DNSKEY in state HIDDEN
keymgr: can we transition KSK zone.example/ECDSAP256SHA256/56446 type DNSKEY state HIDDEN to state RUMOURED?
keymgr: dnssec evaluation of KSK zone.example/ECDSAP256SHA256/56446 record DNSKEY: rule1=(~false or false) rule2=(~true or true) rule3=(~true or true)
keymgr: transition KSK zone.example/ECDSAP256SHA256/56446 type DNSKEY state HIDDEN to state RUMOURED!
keymgr: examine KSK zone.example/ECDSAP256SHA256/56446 type KRRSIG in state HIDDEN
keymgr: can we transition KSK zone.example/ECDSAP256SHA256/56446 type KRRSIG state HIDDEN to state RUMOURED?
keymgr: dnssec evaluation of KSK zone.example/ECDSAP256SHA256/56446 record KRRSIG: rule1=(~false or false) rule2=(~true or true) rule3=(~true or true)
keymgr: transition KSK zone.example/ECDSAP256SHA256/56446 type KRRSIG state HIDDEN to state RUMOURED!
keymgr: examine KSK zone.example/ECDSAP256SHA256/56446 type DS in state HIDDEN
keymgr: can we transition KSK zone.example/ECDSAP256SHA256/56446 type DS state HIDDEN to state RUMOURED?
keymgr: policy says no to KSK zone.example/ECDSAP256SHA256/56446 type DS state HIDDEN to state RUMOURED
keymgr: examine ZSK zone.example/ECDSAP256SHA256/64179 type DNSKEY in state HIDDEN
keymgr: can we transition ZSK zone.example/ECDSAP256SHA256/64179 type DNSKEY state HIDDEN to state RUMOURED?
keymgr: dnssec evaluation of ZSK zone.example/ECDSAP256SHA256/64179 record DNSKEY: rule1=(~false or false) rule2=(~true or true) rule3=(~true or true)
keymgr: transition ZSK zone.example/ECDSAP256SHA256/64179 type DNSKEY state HIDDEN to state RUMOURED!
keymgr: examine ZSK zone.example/ECDSAP256SHA256/64179 type ZRRSIG in state HIDDEN
keymgr: can we transition ZSK zone.example/ECDSAP256SHA256/64179 type ZRRSIG state HIDDEN to state RUMOURED?
keymgr: dnssec evaluation of ZSK zone.example/ECDSAP256SHA256/64179 record ZRRSIG: rule1=(~false or false) rule2=(~true or true) rule3=(~true or true)
keymgr: transition ZSK zone.example/ECDSAP256SHA256/64179 type ZRRSIG state HIDDEN to state RUMOURED!
keymgr: examine ZSK zone.example/ECDSAP256SHA256/20481 type DNSKEY in state HIDDEN
keymgr: ZSK zone.example/ECDSAP256SHA256/20481 type DNSKEY in stable state HIDDEN
keymgr: examine ZSK zone.example/ECDSAP256SHA256/20481 type ZRRSIG in state HIDDEN
keymgr: ZSK zone.example/ECDSAP256SHA256/20481 type ZRRSIG in stable state HIDDEN
keymgr: examine KSK zone.example/ECDSAP256SHA256/12506 type DNSKEY in state HIDDEN
keymgr: KSK zone.example/ECDSAP256SHA256/12506 type DNSKEY in stable state HIDDEN
keymgr: examine KSK zone.example/ECDSAP256SHA256/12506 type KRRSIG in state HIDDEN
keymgr: KSK zone.example/ECDSAP256SHA256/12506 type KRRSIG in stable state HIDDEN
keymgr: examine KSK zone.example/ECDSAP256SHA256/12506 type DS in state HIDDEN
keymgr: KSK zone.example/ECDSAP256SHA256/12506 type DS in stable state HIDDEN
keymgr: examine KSK zone.example/ECDSAP256SHA256/56446 type DNSKEY in state RUMOURED
keymgr: can we transition KSK zone.example/ECDSAP256SHA256/56446 type DNSKEY state RUMOURED to state OMNIPRESENT?
keymgr: dnssec evaluation of KSK zone.example/ECDSAP256SHA256/56446 record DNSKEY: rule1=(~false or false) rule2=(~true or true) rule3=(~true or true)
keymgr: time says no to KSK zone.example/ECDSAP256SHA256/56446 type DNSKEY state RUMOURED to state OMNIPRESENT (wait 7500 seconds)
keymgr: examine KSK zone.example/ECDSAP256SHA256/56446 type KRRSIG in state RUMOURED
keymgr: can we transition KSK zone.example/ECDSAP256SHA256/56446 type KRRSIG state RUMOURED to state OMNIPRESENT?
keymgr: dnssec evaluation of KSK zone.example/ECDSAP256SHA256/56446 record KRRSIG: rule1=(~false or false) rule2=(~true or true) rule3=(~true or true)
keymgr: time says no to KSK zone.example/ECDSAP256SHA256/56446 type KRRSIG state RUMOURED to state OMNIPRESENT (wait 7500 seconds)
keymgr: examine KSK zone.example/ECDSAP256SHA256/56446 type DS in state HIDDEN
keymgr: can we transition KSK zone.example/ECDSAP256SHA256/56446 type DS state HIDDEN to state RUMOURED?
keymgr: policy says no to KSK zone.example/ECDSAP256SHA256/56446 type DS state HIDDEN to state RUMOURED
keymgr: examine ZSK zone.example/ECDSAP256SHA256/64179 type DNSKEY in state RUMOURED
keymgr: can we transition ZSK zone.example/ECDSAP256SHA256/64179 type DNSKEY state RUMOURED to state OMNIPRESENT?
keymgr: dnssec evaluation of ZSK zone.example/ECDSAP256SHA256/64179 record DNSKEY: rule1=(~false or false) rule2=(~true or true) rule3=(~true or true)
keymgr: time says no to ZSK zone.example/ECDSAP256SHA256/64179 type DNSKEY state RUMOURED to state OMNIPRESENT (wait 7500 seconds)
keymgr: examine ZSK zone.example/ECDSAP256SHA256/64179 type ZRRSIG in state RUMOURED
keymgr: can we transition ZSK zone.example/ECDSAP256SHA256/64179 type ZRRSIG state RUMOURED to state OMNIPRESENT?
keymgr: dnssec evaluation of ZSK zone.example/ECDSAP256SHA256/64179 record ZRRSIG: rule1=(~false or false) rule2=(~true or true) rule3=(~true or true)
keymgr: time says no to ZSK zone.example/ECDSAP256SHA256/64179 type ZRRSIG state RUMOURED to state OMNIPRESENT (wait 90300 seconds)
Removing expired key 20481/ECDSAP256SHA256 from DNSKEY RRset.
DNSKEY zone.example/ECDSAP256SHA256/20481 (ZSK) is now deleted
Removing expired key 12506/ECDSAP256SHA256 from DNSKEY RRset.
DNSKEY zone.example/ECDSAP256SHA256/12506 (KSK) is now deleted
Fetching zone.example/ECDSAP256SHA256/56446 (KSK) from key repository.
DNSKEY zone.example/ECDSAP256SHA256/56446 (KSK) is now published
DNSKEY zone.example/ECDSAP256SHA256/56446 (KSK) is now active
Fetching zone.example/ECDSAP256SHA256/64179 (ZSK) from key repository.
DNSKEY zone.example/ECDSAP256SHA256/64179 (ZSK) is now published
DNSKEY zone.example/ECDSAP256SHA256/64179 (ZSK) is now active
zone zone.example/IN (signed): next key event in 7500 seconds
zone zone.example/IN (signed): next key event: 26-Mar-2020 20:53:34.338
```
### Possible fixes
None known.
One idea put forward was that the TTL field in the .key file did not match the policy (which it did not, .key file had the `dnssec-keygen` default: omitted TTL) but adding the same TTL to the key file did not appear to change the overall behavior.April 2020 (9.11.18, 9.16.2, 9.17.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/1661"max-journal-size default" is based on the wrong DB size in 9.162020-05-19T00:37:13ZEvan Hunt"max-journal-size default" is based on the wrong DB size in 9.16In the work for #1515 (`max-ixfr-ratio`) it became clear that `dns_db_getsize()` was not returning the correct database size in bytes - it returns the sum of the sizes of all the rdataslabs in the database, which have a great deal of ext...In the work for #1515 (`max-ixfr-ratio`) it became clear that `dns_db_getsize()` was not returning the correct database size in bytes - it returns the sum of the sizes of all the rdataslabs in the database, which have a great deal of extra overhead space in them. This was corrected in master, but should also be fixed in 9.16 (even if we don't backport `max-ixfr-ratio`), because it's used to compute the maximum journal size when `max-journal-size` is set to `default`.April 2020 (9.11.18, 9.16.2, 9.17.1)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1447BIND unresponsive during large IXFR and RPZ transfers2020-05-09T18:07:44ZStephen MorrisBIND unresponsive during large IXFR and RPZ transfersDuring a large IXFR, or during the transfer of a response policy zone (regardless of whether it is done by AXFR or IXFR), BIND can become unresponsive for a few seconds.
For more details, see this [internal ISC report](https://wiki.isc....During a large IXFR, or during the transfer of a response policy zone (regardless of whether it is done by AXFR or IXFR), BIND can become unresponsive for a few seconds.
For more details, see this [internal ISC report](https://wiki.isc.org/bin/view/Main/QueryLatencyTransferEffect).
This may be related to #1194.April 2020 (9.11.18, 9.16.2, 9.17.1)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1735Release Checklist for BIND 9.11.18, BIND 9.11.18-S1, BIND 9.16.2, BIND 9.17.12020-04-16T21:29:03ZMichal NowakRelease Checklist for BIND 9.11.18, BIND 9.11.18-S1, BIND 9.16.2, BIND 9.17.1## Release Schedule
**Tagging Deadline:** Wednesday, April 8th, 2020
**Public Release:** Wednesday, April 15th, 2020
## Release Checklist
## 2 Working Days Before the Tagging Deadline
- [x] ***(QA)*** Check whether all issues assig...## Release Schedule
**Tagging Deadline:** Wednesday, April 8th, 2020
**Public Release:** Wednesday, April 15th, 2020
## Release Checklist
## 2 Working Days Before the Tagging Deadline
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
## Before the Tagging Deadline
- [x] ***(QA)*** Inform Support/Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(SwEng)*** Update API files for libraries with new version information.
- [x] ***(SwEng)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(SwEng)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(SwEng)*** Update `CHANGES`.
- [x] ***(SwEng)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(SwEng)*** Update `README.md`.
- [x] ***(SwEng)*** Update `version`.
- [x] ***(SwEng)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that all the above steps were performed correctly.
- [x] ***(QA)*** Check that the contents of release notes match the merge requests comprising the releases.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(SwEng)*** Tag the releases[^2]. (Tags may only be pushed to the public repository for releases which are *not* security releases.)
- [x] ***(SwEng)*** If this is the first tag for a release (e.g. beta), create a release branch named `release_v9_X_Y` to allow development to continue on the maintenance branch whilst release engineering continues.
## Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
## On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public packages (`*.deb`, RPMs).
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(SwEng)*** Push tags for the published releases to the public repository.
- [x] ***(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`).
- [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.
[^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.
[^2]: Preferred command line: `git tag -u <DEVELOPER_KEYID> -a -s -m "BIND 9.X.Y[alphatag]" v9_X_Y[alphatag]`, where `[alphatag]` is an optional string such as `b1`, `rc1`, etc.April 2020 (9.11.18, 9.16.2, 9.17.1)Michał KępieńMichał Kępień2020-04-15https://gitlab.isc.org/isc-projects/bind9/-/issues/864zone type table in ARM needs improvement2020-04-15T11:52:07ZEvan Huntzone type table in ARM needs improvementThe table of zone types and their descriptions in chapter 5 of the ARM is poorly formatted - in the PDF the columns don't line up correctly and there are lines and numbers crisscrossing the text; in HTML, 80% of the page width is taken u...The table of zone types and their descriptions in chapter 5 of the ARM is poorly formatted - in the PDF the columns don't line up correctly and there are lines and numbers crisscrossing the text; in HTML, 80% of the page width is taken up with the type name ("master" or "mirror" or whatever) and then the descriptive text is jammed into a narrow column down the right side of the browser window.April 2020 (9.11.18, 9.16.2, 9.17.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/1673lib/isc/pk11.c depend on libdns headers2020-04-15T11:52:00ZOndřej Surýlib/isc/pk11.c depend on libdns headersThere's a circular dependency between `lib/isc/pk11.c` requiring `<dst/result.h>` making libisc build depend on libdns headers. This is weird and wrong and needs to be fixed.There's a circular dependency between `lib/isc/pk11.c` requiring `<dst/result.h>` making libisc build depend on libdns headers. This is weird and wrong and needs to be fixed.April 2020 (9.11.18, 9.16.2, 9.17.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1678BIND fails to build with MYSQL support against mysql8/mysql-connector-82020-04-15T11:51:32ZKlemen MihevcBIND fails to build with MYSQL support against mysql8/mysql-connector-8<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
BIND fails to build with MYSQL support against mysql8/mysql-connector-8
### BIND version used
BIND 9.16.0 (Stable Release) <id:6270e60>
### What is the current *bug* behavior?
```
../../contrib/dlz/drivers/dlz_mysql_driver.c: In function ‘�mysql_create�’:
../../contrib/dlz/drivers/dlz_mysql_driver.c:754:2:� �error: unknown type name ‘my_bool’; did you mean ‘bool�’?
754 | �my_bool� auto_reconnect = 1;
| �~~~~~~�
| �bool�
make[2]: *** [Makefile:638: dlz_mysql_driver.lo] Error 1
```
### Possible fixes
Full build.log from gentoo, together with a patch...
```
https://bugs.gentoo.org/712692
https://712692.bugs.gentoo.org/attachment.cgi?id=619928&action=diff&format=raw&headers=1
```April 2020 (9.11.18, 9.16.2, 9.17.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/1715kasp system test timing issue with view zones2020-04-09T06:50:53ZMatthijs Mekkingmatthijs@isc.orgkasp system test timing issue with view zonesMost zones are checked if signing has been completed, before executing the kasp specific checks. There is not yet such a check for zones in views. This may result in intermittent failures.Most zones are checked if signing has been completed, before executing the kasp specific checks. There is not yet such a check for zones in views. This may result in intermittent failures.April 2020 (9.11.18, 9.16.2, 9.17.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/1669"kasp" system test is failing consistently on Windows2020-04-09T06:50:14ZMichał Kępień"kasp" system test is failing consistently on WindowsThe same four checks always fail on Windows:
```
kasp1.log-I:kasp:check next key event for zone step2.algorithm-roll.kasp (570)
kasp1.log-I:kasp:error: bad next key event time 20909 for zone step2.algorithm-roll.kasp (expect 21600)
kasp...The same four checks always fail on Windows:
```
kasp1.log-I:kasp:check next key event for zone step2.algorithm-roll.kasp (570)
kasp1.log-I:kasp:error: bad next key event time 20909 for zone step2.algorithm-roll.kasp (expect 21600)
kasp1.log:I:kasp:failed
--
kasp1.log-I:kasp:check next key event for zone step5.algorithm-roll.kasp (594)
kasp1.log-I:kasp:error: bad next key event time 24513 for zone step5.algorithm-roll.kasp (expect 25200)
kasp1.log:I:kasp:failed
--
kasp1.log-I:kasp:check next key event for zone step2.csk-algorithm-roll.kasp (618)
kasp1.log-I:kasp:error: bad next key event time 20916 for zone step2.csk-algorithm-roll.kasp (expect 21600)
kasp1.log:I:kasp:failed
--
kasp1.log-I:kasp:check next key event for zone step5.csk-algorithm-roll.kasp (642)
kasp1.log-I:kasp:error: bad next key event time 24519 for zone step5.csk-algorithm-roll.kasp (expect 25200)
kasp1.log:I:kasp:failed
--
kasp2.log-I:kasp:check next key event for zone step2.algorithm-roll.kasp (570)
kasp2.log-I:kasp:error: bad next key event time 20956 for zone step2.algorithm-roll.kasp (expect 21600)
kasp2.log:I:kasp:failed
--
kasp2.log-I:kasp:check next key event for zone step5.algorithm-roll.kasp (594)
kasp2.log-I:kasp:error: bad next key event time 24559 for zone step5.algorithm-roll.kasp (expect 25200)
kasp2.log:I:kasp:failed
--
kasp2.log-I:kasp:check next key event for zone step2.csk-algorithm-roll.kasp (618)
kasp2.log-I:kasp:error: bad next key event time 20962 for zone step2.csk-algorithm-roll.kasp (expect 21600)
kasp2.log:I:kasp:failed
--
kasp2.log-I:kasp:check next key event for zone step5.csk-algorithm-roll.kasp (642)
kasp2.log-I:kasp:error: bad next key event time 24564 for zone step5.csk-algorithm-roll.kasp (expect 25200)
kasp2.log:I:kasp:failed
--
kasp3.log-I:kasp:check next key event for zone step2.algorithm-roll.kasp (570)
kasp3.log-I:kasp:error: bad next key event time 20936 for zone step2.algorithm-roll.kasp (expect 21600)
kasp3.log:I:kasp:failed
--
kasp3.log-I:kasp:check next key event for zone step5.algorithm-roll.kasp (594)
kasp3.log-I:kasp:error: bad next key event time 24539 for zone step5.algorithm-roll.kasp (expect 25200)
kasp3.log:I:kasp:failed
--
kasp3.log-I:kasp:check next key event for zone step2.csk-algorithm-roll.kasp (618)
kasp3.log-I:kasp:error: bad next key event time 20943 for zone step2.csk-algorithm-roll.kasp (expect 21600)
kasp3.log:I:kasp:failed
--
kasp3.log-I:kasp:check next key event for zone step5.csk-algorithm-roll.kasp (642)
kasp3.log-I:kasp:error: bad next key event time 24545 for zone step5.csk-algorithm-roll.kasp (expect 25200)
kasp3.log:I:kasp:failed
```
I am not sure how long this has been going on because another Windows-specific issue (!3184) has been masking this problem.
@matthijs: I have not yet looked at this problem closely, please take a look if you have some time. Keep in mind that the `kasp` test takes a lot more to run on Windows than on Unix systems (about 15 minutes; yes, you read that right). We will need to get this fixed before tagging or else we will have trouble producing release tarballs (as CI pipelines will not be able to pass).April 2020 (9.11.18, 9.16.2, 9.17.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/1742Logging is broken on Windows2020-04-08T13:28:32ZMichał KępieńLogging is broken on Windows3a24eacbb619b89eacf87281b4d1a73e68c19471 (!3321) seems to be the
culprit.
Last scheduled *master* pipeline for which Windows (mostly) worked:
https://gitlab.isc.org/isc-projects/bind9/pipelines/38307
- https://gitlab.isc.org/isc-pro...3a24eacbb619b89eacf87281b4d1a73e68c19471 (!3321) seems to be the
culprit.
Last scheduled *master* pipeline for which Windows (mostly) worked:
https://gitlab.isc.org/isc-projects/bind9/pipelines/38307
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/802733
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/802734
First scheduled *master* pipeline for which Windows is broken:
https://gitlab.isc.org/isc-projects/bind9/pipelines/38401
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/804958
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/804959
I narrowed it down to 3a24eacbb619b89eacf87281b4d1a73e68c19471 by
testing the merge requests merged between these two scheduled pipelines.April 2020 (9.11.18, 9.16.2, 9.17.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1717rwlock contention in isc_log_wouldlog() API (performance impact)2020-04-08T08:54:05ZOndřej Surýrwlock contention in isc_log_wouldlog() API (performance impact)In !3229, we introduced a rwlock contention in `isc_log_wouldlog()` which has a significant performance impact.In !3229, we introduced a rwlock contention in `isc_log_wouldlog()` which has a significant performance impact.April 2020 (9.11.18, 9.16.2, 9.17.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1743"addzone" system test fails consistently for non-LMDB builds2020-04-07T21:01:36ZMichał Kępień"addzone" system test fails consistently for non-LMDB builds```
S:addzone:Tue Apr 7 12:48:01 CEST 2020
T:addzone:1:A
A:addzone:System test addzone
...
I:addzone:check that named restarts with multiple added zones (56)
I:addzone:Couldn't start server /tmp/bind9/bin/named/named -D addzone-ns3 -X n...```
S:addzone:Tue Apr 7 12:48:01 CEST 2020
T:addzone:1:A
A:addzone:System test addzone
...
I:addzone:check that named restarts with multiple added zones (56)
I:addzone:Couldn't start server /tmp/bind9/bin/named/named -D addzone-ns3 -X named.lock -m record,size,mctx -c named.conf -d 99 -g -U 4 >>named.run 2>&1 & echo $! (pid=24490)
I:addzone:failed
kill: sending signal to 24490 failed: No such process
I:addzone:failed
I:addzone:exit status: 1
R:addzone:FAIL
E:addzone:Tue Apr 7 12:48:37 CEST 2020
```
The offending test code line is:
```sh
$RNDCCMD 10.53.0.3 addzone '"test\".baz"' '{ type master; check-names ignore; file "e.db"; };' > /dev/null 2>&1 || ret=1
```
(introduced in ad030332bdb14b5c0a0aacee2f89cedbd98ec041 - part of !3150)
The last line in the relevant `_default.nzf` file prevents `named` from
starting up:
```sh
$ cat bin/tests/system/addzone/ns3/_default.nzf
# New zone file for view: _default
# This file contains configuration for zones added by
# the 'rndc addzone' command. DO NOT EDIT BY HAND.
zone "test1.baz" { type master; file "e.db"; };
zone "test4.baz" { type master; file "e.db"; };
zone "test5.baz" { type master; file "e.db"; };
zone "test/.baz" { type master; check-names ignore; file "e.db"; };
zone "test".baz" { type master; check-names ignore; file "e.db"; };
$ tail bin/tests/system/addzone/ns3/named.run
07-Apr-2020 12:48:12.255 unable to open GeoIP2 database '/usr/share/GeoIP/GeoIP2-Domain.mmdb' (status 1)
07-Apr-2020 12:48:12.255 using default UDP/IPv4 port range: [32768, 60999]
07-Apr-2020 12:48:12.255 using default UDP/IPv6 port range: [32768, 60999]
07-Apr-2020 12:48:12.255 listening on IPv4 interface lo, 10.53.0.3#5300
07-Apr-2020 12:48:12.255 generating session key for dynamic DNS
07-Apr-2020 12:48:12.255 _default.nzf:8: '{' expected near '"'
07-Apr-2020 12:48:12.255 Error parsing NZF file '_default.nzf': unexpected token
07-Apr-2020 12:48:12.265 load_configuration: unexpected token
07-Apr-2020 12:48:12.288 loading configuration: unexpected token
07-Apr-2020 12:48:12.288 exiting (due to fatal error)
```
Pinging @marka based on `git blame`. Also @each as he reviewed the MR
and is in an arguably more convenient time zone.
We will need to get this fixed before tagging the April releases as it
is causing the `addzone` system test to consistently fail on Windows
(which does not have LMDB available).April 2020 (9.11.18, 9.16.2, 9.17.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/1575Design document for native DoH RFC 84842020-04-04T06:05:54ZVicky Riskvicky@isc.orgDesign document for native DoH RFC 8484Creating a separate issue to create the initial design for DoH, specifying the components to be used, high level flow. Presumably this will be put in a wiki page? It should be sent to the bind-dev list as well.Creating a separate issue to create the initial design for DoH, specifying the components to be used, high level flow. Presumably this will be put in a wiki page? It should be sent to the bind-dev list as well.April 2020 (9.11.18, 9.16.2, 9.17.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1679Handle systems with broken gettimeofday system calls2020-03-25T21:31:38ZMark AndrewsHandle systems with broken gettimeofday system callsJob [#758142](https://gitlab.isc.org/isc-projects/bind9/-/jobs/758142) failed for a38a3244424c593c7b65bb729683c9d953c2cf87:
isc_stdtime_get corrects systems which gettimeofday returns a out-of-range tv_usec field by adding and subtracti...Job [#758142](https://gitlab.isc.org/isc-projects/bind9/-/jobs/758142) failed for a38a3244424c593c7b65bb729683c9d953c2cf87:
isc_stdtime_get corrects systems which gettimeofday returns a out-of-range tv_usec field by adding and subtracting seconds from tv_sec and tv_usec as appropriate. This results in a seconds value which is outside the expected range by 1 (too large) based on observed failures.
```
I:nsupdate:check that unixtime serial number is correctly generated (7)
I:nsupdate:out-of-range serial=1584313212 > now=1584313211
I:nsupdate:failed
```
```
n=`expr $n + 1`
ret=0
echo_i "check that unixtime serial number is correctly generated ($n)"
$DIG $DIGOPTS +short unixtime.nil. soa @10.53.0.1 > dig.out.old.test$n || ret=1
oldserial=`awk '{print $3}' dig.out.old.test$n` || ret=1
start=`$PERL -e 'print time()."\n";'`
$NSUPDATE <<END > /dev/null 2>&1 || ret=1
server 10.53.0.1 ${PORT}
ttl 600
update add new.unixtime.nil in a 1.2.3.4
send
END
now=`$PERL -e 'print time()."\n";'`
sleep 1
$DIG $DIGOPTS +short unixtime.nil. soa @10.53.0.1 > dig.out.new.test$n || ret=1
serial=`awk '{print $3}' dig.out.new.test$n` || ret=1
[ "$oldserial" = "$serial" ] && { echo_i "oldserial == serial"; ret=1; }
if [ "$serial" -lt "$start" ]; then
echo_i "out-of-range serial=$serial < start=$start"; ret=1;
elif [ "$serial" -gt "$now" ]; then
echo_i "out-of-range serial=$serial > now=$now"; ret=1;
fi
[ $ret = 0 ] || { echo_i "failed"; status=1; }
```
```
15-Mar-2020 23:00:11.995 journal file unixtime.db.jnl does not exist, creating it
15-Mar-2020 23:00:11.995 writing to journal
15-Mar-2020 23:00:11.995 del unixtime.nil. 300 IN SOA ns1.unixtime.nil. hostmaster.unixtime.nil. 1 2000 2000 1814400 3600
15-Mar-2020 23:00:11.995 add unixtime.nil. 300 IN SOA ns1.unixtime.nil. hostmaster.unixtime.nil. 1584313212 2000 2000 1814400 3600
15-Mar-2020 23:00:11.995 add new.unixtime.nil. 600 IN A 1.2.3.4
```
1584313212 is 15-Mar-2020 23:00:12April 2020 (9.11.18, 9.16.2, 9.17.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1698Converting isc_log to RWLOCK broke Windows2020-03-24T04:47:48ZOndřej SurýConverting isc_log to RWLOCK broke WindowsThe !3229 broke Windows system tests - the tests are stuck indefinitely. See https://gitlab.isc.org/isc-projects/bind9/-/jobs/777703 (ondrej/msvc-stuck-v1 branch) as example vs https://gitlab.isc.org/isc-projects/bind9/-/jobs/777784 (on...The !3229 broke Windows system tests - the tests are stuck indefinitely. See https://gitlab.isc.org/isc-projects/bind9/-/jobs/777703 (ondrej/msvc-stuck-v1 branch) as example vs https://gitlab.isc.org/isc-projects/bind9/-/jobs/777784 (ondrej/msvc-stuck-v2 branch).
There's nothing really obvious, but converting the rwlocks to native Windows SRWLock doesn't help, so it must be a way how we are using the locks on Windows.April 2020 (9.11.18, 9.16.2, 9.17.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1684timer_test.c fails to compile with clang-112020-03-20T15:08:52ZOndřej Surýtimer_test.c fails to compile with clang-11```
timer_test.c:194:6: error: cast to smaller integer type 'isc_timertype_t' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
if ((isc_timertype_t)event->ev_arg == isc_timertype_ticker) {
^~~~~~~~~~~~~~~~~~~~~~~~~...```
timer_test.c:194:6: error: cast to smaller integer type 'isc_timertype_t' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
if ((isc_timertype_t)event->ev_arg == isc_timertype_ticker) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
Makefile:250: recipe for target 'timer_test.lo' failed
```April 2020 (9.11.18, 9.16.2, 9.17.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/1304Update FreeBSD 12 jail to 12.1-RELEASE in CI2020-03-19T06:16:07ZMichal NowakUpdate FreeBSD 12 jail to 12.1-RELEASE in CIFreeBSD 12.1-RELEASE was [released](https://www.freebsd.org/releases/12.1R/announce.html) recently.
FreeBSD 12 jail in the CI should be updated.FreeBSD 12.1-RELEASE was [released](https://www.freebsd.org/releases/12.1R/announce.html) recently.
FreeBSD 12 jail in the CI should be updated.April 2020 (9.11.18, 9.16.2, 9.17.1)Michał KępieńMichał Kępień