BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2020-08-05T09:09:56Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2065"geoip2" system test fails intermittently2020-08-05T09:09:56ZMichał Kępień"geoip2" system test fails intermittentlyThe problem affects ~"v9.17" and ~"v9.16" on various runners:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1064670
- https://gitlab.isc.org/isc-private/bind9/-/jobs/1064060
- https://gitlab.isc.org/isc-private/bind9/-/jobs/1...The problem affects ~"v9.17" and ~"v9.16" on various runners:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1064670
- https://gitlab.isc.org/isc-private/bind9/-/jobs/1064060
- https://gitlab.isc.org/isc-private/bind9/-/jobs/1064109
- https://gitlab.isc.org/isc-private/bind9/-/jobs/1064111
This was not happening for July releases.August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2055[CVE-2020-8624] "update-policy" rules of type "subdomain" are enforced incorr...2020-08-25T06:59:03ZJoop Boonen[CVE-2020-8624] "update-policy" rules of type "subdomain" are enforced incorrectly<!--
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
update-policy { grant dev.DOMAIN.TLD subdomain dev.DOMAIN.TLD a aaaa txt; } is not handled correctly
It is also possible to change entries in DOMAIN.TLD
### BIND version used
9.16.5 opensuse
9.11.5 debian buster
Both exactly the same Problem
### Steps to reproduce
Configuration:
````
include "/etc/bind/dev.key";
zone DOMAIN.TLD {
type master;
file "/var/lib/bind/zones/DOMAIN.TLD";
key-directory "/var/lib/bind/keys";
masterfile-format raw;
update-policy {
grant dhcp zonesub a dhcid;
grant local-ddns zonesub any;
grant dev.DOMAIN.TLD subdomain dev.DOMAIN.TLD a aaaa txt;
};
allow-transfer {
local;
};
};
````
Key
````
cat /etc/bind/dev.key
key "dev.DOMAIN.TLD" {
algorithm hmac-sha512;
secret "******";
};
````
````
nsupdate -k dev.key
> server 192.168.122.129
> ttl 3600
> update add test3.dev.DOMAIN.TLD a 192.0.2.3
> send
> update add test.DOMAIN.TLD a 192.0.2.1
> send
````
````
Jul 28 16:48:59 leap152-bind named[5894]: client @0x7f5718000c80 192.168.122.1#40886/key dev.DOMAIN.TLD: updating zone 'DOMAIN.de/IN': adding an RR at 'test3.dev.DOMAIN.de' A 192.0.2.3
Jul 28 16:48:59 leap152-bind named[5894]: zone DOMAIN.de/IN: sending notifies (serial 2020050521)
Jul 28 16:49:07 leap152-bind named[5894]: client @0x7f5718000c80 192.168.122.1#40886/key dev.DOMAIN.TLD: updating zone 'DOMAIN.de/IN': adding an RR at 'test.DOMAIN.de' A 192.0.2.1
Jul 28 16:49:07 leap152-bind named[5894]: zone DOMAIN.de/IN: sending notifies (serial 2020050522)
````
### What is the current *bug* behavior?
It is also possible to change entries in DOMAIN.TLD
### What is the expected *correct* behavior?
````
nsupdate -k dev.key
> server 192.168.122.129
> ttl 3600
> update add test4.dev.DOMAIN.TLD a 192.0.2.4
> send
> update add test4.DOMAIN.TLD a 192.0.2.4
> send
update failed: REFUSED
````
````
Jul 28 19:55:24 leap152-bind named[7625]: client @0x7ff5580a6970 192.168.122.1#46061/key dev.DOMAIN.TLD: updating zone 'DOMAIN.de/IN': adding an RR at 'test4.dev.DOMAIN.de' A 192.0.2.4
Jul 28 19:55:24 leap152-bind named[7625]: zone DOMAIN.de/IN: sending notifies (serial 2020050523)
Jul 28 19:55:38 leap152-bind named[7625]: client @0x7ff5580a6970 192.168.122.1#46061/key dev.DOMAIN.TLD: updating zone 'DOMAIN.de/IN': update failed: rejected by secure update (REFUSED)
````
This is seen on:
````
9.11.2 opensuse
9.10.3 debian stretch
````
### Relevant configuration files
````
zone DOMAIN.TLD {
type master;
file "/var/lib/bind/zones/DOMAIN.TLD";
key-directory "/var/lib/bind/keys";
masterfile-format raw;
update-policy {
grant dhcp zonesub a dhcid;
grant local-ddns zonesub any;
grant dev.DOMAIN.TLD subdomain dev.DOMAIN.TLD a aaaa txt;
};
allow-transfer {
local;
};
};
cat /etc/bind/dev.key
key "dev.DOMAIN.TLD" {
algorithm hmac-sha512;
secret "******";
};
````
### Relevant logs and/or screenshots
````
nsupdate -k dev.key
> server 192.168.122.129
> ttl 3600
> update add test3.dev.DOMAIN.TLD a 192.0.2.3
> send
> update add test.DOMAIN.TLD a 192.0.2.1
> send
````
````
Jul 28 16:48:59 leap152-bind named[5894]: client @0x7f5718000c80 192.168.122.1#40886/key dev.DOMAIN.TLD: updating zone 'DOMAIN.de/IN': adding an RR at 'test3.dev.DOMAIN.de' A 192.0.2.3
Jul 28 16:48:59 leap152-bind named[5894]: zone DOMAIN.de/IN: sending notifies (serial 2020050521)
Jul 28 16:49:07 leap152-bind named[5894]: client @0x7f5718000c80 192.168.122.1#40886/key dev.DOMAIN.TLD: updating zone 'DOMAIN.de/IN': adding an RR at 'test.DOMAIN.de' A 192.0.2.1
Jul 28 16:49:07 leap152-bind named[5894]: zone DOMAIN.de/IN: sending notifies (serial 2020050522)
````
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2050Add libuv version to "named -V" output2020-07-30T12:47:13ZMichal NowakAdd libuv version to "named -V" outputAdd libuv version to "named -V" output, e.g.:
```
compiled with libuv version: 1.38.0
linked to libuv version: 1.38.0
```Add libuv version to "named -V" output, e.g.:
```
compiled with libuv version: 1.38.0
linked to libuv version: 1.38.0
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/2043dns_rdata_hip_next() fails to return ISC_R_NOMORE at the right time.2020-07-24T05:29:54ZMark Andrewsdns_rdata_hip_next() fails to return ISC_R_NOMORE at the right time.August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/2038Bind not handling interfaces changes correctly when listen-on-v6 any specified2020-08-04T09:47:10ZPeter DaviesBind not handling interfaces changes correctly when listen-on-v6 any specifiedBind not handling interfaces changes correctly when listen-on-v6 any is specified:
Ref: [RT #16753](https://support.isc.org/Ticket/Display.html?id=16753)
Interfaces changes not being correctly handled on ipv6 changes, when the l...Bind not handling interfaces changes correctly when listen-on-v6 any is specified:
Ref: [RT #16753](https://support.isc.org/Ticket/Display.html?id=16753)
Interfaces changes not being correctly handled on ipv6 changes, when the listen-on-v6 statement is defined as "any".
After network reconfiguration bind stopped listening on an previously active ipv6 socket.August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/2037[CVE-2020-8623] A flaw in native PKCS#11 code can lead to a remotely triggera...2020-11-27T20:05:53ZOndřej Surý[CVE-2020-8623] A flaw in native PKCS#11 code can lead to a remotely triggerable assertion failure in pk11.c> Came from ...@yandex.ru:
>
> BIND should be compiled with --enable-native-pkcs11 and --with-pkcs11 options.
>
> The exploit triggers abort() in pk11_numbits function.
>
> Bug details:
> from lib/isc/pk11.c
>
> ```c
> unsigned int
>...> Came from ...@yandex.ru:
>
> BIND should be compiled with --enable-native-pkcs11 and --with-pkcs11 options.
>
> The exploit triggers abort() in pk11_numbits function.
>
> Bug details:
> from lib/isc/pk11.c
>
> ```c
> unsigned int
> pk11_numbits(CK_BYTE_PTR data, unsigned int bytecnt) {
> unsigned int bitcnt, i;
> CK_BYTE top;
>
> if (bytecnt == 0) {
> return (0);
> }
> bitcnt = bytecnt * 8;
> for (i = 0; i < bytecnt; i++) {
> top = data[i];
> if (top == 0) {
> bitcnt -= 8;
> continue;
> }
> ...
> }
> INSIST(0);
> ISC_UNREACHABLE();
> }
> ```
> Which means that if all bytes are 0, abort will be triggered.
>
> How to reproduce:
> 1) configure and build softhsm 2.6.1:
> ```
> $ ./configure --prefix=/var/softhsm --with-openssl=/var/openssl --with-crypto-backend=openssl
> $ make && sudo make install
> ```
>
> 2) compile BIND with PKCS11 support
> ```
> $ ./configure --prefix=/opt/bind --disable-chroot --enable-native-pkcs11 --with-pkcs11=/var/softhsm/lib/softhsm/libsofthsm2.so
> $ make && sudo make install
> ```
>
> 3) Configure BIND
> ```
> # init softhsm (PIN 1234)
> # /var/softhsm/bin//softhsm2-util --init-token --free --label softhsm
> Slot 1 has a free/uninitialized token.
> === SO PIN (4-255 characters) ===
> Please enter SO PIN: ****
> Please reenter SO PIN: ****
> === User PIN (4-255 characters) ===
> Please enter user PIN: ****
> Please reenter user PIN: ****
> The token has been initialized and is reassigned to slot 1294545520
>
> # export SLOT=1294545520
>
> # cd bin/tests/system/pkcs11
> ```
>
> Edit ns1/example.db.in and ns1/named.conf.in, change IP from 10.53.0.1 to your server IP
> After that run included setports.sh:
> ```
> # bash setports.sh
> ```
>
> Now you can generate the keys:
> ```
> # bash setup.sh
> ```
>
> ```
> # cp ns1/* /opt/bind/etc
> ```
>
> Fix permissions:
> ```
> # chown -R bind:bind /opt/bind/var/run
> ```
>
> Edit `/opt/bind/etc/named.conf` and change all paths to `*.example.db.signed` to full path, should be like this:
> ```
> zone "ecdsap384sha384.example." {
> type master;
> file "/opt/bind/etc/ecdsap384sha384.example.db.signed";
> allow-update { any; };
> };
> ```
>
>
> 4) Run BIND
> ```
> # cd /opt/bind/var/run
> # /opt/bind/sbin/named -g -d0 -u bind -c /opt/bind/etc/named.conf
> ```
>
> 5) run t1.py
> ```
> $ ./t1.py <your_server_ip> 53
> ```
>
> Example bind log:
>
> ```
> 25-Jun-2020 01:23:14.297 pk11.c:698: INSIST(0) failed, back trace
> 25-Jun-2020 01:23:14.297 #0 0x5583e7797e9b in __do_global_dtors_aux_fini_array_entry()+0x5583e6971623
> 25-Jun-2020 01:23:14.297 #1 0x5583e705686d in __do_global_dtors_aux_fini_array_entry()+0x5583e622fff5
> 25-Jun-2020 01:23:14.301 #2 0x5583e779783d in __do_global_dtors_aux_fini_array_entry()+0x5583e6970fc5
> 25-Jun-2020 01:23:14.301 #3 0x5583e77909d1 in __do_global_dtors_aux_fini_array_entry()+0x5583e696a159
> 25-Jun-2020 01:23:14.301 #4 0x5583e76de425 in __do_global_dtors_aux_fini_array_entry()+0x5583e68b7bad
> 25-Jun-2020 01:23:14.301 #5 0x5583e76c2080 in __do_global_dtors_aux_fini_array_entry()+0x5583e689b808
> 25-Jun-2020 01:23:14.301 #6 0x5583e76b4686 in __do_global_dtors_aux_fini_array_entry()+0x5583e688de0e
> 25-Jun-2020 01:23:14.305 #7 0x5583e734667e in __do_global_dtors_aux_fini_array_entry()+0x5583e651fe06
> 25-Jun-2020 01:23:14.305 #8 0x5583e7193db9 in __do_global_dtors_aux_fini_array_entry()+0x5583e636d541
> 25-Jun-2020 01:23:14.305 #9 0x5583e71a2181 in __do_global_dtors_aux_fini_array_entry()+0x5583e637b909
> 25-Jun-2020 01:23:14.305 #10 0x5583e7826f71 in __do_global_dtors_aux_fini_array_entry()+0x5583e6a006f9
> 25-Jun-2020 01:23:14.305 #11 0x5583e782800c in __do_global_dtors_aux_fini_array_entry()+0x5583e6a01794
> 25-Jun-2020 01:23:14.305 #12 0x7fd791aba6db in __do_global_dtors_aux_fini_array_entry()+0x7fd790c93e63
> 25-Jun-2020 01:23:14.305 #13 0x7fd7913d988f in __do_global_dtors_aux_fini_array_entry()+0x7fd7905b3017
> 25-Jun-2020 01:23:14.309 exiting (due to assertion failure)
> Aborted (core dumped)
> ```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2033'rndc dnstap --roll' fix was incomplete2020-08-04T11:02:59ZMark Andrews'rndc dnstap --roll' fix was incomplete```
1178 }
21. Condition i < versions, taking true branch.
1179 if (i < versions) {
CID 305429 (#1 of 1): Out-of-bounds read (OVERRUN)
22. overrun-l...```
1178 }
21. Condition i < versions, taking true branch.
1179 if (i < versions) {
CID 305429 (#1 of 1): Out-of-bounds read (OVERRUN)
22. overrun-local: Overrunning array of 2048 bytes at byte offset 2048 by dereferencing pointer &to_keep[i + 1]. [Note: The source code implementation of the function has been overridden by a builtin model.]
1180 memmove(&to_keep[i + 1],
1181 &to_keep[i],
1182 sizeof(to_keep[0]) *
1183 (versions - i -
1184 1));
1185 to_keep[i] = version;
1186 }
1187 }
1188 }
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2031Windows crashes with netmgr-based statschannel2020-07-27T21:33:09ZMichał KępieńWindows crashes with netmgr-based statschannelThe following crash happened in the `statistics` system test for both
Windows builds (Release and Debug) in a [pipeline][1] run for
f27c0c32572aad530514700ab2033f20c897c3f4:
```
16-Jul-2020 21:34:32.694 c:\builds\isc-projects\bind9\lib\...The following crash happened in the `statistics` system test for both
Windows builds (Release and Debug) in a [pipeline][1] run for
f27c0c32572aad530514700ab2033f20c897c3f4:
```
16-Jul-2020 21:34:32.694 c:\builds\isc-projects\bind9\lib\isc\buffer.c:76: REQUIRE((((b) != ((void *)0)) && (((const isc__magic_t *)(b))->magic == (0x42756621U)))) failed
```
Given that:
- I have not seen such crashes before,
- a pipeline ran for d8e6b32a18e6d4cc17830af237c00899de1c4912 did not
trigger these crashes,
- the only code-related MR merged between the last successful pipeline
and the first crashing one was !3847,
there is a fair chance that !3847 introduced a Windows-specific bug (or
a generic one that is simply easier to trigger on Windows).
@each: assigning you as the author for !3847, please take a look.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/pipelines/46984August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2030BIND ARM incorrectly documents the processing of forwarders (still has the pr...2020-08-04T19:54:13ZCathy AlmondBIND ARM incorrectly documents the processing of forwarders (still has the pre 9.3.0 explanation)This should be easy to fix.
In BIND 9.16 ARM I am reading in section 1.4.5 (Caching Name Servers):
```
Forwarding
Even a caching name server does not necessarily perform the complete recursive lookup itself. Instead, it
can forward som...This should be easy to fix.
In BIND 9.16 ARM I am reading in section 1.4.5 (Caching Name Servers):
```
Forwarding
Even a caching name server does not necessarily perform the complete recursive lookup itself. Instead, it
can forward some or all of the queries that it cannot satisfy from its cache to another caching name server,
commonly referred to as a forwarder.
There may be one or more forwarders, and they are queried in turn until the list is exhausted or an answer is
found. Forwarders are typically used when you do not wish all the servers at a given site to interact directly
with the rest of the Internet servers. A typical scenario would involve a number of internal DNS servers and
an Internet firewall. Servers unable to pass packets through the firewall would forward to the server that
can do it, and that server would query the Internet DNS servers on the internal server’s behalf.
```
This changed in 9.3.0 with this:
> 1367. [func] Use response times to select forwarders.
And it has been asked about and discussed by users many times since, so I'm quite surprised the ARM is still wrong.
This ancient bug ticket asked for an update to the documentation, but it was never actioned and eventually closed in a stale bugs ticket cleanup:
[https://bugs.isc.org/Ticket/Display.html?id=16518](https://bugs.isc.org/Ticket/Display.html?id=16518)
The submitter also suggests consulting of an RBL as another use case for forwarding worth documenting (we've seen this in action recently on a customer site) - so that might also be added to this section.
None of the options actually detail *how* the list of forwarders is used, so it's only in this section that we need to elaborate on it.
See also customer submitted ticket [#16812](https://support.isc.org/Ticket/Display.html?id=16812)August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2029Release Checklist for BIND 9.11.22, BIND 9.11.22-S1, BIND 9.16.6, BIND 9.17.42020-08-26T09:36:21ZMichał KępieńRelease Checklist for BIND 9.11.22, BIND 9.11.22-S1, BIND 9.16.6, BIND 9.17.4## Release Schedule
**Code Freeze:** Wednesday, August 5th, 2020
**Tagging Deadline:** Monday, August 10th, 2020
**Public Release:** Thursday, August 20th, 2020
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Info...## Release Schedule
**Code Freeze:** Wednesday, August 5th, 2020
**Tagging Deadline:** Monday, August 10th, 2020
**Public Release:** Thursday, August 20th, 2020
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [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)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(Support)*** Check release notes, ask QA to correct any mistakes found.
- [x] ***(Marketing)*** Check release notes, ask QA to correct any mistakes found.
- [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 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)*** 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] ***(SwEng)*** Push tags for the published releases to the public repository.
- [x] ***(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.
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- [x] ***(QA)*** Sanitize all confidential issues assigned to the release milestone and make them public.
- [x] ***(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.
[^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.August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Michal NowakMichal Nowak2020-08-20https://gitlab.isc.org/isc-projects/bind9/-/issues/2028[CVE-2020-8622] A truncated TSIG response can lead to an assertion failure2020-08-31T06:27:58ZMichael McNally[CVE-2020-8622] A truncated TSIG response can lead to an assertion failureOn [Support #16800](https://support.isc.org/Ticket/Display.html?id=16800) a customer reports to us:
There is a bug that we've seen in BIND, where a crash can occur if BIND receives a response to a TSIG-signed packet where the TSIG recor...On [Support #16800](https://support.isc.org/Ticket/Display.html?id=16800) a customer reports to us:
There is a bug that we've seen in BIND, where a crash can occur if BIND receives a response to a TSIG-signed packet where the TSIG record is not completely (or at all) contained in the response which is at least 4097 bytes _and_ the packet is marked as truncated (tc bit == 1).
We initially saw it in a 9.9 version, but then updated to an ESV 9.11 and have reproduced the issue there as well. Our 9.9 stack trace is corrupted, but we were able to get a stack trace from 9.11.
```
#0 0x000000fff63010c0 in raise () from /lib64/libc.so.6
#1 0x000000fff6303060 in abort () from /lib64/libc.so.6
#2 0x000000aaab8ad8b8 in assertion_failed ()
#3 0x000000fff6b12ac8 in isc_assertion_failed () from /lib64/libisc.so.169
#4 0x000000fff6e8a228 in dns_message_checksig () from /lib64/libdns.so.1102
#5 0x000000fff6f4c2b0 in resquery_response () from /lib64/libdns.so.1102
#6 0x000000fff6b3fcd0 in run () from /lib64/libisc.so.169
#7 0x000000fff6847e24 in start_thread () from /lib64/libpthread.so.0
#8 0x000000fff6418f2c in __thread_start () from /lib64/libc.so.6
```
A key element appears to be that even though BIND issues an OPT record requesting a packet size of 4096, if:
- The initial request has a TSIG.
- The responder responds with more than 4096 bytes (or at least a situation where the TSIG record is not completely contained with the first 4096 bytes)
- the response is marked with the TC bit == 1.
This is also in a scenario where BIND is acting as a forwarder, though I do not know if that is relevant.August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2026README.md -- typo2020-08-04T02:23:56ZRay KrebsREADME.md -- typotypo - fixing missing space between command and argument
-`xcode-select--install`. (Note that an Apple ID may be required to access the download
+`xcode-select --install`. (Note that an Apple ID may be required to access the download
[...typo - fixing missing space between command and argument
-`xcode-select--install`. (Note that an Apple ID may be required to access the download
+`xcode-select --install`. (Note that an Apple ID may be required to access the download
[0001-typo-fixing-missing-space-between-command-and-argume.patch](/uploads/d3b24a4b51146f772f34f95aed4b2b81/0001-typo-fixing-missing-space-between-command-and-argume.patch)August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2024A single hung outgoing TCP connection causes resolution to time out with defa...2020-08-04T13:23:19ZMichał KępieńA single hung outgoing TCP connection causes resolution to time out with default settingsWhen named acting as a resolver connects to an authoritative server over
TCP, it [sets][1] the idle timeout for that connection to 20 seconds.
This fixed timeout was [picked][2] back when the default processing
timeout for each client qu...When named acting as a resolver connects to an authoritative server over
TCP, it [sets][1] the idle timeout for that connection to 20 seconds.
This fixed timeout was [picked][2] back when the default processing
timeout for each client query was [hardcoded][3] to 30 seconds. Commit
000a8970f840a0c27c5cc404826853c4674362ac made this processing timeout
configurable through `resolver-query-timeout` and decreased its default
value to 10 seconds, but the idle TCP timeout was not adjusted to
reflect that change. As a result, with the current defaults in effect,
a single hung TCP connection will consistently cause the resolution
process for a given query to time out.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/c53bfb30e84498559dd004cb674fafb47235a05b/lib/dns/resolver.c#L3020
[2]: 09b45f7b5800c4dbb86846dea35e8aba0a25b0d0
[3]: https://gitlab.isc.org/isc-projects/bind9/-/blob/7f950d7cb71c8816168654f5a28edbb67ee27553/lib/dns/resolver.c#L3320August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2022use netmgr for statschannel2022-08-31T11:01:40ZEvan Huntuse netmgr for statschannelUpdate the statistics channel to use the network manager.Update the statistics channel to use the network manager.August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2021Double unlock in bin/named/server.c2020-07-16T07:55:39ZMichal NowakDouble unlock in bin/named/server.cCoverity reports [double unlock](https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=34348205&defectInstanceId=10861501&mergedDefectId=304960) in `bin/named/server.c` in July 12 run.
This likely came with the [recent LMD...Coverity reports [double unlock](https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=34348205&defectInstanceId=10861501&mergedDefectId=304960) in `bin/named/server.c` in July 12 run.
This likely came with the [recent LMDB fixes](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3758), the only locking change to `bin/named/server.c` from July 5 (the time of the previous Coverity run) to July 12 (the time of the identification in Coverity).August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/2020configure call needs to be cleaned up main: gcc:centos6:amd642020-07-31T06:26:12ZMark Andrewsconfigure call needs to be cleaned up main: gcc:centos6:amd64Job [#1019080](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1019080) failed for c91dc92410f15d1c93c70d2c596350eee7748958:
Unrecognized options:
--with-libtool, --without-make-clean, --with-python, --without-pythonJob [#1019080](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1019080) failed for c91dc92410f15d1c93c70d2c596350eee7748958:
Unrecognized options:
--with-libtool, --without-make-clean, --with-python, --without-pythonAugust 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2014Statschannel system test failed at setup stage.2020-07-16T07:22:03ZMark AndrewsStatschannel system test failed at setup stage.Job [#1013834](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1013834) failed for 032133d8cedd202f30f8e32b38386158cc647649:
Looking at the contents of ns2 and sign.sh it appears that the dnssec-signzone failed. This is almost certain...Job [#1013834](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1013834) failed for 032133d8cedd202f30f8e32b38386158cc647649:
Looking at the contents of ns2 and sign.sh it appears that the dnssec-signzone failed. This is almost certainly due to verification failing as it set expiration to `"now"+1s`.
```
S:statschannel:2020-07-08T02:16:29+0000
T:statschannel:1:A
A:statschannel:System test statschannel
I:statschannel:PORTRANGE:12500 - 12599
I:statschannel:setup.sh script failed
R:statschannel:FAIL
E:statschannel:2020-07-08T02:16:31+0000
```
```
[beetle:system/statschannel/ns2] marka% ls
Kdnssec.+013+42972.key Kdnssec.+013+47508.private
Kdnssec.+013+42972.private dsset-dnssec.
Kdnssec.+013+47508.key named.conf
[beetle:system/statschannel/ns2] marka%
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2013Unchecked returns of inet_pton in geoip_test.c2020-07-13T01:45:30ZMark AndrewsUnchecked returns of inet_pton in geoip_test.c```
305 dns_geoip_elem_t elt;
306 struct in_addr in4;
307 isc_netaddr_t na;
308
CID 281437 (#1 of 1): Unchecked return value (CHECKED_RETURN)
1. check_return: Calling inet_pton without checking return value (as ...```
305 dns_geoip_elem_t elt;
306 struct in_addr in4;
307 isc_netaddr_t na;
308
CID 281437 (#1 of 1): Unchecked return value (CHECKED_RETURN)
1. check_return: Calling inet_pton without checking return value (as is done elsewhere 89 out of 91 times).
309 inet_pton(AF_INET, addr, &in4);
310 isc_netaddr_fromin(&na, &in4);
...
322 dns_geoip_elem_t elt;
323 struct in6_addr in6;
324 isc_netaddr_t na;
325
CID 281472 (#1 of 1): Unchecked return value (CHECKED_RETURN)
1. check_return: Calling inet_pton without checking return value (as is done elsewhere 89 out of 91 times).
326 inet_pton(AF_INET6, addr, &in6);
327 isc_netaddr_fromin6(&na, &in6);
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2012Add assertion check to silence dereference before NULL check in tsig_test.c2020-07-13T03:21:36ZMark AndrewsAdd assertion check to silence dereference before NULL check in tsig_test.c```
363 /*
364 * Start digesting.
365 */
deref_ptr_in_call: Dereferencing pointer tsigout. [show details]
366 result = add_mac(outctx, tsigout);
367 assert_int_equal(result, ISC_R_SUCCESS);
...
47...```
363 /*
364 * Start digesting.
365 */
deref_ptr_in_call: Dereferencing pointer tsigout. [show details]
366 result = add_mac(outctx, tsigout);
367 assert_int_equal(result, ISC_R_SUCCESS);
...
474 if (tsigin != NULL) {
475 isc_buffer_free(&tsigin);
476 }
CID 281475 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking tsigout suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
477 if (tsigout != NULL) {
478 isc_buffer_free(&tsigout);
479 }
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/2011Off-by-one error in dns_rdatatype_attributes?2020-07-08T03:45:35ZMichael McNallyOff-by-one error in dns_rdatatype_attributes?On [Support #16775](https://support.isc.org/Ticket/Display.html?id=16775), Jinmei writes to let us know:
> I happened to notice one very minor "off-by-one" glitch in lib/dns/rdata.c:dns_rdatatype_attributes, which would be fixed by the ...On [Support #16775](https://support.isc.org/Ticket/Display.html?id=16775), Jinmei writes to let us know:
> I happened to notice one very minor "off-by-one" glitch in lib/dns/rdata.c:dns_rdatatype_attributes, which would be fixed by the following patch. That is, I believe including 255 is more logical according to the meta type range specified by IANA: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
>
> This doesn't affect the behavior anyway (hence "very minor"), since RDATATYPE_ATTRIBUTE_SW covers the case of type == 255. But the "fixed" code would be less confusing for code readers.
>
> (BTW: If 255 was intentionally excluded because the type is not "UNKNOWN", I'd say 249-254 should also be excluded).
```
diff --git a/lib/dns/rdata.c b/lib/dns/rdata.c
index c8453aae5c..7a281c2ef7 100644
--- a/lib/dns/rdata.c
+++ b/lib/dns/rdata.c
@@ -1286,7 +1286,7 @@ dns_rdata_checknames(dns_rdata_t *rdata, const dns_name_t *owner,
unsigned int
dns_rdatatype_attributes(dns_rdatatype_t type) {
RDATATYPE_ATTRIBUTE_SW
- if (type >= (dns_rdatatype_t)128 && type < (dns_rdatatype_t)255) {
+ if (type >= (dns_rdatatype_t)128 && type <= (dns_rdatatype_t)255) {
return (DNS_RDATATYPEATTR_UNKNOWN | DNS_RDATATYPEATTR_META);
}
return (DNS_RDATATYPEATTR_UNKNOWN);
```
Has he discovered an error on our part or was this done intentionally (in which case, can we explain why?)August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)