BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-04-08T09:06:50Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2620Ensure proper resource cleanup for failed gss_accept_sec_context() calls2021-04-08T09:06:50ZMichał KępieńEnsure proper resource cleanup for failed gss_accept_sec_context() callsEven if a call to `gss_accept_sec_context()` fails, it might still cause
a GSS-API response token to be allocated and left for the caller to
release. We should make sure that all resources are properly cleaned up
when a call to `gss_acc...Even if a call to `gss_accept_sec_context()` fails, it might still cause
a GSS-API response token to be allocated and left for the caller to
release. We should make sure that all resources are properly cleaned up
when a call to `gss_accept_sec_context()` fails.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2613lib/dns/gen is not deleted on make clean2021-04-09T08:35:26ZArtem Boldarievlib/dns/gen is not deleted on make cleanWhen doing `make clean`, `lib/dns/gen` executable is not being deleted. The issues is present when building at least on Linux or FreeBSD. Not a show stopper, but annoying when building for multiple platforms from the same directory.When doing `make clean`, `lib/dns/gen` executable is not being deleted. The issues is present when building at least on Linux or FreeBSD. Not a show stopper, but annoying when building for multiple platforms from the same directory.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2611doth system test fails due to SSL error in BIO: 5 unexpected error2021-04-09T08:38:34ZMatthijs Mekkingmatthijs@isc.orgdoth system test fails due to SSL error in BIO: 5 unexpected errorFor example here:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1614684
```
I:doth:checking DoH query (POST) (6)
02-Apr-2021 12:17:13.870 SSL error in BIO: 5 unexpected error
02-Apr-2021 12:17:13.870 SSL error in BIO: 5 unexpected e...For example here:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1614684
```
I:doth:checking DoH query (POST) (6)
02-Apr-2021 12:17:13.870 SSL error in BIO: 5 unexpected error
02-Apr-2021 12:17:13.870 SSL error in BIO: 5 unexpected error
02-Apr-2021 12:17:13.870 SSL error in BIO: 5 unexpected error
I:doth:failed
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2609Release Checklist for BIND 9.11.30/9.11.31, BIND 9.11.30-S1/9.11.31-S1, BIND ...2021-04-30T12:45:45ZMichał KępieńRelease Checklist for BIND 9.11.30/9.11.31, BIND 9.11.30-S1/9.11.31-S1, BIND 9.16.14/9.16.15, BIND 9.16.14-S1/9.16.15-S1, BIND 9.17.12## Release Schedule
**Code Freeze:** Wednesday, April 7th, 2021
**Tagging Deadline:** Monday, April 12th, 2021
**Public Release:** Wednesday, April 28th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone w...## Release Schedule
**Code Freeze:** Wednesday, April 7th, 2021
**Tagging Deadline:** Monday, April 12th, 2021
**Public Release:** Wednesday, April 28th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.17.12](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=April%202021%20(9.11.30%2F9.11.31%2C%209.11.30-S1%2F9.11.31-S1%2C%209.16.14%2F9.16.15%2C%209.16.14-S1%2F9.16.15-S1%2C%209.17.12)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
- [9.16.15](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=April%202021%20(9.11.30%2F9.11.31%2C%209.11.30-S1%2F9.11.31-S1%2C%209.16.14%2F9.16.15%2C%209.16.14-S1%2F9.16.15-S1%2C%209.17.12)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
- [9.11.31](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=April%202021%20(9.11.30%2F9.11.31%2C%209.11.30-S1%2F9.11.31-S1%2C%209.16.14%2F9.16.15%2C%209.16.14-S1%2F9.16.15-S1%2C%209.17.12)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.11)
**Merge requests merged into the milestone without a release note:**
- [9.17.12](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=April%202021%20(9.11.30%2F9.11.31%2C%209.11.30-S1%2F9.11.31-S1%2C%209.16.14%2F9.16.15%2C%209.16.14-S1%2F9.16.15-S1%2C%209.17.12)¬[label_name][]=Release%20Notes&target_branch=main)
- [9.16.15](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=April%202021%20(9.11.30%2F9.11.31%2C%209.11.30-S1%2F9.11.31-S1%2C%209.16.14%2F9.16.15%2C%209.16.14-S1%2F9.16.15-S1%2C%209.17.12)¬[label_name][]=Release%20Notes&target_branch=v9_16)
- [9.11.31](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=April%202021%20(9.11.30%2F9.11.31%2C%209.11.30-S1%2F9.11.31-S1%2C%209.16.14%2F9.16.15%2C%209.16.14-S1%2F9.16.15-S1%2C%209.17.12)¬[label_name][]=Release%20Notes&target_branch=v9_11)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.17.12](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=April%202021%20(9.11.30%2F9.11.31%2C%209.11.30-S1%2F9.11.31-S1%2C%209.16.14%2F9.16.15%2C%209.16.14-S1%2F9.16.15-S1%2C%209.17.12)&label_name[]=No%20CHANGES&target_branch=main)
- [9.16.15](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=April%202021%20(9.11.30%2F9.11.31%2C%209.11.30-S1%2F9.11.31-S1%2C%209.16.14%2F9.16.15%2C%209.16.14-S1%2F9.16.15-S1%2C%209.17.12)&label_name[]=No%20CHANGES&target_branch=v9_16)
- [9.11.31](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=April%202021%20(9.11.30%2F9.11.31%2C%209.11.30-S1%2F9.11.31-S1%2C%209.16.14%2F9.16.15%2C%209.16.14-S1%2F9.16.15-S1%2C%209.17.12)&label_name[]=No%20CHANGES&target_branch=v9_11)
## 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] ***(QA)*** Update API files for libraries with new version information.
- [x] ***(QA)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(QA)*** Update `CHANGES`.
- [x] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update `README.md`.
- [x] ***(QA)*** Update `version`.
- [x] ***(QA)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### 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)*** Send eligible customers updated links to the Subscription Edition (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [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] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** 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` 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.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Michał KępieńMichał Kępień2021-04-28https://gitlab.isc.org/isc-projects/bind9/-/issues/2608Change stale-answer-client-timeout default to off2021-04-22T07:30:06ZMatthijs Mekkingmatthijs@isc.orgChange stale-answer-client-timeout default to offUsing "stale-answer-client-timeout" turns out to have unforeseen
negative consequences (see e.g. #2594). The team is in agreement that
disabling it by default is a prudent thing to do for the time being.Using "stale-answer-client-timeout" turns out to have unforeseen
negative consequences (see e.g. #2594). The team is in agreement that
disabling it by default is a prudent thing to do for the time being.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2607Remove custom ISC SPNEGO implementation2021-04-02T06:06:24ZOndřej SurýRemove custom ISC SPNEGO implementationThe SPNEGO mechanism is available in both major implementations of Kerberos protocol:
* MIT Kerberos 5 since version 1.5
* Heimdal Kerberos since version 0.7
e.g. both are available since 2006-2007.The SPNEGO mechanism is available in both major implementations of Kerberos protocol:
* MIT Kerberos 5 since version 1.5
* Heimdal Kerberos since version 0.7
e.g. both are available since 2006-2007.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2604[CVE-2021-25216] ZDI-CAN-13347: A second vulnerability in BIND's GSSAPI secur...2021-04-29T10:36:42ZOndřej Surý[CVE-2021-25216] ZDI-CAN-13347: A second vulnerability in BIND's GSSAPI security policy negotiation can be targeted by a buffer overflow attack### CVE-specific actions
- [x] [Assign a CVE identifier](#note_204258)
- [x] [Determine CVSS score](#note_204769)
- [x] [Determine the range of BIND versions affected (including the Subscription Edition)](#note_204773)
- [x] [De...### CVE-specific actions
- [x] [Assign a CVE identifier](#note_204258)
- [x] [Determine CVSS score](#note_204769)
- [x] [Determine the range of BIND versions affected (including the Subscription Edition)](#note_204773)
- [x] [Determine whether workarounds for the problem exists](#note_204776)
- [x] Prepare a detailed description of the problem which should include the following by default:
- [instructions for reproducing the problem (a system test is good enough)](isc-private/bind9!287)
- [explanation of code flow which triggers the problem (a system test is *not* good enough)](#note_205320)
- [x] [Prepare a private merge request containing the following items in separate commits:](isc-private/bind9!283)
- a test for the issue (may be moved to a separate merge request for deferred merging)
- a fix for the issue
- documentation updates (`CHANGES`, [release notes](#note_205396), anything else applicable)
- [x] Ensure the merge request from the previous step is reviewed by SWENG staff and has no outstanding discussions
- [x] Ensure the documentation changes introduced by the merge request addressing the problem are reviewed by Support and Marketing staff
- [x] Prepare backports of the merge request addressing the problem for all affected (and still maintained) BIND branches (backporting might affect the issue's scope and/or description)
- [x] Prepare a standalone patch for the last stable release of each affected (and still maintained) BIND branch
### Release-specific actions
- [x] Create/update the private issue containing links to fixes & reproducers for all CVEs fixed in a given release cycle
- [x] Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined
- [x] Ensure the merge requests containing CVE fixes are merged into `security-*` branches in CVE identifier order
---
## CVSS
8.1: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
## ABSTRACT
Trend Micro's Zero Day Initiative has identified a vulnerability affecting the following products:
ISC - BIND
## VULNERABILITY DETAILS
* Version tested:9.16.13
* Installer file:https://downloads.isc.org/isc/bind9/9.16.13/bind-9.16.13.tar.xz
* Platform tested:debian-10.8.0-i386-netinst
---
### Analysis
```
integer overflow exist in der_get_oid() and leads to a wild-copy
it affected 32-bit only
```
~~~C++
lib/dns/spnego.c
der_get_oid(const unsigned char *p, size_t len, oid *data, size_t *size) {
int n;
size_t oldlen = len;
data->components = NULL;
data->length = 0;
if (len < 1U) {
return (ASN1_OVERRUN);
}
[1] data->components = malloc((len + 1) * sizeof(*data->components));
...
}
~~~
On 32 bit platforms 'len' is unsigned integer.
On line #1 integer overflow occurs if we set 'len' to 0x40000000, thus small buffer will be allocated.
Later it will be overwritten in oid decoding loop
debug log
```
Thread 2 "isc-net-0000" hit Breakpoint 2, 0x00d4dc9e in der_get_oid ()
1: x/i $pc
=> 0xd4dc9e <der_get_oid+171>: add eax,0x1
(gdb) i r $eax
eax 0x40000000 1073741824
(gdb) si
0x00d4dca1 in der_get_oid ()
1: x/i $pc
=> 0xd4dca1 <der_get_oid+174>: shl eax,0x2
(gdb) si
0x00d4dca4 in der_get_oid ()
1: x/i $pc
=> 0xd4dca4 <der_get_oid+177>: sub esp,0xc
(gdb) si
0x00d4dca7 in der_get_oid ()
1: x/i $pc
=> 0xd4dca7 <der_get_oid+180>: push eax
(gdb) si
0x00d4dca8 in der_get_oid ()
1: x/i $pc
=> 0xd4dca8 <der_get_oid+181>: call 0x5aa260 <malloc@plt>
(gdb) i r $eax
eax 0x4 4 // integer overflowed
(gdb) bt
#0 0x00d4dca8 in der_get_oid ()
#1 0x00d4f03a in decode_oid ()
#2 0x00d45878 in decode_MechType ()
#3 0x00d46108 in decode_MechTypeList ()
#4 0x00d478c0 in decode_NegTokenInit ()
#5 0x00d4c117 in gss_accept_sec_context_spnego ()
#6 0x00d0530a in dst_gssapi_acceptctx ()
#7 0x00b89bc8 in process_gsstkey ()
#8 0x00b8c332 in dns_tkey_processquery ()
#9 0x00712d33 in ns_query_start ()
#10 0x006998ed in ns.client_request ()
#11 0x00e17092 in isc.nm_async_readcb ()
#12 0x00e166c2 in isc.nm_readcb ()
#13 0x00e4266e in processbuffer ()
#14 0x00e4a2f5 in process_sock_buffer ()
#15 0x00e43038 in read_cb ()
#16 0xb740a727 in ?? () from /lib/i386-linux-gnu/libuv.so.1
#17 0xb740b2b7 in ?? () from /lib/i386-linux-gnu/libuv.so.1
#18 0xb7410468 in uv.io_poll () from /lib/i386-linux-gnu/libuv.so.1
#19 0xb7401146 in uv_run () from /lib/i386-linux-gnu/libuv.so.1
#20 0x00e068e7 in nm_thread ()
#21 0x00e9c1e0 in isc.trampoline_run ()
#22 0xb793d321 in ?? () from /lib/i386-linux-gnu/libasan.so.5
#23 0xb73cdfd2 in start_thread (arg=<optimized out>) at pthread_create.c:486
#24 0xb72b96d6 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108
```
ASAN report
```
=================================================================
==6064==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb4a23154 at pc 0x00d4de48 bp 0xb26f8a38 sp 0xb26f8a2c
WRITE of size 4 at 0xb4a23154 thread T1
#0 0xd4de47 in der_get_oid (/var/bind/sbin/named+0x868e47)
#1 0xd4f039 in decode_oid (/var/bind/sbin/named+0x86a039)
#2 0xd45877 in decode_MechType (/var/bind/sbin/named+0x860877)
#3 0xd46107 in decode_MechTypeList (/var/bind/sbin/named+0x861107)
#4 0xd478bf in decode_NegTokenInit (/var/bind/sbin/named+0x8628bf)
#5 0xd4c116 in gss_accept_sec_context_spnego (/var/bind/sbin/named+0x867116)
#6 0xd05309 in dst_gssapi_acceptctx (/var/bind/sbin/named+0x820309)
#7 0xb89bc7 in process_gsstkey (/var/bind/sbin/named+0x6a4bc7)
#8 0xb8c331 in dns_tkey_processquery (/var/bind/sbin/named+0x6a7331)
#9 0x712d32 in ns_query_start (/var/bind/sbin/named+0x22dd32)
#10 0x6998ec in ns__client_request (/var/bind/sbin/named+0x1b48ec)
#11 0xe17091 in isc__nm_async_readcb (/var/bind/sbin/named+0x932091)
#12 0xe166c1 in isc__nm_readcb (/var/bind/sbin/named+0x9316c1)
#13 0xe4266d in processbuffer (/var/bind/sbin/named+0x95d66d)
#14 0xe4a2f4 in process_sock_buffer (/var/bind/sbin/named+0x9652f4)
#15 0xe43037 in read_cb (/var/bind/sbin/named+0x95e037)
#16 0xb740a726 (/lib/i386-linux-gnu/libuv.so.1+0x17726)
#17 0xb740b2b6 (/lib/i386-linux-gnu/libuv.so.1+0x182b6)
#18 0xb7410467 in uv__io_poll (/lib/i386-linux-gnu/libuv.so.1+0x1d467)
#19 0xb7401145 in uv_run (/lib/i386-linux-gnu/libuv.so.1+0xe145)
#20 0xe068e6 in nm_thread (/var/bind/sbin/named+0x9218e6)
#21 0xe9c1df in isc__trampoline_run (/var/bind/sbin/named+0x9b71df)
#22 0xb793d320 (/lib/i386-linux-gnu/libasan.so.5+0x4a320)
#23 0xb73cdfd1 in start_thread /build/glibc-Stc26X/glibc-2.28/nptl/pthread_create.c:486
#24 0xb72b96d5 in __clone (/lib/i386-linux-gnu/libc.so.6+0xfa6d5)
0xb4a23154 is located 0 bytes to the right of 4-byte region [0xb4a23150,0xb4a23154)
allocated by thread T1 here:
#0 0xb79de5d4 in __interceptor_malloc (/lib/i386-linux-gnu/libasan.so.5+0xeb5d4)
#1 0xd4dcac in der_get_oid (/var/bind/sbin/named+0x868cac)
#2 0xd4f039 in decode_oid (/var/bind/sbin/named+0x86a039)
#3 0xd45877 in decode_MechType (/var/bind/sbin/named+0x860877)
#4 0xd46107 in decode_MechTypeList (/var/bind/sbin/named+0x861107)
#5 0xd478bf in decode_NegTokenInit (/var/bind/sbin/named+0x8628bf)
#6 0xd4c116 in gss_accept_sec_context_spnego (/var/bind/sbin/named+0x867116)
#7 0xd05309 in dst_gssapi_acceptctx (/var/bind/sbin/named+0x820309)
#8 0xb89bc7 in process_gsstkey (/var/bind/sbin/named+0x6a4bc7)
#9 0xb8c331 in dns_tkey_processquery (/var/bind/sbin/named+0x6a7331)
#10 0x712d32 in ns_query_start (/var/bind/sbin/named+0x22dd32)
#11 0x6998ec in ns__client_request (/var/bind/sbin/named+0x1b48ec)
#12 0xe17091 in isc__nm_async_readcb (/var/bind/sbin/named+0x932091)
#13 0xe166c1 in isc__nm_readcb (/var/bind/sbin/named+0x9316c1)
#14 0xe4266d in processbuffer (/var/bind/sbin/named+0x95d66d)
#15 0xe4a2f4 in process_sock_buffer (/var/bind/sbin/named+0x9652f4)
#16 0xe43037 in read_cb (/var/bind/sbin/named+0x95e037)
#17 0xb740a726 (/lib/i386-linux-gnu/libuv.so.1+0x17726)
Thread T1 created by T0 here:
#0 0xb79c6b50 in pthread_create (/lib/i386-linux-gnu/libasan.so.5+0xd3b50)
#1 0xed85a5 in isc_thread_create (/var/bind/sbin/named+0x9f35a5)
#2 0xe03a94 in isc_nm_start (/var/bind/sbin/named+0x91ea94)
#3 0x5cc8f5 in create_managers (/var/bind/sbin/named+0xe78f5)
#4 0x5cd5ea in setup (/var/bind/sbin/named+0xe85ea)
#5 0x5cdc89 in main (/var/bind/sbin/named+0xe8c89)
#6 0xb71d9b40 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: heap-buffer-overflow (/var/bind/sbin/named+0x868e47) in der_get_oid
Shadow bytes around the buggy address:
0x369445d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x369445e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x369445f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36944600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36944610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x36944620: fa fa fa fa fa fa fa fa fa fa[04]fa fa fa 00 fa
0x36944630: fa fa 00 01 fa fa 00 04 fa fa 04 fa fa fa fd fa
0x36944640: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x36944650: fa fa fd fa fa fa fd fd fa fa fd fd fa fa fd fa
0x36944660: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fd
0x36944670: fa fa fd fd fa fa fd fa fa fa fd fa fa fa fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==6064==ABORTING
```
## CREDIT
This vulnerability was discovered by:
Anonymous working with Trend Micro Zero Day Initiative
## FURTHER DETAILS
If supporting files were contained with this report they are provided within a password protected ZIP file. The password is the ZDI candidate number in the form: ZDI-CAN-XXXX where XXXX is the ID number.
Please confirm receipt of this report. We expect all vendors to remediate ZDI vulnerabilities within 120 days of the reported date. If you are ready to release a patch at any point leading up to the deadline, please coordinate with us so that we may release our advisory detailing the issue. If the 120-day deadline is reached and no patch has been made available we will release a limited public advisory with our own mitigations, so that the public can protect themselves in the absence of a patch. Please keep us updated regarding the status of this issue and feel free to contact us at any time:
Zero Day Initiative
zdi-disclosures@trendmicro.com
The PGP key used for all ZDI vendor communications is available from:
http://www.zerodayinitiative.com/documents/disclosures-pgp-key.asc
## INFORMATION ABOUT THE ZDI
Established by TippingPoint and acquired by Trend Micro, the Zero Day Initiative (ZDI) neither re-sells vulnerability details nor exploit code. Instead, upon notifying the affected product vendor, the ZDI provides its Trend Micro TippingPoint customers with zero day protection through its intrusion prevention technology. Explicit details regarding the specifics of the vulnerability are not exposed to any parties until an official vendor patch is publicly available.
Please contact us for further details or refer to:
http://www.zerodayinitiative.com
## DISCLOSURE POLICY
Our vulnerability disclosure policy is available online at:
http://www.zerodayinitiative.com/advisories/disclosure_policy/
## ATTACHMENTS
[redacted]April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2600general: error: managed-keys-zone: dns_journal_compact failed: no more2021-04-26T10:22:12ZJean-Christophe Manciotgeneral: error: managed-keys-zone: dns_journal_compact failed: no more- Ubuntu hirsute and Debian bullseye
- bind9 9.17.11
```
# echo 'q' | sudo systemctl --no-pager --full status named
● named.service - BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset...- Ubuntu hirsute and Debian bullseye
- bind9 9.17.11
```
# echo 'q' | sudo systemctl --no-pager --full status named
● named.service - BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-03-26 08:39:18 CET; 19min ago
Docs: man:named(8)
Main PID: 1469485 (named)
Tasks: 14 (limit: 9260)
Memory: 27.3M
CGroup: /system.slice/named.service
└─1469485 /usr/sbin/named -f -u bind
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.331 zoneload: info: zone 0.in-addr.arpa/IN: loaded serial 2020100901
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.339 zoneload: info: zone 127.in-addr.arpa/IN: loaded serial 2020100901
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.347 zoneload: info: zone 255.in-addr.arpa/IN: loaded serial 2020100901
...
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.355 zoneload: info: zone localhost/IN: loaded serial 2020100901
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.367 general: notice: all zones loaded
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.375 general: notice: running
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.375 general: info: zone sdxlive.com/IN (signed): receive_secure_serial: unchanged
Mar 26 08:39:48 hostname named[1469485]: 26-Mar-2021 08:39:48.491 general: error: managed-keys-zone: dns_journal_compact failed: no more
```
This issue appeared with 9.17.11 and was not present with previous releases.
Is there a workaround?April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2597Make calling generic rdata methods consistent2021-03-29T14:02:33ZMark AndrewsMake calling generic rdata methods consistentApril 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2594query.c:8367: INSIST(qctx->rdataset == ((void *)0) || (((&qctx->client->query...2022-09-21T11:18:47ZCathy Almondquery.c:8367: INSIST(qctx->rdataset == ((void *)0) || (((&qctx->client->query)->attributes & 0x40000) != 0)) failedAs reported in BIND 9.16.13-S1
```
18-Mar-2021 13:19:40.211 query.c:8367: INSIST(qctx->rdataset == ((void *)0) || (((&qctx->client->query)->attributes & 0x40000) != 0)) failed, back trace
18-Mar-2021 13:19:40.211 #0 0x55e22a736cf4 in ??...As reported in BIND 9.16.13-S1
```
18-Mar-2021 13:19:40.211 query.c:8367: INSIST(qctx->rdataset == ((void *)0) || (((&qctx->client->query)->attributes & 0x40000) != 0)) failed, back trace
18-Mar-2021 13:19:40.211 #0 0x55e22a736cf4 in ??
18-Mar-2021 13:19:40.211 #1 0x7f3df81838a0 in ??
18-Mar-2021 13:19:40.211 #2 0x7f3df9818af9 in ??
18-Mar-2021 13:19:40.211 #3 0x7f3df9818ca4 in ??
18-Mar-2021 13:19:40.211 #4 0x7f3df98131ec in ??
18-Mar-2021 13:19:40.211 #5 0x7f3df9819511 in ??
18-Mar-2021 13:19:40.211 #6 0x7f3df98199aa in ??
18-Mar-2021 13:19:40.211 #7 0x7f3df81ba11b in ??
18-Mar-2021 13:19:40.211 #8 0x7f3df81c0636 in ??
18-Mar-2021 13:19:40.211 #9 0x7f3df65f315a in ??
18-Mar-2021 13:19:40.211 #10 0x7f3df6324f73 in ??
18-Mar-2021 13:19:40.211 exiting (due to assertion failure)
```
ISC packaged RPM for RHEL/Centos 8 etc..
Originally occurred with these serve-stale settings:
```
stale-answer-enable yes;
// stale-answer-client-timeout 0;
max-stale-ttl 1w;
```
Uncommenting `stale-answer-client-timeout 0;` appears to prevent the crashes, otherwise they're occurring very frequently.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2592dig -u is extremely inaccurate, especially on machines with the kernel timer ...2022-04-26T13:18:31ZPatrick McLeandig -u is extremely inaccurate, especially on machines with the kernel timer tick set at 100HzThe current isc_time_now uses `CLOCK_REALTIME_COARSE` which only updates on a timer tick. This clock is generally fine for millisecond accuracy, but on servers with 100hz clocks, this clock is nowhere near accurate enough for microsecond...The current isc_time_now uses `CLOCK_REALTIME_COARSE` which only updates on a timer tick. This clock is generally fine for millisecond accuracy, but on servers with 100hz clocks, this clock is nowhere near accurate enough for microsecond accuracy.
This makes the `dig -u` command report very inaccurate timings. On a fast network with sub-ms responses, the reported time will oscillate between 0us and 10000us. I have created a patch to make this use `CLOCK_REALTIME` if the `-u` option is passed to dig.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2589Follow-up from "Resolve "memory leak when named attempts to listen on FreeBSD...2021-03-19T08:15:16ZOndřej SurýFollow-up from "Resolve "memory leak when named attempts to listen on FreeBSD virtual interface""The following discussion from !4823 should be addressed:
- [ ] @sgoldlust started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4823#note_200533):
> ```
> - If an outgoing packet exceeded max-udp-si...The following discussion from !4823 should be addressed:
- [ ] @sgoldlust started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4823#note_200533):
> ```
> - If an outgoing packet exceeded max-udp-size, it was dropped instead
> of sending a proper response. To address this issue, the IP_DONTFRAG settings on
> UDP sockets, which were enabled during DNS Flag Day 2020, were rolled back.
> ```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2585filter-a plugin2021-04-06T16:27:07ZMatthijs Mekkingmatthijs@isc.orgfilter-a pluginReverse the functionality of the 'filter-aaaa' plugin to omit A records instead of AAAA records.
This is useful especially in some IPv6-only environments. Sometimes, client software ignores system preferences and choses A over AAAA (e.g...Reverse the functionality of the 'filter-aaaa' plugin to omit A records instead of AAAA records.
This is useful especially in some IPv6-only environments. Sometimes, client software ignores system preferences and choses A over AAAA (e.g. 'NodeJS' does or used to do this). On an IPv6-only system, this will result in a failed connection attempt. If no 'happy eyeballs' is used, this will at least defer connection till after timeout, or worse it will make the connection impossible.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2583Fix TCPDNS and TLSDNS timers2021-04-02T09:00:10ZBrian ConryFix TCPDNS and TLSDNS timersAfter the TCPDNS refactoring the initial and idle timers were broken and
only the tcp-initial-timeout was always applied on the whole TCP
connection.
This broke any TCP connection that took longer than tcp-initial-timeout,
most often th...After the TCPDNS refactoring the initial and idle timers were broken and
only the tcp-initial-timeout was always applied on the whole TCP
connection.
This broke any TCP connection that took longer than tcp-initial-timeout,
most often this would affect large zone AXFRs.
This commit changes the timeout logic in this way:
* On TCP connection accept the tcp-initial-timeout is applied
and the timer is started
* When we are processing and/or sending any DNS message the timer is
stopped
* When we stop processing all DNS messages, the tcp-idle-timeout
is applied and the timer is started againApril 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2582ThreadSanitizer: data race lib/dns/zone.c:10272:7 in zone_maintenance2021-04-09T08:50:49ZMichal NowakThreadSanitizer: data race lib/dns/zone.c:10272:7 in zone_maintenanceTSAN [error](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1577490) on `v9_11` (ff463f375f882e9bf4ab228bc5d1bbcc3e7b4571):
```
S:notify:Wed Mar 17 04:43:32 UTC 2021
T:notify:1:A
A:notify:System test notify
I:notify:PORTRANGE:10000 - ...TSAN [error](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1577490) on `v9_11` (ff463f375f882e9bf4ab228bc5d1bbcc3e7b4571):
```
S:notify:Wed Mar 17 04:43:32 UTC 2021
T:notify:1:A
A:notify:System test notify
I:notify:PORTRANGE:10000 - 10099
I:notify:checking initial status (1)
I:notify:checking startup notify rate limit (2)
I:notify:reloading with example2 using HUP and waiting up to 45 seconds
I:notify:checking notify message was logged (3)
I:notify:checking example2 loaded (4)
I:notify:checking example2 contents have been transferred after HUP reload (5)
I:notify:stopping master and restarting with example4 then waiting up to 45 seconds
I:notify:checking notify message was logged (6)
I:notify:checking example4 loaded (7)
I:notify:checking example4 contents have been transferred after restart (8)
I:notify:checking notify to alternate port with master inheritance (9)
I:notify:checking notify to multiple views using tsig (10)
I:notify:exit status: 0
I:notify:1 sanitizer report(s) found
R:notify:FAIL
E:notify:Wed Mar 17 04:44:05 UTC 2021
```
```
WARNING: ThreadSanitizer: data race
Read of size 4 at 0x000000000001 by thread T1:
#0 zone_maintenance lib/dns/zone.c:10272:7
#1 zone_timer lib/dns/zone.c:13569:2
#2 dispatch lib/isc/task.c:1157:7
#3 run lib/isc/task.c:1331:2
Previous write of size 4 at 0x000000000001 by thread T2 (mutexes: write M1):
#0 dns_zone_notifyreceive2 lib/dns/zone.c:14053:3
#1 ns_notify_start bin/named/notify.c:150:13
#2 client_request bin/named/client.c:3150:3
#3 dispatch lib/isc/task.c:1157:7
#4 run lib/isc/task.c:1331:2
Location is heap block of size 2841 at 0x000000000009 allocated by thread T3:
#0 malloc <null>
#1 internal_memalloc lib/isc/mem.c:887:8
#2 mem_get lib/isc/mem.c:792:8
#3 mem_allocateunlocked lib/isc/mem.c:1545:8
#4 isc___mem_allocate lib/isc/mem.c:1566:7
#5 isc__mem_allocate lib/isc/mem.c:3048:11
#6 isc___mem_get lib/isc/mem.c:1304:11
#7 isc__mem_get lib/isc/mem.c:3012:11
#8 dns_zone_create lib/dns/zone.c:930:9
#9 dns_zonemgr_createzone lib/dns/zone.c:16916:11
#10 configure_zone bin/named/./server.c:5637:3
#11 configure_view bin/named/./server.c:3435:3
#12 load_configuration bin/named/./server.c:8179:3
#13 run_server bin/named/./server.c
#14 dispatch lib/isc/task.c:1157:7
#15 run lib/isc/task.c:1331:2
Mutex M1 is already destroyed.
Thread T3 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:60:8
#2 isc__taskmgr_create lib/isc/task.c:1468:7
#3 isc_taskmgr_create lib/isc/task.c:2109:11
#4 create_managers bin/named/./main.c:886:11
#5 setup bin/named/./main.c:1305:11
#6 main bin/named/./main.c:1556:2
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:60:8
#2 isc__taskmgr_create lib/isc/task.c:1468:7
#3 isc_taskmgr_create lib/isc/task.c:2109:11
#4 create_managers bin/named/./main.c:886:11
#5 setup bin/named/./main.c:1305:11
#6 main bin/named/./main.c:1556:2
Thread T3 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:60:8
#2 isc__taskmgr_create lib/isc/task.c:1468:7
#3 isc_taskmgr_create lib/isc/task.c:2109:11
#4 create_managers bin/named/./main.c:886:11
#5 setup bin/named/./main.c:1305:11
#6 main bin/named/./main.c:1556:2
SUMMARY: ThreadSanitizer: data race lib/dns/zone.c:10272:7 in zone_maintenance
```
There's this similar TSAN on `v9_11`: https://gitlab.isc.org/isc-projects/bind9/-/issues/2261.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2581"INSIST(oldsize == size);" assertion fails (down the call stack) for tls_writ...2021-03-29T13:16:03ZMichał Kępień"INSIST(oldsize == size);" assertion fails (down the call stack) for tls_write_cb()This is a new crash which was first observed on FreeBSD VMs in [pipeline
#66473][1]:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1575006
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1575007
However, it looks like somet...This is a new crash which was first observed on FreeBSD VMs in [pipeline
#66473][1]:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1575006
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1575007
However, it looks like something that was introduced earlier than in
commit 24c796942f53aefcd5929d820ee09b01f28ee827:
```
I:doth:ns1 died before a SIGTERM was sent
I:doth:stopping servers failed
I:doth:Core dump(s) found: doth/ns1/core.46383
D:doth:backtrace from doth/ns1/core.46383:
D:doth:--------------------------------------------------------------------------------
D:doth:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D doth-ns1 -X named.lock -m re'.
D:doth:Program terminated with signal SIGABRT, Aborted.
D:doth:#0 0x000000080100cc2a in thr_kill () from /lib/libc.so.7
D:doth:[Current thread is 1 (LWP 100126)]
D:doth:#0 0x000000080100cc2a in thr_kill () from /lib/libc.so.7
D:doth:#1 0x000000080100b084 in raise () from /lib/libc.so.7
D:doth:#2 0x0000000800f81279 in abort () from /lib/libc.so.7
D:doth:#3 0x000000000023b122 in assertion_failed (file=<optimized out>, line=<optimized out>, type=isc_assertiontype_insist, cond=<optimized out>) at main.c:259
D:doth:#4 0x000000080032e6ca in isc_assertion_failed (file=0x1871e <error: Cannot access memory at address 0x1871e>, line=6, type=isc_assertiontype_require, cond=0x80100cc4a <thr_self+10> "\017\202\264G") at assertions.c:46
D:doth:#5 0x000000080033ca98 in isc__mem_put (ctx=0x801a05000, ptr=0x804c60010, size=6453, file=<optimized out>, line=0) at mem.c:775
D:doth:#6 0x00000008003179c6 in free_senddata (sock=<optimized out>) at netmgr/tlsdns.c:1295
D:doth:#7 0x0000000800317a50 in tls_write_cb (req=<optimized out>, status=0) at netmgr/tlsdns.c:1307
D:doth:#8 0x0000000800c1b065 in ?? () from /usr/local/lib/libuv.so.1
D:doth:#9 0x0000000800c1a92a in ?? () from /usr/local/lib/libuv.so.1
D:doth:#10 0x0000000800c2112b in uv.io_poll () from /usr/local/lib/libuv.so.1
D:doth:#11 0x0000000800c10551 in uv_run () from /usr/local/lib/libuv.so.1
D:doth:#12 0x000000080030771b in nm_thread (worker0=0x8013b0010) at netmgr/netmgr.c:553
D:doth:#13 0x000000080034dde5 in isc__trampoline_run (arg=0x8013f4d60) at trampoline.c:184
D:doth:#14 0x0000000800e37fac in ?? () from /lib/libthr.so.3
D:doth:#15 0x0000000000000000 in ?? ()
D:doth:Backtrace stopped: Cannot access memory at address 0x7fffdfffe000
D:doth:--------------------------------------------------------------------------------
D:doth:full backtrace from doth/ns1/core.46383 saved in doth/ns1/core.46383-backtrace.txt
D:doth:core dump doth/ns1/core.46383 archived as doth/ns1/core.46383.gz
R:doth:FAIL
```
The `INSIST` that fails is: `INSIST(oldsize == size);`
@artem, any ideas?
[1]: https://gitlab.isc.org/isc-projects/bind9/-/pipelines/66473April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2580Does not compile without deprecated OpenSSL APIs2021-03-29T12:37:05ZRosen PenevDoes not compile without deprecated OpenSSL APIsSince it seems I can't make merge requests, here's a patch:
```
--- a/lib/isc/tls.c
+++ b/lib/isc/tls.c
@@ -9,8 +9,10 @@
* information regarding copyright ownership.
*/
+#include <openssl/bn.h>
#include <openssl/err.h>
#include <...Since it seems I can't make merge requests, here's a patch:
```
--- a/lib/isc/tls.c
+++ b/lib/isc/tls.c
@@ -9,8 +9,10 @@
* information regarding copyright ownership.
*/
+#include <openssl/bn.h>
#include <openssl/err.h>
#include <openssl/opensslv.h>
+#include <openssl/rsa.h>
#include <isc/atomic.h>
#include <isc/log.h>
@@ -220,11 +222,11 @@ isc_tlsctx_createserver(const char *keyfile, const char *certfile,
rsa = NULL;
ASN1_INTEGER_set(X509_get_serialNumber(cert), 1);
- X509_gmtime_adj(X509_get_notBefore(cert), 0);
+ X509_gmtime_adj(X509_getm_notBefore(cert), 0);
/*
* We set the vailidy for 10 years.
*/
- X509_gmtime_adj(X509_get_notAfter(cert), 3650 * 24 * 3600);
+ X509_gmtime_adj(X509_getm_notAfter(cert), 3650 * 24 * 3600);
X509_set_pubkey(cert, pkey);
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2579Hung unit tests are never terminated2021-04-07T09:46:42ZMichał KępieńHung unit tests are never terminatedWhen Kyua is used for running unit tests (which is the case for BIND
versions older than 9.17), it enforces a default 5-minute run time limit
on every binary it executes. This prevents hung unit tests from
sticking around until the GitL...When Kyua is used for running unit tests (which is the case for BIND
versions older than 9.17), it enforces a default 5-minute run time limit
on every binary it executes. This prevents hung unit tests from
sticking around until the GitLab CI job run time limit is exceeded.
As use of Kyua was dropped in BIND 9.17, hung unit tests run for the
`main` branch are never terminated until the whole GitLab CI job is torn
down due its run time limit being exceeded. Furthermore, it is not easy
to tell *which* unit test hung in a given GitLab CI job without
post-processing its log. Example:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1562799
(In this case, it was `lib/isc/tests/tlsdns_test` that hung.)
The `lib/unit-test-drivers.sh` unit test driver should be extended to
terminate uncooperative unit test binaries in a timely fashion.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2578System test setup sometimes fails because of missing port assignments2021-04-08T09:37:53ZMichał KępieńSystem test setup sometimes fails because of missing port assignmentsExample test job failures:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1505564
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1505566
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1505642
- https://gitlab.isc.org...Example test job failures:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1505564
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1505566
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1505642
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1505647
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1506024
The problem here is that:
- the [sleep period][1] in case of failure to acquire the
`bin/tests/system/get_ports.lock` lock file is fixed, which leads to
a "thundering herd" type of problem, where (depending on how
processes are scheduled by the operating system) multiple system
tests try to acquire the lock file at the same time and subsequently
sleep for 1 second, only for the same situation to likely happen the
next time around,
- the lock file is being locked and then unlocked for every single
_port_ assignment made, not just once for the entire _range_ of
ports a system test should use; in other words, the lock file is
currently locked and unlocked 13 times per system test.
Given the above, in certain cases, with the [retry count][2] set to 10
attempts and up to 6 system tests being run [in parallel][3] in every
GitLab CI job, a given system test may simply not manage to acquire the
lock file before it reaches the retry limit. This is what happened in
all the jobs linked to above (search for `PORTS:,` in the job logs).
Another (arguably less severe) problem with this design is that it
results in delayed test startup when multiple system tests are started
in parallel using `make -jX check` (also due to the lock file contention
issue described above). Here are some sample timings produced with a
version of `bin/tests/system/run.sh` which only runs
`bin/tests/system/get_ports.sh` and then immediately exits (without
running any `setup.sh` or `tests.sh` script):
```sh
$ time make -C bin/tests/system/ -j6 check TESTS="acl"
...
real 0m0,248s
user 0m0,217s
sys 0m0,054s
$ time make -C bin/tests/system/ -j6 check TESTS="acl additional"
...
real 0m1,294s
user 0m0,345s
sys 0m0,061s
$ time make -C bin/tests/system/ -j6 check TESTS="acl additional addzone"
...
real 0m2,327s
user 0m0,458s
sys 0m0,126s
$ time make -C bin/tests/system/ -j6 check TESTS="acl additional addzone allow-query"
...
real 0m3,312s
user 0m0,605s
sys 0m0,164s
$ time make -C bin/tests/system/ -j6 check TESTS="acl additional addzone allow-query auth"
...
real 0m4,327s
user 0m0,754s
sys 0m0,207s
$ time make -C bin/tests/system/ -j6 check TESTS="acl additional addzone allow-query auth autosign"
...
real 0m5,352s
user 0m0,859s
sys 0m0,274s
$ time make -C bin/tests/system/ -j6 check TESTS="acl additional addzone allow-query auth autosign builtin"
...
real 0m5,343s
user 0m0,941s
sys 0m0,259s
$ time make -C bin/tests/system/ -j6 check TESTS="acl additional addzone allow-query auth autosign builtin cacheclean"
...
real 0m5,384s
user 0m1,053s
sys 0m0,276s
```
What this shows is that it takes almost 6 seconds to actually start all
of the requested 6 tests in parallel. This initial "problem" resolves
itself shortly afterwards, though, as the started tests take various
amounts of time to finish and thus the lock file contention issue
mostly disappears for tests started later on.
It would be nice to come up with a version of the `get_ports.sh` script
which does not suffer from the above issues.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/8795b12c49d3f2f5c9c5254cbf2532a4f230f0cc/bin/tests/system/get_ports.sh#L58
[2]: https://gitlab.isc.org/isc-projects/bind9/-/blob/8795b12c49d3f2f5c9c5254cbf2532a4f230f0cc/bin/tests/system/get_ports.sh#L27
[3]: https://gitlab.isc.org/isc-projects/bind9/-/blob/8795b12c49d3f2f5c9c5254cbf2532a4f230f0cc/.gitlab-ci.yml#L13April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2569nsupdate on Solaris produces different failure text than expected2021-03-29T12:22:12ZMichal Nowaknsupdate on Solaris produces different failure text than expectedThe `nsupdate` system test fails on Solaris 11.4 because `nsupdate` fails with "failure" where "not found" is expected:
```
I:nsupdate:ensure unresolvable server name is fatal in non-interactive mode (40)
couldn't get address for 'unreso...The `nsupdate` system test fails on Solaris 11.4 because `nsupdate` fails with "failure" where "not found" is expected:
```
I:nsupdate:ensure unresolvable server name is fatal in non-interactive mode (40)
couldn't get address for 'unresolvable..': failure
syntax error
I:nsupdate:failed
I:nsupdate:ensure unresolvable server name is not fatal in interactive mode (41)
couldn't get address for 'unresolvable..': failure
I:nsupdate:failed
```
```shell
n=`expr $n + 1`
ret=0
echo_i "ensure unresolvable server name is fatal in non-interactive mode ($n)"
$NSUPDATE <<END > nsupdate.out 2>&1 && ret=1
server unresolvable..
END
cat nsupdate.out
grep "couldn't get address for 'unresolvable..': not found" nsupdate.out > /dev/null || ret=1
grep "syntax error" nsupdate.out > /dev/null || ret=1
[ $ret = 0 ] || { echo_i "failed"; status=1; }
n=`expr $n + 1`
ret=0
echo_i "ensure unresolvable server name is not fatal in interactive mode ($n)"
$NSUPDATE -i <<END > nsupdate.out 2>&1 || ret=1
server unresolvable..
END
cat nsupdate.out
grep "couldn't get address for 'unresolvable..': not found" nsupdate.out > /dev/null || ret=1
[ $ret = 0 ] || { echo_i "failed"; status=1; }
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)