ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-01-26T11:33:40Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2787Assertion failure handling non-zero opcodes in DoT and DoH2022-01-26T11:33:40ZOndřej SurýAssertion failure handling non-zero opcodes in DoT and DoHBIND 9 Development branch builds of named DNS server will crash with an assertion error when they receive DNS queries with non-zero OPcodes over TLS.
To reproduce, configure `named` to listen over DoT or DoH and do: `dig +tls +opcode=1 ...BIND 9 Development branch builds of named DNS server will crash with an assertion error when they receive DNS queries with non-zero OPcodes over TLS.
To reproduce, configure `named` to listen over DoT or DoH and do: `dig +tls +opcode=1 @<10.9.9.124>`July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/1936Mention DHCPRELEASE in the "Known RFC Violations" section of the DHCPv4 ARM a...2021-08-13T15:13:52ZAndrei Pavelandrei@isc.orgMention DHCPRELEASE in the "Known RFC Violations" section of the DHCPv4 ARM as a message that doesn't require server-idThere's already the second bullet point that mentions that DHCPDECLINE messages don't have to contain server ID in Kea, despite the RFC saying it MUST. As @wlodek rightfully pointed out in the review of #1119, Kea also does not enforce s...There's already the second bullet point that mentions that DHCPDECLINE messages don't have to contain server ID in Kea, despite the RFC saying it MUST. As @wlodek rightfully pointed out in the review of #1119, Kea also does not enforce server ID existence for DHCPRELEASE messages while the RFC mentions it MUST. So we should also mention DHCPRELEASE in the ARM as an intended violation.kea1.9.11Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1935GSS-TSIG-enabled nsupdate2021-08-03T09:06:36ZTomek MrugalskiGSS-TSIG-enabled nsupdate@fdupont proposed to implement a GSS-TSIG enabled `nsupdate` equivalent (from BIND 9) that uses Kea framework.
This will be very helpful for debugging and testing in general.@fdupont proposed to implement a GSS-TSIG enabled `nsupdate` equivalent (from BIND 9) that uses Kea framework.
This will be very helpful for debugging and testing in general.kea1.9.10Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2786Lock key files race condition can lead to deadlock2021-07-01T13:47:43ZMatthijs Mekkingmatthijs@isc.orgLock key files race condition can lead to deadlockBesides the issue with `in-view` and key file locking that leads to a deadlock at startup (#2783) there is another possible deadlock scenario, although it is triggered less likely.
When BIND 9 is using `dnssec-policy` and views, a threa...Besides the issue with `in-view` and key file locking that leads to a deadlock at startup (#2783) there is another possible deadlock scenario, although it is triggered less likely.
When BIND 9 is using `dnssec-policy` and views, a thread needs to hold a set of locks in order to do safe key file I/O operations. `named` will walk all the views the zone is in and obtain a mutex lock attached to that zone.
It is possible that one thread is working on a zone in one view, and another thread is working on the same zone in a different view. To do safe key file I/O operations, a thread needs to hold all zone locks, but if both threads already holds one lock, they will wait indefinitely on each other until the other mutex becomes unlocked.July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2785host does not parse options timeout and retries2022-04-26T13:21:13ZPetr Menšíkhost does not parse options timeout and retries### Summary
man host mentions on -W option default could be overiden in /etc/resolv.conf. Worked on 9.11, no longer on 9.16.
### BIND version used
```
BIND 9.16.16-RH (Stable Release) <id:0c314d8>
running on Linux x86_64 5.12.10-300.f...### Summary
man host mentions on -W option default could be overiden in /etc/resolv.conf. Worked on 9.11, no longer on 9.16.
### BIND version used
```
BIND 9.16.16-RH (Stable Release) <id:0c314d8>
running on Linux x86_64 5.12.10-300.fc34.x86_64 #1 SMP Thu Jun 10 14:21:36 UTC 2021
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' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-python=/usr/bin/python3' '--with-libtool' '--localstatedir=/var' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--with-maxminddb' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-gssapi=yes' '--with-lmdb=yes' '--without-libjson' '--with-json-c' '--enable-dnstap' '--enable-fixed-rrset' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CC=gcc' 'CFLAGS= -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld ' 'LT_SYS_LIBRARY_PATH=/usr/lib64:' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 11.1.1 20210428 (Red Hat 11.1.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libxml2 version: 2.9.12
linked to libxml2 version: 20912
compiled with json-c version: 0.14
linked to json-c version: 0.14
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.2
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/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/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
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
- echo "nameserver 127.0.0.255 > /etc/resolv.conf"
- echo "options timeout:1 attempts:1" >> /etc/resolv.conf
- time host localhost
### What is the current *bug* behavior?
(host on 9.16)
```# time host localhost
;; connection timed out; no servers could be reached
real 0m10.011s
user 0m0.005s
sys 0m0.006s
```
Obviously options are ignored.
### What is the expected *correct* behavior?
(host on 9.11)
```
# time host localhost
;; connection timed out; no servers could be reached
real 0m2,010s
user 0m0,003s
sys 0m0,006s
```
### Relevant configuration files
```
# resolv.conf
options timeout:1 attempts:1
nameserver 127.0.0.255
```
### Relevant logs and/or screenshots
none
### Possible fixes
It should parse more options in lib/irs/resconf.c, similar to lwres configuration parsing done in 9.11. Found when retesting ancient test case for [RHEL bug](https://bugzilla.redhat.com/show_bug.cgi?id=570851). Manual page for host mentions default from /etc/resolv.conf. It should read it or at least manual page should not mention it is related.
Because it still works on 9.11, it is a regression.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/kea/-/issues/1934Dual stack DDNS2022-01-13T16:24:34Zjohn dickinsonDual stack DDNS---
name: Dual stack DDNS
about: Documentation and feature request regarding Dual stack DDNS
---
Testing with kea 1.9.8 and Ubuntu 20.04 as dhcp client.
I find the documentation regarding ddns in dual stacked networks a bit confusing. 8...---
name: Dual stack DDNS
about: Documentation and feature request regarding Dual stack DDNS
---
Testing with kea 1.9.8 and Ubuntu 20.04 as dhcp client.
I find the documentation regarding ddns in dual stacked networks a bit confusing. 8.2.21. Using Client Identifier and Hardware Address https://downloads.isc.org/isc/kea/1.9.8/doc/html/arm/dhcp4-srv.html#using-client-identifier-and-hardware-address talks about the need for matching identifiers and gives the distinct impression that it works in Kea. However, 13.1.3. Dual-Stack Environments https://downloads.isc.org/isc/kea/1.9.8/doc/html/arm/ddns.html#dual-stack-environments clearly says that Kea does not currently support this feature.
Please could you add a Note to the 8.2.21 section saying that this is not supported or better yet could you add this functionality.
If you just do the doc update them you also need to fix the text referring to RFC4703 to be RFC4361 in section 13.1.3 (the link is of it's just the text that is wrong).
As for adding this feature, I have seen a couple of messages on kea-users related to this that have no response.
From what I can see with wireshark all the information needed to do this is provided in a v4 client identifier and is identical to that in v6. Here is a hexdump of the Client Identifier option in both v4 and v6:
```
v4
0000 3d 13 ff 5d e2 6c 15 00 02 00 00 ab 11 9a 57 20 =..].l........W
0010 95 71 61 bd d0 .qa..
v6
0000 00 01 00 0e 00 02 00 00 ab 11 9a 57 20 95 71 61 ...........W .qa
0010 bd d0 ..
```
As you can see both contain 00 02 00 00 ab 11 9a 57 20 95 71 61 bd d0 and in v4 the third octet is ff (255) as specified in RFC4361 6.1
If you are going to add this feature please could you give some idea of timescale? If this is not a priority, let me know I could try and find some time to hack together a fix :)kea2.1.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1933Makefile cleanup: remove workaround for 11yo boost problem2022-11-02T15:10:20ZTomek MrugalskiMakefile cleanup: remove workaround for 11yo boost problemThere's a tradition that doesn't want to die. A long time ago someone added a work around for boost 1.40 problem. The referenced boost ticket was closed 11 years ago.
```
# Some versions of GCC warn about some versions of Boost regardin...There's a tradition that doesn't want to die. A long time ago someone added a work around for boost 1.40 problem. The referenced boost ticket was closed 11 years ago.
```
# Some versions of GCC warn about some versions of Boost regarding
# missing initializer for members in its posix_time.
# https://svn.boost.org/trac/boost/ticket/3477
# But older GCC compilers don't have the flag.
AM_CXXFLAGS += $(WARNING_NO_MISSING_FIELD_INITIALIZERS_CFLAG)
```
Bugs are not whisky... 11yo is bad.
It seems this was cleaned up in the core code, but not in premium.backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2784New 9.17 options for setting socket buffer sizes have a mistake in the ARM2021-06-22T20:32:01ZCathy AlmondNew 9.17 options for setting socket buffer sizes have a mistake in the ARMFrom #2313
There are four new options. They are listed in the syntax section as:
tcp-receive-buffer
udp-receive-buffer
tcp-send-buffer
udp-send-buffer
They're also named thus in CHANGES and relnotes.
But in the section of the ARM t...From #2313
There are four new options. They are listed in the syntax section as:
tcp-receive-buffer
udp-receive-buffer
tcp-send-buffer
udp-send-buffer
They're also named thus in CHANGES and relnotes.
But in the section of the ARM that describes the usage, the two inbound buffer tuning knobs are described instead as tcp-recv-buffer and udp-recv-buffer. Oops.
Please can we fix this in the July releases?July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2783Pre-fork deadlock during key-directory locking, due to the "In-View" statement.2021-07-08T08:25:03ZKris KarasPre-fork deadlock during key-directory locking, due to the "In-View" statement.### Summary
When attempting to test the fixes for #2778, *named* deadlocks during initialization. In my particular case, named is invoked like so:
```
/usr/sbin/named -u bind -t /var/named
```
On downstream servers (which have no dnsse...### Summary
When attempting to test the fixes for #2778, *named* deadlocks during initialization. In my particular case, named is invoked like so:
```
/usr/sbin/named -u bind -t /var/named
```
On downstream servers (which have no dnssec maintenance enabled, no ```key-directory:``` clauses), named starts normally and performs correctly. On the upstream server, which has several views with corresponding, per-view ```key-directory:``` clauses, the invocation of *named* never completes, the command line as shown never returning to its caller.
### BIND version used
```
BIND 9.16.18 (Stable Release) <id:1c027c4>
running on Linux x86_64 5.12.12 #1 SMP Fri Jun 18 05:38:32 EDT 2021
built by make with '--build=x86_64-slackware-linux-gnu' '--docdir=/usr/doc/bind-9.16.18' '--sysconfdir=/etc/bind' '--infodir=/usr/info' '--libdir=/usr/lib64' '--mandir=/usr/man' '--prefix=/usr' '--localstatedir=/var' '--enable-largefile' '--with-libtool' '--enable-shared' '--with-gssapi=/usr' '--with-libidn2' '--with-dlopen' '--with-dlz-filesystem' '--with-dlz-stub' '--enable-auto-validation' '--enable-dnsrps' '--enable-full-report' '--enable-fixed-rrset' '--enable-querytrace' '--with-python=/usr/bin/python3' '--with-openssl' 'build_alias=x86_64-slackware-linux-gnu' 'CFLAGS=-g -O2 -fPIC -march=opteron' 'PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/local/share/pkgconfig:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 10.3.0
compiled with OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libxml2 version: 2.9.12
linked to libxml2 version: 20912
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
A reproducer is still in-the-works. At the moment, I'm wading through ```strace``` and ```eu-stack``` output, looking for anything that can narrow down where the deadlock is occurring.
### What is the current *bug* behavior?
*named* deadlocks during the initialization phase, where it checks its configuration for usability before returning a 0 (OK) status to its invoker.
### What is the expected *correct* behavior?
*named* should check its configuration, and return to its caller with 0 exit status (configuration looks OK) or some other value (incorrect configuration).
### Output of eu-stack utility
Here, named has been invoked with "-n 1" to reduce the number of threads to keep track of.
```
PID 16077 - process
TID 16077:
#0 0x00007f8cf0939632 __sigtimedwait
#1 0x00007f8cf0aee014 sigwait
#2 0x00007f8cf1075d99 isc_app_ctxrun
#3 0x00007f8cf1076024 isc_app_run
#4 0x000000000041a8ce main
#5 0x00007f8cf09211ad __libc_start_main
#6 0x000000000041b3ea _start
TID 16078:
#0 0x00007f8cf0aed2cb __lll_lock_wait
#1 0x00007f8cf0ae6172 __pthread_mutex_lock
#2 0x00007f8cf13f5a9d dns__zone_lockunlock_keyfiles
#3 0x00007f8cf13d8fb9 dns_update_signaturesinc
#4 0x00007f8cf13dc409 dns_update_signatures
#5 0x00007f8cf13fbf0f rss_post
#6 0x00007f8cf13fc270 setnsec3param
#7 0x00007f8cf10a7de4 isc_task_run
#8 0x00007f8cf1092781 process_netievent
#9 0x00007f8cf10928f5 process_queue
#10 0x00007f8cf10930a1 async_cb
#11 0x00007f8cf0e78f65
#12 0x00007f8cf0e89af5 uv__io_poll
#13 0x00007f8cf0e797a4 uv_run
#14 0x00007f8cf10929ae nm_thread
#15 0x00007f8cf10aa1c1 isc__trampoline_run
#16 0x00007f8cf0ae3e85 start_thread
#17 0x00007f8cf0a08b3f __clone
TID 16079:
#0 0x00007f8cf0af023e __futex_abstimed_wait_cancelable64
#1 0x00007f8cf0aea116 pthread_cond_timedwait@@GLIBC_2.3.2
#2 0x00007f8cf10bd698 isc_condition_waituntil
#3 0x00007f8cf10ac1a7 run
#4 0x00007f8cf10aa1c1 isc__trampoline_run
#5 0x00007f8cf0ae3e85 start_thread
#6 0x00007f8cf0a08b3f __clone
TID 16080:
#0 0x00007f8cf0a08e66 epoll_wait
#1 0x00007f8cf10b5514 netthread
#2 0x00007f8cf10aa1c1 isc__trampoline_run
#3 0x00007f8cf0ae3e85 start_thread
#4 0x00007f8cf0a08b3f __clone
```
I will also attach the strace log, showing file and process events. It is somewhat interesting in that, only the first view (external) is processed. None of the various internal views show any file-based activity.[trace.log](/uploads/477168c28f424a939c438792fbffe687/trace.log)
### Analysis
It turns out, after applying some debugging statements to the code, that the culprit is an attempt to lock the same ```key-directory``` more than once, resulting in a deadlock. There is a loop that walks over a per-zone linked list of views, locking the key directory of each in turn. However, if one of those views is referenced in another view by way of the ``in-view`` zone statement, then that view (and its key directory) are included in the list more than once.
### Possible fixes
The code that maintains and walks the linked list of per-zone views will need to be updated to keep track of whether it has been locked already, and to not attempt a double-lock; the same logic will need to be applied on the unlock.July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)https://gitlab.isc.org/isc-projects/bind9/-/issues/2782BIND version number not being auto-generated in Read the Docs2022-01-11T15:14:42ZSuzanne GoldlustBIND version number not being auto-generated in Read the DocsIn /doc/arm/introduction.rst, line 33 reads:
```
This manual covers BIND version |release|.
```
but that is not working (and has never worked) to auto-generate the actual release number in Read the Docs (see attached image). Unfortunatel...In /doc/arm/introduction.rst, line 33 reads:
```
This manual covers BIND version |release|.
```
but that is not working (and has never worked) to auto-generate the actual release number in Read the Docs (see attached image). Unfortunately, I don't know how to fix it.
![Screen_Shot_2021-06-18_at_9.54.30_AM](/uploads/6f0c36cb0ff52e6acac57ce339bf5b97/Screen_Shot_2021-06-18_at_9.54.30_AM.png).January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2781Release Checklist for BIND 9.16.18, BIND 9.16.18-S1, 9.17.152021-06-24T16:23:42ZPetr Špačekpspacek@isc.orgRelease Checklist for BIND 9.16.18, BIND 9.16.18-S1, 9.17.15## Release Schedule
**Public Release:** Friday, June 18th, 2021[^3]
## Documentation Review Links
N/A
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give est...## Release Schedule
**Public Release:** Friday, June 18th, 2021[^3]
## Documentation Review Links
N/A
## 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.~~
- *bumped clang to version 12 in the meantime, so these tags won't pass CI pipelines: https://mattermost.isc.org/isc/pl/caz4gzmfs3dkj8mcsc8jmo9dir*
- [x] ~~***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.~~
- *skipped, no impact expected*
- [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`.~~
- *skipped, diff between tarballs of the previous and current version shows changes only version numbers in the build system so presumably nothing breaks*
- [x] ***(QA)*** Update `CHANGES`.
- [x] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ~~***(QA)*** Update `README.md`.~~
- *skipped, no changes*
- [x] ***(QA)*** Update `version`.
- [x] ~~***(QA)*** Build documentation on `docs.isc.org`.~~
- *skipped, this only applies to `v9_11`*
- [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.~~
- *skipped, this only applies to `v9_11`*
- [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.](isc-private/signing#41)
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** [Verify tarball signatures and check tarball checksums again.](https://mattermost.isc.org/isc/pl/hz91yaf63tg3myw99ejax47gor)
- [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.](https://gitlab.isc.org/isc-private/signing/-/issues/41#note_221095)
- [x] ***(Support)*** [Publish links to downloads on ISC website.](https://mattermost.isc.org/isc/pl/ceykgfoq5fb1pyppcd5g5isfxy)
- [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.~~
- skipped, no ABI changes
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- both v9_16 and main branches had notes for the next version, so I just kept them as they were and renumbered notes-current.rst
- [x] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.
[^3]: emergency releases fixing BIND 9.16.17, 9.16.17-S1, 9.17.14June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Michał KępieńMichał Kępień2021-06-18https://gitlab.isc.org/isc-projects/bind9/-/issues/2780checkconf dnssec-policy doesn't check for inheritance2021-07-23T07:44:53ZMatthijs Mekkingmatthijs@isc.orgcheckconf dnssec-policy doesn't check for inheritanceJuly 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2779W or w characters in domain names are altered to "\000"2021-06-21T12:14:48ZSean ZhangW or w characters in domain names are altered to "\000"<!--
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
We recently upgraded our bind9 from `1:9.16.16-2+ubuntu18.04.1+isc+1` to `1:9.16.17-1+ubuntu21.04.1+isc+1` and start experiencing some wildcard names not being resolved. The resolver will return `servfail`. After some troubleshooting we found that:
Under certain conditions (reproducible), the name in answer will not match the name in question. Found this issue reproducible with following conditions:
1. Character "W" in name in question.
1. Name in the query matches a wildcard record in zone.
Then in the answer, letter "W" (or should be "w") will be replaced with "/000".
### BIND version used
```
BIND 9.16.17-Ubuntu (Stable Release) <id:fe79347>
running on Linux x86_64 4.15.0-143-generic #147-Ubuntu SMP Wed Apr 14 16:10:11 UTC 2021
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--libexecdir=/usr/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-yfFgL0/bind9-9.16.17=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 7.5.0
compiled with OpenSSL version: OpenSSL 1.1.1 11 Sep 2018
linked to OpenSSL version: OpenSSL 1.1.1 11 Sep 2018
compiled with libuv version: 1.38.1
linked to libuv version: 1.38.0
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.12.1
linked to json-c version: 0.12.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.3.2
compiled with protobuf-c version: 1.3.1
linked to protobuf-c version: 1.3.1
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
Start a container:
`docker run --rm -it ubuntu:bionic`
Then in the container, run:
```shell
# install packages
apt-get update &&
apt-get -y install software-properties-common &&
add-apt-repository -y ppa:isc/bind &&
apt-get update &&
apt-get install -y bind9=1:9.16.17-1+ubuntu18.04.1+isc+1 dnsutils
# populate zone data
cat <<EOT > /tmp/test.local.zone
test.local. 1 SOA ns1.test.local. admin.test.local. 1 1 1 1 1
test.local. 1 NS ns1.test.local.
ns1.test.local. 1 A 127.0.0.1
UVW.test.local. 1 A 127.0.0.1
*.sub.test.local. 1 A 127.0.0.1
EOT
# set named configuration
cat <<EOT > /etc/bind/named.conf
options { recursion no; };
zone "test.local" IN { type master; file "/tmp/test.local.zone"; };
EOT
named # start named process
```
Run below `dig` command in the same container and check the answer:
```
dig @127.0.0.1 +noall +answer -t A ABC.sub.test.local. # this will succeed
dig @127.0.0.1 +noall +answer -t A UVW.sub.test.local. # "W" in answer will be altered to "/000"
dig @127.0.0.1 +noall +answer -t A UVW.test.local. # this will succeed despite the "W"
```
### What is the current *bug* behavior?
```
/# dig @127.0.0.1 +noall +answer -t A ABC.sub.test.local.
abc.sub.test.local. 1 IN A 127.0.0.1
/# dig @127.0.0.1 +noall +answer -t A UVW.sub.test.local.
uv\000.sub.test.local. 1 IN A 127.0.0.1 <- "W" was altered
/# dig @127.0.0.1 +noall +answer -t A UVW.test.local.
UVW.test.local. 1 IN A 127.0.0.1
```
### What is the expected *correct* behavior?
```
/# dig @127.0.0.1 +noall +answer -t A UVW.sub.test.local.
uvw.sub.test.local. 1 IN A 127.0.0.1
```
### Relevant configuration files
Configurations used to reproduce the issue:
`named.conf`
```
options { recursion no; };
zone "test.local" IN { type master; file "/tmp/test.local.zone"; };
```
`test.local.zone`
```
test.local. 1 SOA ns1.test.local. admin.test.local. 1 1 1 1 1
test.local. 1 NS ns1.test.local.
ns1.test.local. 1 A 127.0.0.1
UVW.test.local. 1 A 127.0.0.1
*.sub.test.local. 1 A 127.0.0.1
```
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2778Unique key directories reported as reused in 9.16.17, regression vs 9.16.162021-06-24T08:46:10ZKris KarasUnique key directories reported as reused in 9.16.17, regression vs 9.16.16### Summary
A regression in BIND 9.16.17 (versus 9.16.16) causes per-view key directories to no longer be considered as isolating same-zone keys from one another, resulting in duplicate key-directory errors that prevent BIND from starti...### Summary
A regression in BIND 9.16.17 (versus 9.16.16) causes per-view key directories to no longer be considered as isolating same-zone keys from one another, resulting in duplicate key-directory errors that prevent BIND from starting. A typical fatal error message looks like this:
```
/etc/bind/named.conf:193: key-directory 'example.com/(null)' already in use by zone example.com with policy internet: /etc/bind/named.conf:119
```
### BIND version used
```
BIND 9.16.17 (Stable Release) <id:fe79347>
running on Linux x86_64 5.12.11 #1 SMP Thu Jun 17 02:04:48 EDT 2021
built by make with '--build=x86_64-slackware-linux-gnu' '--docdir=/usr/doc/bind-9.16.17' '--sysconfdir=/etc/bind' '--infodir=/usr/info' '--libdir=/usr/lib64' '--mandir=/usr/man' '--prefix=/usr' '--localstatedir=/var' '--enable-largefile' '--with-libtool' '--enable-shared' '--with-gssapi=/usr' '--with-libidn2' '--with-dlopen' '--with-dlz-filesystem' '--with-dlz-stub' '--enable-auto-validation' '--enable-dnsrps' '--enable-full-report' '--enable-fixed-rrset' '--enable-querytrace' '--with-python=/usr/bin/python3' '--with-openssl' 'build_alias=x86_64-slackware-linux-gnu' 'CFLAGS=-g -O2 -fPIC -march=opteron' 'PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/local/share/pkgconfig:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 10.3.0
compiled with OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libxml2 version: 2.9.12
linked to libxml2 version: 20912
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
1. Create a named.conf with a split-horizon view, similar to the sample in the *Relevant configuration files* heading, below.
2. To avoid key collisions (different content in each view for the same example.com zone), keep keys for each view in their own private, per-view directory. Again, see the sample config, below.
3. Upgrade bind from 9.16.16 to 9.16.17 (might also apply to other bind branches, but I haven't tested this).
### What is the current *bug* behavior?
Bind thinks that the key directories are somehow not unique. It's use of the string "/(null)" in the error hints that there might be a missing-string coding bug. That is, where the two key directories would be represented by the strings "example.com/internal/keys" and "example.com/external/keys" in BIND 9.16.16, they are now represented in 9.16.17 by the strings "example.com/(null)" and "example.com/(null)" – a collision. But this is just a wild guess; I haven't traced the code in question.
### What is the expected *correct* behavior?
Bind loads the config, maintains the key directories as per dnssec-policy, starts and runs normally.
### Relevant configuration files
Here is a stripped-down version of the named.conf, substituting the well-known example.com in place of the "*.moonlit-rail.com" used in my actual config.
```
options {
directory "/var/named/db";
};
include "/etc/bind/dnssec-policy.conf";
view "external" {
match-clients { ... };
key-directory "external/keys";
zone "example.com" IN {
type master;
file "external/example.com.zone";
dnssec-policy "internet";
};
};
view "internal" {
match-clients { ... };
key-directory "internal/keys";
zone "example.com" IN {
type master;
file "internal/example.com.zone";
dnssec-policy "intranet";
};
zone "something.example.com" IN {
type master;
file "internal/something.example.com.zone";
dnssec-policy "intranet";
};
};
```
The dnssec-policy.conf is mostly default:
```
dnssec-policy "internet" {
keys {
ksk key-directory lifetime unlimited algorithm ecdsa256;
zsk key-directory lifetime P90D algorithm ecdsa256;
};
nsec3param iterations 15 optout no salt-length 8;
};
dnssec-policy "intranet" {
keys {
ksk key-directory lifetime unlimited algorithm ecdsa256;
zsk key-directory lifetime P30D algorithm ecdsa256;
};
nsec3param iterations 15 optout no salt-length 8;
};
```
### Relevant logs and/or screenshots
```
Jun 17 16:03:14 bindserver named[1000]: /etc/bind/named.conf:193: key-directory 'example.com/(null)' already in use by zone example.com with policy internet: /etc/bind/named.conf:119
```
Note that the two named.conf line numbers, *193* and *119*, correspond with the line ```zone "example.com" IN {``` in the *internal* and *external* views, respectively.
### Possible fixes
I could *git-bisect*, but I suspect one of the devos here will already have a clue.June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2777Views with recursion disabled should not use "max-cache-size 90%;" by default2021-06-22T13:34:50ZMichał KępieńViews with recursion disabled should not use "max-cache-size 90%;" by defaultViews (including the built-in ones) which do not have `max-cache-size`
explicitly set inherit the implicit global default, i.e. `max-cache-size
90%;`. For views which do not allow recursion, this causes memory to be
needlessly prealloca...Views (including the built-in ones) which do not have `max-cache-size`
explicitly set inherit the implicit global default, i.e. `max-cache-size
90%;`. For views which do not allow recursion, this causes memory to be
needlessly preallocated for cache RBT hash tables associated with such
views.
The amount of memory preallocated for each cache RBT hash table (about
0.2% of the effective `max-cache-size` value) is not significant enough
to cause operational issues, but it can still raise an eyebrow on
servers with large amounts of RAM: `named` running with the default
configuration on a 64-bit host with 32 GB of RAM will preallocate about
128 MB of memory just for the cache RBT hash tables for the two built-in
views (`_default` and `_bind`). Each configured view on top of that
makes the issue more and more apparent.
This was noticed while discussing #2279/!5173.July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2776XFR-over-TLS (XoT): Primaries need to be able to restrict XFR to just TLS2021-12-01T09:01:00ZSara DickisnonXFR-over-TLS (XoT): Primaries need to be able to restrict XFR to just TLSAs part of implementing https://gitlab.isc.org/isc-projects/bind9/-/issues/1784
Unless I’m missing something I cannot see a way to configure a primary to allow xfr for a zone ONLY over TLS. I can add a `listen-on` address with `tls`, an...As part of implementing https://gitlab.isc.org/isc-projects/bind9/-/issues/1784
Unless I’m missing something I cannot see a way to configure a primary to allow xfr for a zone ONLY over TLS. I can add a `listen-on` address with `tls`, and I can restrict transfers by TSIG and ACL. However the current ACLs don’t allow a transport to be specified (or a port), so the primary will still provide XFR over TCP. I discussed a `allow-transer-tls` option or similar with Witold very early on but it looks like the existing option has been extended, in which case I think an extension of the ACL directive to include a transport/port is needed? The specification requires that the primary can limit XFR to just TLS to avoid leaking in case the secondary is misconfigured.
This needs some discussion before deciding on a solutionDecember 2021 (9.16.24, 9.16.24-S1, 9.17.21)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2775XFR-over-TLS (XoT): Spec requires client and server MUST use `dot` ALPN and T...2021-10-05T09:01:07ZSara DickisnonXFR-over-TLS (XoT): Spec requires client and server MUST use `dot` ALPN and TLS 1.3As part of implementing https://gitlab.isc.org/isc-projects/bind9/-/issues/1784 per the spec, the XoT spec requires that the `dot` ALPN MUST be used for XoT connections and also that TLS 1.3 or later is required. This seems it will requi...As part of implementing https://gitlab.isc.org/isc-projects/bind9/-/issues/1784 per the spec, the XoT spec requires that the `dot` ALPN MUST be used for XoT connections and also that TLS 1.3 or later is required. This seems it will require extension to the `tls` clause with an ALPN field and implementation of the `protocol` field on client and server side.
*Updates by a team member*
The issue basically consists of two:
1. #2794;
2. #2795.
Related issues:
1. #2776.
2. #2796October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2774named-checkconf gives confusing managed-keys deprecated warning2021-06-30T12:51:17ZMatthijs Mekkingmatthijs@isc.orgnamed-checkconf gives confusing managed-keys deprecated warninghttps://bugzilla.redhat.com/show_bug.cgi?id=1972022https://bugzilla.redhat.com/show_bug.cgi?id=1972022July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2773TSAN error in 9.16/9.17 forwarding updates2021-09-02T08:10:46ZMark AndrewsTSAN error in 9.16/9.17 forwarding updatesJob [#1795733](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1795733) failed for 2c38ba46706b5699a3d142dcb3ee4be4d18ac398:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 recvmsg <nul...Job [#1795733](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1795733) failed for 2c38ba46706b5699a3d142dcb3ee4be4d18ac398:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 recvmsg <null>
#1 <null> <null>
#2 isc__trampoline_run lib/isc/trampoline.c:191
#3 <null> <null>
Previous read of size 8 at 0x000000000001 by thread T2:
#0 memmove <null>
#1 isc_buffer_copyregion lib/isc/buffer.c:530
#2 dns_zone_forwardupdate lib/dns/zone.c:17897
#3 forward_action lib/ns/update.c:3556
#4 task_run lib/isc/task.c:857
#5 isc_task_run lib/isc/task.c:950
#6 isc__nm_async_task lib/isc/netmgr/netmgr.c:880
#7 process_netievent lib/isc/netmgr/netmgr.c:959
#8 process_queue lib/isc/netmgr/netmgr.c:1028
#9 process_all_queues lib/isc/netmgr/netmgr.c:799
#10 async_cb lib/isc/netmgr/netmgr.c:828
#11 <null> <null>
#12 isc__trampoline_run lib/isc/trampoline.c:191
#13 <null> <null>
Location is heap block of size 1310737 at 0x000000000016 allocated by main thread:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:717
#2 mem_get lib/isc/mem.c:626
#3 mem_allocateunlocked lib/isc/mem.c:1292
#4 isc___mem_allocate lib/isc/mem.c:1312
#5 isc__mem_allocate lib/isc/mem.c:2563
#6 isc___mem_get lib/isc/mem.c:1061
#7 isc__mem_get lib/isc/mem.c:2542
#8 isc__netmgr_create lib/isc/netmgr/netmgr.c:365
#9 isc_managers_create lib/isc/managers.c:33
#10 create_managers main.c:920
#11 setup main.c:1245
#12 main main.c:1548
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:79
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:374
#3 isc_managers_create lib/isc/managers.c:33
#4 create_managers main.c:920
#5 setup main.c:1245
#6 main main.c:1548
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:79
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:374
#3 isc_managers_create lib/isc/managers.c:33
#4 create_managers main.c:920
#5 setup main.c:1245
#6 main main.c:1548
SUMMARY: ThreadSanitizer: data race in __interceptor_recvmsg
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2772Update: Validation Easy Start Explained2023-11-02T16:26:07ZMark AndrewsUpdate: Validation Easy Start ExplainedThis section still references managed-keys as of 9.16.16. It needs to be updated to refer to `trust-anchors`.
Also `delv does not consult the managed-keys database maintained by named, which means that if either of the keys in /etc/bin...This section still references managed-keys as of 9.16.16. It needs to be updated to refer to `trust-anchors`.
Also `delv does not consult the managed-keys database maintained by named, which means that if either of the keys in /etc/bind.keys is revoked and rolled over, /etc/bind.keys must be updated to use DNSSEC validation in delv.` is out of date.Not planned