BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-07-31T13:33:24Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2395Stress test: server received an unknown number of TCP queries2023-07-31T13:33:24ZMichal NowakStress test: server received an unknown number of TCP queriesAfter Flamethrower [was updated](https://gitlab.isc.org/isc-private/bind-qa/-/merge_requests/30) to v0.11 on FreeBSD, `v9_11` stress tests [fail](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1413628) with:
```
2021-01-19:05:36:52 INF...After Flamethrower [was updated](https://gitlab.isc.org/isc-private/bind-qa/-/merge_requests/30) to v0.11 on FreeBSD, `v9_11` stress tests [fail](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1413628) with:
```
2021-01-19:05:36:52 INFO: Server 'ns2' (authoritative) received an unknown number of TCP queries
2021-01-19:05:36:52 INFO: About 21,600,000 TCP queries were expected
2021-01-19:05:36:52 INFO: Minimum number of TCP queries required to pass is 19,440,000
2021-01-19:05:36:52 ERROR: BIND did not process enough TCP queries
stress.sh: line 675: queries_received + : syntax error: operand expected (error token is "+ ")
```
`v9_16` stress test jobs are not affected: https://gitlab.isc.org/isc-projects/bind9/-/jobs/1413723.
`main` is pending: https://gitlab.isc.org/isc-projects/bind9/-/pipelines/61487.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2375dnssec-policy key rollover bug when more than two keys are involved2023-07-06T09:26:15ZMatthijs Mekkingmatthijs@isc.orgdnssec-policy key rollover bug when more than two keys are involved### Summary
When using `dnssec-policy`, key rollovers are scheduled automatically. If a key rollover is halted (because for example the DS was never uploaded), and a new key is introduced to replace the previous successor, at some point...### Summary
When using `dnssec-policy`, key rollovers are scheduled automatically. If a key rollover is halted (because for example the DS was never uploaded), and a new key is introduced to replace the previous successor, at some point `dnssec-policy` decides that having only the new key is a valid state, removing the two previous keys. This moves the zone into a bogus state, where the DS
in the parent mismatches the DNSKEY RRset in the child zone.
### BIND version used
9.16.9
### Steps to reproduce
Create a `dnssec-policy` with quick rollovers, wait until the third key is introduced, and then some more. At some point the keymgr decides to remove the first two keys.
### What is the current *bug* behavior?
The first two keys are removed from the zone too soon.
### What is the expected *correct* behavior?
All three keys should stay in the zone, until a valid `rndc dnssec -checkds` command is issued.
### Relevant configuration files
```
///
/// 20201209 DST, BIND 9.16 dnssec policy test
///
dnssec-policy "test" {
// Keys
keys {
csk key-directory lifetime 7d algorithm 13;
};
// Key timings
dnskey-ttl 3600;
publish-safety 1h;
retire-safety 1h;
// Zone parameters
max-zone-ttl 3600;
zone-propagation-delay 300;
// Parent parameters
parent-ds-ttl 1h;
parent-propagation-delay 1h;
};
zone "badware.ch" {
type master;
dnssec-policy test;
key-directory "/etc/bind/inline-signing-keys";
file "dynamic/badware.ch";
};
```
### Relevant logs and/or screenshots
https://dnsviz.net/d/badware.ch/X-MRAg/dnssec/
### Possible fixesFebruary 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2354[CVE-2020-8625] ZDI-CAN-12302: ISC BIND TKEY Query Heap-based Buffer Overflow...2023-06-19T09:07:00ZCathy Almond[CVE-2020-8625] ZDI-CAN-12302: ISC BIND TKEY Query Heap-based Buffer Overflow Remote Code Execution Vulnerability### CVE-specific actions
- [x] Assign a CVE identifier
- [x] Determine CVSS score
- [x] Determine the range of BIND versions affected (including the Subscription Edition)
- [x] Determine whether workarounds for the problem exist...### CVE-specific actions
- [x] Assign a CVE identifier
- [x] Determine CVSS score
- [x] Determine the range of BIND versions affected (including the Subscription Edition)
- [x] Determine whether workarounds for the problem exists
- [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)
- explanation of code flow which triggers the problem (a system test is *not* good enough)
- [x] Prepare a private merge request containing the following items in separate commits:
- 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, 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: isc-private/bind9#34
- [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
---
As reported to ISC Security Officer:
ZDI-CAN-12302: ISC BIND TKEY Query Heap-based Buffer Overflow Remote Code Execution Vulnerability
-- 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.9
* Installer file:bind-9.16.9.tar.xz
* Platform tested:ubuntu 20.04.1 desktop edition
---
### Analysis
```
the bug is CVE-2006-5989, ISC did not merge the patch
https://bugzilla.redhat.com/show_bug.cgi?id=206736
it leads to heap overflow off-by-4
it affected the latest Current-Stable, 9.16.9
it require the tkey-gssapi-keytab config in named.conf
```
~~~C++
static int
der_get_oid(const unsigned char *p, size_t len, oid *data, size_t *size) {
...
data->components = malloc(len * sizeof(*data->components));
if (data->components == NULL) {
return (ENOMEM);
}
data->components[0] = (*p) / 40;
data->components[1] = (*p) % 40; <--- (1) two element is written
--len; <--- (2) but len is plus one only
++p;
for (n = 2; len > 0U; ++n) {
unsigned u = 0;
do {
--len;
u = u * 128 + (*p++ % 128);
} while (len > 0U && p[-1] & 0x80);
data->components[n] = u; <--- (3) off-by-4
}
...
return (0);
}
~~~
debug log
```
(gdb) b *0x18E27E+0x7fb83fd83000
Breakpoint 1 at 0x7fb83ff1127e
(gdb) b *0x18E309+0x7fb83fd83000
Breakpoint 2 at 0x7fb83ff11309
(gdb) c
Continuing.
[Switching to Thread 0x7fb83d1f8700 (LWP 77138)]
Thread 2 "isc-net-0000" hit Breakpoint 1, 0x00007fb83ff1127e in ?? () from /lib/x86_64-linux-gnu/libdns.so.1601
(gdb) x/i $pc
=> 0x7fb83ff1127e: call 0x7fb83fdab5d0 <malloc@plt>
(gdb) i r $rdi
rdi 0x28 40
(gdb) ni
0x00007fb83ff11283 in ?? () from /lib/x86_64-linux-gnu/libdns.so.1601
(gdb) x/30xg $rax-0x10
0x7fb82c0164b0: 0x0000000000000000 0x0000000000000035
0x7fb82c0164c0: 0x00007fb82c016650 0x0000000000000000
0x7fb82c0164d0: 0x0000000000000000 0x0000000000000000
0x7fb82c0164e0: 0x0000000000000000 0x0000000000000025
0x7fb82c0164f0: 0x00007fb82c016230 0x00007fb83f55fc20
0x7fb82c016500: 0x0000000000000000 0x0000000000000025
0x7fb82c016510: 0x00007fb82c016530 0x00007fb82c0008d0
0x7fb82c016520: 0x0000000000000000 0x0000000000000025
0x7fb82c016530: 0x0000000000000000 0x00007fb82c0008d0
0x7fb82c016540: 0x0000000000000000 0x00000000000000b5
0x7fb82c016550: 0x00007fb82c015120 0x00007fb82c0008d0
0x7fb82c016560: 0x0000000000000000 0x00000000ffffffff
0x7fb82c016570: 0x0000000000000000 0x0000000000000000
0x7fb82c016580: 0x0000000000000000 0x0000000000000000
0x7fb82c016590: 0x0000000000000000 0x0000000000000000
(gdb) c
Continuing.
Thread 2 "isc-net-0000" hit Breakpoint 2, 0x00007fb83ff11309 in ?? () from /lib/x86_64-linux-gnu/libdns.so.1601
(gdb) x/i $pc
=> 0x7fb83ff11309: mov DWORD PTR [rax+rcx*4],edi // overwrite next chunk header
(gdb) x/xg $rax+$rcx*4
0x7fb82c0164e8: 0x0000000000000025
(gdb) bt
#0 0x00007fb83ff11309 in ?? () from /lib/x86_64-linux-gnu/libdns.so.1601
#1 0x00007fb83ff1144a in ?? () from /lib/x86_64-linux-gnu/libdns.so.1601
#2 0x00007fb83ff11a2d in gss_accept_sec_context_spnego () from /lib/x86_64-linux-gnu/libdns.so.1601
#3 0x00007fb83ff1d083 in dst_gssapi_acceptctx () from /lib/x86_64-linux-gnu/libdns.so.1601
#4 0x00007fb83feb65cd in dns_tkey_processquery () from /lib/x86_64-linux-gnu/libdns.so.1601
#5 0x00007fb83ffcf27f in ns_query_start () from /lib/x86_64-linux-gnu/libns.so.1601
#6 0x00007fb83ffb2131 in ns.client_request () from /lib/x86_64-linux-gnu/libns.so.1601
#7 0x00007fb83fce2b26 in ?? () from /lib/x86_64-linux-gnu/libisc.so.1601
#8 0x00007fb83fce33cd in ?? () from /lib/x86_64-linux-gnu/libisc.so.1601
#9 0x00007fb83fcdf74c in ?? () from /lib/x86_64-linux-gnu/libisc.so.1601
#10 0x00007fb83f470b01 in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
#11 0x00007fb83f471638 in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
#12 0x00007fb83f476ae0 in uv.io_poll () from /lib/x86_64-linux-gnu/libuv.so.1
#13 0x00007fb83f4667ac in uv_run () from /lib/x86_64-linux-gnu/libuv.so.1
#14 0x00007fb83fcdec2d in ?? () from /lib/x86_64-linux-gnu/libisc.so.1601
#15 0x00007fb83f7b4609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#16 0x00007fb83f6d5293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) c
Continuing.
Thread 3 "isc-net-0001" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fb83c8b6700 (LWP 77139)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb)
```
-- CREDIT ---------------------------------------
This vulnerability was discovered by:
Anonymous working with Trend Micro Zero Day InitiativeFebruary 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/2434Serve stale when fetch limits are hit2023-05-25T10:49:28ZMatthijs Mekkingmatthijs@isc.orgServe stale when fetch limits are hitSee also #2066 and #2303
Serve stale has been improved a lot by updating configuration defaults, adding options `stale-refresh-time` and `stale-answer-client-timeout`. Basically there are now two modes:
1. Resolve the query, fallback ...See also #2066 and #2303
Serve stale has been improved a lot by updating configuration defaults, adding options `stale-refresh-time` and `stale-answer-client-timeout`. Basically there are now two modes:
1. Resolve the query, fallback to stale data (`stale-answer-client-timeout` disabled or positive value).
2. Prefer stale data in cache, then refresh the data in cache (`stale-answer-client-timeout 0`).
In case 1, BIND will still not return stale data to the client when fetch limits are hit. This is an indication that the upstream (forwarder, or authoritative server) are under attack, and chances are slim we will get a useful response. In this case, we should also return stale data.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2365Use of "statistics-channel" appears to cause a memory leak.2023-04-04T14:17:01ZBunny EvansUse of "statistics-channel" appears to cause a memory leak.### Summary
Telegraf pointing at bind 9.11 (or 9.16) observes a continuous memory increase.
### BIND version used
BIND 9.11.26 (Extended Support Version) <id:3ff8620>
running on FreeBSD amd64 12.2-RELEASE-p1 FreeBSD 12.2-RELEASE-p1 GE...### Summary
Telegraf pointing at bind 9.11 (or 9.16) observes a continuous memory increase.
### BIND version used
BIND 9.11.26 (Extended Support Version) <id:3ff8620>
running on FreeBSD amd64 12.2-RELEASE-p1 FreeBSD 12.2-RELEASE-p1 GENERIC
The same applies with 9.16.9/10
### Steps to reproduce
Enable statistics channels. In this case:
statistics-channels {
inet 10.0.0.8 port 8053 allow { 10.0.0.0/24; };
inet 127.0.0.1 port 8053 allow { 127.0.0.1; };
};
Add telegraf to the mix (as per https://github.com/influxdata/telegraf/blob/release-1.14/plugins/inputs/bind/README.md )
[inputs.bind]
urls = ["http://localhost:8053/xml/v3"]
gather_memory_contexts = false
gather_views = true
(this leak appears independent of /xml/v3 or /json/v1 )
### What is the current *bug* behavior?
Memory grows at about 230 kB / minute with 9.11
I think it was around 2 MB / minute with 9.16
9.16.9, 6 days, grew to 19 GB.
9.16.9, 7 days, grew to 22 GB.
9.16.10, 4 days, grew to 11 GB.
9.11.26, 4 days, grew to 2 GB.
It has not yet run to the point of crashing.
Accessing the web interface version causes an approximate 2MB jump in "Total Memory" But that goes
away after a minute or so.
### What is the expected *correct* behavior?
To be able to run for weeks without growing endlessly.
### Relevant configuration files
### Relevant logs and/or screenshots
when run with "-m report" memstats file contains:
Dump of all outstanding memory allocations:
None.
![Screenshot_2020-12-29_161432](/uploads/020d4cc4db08943152b716f9493601b2/Screenshot_2020-12-29_161432.png)
![Screenshot_2020-12-29_163417](/uploads/efbbcc9eb19322d408834d4a1ff535eb/Screenshot_2020-12-29_163417.png)
### Possible fixes
The code, while awesome, is beyond my ability to grok.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2448Sphinx-generated documentation built in GitLab CI is sometimes defective2022-08-05T11:42:43ZMichał KępieńSphinx-generated documentation built in GitLab CI is sometimes defective@pspacek noticed that the latest PDF version of the BIND 9 ARM is
missing the entire "BIND 9 Configuration Reference" chapter:
https://ftp.isc.org/isc/bind9/9.17.9/doc/arm/Bv9ARM.pdf
The same problem seems to be affecting the PDF for 9...@pspacek noticed that the latest PDF version of the BIND 9 ARM is
missing the entire "BIND 9 Configuration Reference" chapter:
https://ftp.isc.org/isc/bind9/9.17.9/doc/arm/Bv9ARM.pdf
The same problem seems to be affecting the PDF for 9.17.8:
https://ftp.isc.org/isc/bind9/9.17.8/doc/arm/Bv9ARM.pdf
but not for 9.17.7:
https://ftp.isc.org/isc/bind9/9.17.7/doc/arm/Bv9ARM.pdf
None of the 9.16.x PDFs seem to be broken this way.
I could not reproduce this problem locally and also confirmed there were
no changes in the `doc/` directory between 9.17.7 and 9.17.8 that could
have caused this. Upon further investigation, I discovered that the
problem is caused by using parallel `make` jobs (`-j`) when running
`make doc` in GitLab CI - this causes multiple `sphinx-build` instances
to run simultaneously in the same working directory, which means they
can stomp on each other's data. Unfortunately, problems like this only
triggered Sphinx warnings, not errors, so the relevant GitLab CI jobs
have been silently passing.
~~This conclusion means that *all* forms of our documentation might have
been malformed in one way or another ever since we migrated to Sphinx,
i.e. since May 2020 (see !1761, !3536). Looking at GitLab CI job traces
from the past 2 months, it can be estimated that the problem has a
roughly 15% chance of getting triggered for any Sphinx documentation
build job.~~ (See correction [below][1].)
[1]: #note_190871February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2403dig has a fit with option -multi (typo on +multi)2022-04-26T13:16:36ZJP Mensdig has a fit with option -multi (typo on +multi)### Summary
`dig` crashes when erroneously given option `-multi`
During a training, a student (Rob) erroneously specified `-multi` instead of `+multi` when using `dig` on an internal training domain. This was using `bind-utils-9.11.20-...### Summary
`dig` crashes when erroneously given option `-multi`
During a training, a student (Rob) erroneously specified `-multi` instead of `+multi` when using `dig` on an internal training domain. This was using `bind-utils-9.11.20-5.el8.x86_64` on CentOS 8.
I am able to reproduce this on a similar machine with an ISC COPR release.
### BIND version used
```
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on Linux x86_64 4.18.0-240.1.1.el8_3.x86_64 #1 SMP Thu Nov 19 17:20:08 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr' '--exec-prefix=/opt/isc/isc-bind/root/usr' '--bindir=/opt/isc/isc-bind/root/usr/bin' '--sbindir=/opt/isc/isc-bind/root/usr/sbin' '--sysconfdir=/etc/opt/isc/scls/isc-bind' '--datadir=/opt/isc/isc-bind/root/usr/share' '--includedir=/opt/isc/isc-bind/root/usr/include' '--libdir=/opt/isc/isc-bind/root/usr/lib64' '--libexecdir=/opt/isc/isc-bind/root/usr/libexec' '--localstatedir=/var/opt/isc/scls/isc-bind' '--sharedstatedir=/var/opt/isc/scls/isc-bind/lib' '--mandir=/opt/isc/isc-bind/root/usr/share/man' '--infodir=/opt/isc/isc-bind/root/usr/share/info' '--disable-static' '--enable-dnstap' '--with-pic' '--with-gssapi' '--with-json-c' '--with-libtool' '--with-libxml2' '--without-lmdb' '--with-python' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/opt/isc/isc-bind/root/usr/lib64' 'LT_SYS_LIBRARY_PATH=/usr/lib64' 'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig' 'SPHINX_BUILD=/builddir/build/BUILD/bind-9.16.11/sphinx/bin/sphinx-build'
compiled by GCC 8.3.1 20191121 (Red Hat 8.3.1-5)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
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
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
default paths:
named configuration: /etc/opt/isc/scls/isc-bind/named.conf
rndc configuration: /etc/opt/isc/scls/isc-bind/rndc.conf
DNSSEC root key: /etc/opt/isc/scls/isc-bind/bind.keys
nsupdate session key: /var/opt/isc/scls/isc-bind/run/named/session.key
named PID file: /var/opt/isc/scls/isc-bind/run/named/named.pid
named lock file: /var/opt/isc/scls/isc-bind/run/named/named.lock
```
### Steps to reproduce
```
/opt/isc/isc-bind/root/bin/dig isc.org -multi
```
### What is the current *bug* behavior?
```console
$ /opt/isc/isc-bind/root/bin/dig isc.org -multi
add 0x55a9501c2160 size 8528 file log.c line 257 mctx 0x55a9501b53e0
add 0x7fd9d72c6010 size 72 file log.c line 306 mctx 0x55a9501b53e0
add 0x7fd9d72c7010 size 80 file log.c line 665 mctx 0x55a9501b53e0
add 0x7fd9d72c8018 size 23 file log.c line 667 mctx 0x55a9501b53e0
add 0x7fd9d72c7060 size 80 file log.c line 665 mctx 0x55a9501b53e0
add 0x7fd9d72c8030 size 23 file log.c line 667 mctx 0x55a9501b53e0
add 0x7fd9d72c70b0 size 80 file log.c line 665 mctx 0x55a9501b53e0
add 0x7fd9d72c8048 size 22 file log.c line 667 mctx 0x55a9501b53e0
add 0x7fd9d72c7100 size 80 file log.c line 665 mctx 0x55a9501b53e0
add 0x7fd9d72c9008 size 13 file log.c line 667 mctx 0x55a9501b53e0
add 0x7fd9d72c9010 size 32 file log.c line 996 mctx 0x55a9501b53e0
add 0x7fd9d72ca010 size 336 file log.c line 996 mctx 0x55a9501b53e0
del 0x7fd9d72c9010 size 32 file log.c line 1004 mctx 0x55a9501b53e0
add 0x7fd9d72c9010 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9030 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9050 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9070 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9090 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9090 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c90b0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c90d0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c90f0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9110 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9130 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9150 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9170 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9190 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c91b0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c91d0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c91f0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9210 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9230 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9250 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9270 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9290 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72cb010 size 288 file task.c line 1386 mctx 0x55a9501b53e0
add 0x7fd9d72cc010 size 144 file task.c line 1410 mctx 0x55a9501b53e0
add 0x7fd9d72cd010 size 216 file task.c line 286 mctx 0x55a9501b53e0
add 0x7fd9d72ce010 size 160 file timer.c line 697 mctx 0x55a9501b53e0
add 0x7fd9d72cf010 size 56 file heap.c line 87 mctx 0x55a9501b53e0
add 0x7fd9d72d0010 size 168 file socket.c line 3806 mctx 0x55a9501b53e0
add 0x7fd9d72c7150 size 80 file socket.c line 3827 mctx 0x55a9501b53e0
add 0x7fd9d729c010 size 168000 file socket.c line 3578 mctx 0x55a9501b53e0
add 0x55a9501c7ce0 size 84000 file socket.c line 3584 mctx 0x55a9501b53e0
add 0x55a9501dc550 size 40960 file socket.c line 3589 mctx 0x55a9501b53e0
add 0x55a9501e65a0 size 84000 file socket.c line 3631 mctx 0x55a9501b53e0
add 0x55a9501fae10 size 24576 file socket.c line 3638 mctx 0x55a9501b53e0
add 0x7fd9d72cefb0 size 96 file mem.c line 1607 mctx 0x55a9501b53e0
add 0x55a95021a170 size 2464 file resconf.c line 522 mctx 0x55a9501b53e0
add 0x7fd9d72d1010 size 152 file resconf.c line 239 mctx 0x55a9501b53e0
add 0x7fd9d72d10a8 size 152 file resconf.c line 239 mctx 0x55a9501b53e0
add 0x55a950220418 size 2072 file dighost.c line 487 mctx 0x55a9501b53e0
add 0x55a950220418 size 2072 file dighost.c line 487 mctx 0x55a9501b53e0
add 0x55a950220c38 size 2072 file dighost.c line 487 mctx 0x55a9501b53e0
del 0x7fd9d72d1010 size 152 file resconf.c line 652 mctx 0x55a9501b53e0
del 0x7fd9d72d10a8 size 152 file resconf.c line 652 mctx 0x55a9501b53e0
del 0x55a95021a170 size 2464 file resconf.c line 665 mctx 0x55a9501b53e0
add 0x55a950221458 size 5176 file dighost.c line 618 mctx 0x55a9501b53e0
add 0x55a950222898 size 5176 file dighost.c line 618 mctx 0x55a9501b53e0
Invalid option: -lti
Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt}
{global-d-opt} host [@local-server] {local-d-opt}
[ host [@local-server] {local-d-opt} [...]]
Use "dig -h" (or "dig -h | more") for complete list of options
```
### What is the expected *correct* behavior?
```
Invalid option: -lti
Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt}
{global-d-opt} host [@local-server] {local-d-opt}
[ host [@local-server] {local-d-opt} [...]]
Use "dig -h" (or "dig -h | more") for complete list of options
```
### Relevant configuration files
### Relevant logs and/or screenshots
### Possible fixesFebruary 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/1086Reduce the number of "bad configuration options" flags2022-01-21T13:45:13ZMatthijs Mekkingmatthijs@isc.orgReduce the number of "bad configuration options" flagstl;dr:
1. Reduce the number of bad option flags.
2. Print a warning when an option is flagged `experimental`.
3. Do something about the non-operational flags `test only` and `default changed`
There is a subtle difference between unsupp...tl;dr:
1. Reduce the number of bad option flags.
2. Print a warning when an option is flagged `experimental`.
3. Do something about the non-operational flags `test only` and `default changed`
There is a subtle difference between unsupported configuration options:
- `ancient`: these are options that existed in 9.8 but removed in 9.9. Having them in named.conf is a configuration error, causing named to exit on startup.
- `obsoleted`: these are options that no longer do anything, and should be removed from the configuration file, but is not a configuration error. Having these options in named.conf will log a warning that says the option is obsoleted and should be removed.
- `deprecated`: these are options that still work but are deprecated. They will no longer be supported and you should use the newer configuration options. They will still work, and configuring them will trigger the expected behavior, but these options will be removed in a future version.
- `not implemented`: These options are not implemented but do have a option name assigned.
- `not yet implemented`: These options are not yet implemented but do have a option name assigned.
- `not operational`: These options only do something if at compile time the feature was enabled, otherwise they are ignored.
- `not configured`: These options are only allowed if at compile time the feature was enabled, otherwise having them in named.conf is a configuration error.
- Then there are the options that have no special handling, these are "unknown". They are a configuration error and cause named to exit at startup.
Below are the list of options that fall in one of these categories.
Let's reduce the number of options to the following:
- "unknown": Any option that is not supported and will result in a configuration error does not need a special flag. When encountering such an option, named will log that it encountered an "unknown option". Includes all `ancient` options.
- `ancient`: These options are treated the same way as the unknown options, except it tells the operator and implementer the option was in use in the past.
- `obsoleted`: This option does nothing and having them in your configuration file is a noop. The option may be removed in the future. This includes not (yet) implemented options. `not implemented` and `not yet implemented` options will be treated similar as `obsoleted` (the idea being that if an option is implemented it should be functional`).
- `deprecated`: This option still works, but should be removed because the option may be removed in the future.
- `not configured`: These options are only allowed if their feature is enabled at compile time. Having them in your named.conf otherwise is a configuration error. `not operational` is promoted to `not configured`.
In addition to these bad configuration options there is also difference between good options:
- The normal options that do not require any special processing or logging.
- `multiple`: This option is the same as normal options but may appear multiple times.
- `experimental`: Experimental options that (currently) are treated as normal options.
- `default changed`: This tells the user that if the configuration option is not present, the default has changed.
- `test only`: This option is for testing purposes only.
Experimental options should also trigger a log warning.
We may want to do something about the broken `default changed` and `test only` options.
# Ancient options
| option | clause |
| ------ | ------ |
| deallocate-on-exit | options |
| fake-iquery | options |
| has-old-clients | options |
| host-statistics | options |
| host-statistics-max | options |
| multiple-cnames | options |
| named-xfer | options |
| serial-queries | options |
| statistics-interval | options |
| treat-cr-as-space | options |
| use-id-pool | options |
| fetch-glue | view |
| min-roots | view |
| rfc2308-type1 | view |
| topology | view |
| maintain-ixfr-base | zone |
| max-ixfr-log-size | zone |
| ixfr-base | zone |
| ixfr-tmp-file | zone |
| pubkey | zone |
# Obsoleted options
| option | clause |
| ------ | ------ |
| lwres | top |
| geoip-use-ecs | options |
| sit-secret | options |
| use-ixfr | options |
| acache-cleaning-interval | view |
| acache-enable | view |
| additional-from-auth | view |
| additional-from-cache | view |
| allow-v6-synthesis | view |
| cleaning-interval | view |
| dnssec-enable | view |
| filter-aaaa | view |
| filter-aaaa-on-v4 | view |
| filter-aaaa-on-v6 | view |
| max-acache-size | view |
| nosit-udp-size | view |
| queryport-pool-ports | view |
| queryport-pool-updateinterval | view |
| request-sit | view, server |
| use-queryport-pool | view |
| support-ixfr | server |
# Deprecated options
| option | clause |
| ------ | ------ |
| managed-keys | top, view, bind.keys |
| trusted-keys | top, view, bind.keys |
# Not implemented
None.
# Not yet implemented
| option | clause |
| ------ | ------ |
| suppress-initial-notify | view |
# Not operational
| option | clause | feature |
| ------ | ------ | ------- |
| lmdb-mapsize | view | lmdb |
# Not configured
| option | clause | feature |
| ------ | ------ | ------- |
| dnstap-output | options | dnstap |
| dnstap-identity | options | dnstap |
| dnstap-version | options | dnstap |
| fstrm-set-buffer-hint | options | dnstap |
| fstrm-set-flush-timeout | options | dnstap |
| fstrm-set-input-queue-size | options | dnstap |
| fstrm-set-output-notify-threshold | options | dnstap |
| fstrm-set-output-queue-model | options | dnstap |
| fstrm-set-output-queue-size | options | dnstap |
| fstrm-set-reopen-interval | options | dnstap |
| geoip-directory | options | geoip |
| dnsrps-enable | view, rpz | dnsrps |
| dnsrps-options | view, rpz | dnsrps |
| dnstap | view | dnstap |February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2392XoT xfrin2022-01-21T13:30:45ZOndřej SurýXoT xfrinThis is child issue split from #1784; the goal is to add XoT support to xfrin to support incoming XFR via XoT.This is child issue split from #1784; the goal is to add XoT support to xfrin to support incoming XFR via XoT.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2071BIND stuck after error "unable to obtain neither an IPv4 nor an IPv6 dispatch"2021-10-08T14:37:43ZAnand BuddhdevBIND stuck after error "unable to obtain neither an IPv4 nor an IPv6 dispatch"### Summary
Server appeared to be stuck in some strange state after "rndc reconfig".
### BIND version used
```
BIND 9.16.5 (Stable Release) <id:c00b458>
running on Linux x86_64 3.10.0-1127.13.1.el7.x86_64 #1 SMP Tue Jun 23 15:46:38 UT...### Summary
Server appeared to be stuck in some strange state after "rndc reconfig".
### BIND version used
```
BIND 9.16.5 (Stable Release) <id:c00b458>
running on Linux x86_64 3.10.0-1127.13.1.el7.x86_64 #1 SMP Tue Jun 23 15:46:38 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/named' '--disable-static' '--with-pic' '--without-python' '--with-libtool' '--without-lmdb' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /etc/named/named.conf
rndc configuration: /etc/named/rndc.conf
DNSSEC root key: /etc/named/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Haven't been able to reproduce this. We run "rndc reconfig" frequently on many of our BIND servers, and this is the first time I've seen such behaviour. On this specific server, after log rotation, logrotate ran "rndc reconfig" and BIND logged this:
### What is the current *bug* behavior?
After logging that error, BIND appeared to be stuck in a strange state. It was answering queries over UDP (did not check TCP). However, it was not refreshing any of the secondary zones. However, I don't know what was going on, because logrotate compressed the rotated log file and deleted the original, but the named process still held it open. However, it couldn't write any logs. "rndc zonestatus" for various zones showed them loaded and stuck on older serials.
### What is the expected *correct* behavior?
BIND should have reloaded its configuration and created a new log file in /var/log/named/named.log
### Relevant configuration files
I'm not including the entire config file here, but here are the relevant snippets:
```
logging {
channel "default" {
file "/var/log/named/named.log";
severity info;
print-time yes;
print-category yes;
};
channel "ratelimit" {
file "/var/log/named/ratelimit.ringlog" versions 10 size 10485760;
print-time yes;
};
category "default" {
"default";
};
category "rate-limit" {
"ratelimit";
};
category "update" {
"null";
};
category "update-security" {
"null";
};
};
options {
answer-cookie no;
directory "/var/named";
keep-response-order {
"any";
};
listen-on {
127.0.0.1/32;
IPv4 address/32;
};
listen-on-v6 {
::1/128;
IPv6 address/128;
};
server-id hostname;
tcp-clients 1000;
transfers-in 100;
transfers-out 100;
version "9.16";
dnssec-validation no;
ixfr-from-differences yes;
minimal-responses yes;
recursion no;
allow-transfer {
"internal";
};
max-journal-size 10485760;
notify explicit;
zero-no-soa-ttl no;
zone-statistics none;
};
```
### Relevant logs and/or screenshots
This was the last thing logged in the rotated file:
```
10-Aug-2020 09:21:29.548 general: received control channel command 'reconfig'
10-Aug-2020 09:21:29.548 general: loading configuration from '/etc/named/named.conf'
10-Aug-2020 09:21:29.848 general: unable to open '/etc/named/bind.keys'; using built-in keys instead
10-Aug-2020 09:21:29.851 general: using default UDP/IPv4 port range: [32768, 60999]
10-Aug-2020 09:21:29.851 general: using default UDP/IPv6 port range: [32768, 60999]
10-Aug-2020 09:21:29.853 general: sizing zone task pool based on 4615 zones
10-Aug-2020 09:21:30.253 config: none:98: 'max-cache-size 90%' - setting to 57795MB (out of 64216MB)
10-Aug-2020 09:21:30.253 general: ./server.c:4530: unexpected error:
10-Aug-2020 09:21:30.253 general: unable to obtain neither an IPv4 nor an IPv6 dispatch
10-Aug-2020 09:21:30.276 general: reloading configuration failed: unexpected error
```
We were debugging the issue the next day, on Aug 11. When we couldn't figure anything out, we tried to restart BIND. It runs under systemd on our server, and this is what appeared in the systemd journal:
```
Aug 11 09:08:00 hostname systemd[1]: Stopping BIND...
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:09:30 hostname systemd[1]: named.service stop-sigterm timed out. Killing.
```
BIND logged those errors, but failed to exit, so systemd sent it a KILL signal after 90s.
### Possible fixes
I don't have any suggestion for a fix.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/1992Backport primaries and documentation changes to v9.162021-06-28T09:15:09ZOndřej SurýBackport primaries and documentation changes to v9.16* [x] !3703
* [x] !3679
* [x] !3692
* [x] !3644
* [x] !3676
* [x] !3793
* [x] !3591
* [x] !3800* [x] !3703
* [x] !3679
* [x] !3692
* [x] !3644
* [x] !3676
* [x] !3793
* [x] !3591
* [x] !3800February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2349Should we back-port max-ixfr-ratio from 9.17 to earlier versions of BIND?2021-05-10T16:49:36ZCathy AlmondShould we back-port max-ixfr-ratio from 9.17 to earlier versions of BIND?I can't see any other elegant option currently that could be used to 'protect' a zone hosting set-up from receipt and onward propagation of a massive IXFR to the service-providing authoritatives.
This happens sometimes accidentally (see...I can't see any other elegant option currently that could be used to 'protect' a zone hosting set-up from receipt and onward propagation of a massive IXFR to the service-providing authoritatives.
This happens sometimes accidentally (see [Support Ticket #17366](https://support.isc.org/Ticket/Display.html?id=17366)) and I would rather provide a solid solution in named, than encourage scripting that spots when something like this happens, and then goes off to delete .jnl or zone files on disk to prevent the same IXFR heading out to Internet-facing servers, where the effects of applying it can be seriously detrimental to server performance.
!3113
#1515February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2442TSAN error: lib/dns/rbtdb.c2021-03-18T12:00:07ZMark AndrewsTSAN error: lib/dns/rbtdb.cJob [#1434050](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1434050) failed for e6064e7cd9dc4848cdcc63f051bda46e935c733d:
```
WARNING: ThreadSanitizer: data race
Write of size 4 at 0x000000000001 by thread T1 (mutexes: read M1, r...Job [#1434050](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1434050) failed for e6064e7cd9dc4848cdcc63f051bda46e935c733d:
```
WARNING: ThreadSanitizer: data race
Write of size 4 at 0x000000000001 by thread T1 (mutexes: read M1, read M2):
#0 check_stale_header lib/dns/rbtdb.c:4573
#1 cache_find lib/dns/rbtdb.c:5061
#2 dns_db_findext lib/dns/db.c:536
#3 query_lookup lib/ns/query.c:5805
#4 query_gotanswer lib/ns/query.c:7556
#5 query_resume lib/ns/query.c:6614
#6 fetch_callback lib/ns/query.c:6161
#7 dispatch lib/isc/task.c:1152
#8 run lib/isc/task.c:1344
#9 <null> <null>
Previous write of size 4 at 0x000000000001 by thread T2 (mutexes: read M1, read M2):
#0 check_stale_header lib/dns/rbtdb.c:4573
#1 cache_find lib/dns/rbtdb.c:5061
#2 dns_db_findext lib/dns/db.c:536
#3 query_lookup lib/ns/query.c:5805
#4 query_gotanswer lib/ns/query.c:7556
#5 query_resume lib/ns/query.c:6614
#6 fetch_callback lib/ns/query.c:6161
#7 dispatch lib/isc/task.c:1152
#8 run lib/isc/task.c:1344
#9 <null> <null>
Location is heap block of size 209 at 0x000000000011 allocated by thread T3:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:713
#2 mem_get lib/isc/mem.c:622
#3 mem_allocateunlocked lib/isc/mem.c:1268
#4 isc___mem_allocate lib/isc/mem.c:1288
#5 isc__mem_allocate lib/isc/mem.c:2453
#6 isc___mem_get lib/isc/mem.c:1037
#7 isc__mem_get lib/isc/mem.c:2432
#8 dns_rdataslab_fromrdataset lib/dns/rdataslab.c:270
#9 addrdataset lib/dns/rbtdb.c:6813
#10 dns_db_addrdataset lib/dns/db.c:719
#11 addoptout lib/dns/ncache.c:281
#12 dns_ncache_add lib/dns/ncache.c:101
#13 ncache_adderesult lib/dns/resolver.c:6795
#14 ncache_message lib/dns/resolver.c:6972
#15 rctx_ncache lib/dns/resolver.c:9350
#16 resquery_response lib/dns/resolver.c:8063
#17 dispatch lib/isc/task.c:1152
#18 run lib/isc/task.c:1344
#19 <null> <null>
Mutex M1 is already destroyed.
Mutex M2 is already destroyed.
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:940
#4 setup bin/named/main.c:1248
#5 main bin/named/main.c:1548
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:940
#4 setup bin/named/main.c:1248
#5 main bin/named/main.c:1548
Thread T3 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_taskmgr_create lib/isc/task.c:1434
#3 create_managers bin/named/main.c:940
#4 setup bin/named/main.c:1248
#5 main bin/named/main.c:1548
SUMMARY: ThreadSanitizer: data race lib/dns/rbtdb.c:4573 in check_stale_header
```February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2468CID 318094: Null pointer dereferences (REVERSE_INULL)2021-03-02T13:51:47ZMark AndrewsCID 318094: Null pointer dereferences (REVERSE_INULL)Remove redundant `version == NULL` check. This should have been included in 3b11bacbb7b92aa2c1043ad27f8fd89763ed984b.
```
*** CID 318094: Null pointer dereferences (REVERSE_INULL)
/lib/dns/rbtdb.c: 1389 in newversion()
1383 vers...Remove redundant `version == NULL` check. This should have been included in 3b11bacbb7b92aa2c1043ad27f8fd89763ed984b.
```
*** CID 318094: Null pointer dereferences (REVERSE_INULL)
/lib/dns/rbtdb.c: 1389 in newversion()
1383 version->xfrsize = rbtdb->current_version->xfrsize;
1384 RWUNLOCK(&rbtdb->current_version->rwlock, isc_rwlocktype_read);
1385 rbtdb->next_serial++;
1386 rbtdb->future_version = version;
1387 RBTDB_UNLOCK(&rbtdb->lock, isc_rwlocktype_write);
1388
CID 318094: Null pointer dereferences (REVERSE_INULL)
Null-checking "version" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1389 if (version == NULL) {
1390 return (result);
1391 }
1392
1393 *versionp = version;
1394
```February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2335TLSDNS refactoring2021-02-26T15:14:59ZOndřej SurýTLSDNS refactoringThe TLSDNS needs to be refactored to use libuv/OpenSSL directly, and not via netmgr layers.The TLSDNS needs to be refactored to use libuv/OpenSSL directly, and not via netmgr layers.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2399Release Checklist for BIND 9.11.28, BIND 9.11.28-S1, BIND 9.16.12, BIND 9.16....2021-02-18T14:29:04ZMichał KępieńRelease Checklist for BIND 9.11.28, BIND 9.11.28-S1, BIND 9.16.12, BIND 9.16.12-S1, BIND 9.17.10## Release Schedule
**Code Freeze:** Wednesday, February 3rd, 2021
**Tagging Deadline:** Monday, February 8th, 2021
**Public Release:** Wednesday, February 17th, 2021
## Documentation Review Links
**Closed issues assigned to the mil...## Release Schedule
**Code Freeze:** Wednesday, February 3rd, 2021
**Tagging Deadline:** Monday, February 8th, 2021
**Public Release:** Wednesday, February 17th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.17.10](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
- [9.16.12](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
- [9.11.28](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.11)
**Merge requests merged into the milestone without a release note:**
- [9.17.10](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)¬[label_name][]=Release%20Notes&target_branch=main)
- [9.16.12](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)¬[label_name][]=Release%20Notes&target_branch=v9_16)
- [9.11.28](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)¬[label_name][]=Release%20Notes&target_branch=v9_11)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.17.10](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)&label_name[]=No%20CHANGES&target_branch=main)
- [9.16.12](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)&label_name[]=No%20CHANGES&target_branch=v9_16)
- [9.11.28](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=February%202021%20(9.11.28%2C%209.11.28-S1%2C%209.16.12%2C%209.16.12-S1%2C%209.17.10)&label_name[]=No%20CHANGES&target_branch=v9_11)
## Other Links
**QA Report:** *(not yet available)*
**Signing Ticket:** *(not yet available)*
## 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.
- [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.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michał KępieńMichał Kępień2021-02-17https://gitlab.isc.org/isc-projects/bind9/-/issues/2073dnssec-verify tries all keys which results in poor performance2021-02-17T21:37:02ZDaniel Stirnimanndnssec-verify tries all keys which results in poor performance<!--
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
I noticed that for zones with many signatures (>= ~50'000) `dnssec-verify` can perform
noticeably slower the more stand-by keys are included in the DNSKEY RR.
It looks like all ZSK keys in the DNSKEY RR are tried to verify the signatures until one is
found which succeeds. It now depends on the DNSKEY RR data structure which key is tried first and whether
the validation process is fast or slow. It would be good to first compare the RRSIG key-id with the DNSKEY key-id before attempting any cryptographic operations.
### BIND version used
dnssec-verify 9.16.5
### Steps to reproduce
````
# Create keys
# KSK
dnssec-keygen -a ECDSAP256SHA256 -f KSK foo.
Generating key pair.
Kfoo.+013+59071
# ZSK
dnssec-keygen -a ECDSAP256SHA256 foo.
Generating key pair.
Kfoo.+013+29053
# Add keys to foo.zone using an editor
$INCLUDE Kfoo.+013+59071.key
$INCLUDE Kfoo.+013+29053.key
# sign zone
dnssec-signzone -o foo. -P -t -x foo.zone Kfoo.+013+59071.private Kfoo.+013+29053.private
# verify zone
time dnssec-verify -o foo. foo.zone.signed
````
### What is the current *bug* behavior?
Depending on the key id and how many stand-by keys are present, the validation time of `dnssec-verify` slows down noticeably.
Some examples below:
**active ZSK: Kfoo.+013+39828, no stand-by ZSK**
```
time dnssec-verify -o foo. foo.zone.signed
Loading zone 'foo.' from file 'foo.zone.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
real 0m9.677s
user 0m9.645s
sys 0m0.026s
```
About ~9-10sec is the baseline
**active ZSK: Kfoo.+013+59286 , stand-by ZSK: Kfoo.+013+39828**
```
time dnssec-verify -o foo. foo.zone.signed
Loading zone 'foo.' from file 'foo.zone.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 1 stand-by, 0 revoked
real 0m9.662s
user 0m9.630s
sys 0m0.026s
```
Result is correct and within the baseline.
**active ZSK: Kfoo.+013+39828 , stand-by ZSK: Kfoo.+013+59286**
```
time dnssec-verify -o foo. foo.zone.signed
Loading zone 'foo.' from file 'foo.zone.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 1 stand-by, 0 revoked
real 0m14.210s
user 0m14.173s
sys 0m0.029s
```
Result is **poor**!
**active ZSK: Kfoo.+013+39828 , stand-by ZSK: Kfoo.+013+59286, Kfoo.+013+51653**
```
time dnssec-verify -o foo. foo.zone.signed
Loading zone 'foo.' from file 'foo.zone.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 2 stand-by, 0 revoked
real 0m18.310s
user 0m18.274s
sys 0m0.029s
```
Result is **poor**!
### What is the expected *correct* behavior?
No matter how many stand-by keys are present, the validation time is more or less constant.
### Possible fixes
Check the key id before attempting to validate each signature with each key.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/2462CID 316785: Error handling issues in dns_transport_list_new() (CHECKED_RETURN)2021-02-08T13:17:51ZMichal NowakCID 316785: Error handling issues in dns_transport_list_new() (CHECKED_RETURN)This came with the initial commit of the file (e488309da78d82e0c67990af264fcaa7b0ff0283):
```
*** CID 316785: Error handling issues (CHECKED_RETURN)
/lib/dns/transport.c: 292 in dns_transport_list_new()
286 dns_transport_list_t *
2...This came with the initial commit of the file (e488309da78d82e0c67990af264fcaa7b0ff0283):
```
*** CID 316785: Error handling issues (CHECKED_RETURN)
/lib/dns/transport.c: 292 in dns_transport_list_new()
286 dns_transport_list_t *
287 dns_transport_list_new(isc_mem_t *mctx) {
288 dns_transport_list_t *list = isc_mem_get(mctx, sizeof(*list));
289
290 *list = (dns_transport_list_t){ 0 };
291
>>> CID 316785: Error handling issues (CHECKED_RETURN)
>>> Calling "isc_rwlock_init" without checking return value (as is done elsewhere 17 out of 21 times).
292 isc_rwlock_init(&list->lock, 0, 0);
293
294 isc_mem_attach(mctx, &list->mctx);
295 isc_refcount_init(&list->references, 1);
296
297 list->magic = TRANSPORT_LIST_MAGIC;
```February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1697isc_rwlock_init can no longer fail in master, clean up calls.2021-02-08T13:17:14ZMark Andrewsisc_rwlock_init can no longer fail in master, clean up calls.Coverity is complaining about unchecked returns from isc_rwlock_init. Silence by removing return value which is always ISC_R_SUCCESS.
Check earlier active branches to see if similar is appropriate for them.Coverity is complaining about unchecked returns from isc_rwlock_init. Silence by removing return value which is always ISC_R_SUCCESS.
Check earlier active branches to see if similar is appropriate for them.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2377Allow A records below an '_spf' label as a check-names exception2021-02-04T11:43:35ZMark AndrewsAllow A records below an '_spf' label as a check-names exceptionSPF uses A records for existence testing (exists rule). When "_spf" is used as a separating label this results in A records with non LDH owners.SPF uses A records for existence testing (exists rule). When "_spf" is used as a separating label this results in A records with non LDH owners.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Mark AndrewsMark Andrews