ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-03-08T11:25:56Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4600autosign system test hung in cross-version-config-tests CI job2024-03-08T11:25:56ZMichal Nowakautosign system test hung in cross-version-config-tests CI jobJob [#4058605](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4058605) failed for e5a98f14bf3203cf803fcc6bd9f3ff03a2b4a8f7 (CI artifacts were saved).
The `autosign` system test hung for 5 minutes on shutdown in [the `cross-version-con...Job [#4058605](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4058605) failed for e5a98f14bf3203cf803fcc6bd9f3ff03a2b4a8f7 (CI artifacts were saved).
The `autosign` system test hung for 5 minutes on shutdown in [the `cross-version-config-tests` CI job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4058605). I see this for the second time in two days, and I think this is something new and will persist.
This CI job is unique compared to other system test CI jobs: it just starts and stops BIND servers to check that `named.conf` breakages introduced since the previous point release are not present. We had a problem in this scenario before: https://gitlab.isc.org/isc-projects/bind9/-/issues/4213.
```
23-Feb-2024 00:10:42.106 adjust_quantum: old=100, new=137
23-Feb-2024 00:10:42.106 calling free_rbtdb(.)
23-Feb-2024 00:10:42.106 done free_rbtdb(.)
23-Feb-2024 00:10:42.106 done free_rbtdb(oldsigs.example)
23-Feb-2024 00:10:42.106 done free_rbtdb(jitter.nsec3.example)
```
```
2024-02-23 00:18:18 INFO:autosign D:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D autosign_tmp_7ktl_4p5-ns3 -'.
2024-02-23 00:18:18 INFO:autosign D:Program terminated with signal SIGABRT, Aborted.
2024-02-23 00:18:18 INFO:autosign D:#0 0x00007f5df3ae9b9e in __GI_epoll_pwait (epfd=4, events=0x7ffe9b1a8be0, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:40
2024-02-23 00:18:18 INFO:autosign D:Download failed: Invalid argument. Continuing without source file ./misc/../sysdeps/unix/sysv/linux/epoll_pwait.c.
2024-02-23 00:18:18 INFO:autosign D:[Current thread is 1 (Thread 0x7f5df1217500 (LWP 52959))]
2024-02-23 00:18:18 INFO:autosign D:#0 0x00007f5df3ae9b9e in __GI_epoll_pwait (epfd=4, events=0x7ffe9b1a8be0, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:40
2024-02-23 00:18:18 INFO:autosign D:#1 0x00007f5df3ece522 in uv__io_poll (loop=0x7f5df0e53020, timeout=-1) at /usr/src/libuv-v1.47.0/src/unix/linux.c:1430
2024-02-23 00:18:18 INFO:autosign D:#2 0x00007f5df3eb3e20 in uv_run (loop=0x7f5df0e53020, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.47.0/src/unix/core.c:447
2024-02-23 00:18:18 INFO:autosign D:#3 0x00007f5df46b0324 in loop_thread (arg=arg@entry=0x7f5df0e53000) at loop.c:284
2024-02-23 00:18:18 INFO:autosign D:#4 0x00007f5df46c1af1 in thread_body (wrap=0x7f5df0ee7420) at thread.c:85
2024-02-23 00:18:18 INFO:autosign D:#5 0x00007f5df46c1b6a in isc_thread_main (func=func@entry=0x7f5df46b0299 <loop_thread>, arg=0x7f5df0e53000) at thread.c:116
2024-02-23 00:18:18 INFO:autosign D:#6 0x00007f5df46b12c4 in isc_loopmgr_run (loopmgr=0x7f5df0e20a80) at loop.c:456
2024-02-23 00:18:18 INFO:autosign D:#7 0x000055ad3d813480 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1574
```
[core.52959-backtrace.txt](/uploads/3594340469e8638ccfe6192044d7174a/core.52959-backtrace.txt)
[named.run](/uploads/9ff12f3ada8161d465dd0498f6dd7722/named.run)March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4599dns zone failed to reload after upgrade to latest ISC Bind (Ubuntu package)2024-02-26T15:38:01ZDavid Calafrancescodns zone failed to reload after upgrade to latest ISC Bind (Ubuntu package)<!--
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 make sure that you make the new issue
confident...<!--
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 make sure that you make the new issue
confidential by clicking the checkbox at the bottom!
-->
### Summary
<!-- Concisely summarize the bug encountered. -->
### BIND version affected
<!--
Make sure you are testing with the **latest** supported version of BIND
for a given branch. Many bugs have been fixed over time!
See https://kb.isc.org/docs/supported-platforms for the current list.
The latest source is available from https://www.isc.org/download/#BIND
Paste the output of `named -V` here.
-->
named -V
```
BIND 9.16.48-Ubuntu (Extended Support Version) <id:0dab57e>
running on Linux x86_64 5.4.0-172-generic #190-Ubuntu SMP Fri Feb 2 23:24:22 UTC 2024
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' '--runstatedir=/run' '--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' '--disable-isc-spnego' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-jSiMEl/bind9-9.16.48=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.4.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libuv version: 1.34.2
linked to libuv version: 1.34.2
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
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
```
**Upgraded yesterday from this version: **
named -V
```
BIND 9.16.1-Ubuntu (Stable Release) <id:d497c32>
running on Linux x86_64 5.4.0-162-generic #179-Ubuntu SMP Mon Aug 14 08:51:31 UTC 2023
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' '--runstatedir=/run' '--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' '--disable-isc-spnego' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-uTvsKR/bind9-9.16.1=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.4.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
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
<!--
This is extremely important! Be precise and use itemized lists, please.
Even if a default configuration is affected, please include the full configuration
files _you were testing with_.
Example:
1. Use _attached_ configuration file
2. Start BIND server with command: `named -g -c named.conf ...`
3. Simulate legitimate clients using command `dnsperf -S1 -d legit-queries ...`
4. Simulate attack traffic using command `dnsperf -S1 -d attack-queries ...`
-->
1. Zone file that was loading previous to upgrade now fails when the following lines are present in zone:
```
$ORIGIN _domainkey.gvtc.communication.gvtc.net.
hs1-2082415 CNAME gvtc-communication-gvtc-net.hs17a.dkim.hubspotemail.net.
hs2-2082415 CNAME gvtc-communication-gvtc-net.hs17b.dkim.hubspotemail.net.
$ORIGIN gvtc.communication.gvtc.net.
TXT "v=spf1 include:2082415.spf07.hubspotemail.net -all"
$ORIGIN gvtc.net.
```
The above fails to load zone with these errors:
```
Feb 23 01:15:31 ns0-0 named[1003]: /etc/bind/masters/db.gvtc.net:167: record with inherited owner (hs2-2082415._domainkey.gvtc.communication.gvtc.net) immediately after $ORIGIN (gvtc.communication.gvtc.net)
Feb 23 01:15:31 ns0-0 named[1003]: dns_master_load: /etc/bind/masters/db.gvtc.net:167: hs2-2082415._domainkey.gvtc.communication.gvtc.net: CNAME and other data
Feb 23 01:15:31 ns0-0 named[1003]: zone gvtc.net/IN: loading from master file /etc/bind/masters/db.gvtc.net failed: CNAME and other data
Feb 23 01:15:31 ns0-0 named[1003]: zone gvtc.net/IN: not loaded due to errors.
Feb 23 01:15:54 ns0-0 named[1003]: received control channel command 'reload gvtc.net'
Feb 23 01:15:54 ns0-0 named[1003]: /etc/bind/masters/db.gvtc.net:168: record with inherited owner (hs2-2082415._domainkey.gvtc.communication.gvtc.net) immediately after $ORIGIN (gvtc.communication.gvtc.net)
Feb 23 01:15:54 ns0-0 named[1003]: dns_master_load: /etc/bind/masters/db.gvtc.net:168: hs2-2082415._domainkey.gvtc.communication.gvtc.net: CNAME and other data
Feb 23 01:15:54 ns0-0 named[1003]: zone gvtc.net/IN: loading from master file /etc/bind/masters/db.gvtc.net failed: CNAME and other data
Feb 23 01:15:54 ns0-0 named[1003]: zone gvtc.net/IN: not loaded due to errors.
```
Zone was last edited on Feb 13th, 2024 and loaded without issue on prior version of ISC BIND9
Edited the zone to show this construct:
```
$ORIGIN _domainkey.gvtc.communication.gvtc.net.
hs1-2082415 CNAME gvtc-communication-gvtc-net.hs17a.dkim.hubspotemail.net.
hs2-2082415 CNAME gvtc-communication-gvtc-net.hs17b.dkim.hubspotemail.net.
; $ORIGIN gvtc.communication.gvtc.net.
; TXT "v=spf1 include:2082415.spf07.hubspotemail.net -all"
$ORIGIN gvtc.net.
$ORIGIN communication.gvtc.net.
gvtc TXT "v=spf1 include:2082415.spf07.hubspotemail.net -all"
$ORIGIN gvtc.net.
```
Now zone file loads cleanly again.
If we remove comments on two lines and comment the replacement lines, the zone fails. Flip it back to this formation, zone loads.
Only thing different as far as we can tell was updating Bind9 via Ubuntu.
### What is the current *bug* behavior?
<!-- What actually happens. -->
### What is the expected *correct* behavior?
<!-- What you should see instead. -->
### Relevant configuration files
<!-- Paste any relevant configuration files here - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential issue, it is advisable to
obscure key secrets; this can be done automatically by using
`named-checkconf -px`. -->
### Relevant logs
<!-- Paste any relevant logs here - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise. -->https://gitlab.isc.org/isc-projects/kea/-/issues/3261bump up lib versions for 2.5.62024-02-26T07:48:09ZWlodzimierz Wencelbump up lib versions for 2.5.6as stated in a subject, do it as last issue before freezeas stated in a subject, do it as last issue before freezekea2.5.6Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/32602.5.6 release checklist2024-02-28T07:57:12ZWlodzimierz Wencel2.5.6 release checklist# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of these checks and updates can be made before the actual fr...# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of these checks and updates can be made before the actual freeze. For new stable releases or maintenance releases, please don't use the `kea-dev` build farm; use a dedicated build farm for each release cycle.
1. [x] Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.aws.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/Kea_20Build_20Checks/)
1. [x] Check [Performance Test Results](https://jenkins.aws.isc.org/job/kea-dev/job/performance/lastSuccessfulBuild/artifact/qa-dhcp/kea/performance-jenkins/report.html) in Jenkins for drops in performance.
1. [x] Create a Gitlab issue for bumping up library versions and `KEA_HOOKS_VERSION` and notify developers.
* In case of no developers available, it can be done by running: [./tools/bump-lib-versions.sh](https://gitlab.isc.org/isc-projects/kea/-/blob/master/tools/bump-lib-versions.sh) Kea-q.w.e Kea-a.b.c (where `a.b.c` is the version to be released and `q.w.e` is the version previous to that).
1. [x] Look at the issue numbers in commit descriptions. Add to ChangeLog a mention about any change with visible impact that had not been mentioned already.
1. [ ] If any changes have been done to database schemas, then:
1. [ ] Check that a previously released schema has not been changed.
1. [ ] Check that the additions to `dhcpdb_create.*sql`, and nothing more nor less than what was added in this release, is present in a `upgrade_*_to_*.sh.in` script that should also have been added in this release.
1. [x] Prepare release notes.
1. [x] Create release note on Kea GitLab wiki and notify @tomek. It should be created under the `Release-Notes` directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/Release-Notes/release-notes-2.3.4
1. [x] Finish release notes and conduct its review.
1. [x] Notify support that release notes are ready for review. To avoid conflicts in edits wait with next step after review is done.
1. [x] Notify @sgoldlust or @vicky that release notes are ready for review. Due to time difference please do this at least 36 hours before planned release.
1. [ ] Check that packages can be uploaded to cloudsmith.
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick the latest pkg build in the `Packages` field, and the corresponding tarball build in the `Tarball` field, leave the rest as they are `PrivPubRepos: "private"`, `TarballOrPkg: "packages"`, `TestProdRepos: "testing"` and click `Build`.
1. If a new Cloudsmith repository is used, then:
1. [ ] Make sure access tokens have been synchronized from previous Cloudsmith repositories and to the [check-pkgs.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/pkgs-check/check-pkgs.py) QA tool.
1. [x] Check if ReadTheDocs can build Kea documentation. Alternatively, look for failures in emails if you know that the ReadTheDocs webhook is working.
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds) and wait for the build to complete.
The following steps may involve changing files in the repository.
1. [x] Run [update-code-for-release.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/update-code-for-release.py) \
Example command: `GITLAB_TOKEN='...' ./update-code-for-release.py 2.3.4 --repo-dir ~/isc/repos/kea/`. \
Help: `GITLAB_TOKEN='...' ./update-code-for-release.py --help`. \
The script requires an explicit flag for stable and maintenances releases e.g. `--repo-branch v2_4`. \
The script makes the following changes and actions:
1. Runs [prepare_kea_release.sh](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/prepare_kea_release.sh) that:
1. Adds release entries in ChangeLogs.
1. Updates Kea version in configure.ac.
1. Updates copyright years in files that were changed in current year.
1. Sorts message files.
1. Regenerates message files headers.
1. Regenerates parsers using Bison from Docker
1. [x] Run the script again with the `--upload-only` flag which:
1. Creates an issue in GitLab for release changes in kea repo.
1. Creates branches and merge requests for kea and kea-premium.
1. Commits the changes in both repos.
1. Checks out created branches in both repos.
1. Commits and pushes the changes to GitLab server.
1. [x] Check manually User's Guide sections:
1. [x] Chapter 1. Introduction
1. [ ] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [ ] Did we add any additional 3rd party software? Update if needed.
1. [ ] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. [x] Chapter 2. Quick Start
1. [ ] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. [x] Chapter 3. Installation
1. [ ] Check installation hierarchy (this is also automatically checked at the end of [ut-extended job](https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/)).
1. [ ] Check and update Build Requirements.
1. [ ] Check configure options against what `./configure -h` says.
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whitespaces, etc.
1. [x] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [x] If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the MR to master.
## Build selection, tarballs upload and sanity checks
This is the last moment to freeze code! :snowflake:
1. [x] Go to [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/) Jenkins job and pick the last tarball built - it will be a release candidate.
1. [ ] Check tarball before requesting sanity checks from the development team.
1. Download tarballs from picked Jenkins build
1. Check hook libraries.
1. Are there any new hook libraries installed in this release?
1. Are they in the proper tarball? Premium or subscription?
1. Do they have their own package?
1. Check sizes - is the new package reasonable?
1. Check installation tree, compare it with the previous release
1. Check installed libraries.
1. which were updated? (save results)
1. Do any of the libraries from the current release have lower version than in the previous release?
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if each of the installed binaries has a man page.
1. If not, is the binary included in the tarball? That might explain it.
1. Are man pages up to date?
1. Check if documentation is properly formatted, has correct versions and dates.
1. It's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid.
1. [x] Upload tarballs to repo.isc.org using Jenkins and send sanity checks request.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
1. In field `Release_Candidate` pick:
1. `rc1` if this is the first selected build for release, it will push the selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
1. next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in an error)
1. Submit the job that will automatically:
1. Upload the tarballs.
1. Create a GitLab issue for sanity checks, put the announcement there.
1. Send Sanity Checks announcement on the Kea/DHCP channel on Mattermost.\
The announcement includes:
- a link to chapter 4 Sanity Checks of the release process: [KeaReleaseProcess - SanityChecks](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks)
- a link to the GitLab issue
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
## Releasing Tarballs and Packages
Now it's time to publish the code.
1. [x] Update Release Notes with ChangeLog entries.
1. [x] Mark Jenkins jobs with release artifacts to be kept forever and update description of build by adding there version of released kea (e.g. `Kea-2.3.4`).
1. Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button and edit description:
1. [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/).
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/).
1. [x] Upload final tarballs to repo.isc.org.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
1. In field `Release_Candidate` pick `final`. This job will also:
- Open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) for signing final tarballs on repo.isc.org.
- Create Git tags `Kea-a.b.c` in Kea main and premium repositories.
- Create Gitlab releases `Kea-a.b.c` in Kea main and premium repositories.
1. [x] Sign tarballs with the personal key, by running [sign_kea_and_upload_asc.sh](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/sign_kea_and_upload_asc.sh) which signs, verifies signatures and uploads them.
- If release engineer does NOT have signing key, please contact team member.
1. [x] Confirm that the tarballs have the checksums mentioned on the signing ticket.
1. [ ] Wait for clearance from Security Officer to proceed with the public release (if applicable). If this is a security release, next steps will be impacted by CVE checklist.
1. [x] Login to repo.isc.org and upload final tarball to public ftp using the make-available script.
* Example command: `make-available --public --symlink=cur/2.3 /data/shared/sweng/kea/releases/2.3.4`.
* [x] For premium tarballs use `--private` option.
* For more information use `--debug` option.
* To overwrite existing content, use `--force` option.
* If you did a mistake, contact ASAP someone from the ops team to remove incorrectly uploaded tarballs.
* [x] save links to all premium tarballs and put them into signing ticket as a comment.
1. [x] Upload final RPM & DEB packages, tarballs and sign files to cloudsmith.io:
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick your selected pkg build in the `Packages` field, the corresponding tarball build in the `Tarball` field, `PrivPubRepos: "both"`, `TarballOrPkg: "both"`, `TestProdRepos: "production"` and click `Build`.
- This step also verifies sign files.
1. When it finishes run check: [releases-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/).
1. [ ] Check that Docker images can be uploaded to Cloudsmith. Run [build-upload-docker](https://jenkins.aws.isc.org/job/kea-dev/job/build-upload-docker/).
* Make sure the right package job is selected under `Packages`.
* Tick `Upload`.
* Leave `TestProdRepos` to `testing`.
* Leave `versionTag` ticked.
* Tick `latestTag` if this is a stable or a maintenance release.
* If this is a stable or maintenance release, change `KeaDockerBranch` to the appropriate branch.
* Press `Build`.
1. [x] Build and upload Docker images to Cloudsmith. Run [build-upload-docker](https://jenkins.aws.isc.org/job/kea-dev/job/build-upload-docker/) with the same actions as above except change `TestProdRepos` to `production`.
1. [x] Update ReadTheDocs:
1. Trick ReadTheDocs into pulling the latest tags. Click `Build version` on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. If it's a stable release, change the default version to point to this stable release. `Admin -> Advanced Settings -> Default version* -> Kea-a.b.c`.
1. [x] Create an issue and a merge request to bump up Kea version in `configure.ac` to next development version which could be, based on just released version `a.b.c`:
* `a.b.z-git` where `z == c + 1` most of the time, or
* `a.y.0-git` where `y == b + 2` if a new development series starts, or
* `x.1.0-git` where `x == a + 1` when the released minor version `b` is 9 and `a.b.c` was the last version in the development series and a new development version is coming up next.
1. [x] Contact Marketing team, and find a member who will continue work on this release:
1. [x] Assign this ticket to person who will continue.
1. [ ] Share link to signing ticket either directly or as a comment in this issue.
## Marketing
1. [x] Publish links to downloads on ISC website.
1. [ ] Update the supported versions document in the Salesforce portal (if there are stable versions released), and update the Kea document in the portal.
1. [ ] If it is a new `major.minor` version, SWENG will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Verify that the KB on installing from Cloudsmith has also been updated, then update the Kea document in the SF portal and notify support customers that this new private repo exists.
1. [ ] If a new Cloudsmith repository is used, make sure that the Zapier scripts are updated.
* If those are not updated, there was an error made during preparation for new stable release. Please contact QA team and coordinate fix.
1. [x] Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version.
1. [x] Write release email to _kea-announce_.
1. [ ] Write email to _kea-users_ (if a major release).
1. [x] Announce on social media.
1. [x] Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea\_(software)).
1. [ ] Write blog article (if a major release).
1. [ ] Update [Kea page on website if any new hooks](https://www.isc.org/kea/).
1. [ ] Update Kea Premium and Kea Subscription data sheets if any new hooks.
1. [ ] Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
1. [x] Contact Support team, find a person who will continue this release and assign this issue to them.
## Support
1. [x] Update tickets in case of waiting for support customers.
1. [x] Close this ticketkea2.5.6Peter DaviesPeter Davies2024-02-28https://gitlab.isc.org/isc-projects/bind9/-/issues/4597Potential race condition in TTL heap introduced by February 2024 BIND release...2024-03-07T22:29:41ZCathy AlmondPotential race condition in TTL heap introduced by February 2024 BIND release patchesReported to us by an OEM customer who integrates BIND into their own appliance and redistributes:
> In rbtdb.c, there's a call path expirenodeall()->expire_headerlist()->set_ttl()->isc_heap_increased() or isc_heap_decreased(), where a s...Reported to us by an OEM customer who integrates BIND into their own appliance and redistributes:
> In rbtdb.c, there's a call path expirenodeall()->expire_headerlist()->set_ttl()->isc_heap_increased() or isc_heap_decreased(), where a shared TTL heap (per node lock bucket) is modified. Previously, this path is protected by the node write lock, but it's now unprotected, so there can be a race on the heap with, e.g, another thread adding a cache entry to the cache (thus to the TTL heap). expirenodeall() is called via dns_db_expirenodeall(), which is indirectly used for "rndc dumpdb" or "dumpdb flushname/flushtree". So it may be possible, though I've not tried it myself, that invoking these rndc commands results in a crash on a busy recursive server.
>
> It's basically the same for other cases: expirenode() and delete_callback(), although in the latter case the protected data is different. Also, we've found that there's probably no code path to these functions in practice, so it's not a big deal.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4596Regression in cache cleaning2024-03-08T11:20:36ZOndřej SurýRegression in cache cleaningThere's an regression introduced in the fix to #4383 that causes the cache memory to clean too slow, so busy resolvers can run out of configured cache memory by not cleaning expired (TTL-expired) records to be not cleaned from the memory...There's an regression introduced in the fix to #4383 that causes the cache memory to clean too slow, so busy resolvers can run out of configured cache memory by not cleaning expired (TTL-expired) records to be not cleaned from the memory fast enough.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4595Regression in change for CVE-2023-5680 that can cause named to crash2024-03-08T11:03:30ZCathy AlmondRegression in change for CVE-2023-5680 that can cause named to crashReported to us by an OEM customer who integrates BIND into their own appliance and redistributes:
> NOTE: you might find this as a security issue.
>
> We believe we've identified the likely cause of the crash. It's a regression due to ...Reported to us by an OEM customer who integrates BIND into their own appliance and redistributes:
> NOTE: you might find this as a security issue.
>
> We believe we've identified the likely cause of the crash. It's a regression due to the change for CVE-2023-5680. I've added a patch to a unit test for BIND 9.18.24-S1 that can reproduce the crash. I confirmed the crash happened for 9.18.24-S1 and 9.16.48-S1. One straightforward fix is the other patch I've attached to this ticket.
>
> I believe an engineer familiar with the code base can understand how it happens by reading the patch (it has a lot of comments explaining it), so I won't repeat it here. But I'd note one thing: the introduction of the "old IP tree" breaks one critical assumption: when a node's last reference is released, the cleanup makes sure that there is no rdatasetheader that would still have to be cleaned up (such as an expired cache entry). With this, and the fact that whenerver an rdatasetheader makes a node dirty either a node (read or rw) lock is acquired or a node's reference is increased from 0, it was previously guaranteed that overmem purge never frees other entries that the purge code may reference later. Now that the basic assumption is broken, we now have this crash, and there might be other such cases.
>
> I've not tried to reproduce a crash using a `named` executable, but the unit test indicates it's probably possible to trigger the crash by an external attacker, albeit with some high barriers such as being listed as an "ecs-zone" in the named's configuration. You may want to deal with this case as such.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/kea/-/issues/3258ddns-conflict-resolution-mode appears to not be documented2024-02-21T15:36:15ZThomas Markwalderddns-conflict-resolution-mode appears to not be documented#2276 changed boolean use-ddns-conflict-resolution to an enum ddns-conflict-resolution-mode but the latter was not documented in the ARM?#2276 changed boolean use-ddns-conflict-resolution to an enum ddns-conflict-resolution-mode but the latter was not documented in the ARM?https://gitlab.isc.org/isc-projects/bind9/-/issues/4591TTL-based cache cleaning in rbtdb ineffective (M/N problem)2024-03-20T13:50:45ZOndřej SurýTTL-based cache cleaning in rbtdb ineffective (M/N problem)Copying stuff from MatterMost for permanent record:
How it started?
> @ondrej: But I don't know actually - if there's something blocking the top of the heap to be cleaned up (dunno why yet), it could block cleaning everything else behin...Copying stuff from MatterMost for permanent record:
How it started?
> @ondrej: But I don't know actually - if there's something blocking the top of the heap to be cleaned up (dunno why yet), it could block cleaning everything else behind it
So, here's a summary of our finding
The TTL based cleaning is opportunistic. When we are inserting a new node, we look at the top of the heap ("list sorted by TTL-value") and if TTL of the top of the heap is expired, we try to eradicate the data it stores from the cache. The code that decides whether we will do the TTL-based cleaning looks like this:
```c
header = isc_heap_element(rbtdb->heaps[rbtnode->locknum], 1);
if (header != NULL) {
dns_ttl_t rdh_ttl = header->rdh_ttl;
/* Only account for stale TTL if cache is not overmem */
if (!cache_is_overmem) {
rdh_ttl += STALE_TTL(header, rbtdb);
}
if (rdh_ttl < now - RBTDB_VIRTUAL) {
expire_header(rbtdb, header, tree_locked,
expire_ttl);
}
}
```
Now, the RBTDB_VIRTUAL is this:
```
/*
* Allow clients with a virtual time of up to 5 minutes in the past to see
* records that would have otherwise have expired.
*/
#define RBTDB_VIRTUAL 300
```
Which means that even with 0 TTL records, the TTL-based cleaning will not kick-in until 5 minutes has passed.
Now what happens if you insert N records (where N could be large) within the first 5 minutes (cold bootstrap)?
After 5 minutes the TTL based cleaning should kick-in, but that's only if everything in the cache has expired, but even with that.
If we insert M records in the next minute, only M records will gets cleaned at maximum.
But anything that has longer TTL will just add to N, so the backlog of the records that are not subject to the TTL-based cleaning will build up over time until we are overmem and LRU based cleaning kicks in.
Additionally, @ondrej found out that there are records with `rdh_ttl` set to `0` if you just run `dnsperf` on a cold cache resolver, which made us puzzled - shouldn't we be cleaning records only after 5 minutes?
@michal did some excellent work and found out following:
so, i looked at those "zero TTL" frees that happen very shortly into the start of regular resolver operation
turns out that these are "superseded" headers
now, i don't understand why RBTDB does that. but it's this branch in add32() that expires these headers: https://gitlab.isc.org/isc-projects/bind9/-/blob/8fb49c5a8acdb37d4f4be0c5f5b19645d0103f48/lib/dns/rbtdb.c#L6677-6714
basically, AFAICT, what happens here is:
resolver: hey, RBTDB, add this shiny new SOA rdataset header to the cache
RBTDB: oh okay, let me see if i have a SOA header on that node already...
RBTDB: yup, got one. i'll just expire the one i had in there before (topheader) and insert the new one you gave me (newheader).
what i don't understand is why it just doesn't leave that old (identical, AFAICT) rdataset intact. but i'll move on with the reasoning for now.
so, the "previously-topmost" SOA header has its TTL set to zero, so it lands on the top of one of the TTL heaps
once we add a new rdataset, it should be cleaned up. but, as we already established yesterday, that only happens if the reference count of its node is zero.
meanwhile, in my very basic test (literally seconds into firing up dnsperf with the query set we use for respdiff tests, at some 1 kQPS), those rdatasets at the top of the heap are for nodes like net. or com. whose reference counts are around 60, or maybe 80 references. and until that count goes to zero, the first rdataset on the TTL heap will not disappear from there, blocking any rdataset headers on the same TTL heap from being cleaned up as well (backlog)
so, i thought "how bad is it and can we measure it?" and oh, boy, he could:
```
20-Feb-2024 10:46:29.561 connection refused resolving 'geo.fortinet.net/NS/IN': 104.198.248.186#53
20-Feb-2024 10:46:29.564 DNS format error from 203.205.195.75#53 resolving ns3.qq.com/AAAA for <unknown>: Name qq.com (SOA) not subdomain of zone ns3.qq.com -- invalid response
20-Feb-2024 10:46:29.564 FORMERR resolving 'ns3.qq.com/AAAA/IN': 203.205.195.75#53
20-Feb-2024 10:46:29.564 DNS format error from 108.136.87.44#53 resolving api.cloud.huawei.com/AAAA for 127.0.0.1#34840: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
20-Feb-2024 10:46:29.564 FORMERR resolving 'api.cloud.huawei.com/AAAA/IN': 108.136.87.44#53
-- 0 msecs since expiry
-- 0 msecs since expiry
-- 106 msecs since expiry
-- 106 msecs since expiry
-- 29 msecs since expiry
-- 29 msecs since expiry
20-Feb-2024 10:46:29.574 success resolving 'a.karma.sc2.fsapi.com/A' after disabling qname minimization due to 'ncache nxdomain'
-- 243 msecs since expiry
-- 246 msecs since expiry
-- 249 msecs since expiry
-- 433 msecs since expiry
-- 806 msecs since expiry
-- 813 msecs since expiry
-- 243 msecs since expiry
-- 246 msecs since expiry
-- 249 msecs since expiry
-- 433 msecs since expiry
-- 806 msecs since expiry
-- 0 msecs since expiry
-- 816 msecs since expiry
-- 816 msecs since expiry
-- 123 msecs since expiry
-- 323 msecs since expiry
-- 123 msecs since expiry
-- 323 msecs since expiry
20-Feb-2024 10:46:29.601 success resolving 'F00DCFRIBM41.zf.if.atcsg.net/A' after disabling qname minimization due to 'ncache nxdomain'
20-Feb-2024 10:46:29.624 REFUSED unexpected RCODE resolving 'cloud.Jensen.com.cn/NS/IN': 47.118.199.194#53
-- 0 msecs since expiry
-- 0 msecs since expiry
20-Feb-2024 10:46:29.677 DNS format error from 3.97.163.50#53 resolving api.cloud.huawei.com/AAAA for 127.0.0.1#34840: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
20-Feb-2024 10:46:29.677 FORMERR resolving 'api.cloud.huawei.com/AAAA/IN': 3.97.163.50#53
-- 6 msecs since expiry
-- 3 msecs since expiry
-- 9 msecs since expiry
-- 0 msecs since expiry
20-Feb-2024 10:46:29.801 REFUSED unexpected RCODE resolving 'cloud.Jensen.com.cn/NS/IN': 39.96.153.33#53
-- 3 msecs since expiry
-- 3 msecs since expiry
-- 46 msecs since expiry
-- 19 msecs since expiry
-- 0 msecs since expiry
-- 39 msecs since expiry
-- 0 msecs since expiry
-- 0 msecs since expiry
-- 3 msecs since expiry
-- 3 msecs since expiry
-- 126 msecs since expiry
-- 0 msecs since expiry
-- 0 msecs since expiry
-- 0 msecs since expiry
20-Feb-2024 10:46:30.104 REFUSED unexpected RCODE resolving 'cloud.Jensen.com.cn/NS/IN': 139.224.142.104#53
-- 286 msecs since expiry
-- 0 msecs since expiry
-- 69 msecs since expiry
-- 13 msecs since expiry
20-Feb-2024 10:46:30.307 success resolving 'hcdnd.csfw.c.cdnhwc6.com/AAAA' after disabling qname minimization due to 'ncache nxdomain'
-- 0 msecs since expiry
-- 199 msecs since expiry
-- 269 msecs since expiry
-- 656 msecs since expiry
-- 689 msecs since expiry
-- 746 msecs since expiry
-- 789 msecs since expiry
-- 816 msecs since expiry
-- 819 msecs since expiry
-- 819 msecs since expiry
-- 839 msecs since expiry
-- 853 msecs since expiry
-- 873 msecs since expiry
-- 876 msecs since expiry
-- 889 msecs since expiry
-- 896 msecs since expiry
-- 896 msecs since expiry
-- 916 msecs since expiry
-- 936 msecs since expiry
-- 956 msecs since expiry
-- 969 msecs since expiry
-- 979 msecs since expiry
-- 983 msecs since expiry
-- 999 msecs since expiry
-- 999 msecs since expiry
-- 1006 msecs since expiry
-- 1006 msecs since expiry
-- 1053 msecs since expiry
-- 1053 msecs since expiry
-- 1063 msecs since expiry
-- 1066 msecs since expiry
-- 1073 msecs since expiry
-- 1079 msecs since expiry
-- 1083 msecs since expiry
-- 1089 msecs since expiry
-- 1096 msecs since expiry
-- 1133 msecs since expiry
-- 1139 msecs since expiry
-- 1156 msecs since expiry
-- 1163 msecs since expiry
-- 1166 msecs since expiry
-- 1179 msecs since expiry
-- 1183 msecs since expiry
-- 1189 msecs since expiry
-- 1193 msecs since expiry
-- 1196 msecs since expiry
-- 1199 msecs since expiry
-- 1223 msecs since expiry
-- 1223 msecs since expiry
-- 1249 msecs since expiry
-- 1259 msecs since expiry
-- 1276 msecs since expiry
-- 1293 msecs since expiry
-- 1336 msecs since expiry
-- 1363 msecs since expiry
-- 1369 msecs since expiry
-- 1379 msecs since expiry
-- 1393 msecs since expiry
-- 1396 msecs since expiry
-- 1399 msecs since expiry
-- 1403 msecs since expiry
-- 1423 msecs since expiry
-- 1429 msecs since expiry
-- 1436 msecs since expiry
-- 1436 msecs since expiry
-- 1439 msecs since expiry
-- 1446 msecs since expiry
-- 1446 msecs since expiry
-- 1466 msecs since expiry
-- 1466 msecs since expiry
-- 1469 msecs since expiry
-- 1473 msecs since expiry
-- 1486 msecs since expiry
-- 1503 msecs since expiry
-- 1506 msecs since expiry
-- 1516 msecs since expiry
-- 1539 msecs since expiry
-- 1539 msecs since expiry
-- 1556 msecs since expiry
-- 1566 msecs since expiry
-- 1569 msecs since expiry
-- 1589 msecs since expiry
-- 1623 msecs since expiry
-- 1623 msecs since expiry
-- 1629 msecs since expiry
-- 1636 msecs since expiry
-- 1636 msecs since expiry
-- 1649 msecs since expiry
-- 1679 msecs since expiry
-- 1686 msecs since expiry
-- 1703 msecs since expiry
-- 1703 msecs since expiry
-- 1716 msecs since expiry
-- 1726 msecs since expiry
-- 1736 msecs since expiry
-- 1773 msecs since expiry
-- 1796 msecs since expiry
-- 1796 msecs since expiry
-- 1799 msecs since expiry
-- 1803 msecs since expiry
-- 1829 msecs since expiry
-- 1839 msecs since expiry
-- 1876 msecs since expiry
-- 1879 msecs since expiry
-- 1883 msecs since expiry
-- 1889 msecs since expiry
-- 1889 msecs since expiry
-- 1889 msecs since expiry
-- 1899 msecs since expiry
-- 1946 msecs since expiry
-- 1956 msecs since expiry
-- 1983 msecs since expiry
-- 2013 msecs since expiry
-- 2013 msecs since expiry
-- 2023 msecs since expiry
-- 2049 msecs since expiry
-- 2059 msecs since expiry
-- 2063 msecs since expiry
-- 2079 msecs since expiry
-- 2106 msecs since expiry
-- 2109 msecs since expiry
-- 2119 msecs since expiry
-- 2136 msecs since expiry
-- 2156 msecs since expiry
-- 2183 msecs since expiry
-- 2199 msecs since expiry
-- 2203 msecs since expiry
-- 2219 msecs since expiry
-- 2223 msecs since expiry
-- 2229 msecs since expiry
-- 2243 msecs since expiry
-- 2253 msecs since expiry
-- 2263 msecs since expiry
-- 2286 msecs since expiry
-- 2303 msecs since expiry
-- 2343 msecs since expiry
-- 2356 msecs since expiry
-- 2376 msecs since expiry
-- 2376 msecs since expiry
-- 2379 msecs since expiry
-- 2386 msecs since expiry
-- 2416 msecs since expiry
-- 2426 msecs since expiry
-- 2433 msecs since expiry
-- 2449 msecs since expiry
-- 2466 msecs since expiry
-- 2479 msecs since expiry
-- 2509 msecs since expiry
-- 2516 msecs since expiry
-- 2523 msecs since expiry
-- 2529 msecs since expiry
-- 2536 msecs since expiry
-- 2539 msecs since expiry
-- 2539 msecs since expiry
-- 2543 msecs since expiry
-- 2553 msecs since expiry
-- 2559 msecs since expiry
-- 2569 msecs since expiry
-- 2593 msecs since expiry
-- 2609 msecs since expiry
-- 2616 msecs since expiry
-- 2623 msecs since expiry
-- 2629 msecs since expiry
-- 2656 msecs since expiry
-- 2659 msecs since expiry
-- 2673 msecs since expiry
-- 2716 msecs since expiry
-- 2766 msecs since expiry
-- 2773 msecs since expiry
-- 2773 msecs since expiry
-- 2776 msecs since expiry
-- 2783 msecs since expiry
-- 2789 msecs since expiry
-- 2823 msecs since expiry
-- 2843 msecs since expiry
-- 2879 msecs since expiry
-- 2879 msecs since expiry
-- 2886 msecs since expiry
-- 2899 msecs since expiry
-- 2919 msecs since expiry
-- 2926 msecs since expiry
-- 2949 msecs since expiry
-- 2956 msecs since expiry
-- 2956 msecs since expiry
-- 2956 msecs since expiry
-- 2979 msecs since expiry
-- 2983 msecs since expiry
-- 2983 msecs since expiry
-- 2986 msecs since expiry
-- 3033 msecs since expiry
-- 3039 msecs since expiry
-- 3049 msecs since expiry
-- 3066 msecs since expiry
-- 3086 msecs since expiry
-- 3126 msecs since expiry
-- 3129 msecs since expiry
-- 3156 msecs since expiry
-- 3169 msecs since expiry
-- 3173 msecs since expiry
-- 3176 msecs since expiry
-- 3226 msecs since expiry
-- 3253 msecs since expiry
-- 3266 msecs since expiry
-- 3269 msecs since expiry
-- 3279 msecs since expiry
-- 3279 msecs since expiry
-- 3299 msecs since expiry
-- 3323 msecs since expiry
-- 3323 msecs since expiry
-- 3336 msecs since expiry
-- 3336 msecs since expiry
-- 3363 msecs since expiry
-- 3366 msecs since expiry
-- 3396 msecs since expiry
-- 3399 msecs since expiry
-- 3409 msecs since expiry
-- 3449 msecs since expiry
-- 3463 msecs since expiry
-- 3466 msecs since expiry
-- 3499 msecs since expiry
-- 0 msecs since expiry
-- 199 msecs since expiry
-- 269 msecs since expiry
-- 656 msecs since expiry
-- 689 msecs since expiry
-- 746 msecs since expiry
-- 789 msecs since expiry
-- 816 msecs since expiry
-- 819 msecs since expiry
-- 819 msecs since expiry
-- 839 msecs since expiry
-- 853 msecs since expiry
-- 873 msecs since expiry
-- 876 msecs since expiry
-- 889 msecs since expiry
-- 896 msecs since expiry
-- 896 msecs since expiry
-- 916 msecs since expiry
-- 936 msecs since expiry
-- 956 msecs since expiry
-- 969 msecs since expiry
-- 979 msecs since expiry
-- 983 msecs since expiry
-- 999 msecs since expiry
-- 999 msecs since expiry
-- 1006 msecs since expiry
-- 1006 msecs since expiry
-- 1053 msecs since expiry
-- 1053 msecs since expiry
-- 1063 msecs since expiry
-- 1066 msecs since expiry
-- 1073 msecs since expiry
-- 1079 msecs since expiry
-- 1083 msecs since expiry
-- 1089 msecs since expiry
-- 1096 msecs since expiry
-- 1133 msecs since expiry
-- 1139 msecs since expiry
-- 1156 msecs since expiry
-- 1163 msecs since expiry
-- 1166 msecs since expiry
-- 1179 msecs since expiry
-- 1183 msecs since expiry
-- 1189 msecs since expiry
-- 1196 msecs since expiry
-- 1199 msecs since expiry
-- 1203 msecs since expiry
-- 1226 msecs since expiry
-- 1226 msecs since expiry
-- 1253 msecs since expiry
-- 1263 msecs since expiry
-- 1279 msecs since expiry
-- 1296 msecs since expiry
-- 1339 msecs since expiry
-- 1366 msecs since expiry
-- 1373 msecs since expiry
-- 1383 msecs since expiry
-- 1396 msecs since expiry
-- 1399 msecs since expiry
-- 1403 msecs since expiry
-- 1406 msecs since expiry
-- 1426 msecs since expiry
-- 1433 msecs since expiry
-- 1439 msecs since expiry
-- 1439 msecs since expiry
-- 1443 msecs since expiry
-- 1449 msecs since expiry
-- 1449 msecs since expiry
-- 1469 msecs since expiry
-- 1469 msecs since expiry
-- 1473 msecs since expiry
-- 1476 msecs since expiry
-- 1489 msecs since expiry
-- 1506 msecs since expiry
-- 1509 msecs since expiry
-- 1519 msecs since expiry
-- 1543 msecs since expiry
-- 1543 msecs since expiry
-- 1559 msecs since expiry
-- 1569 msecs since expiry
-- 1573 msecs since expiry
-- 1593 msecs since expiry
-- 1626 msecs since expiry
-- 1626 msecs since expiry
-- 1633 msecs since expiry
-- 1639 msecs since expiry
-- 1639 msecs since expiry
-- 1653 msecs since expiry
-- 1683 msecs since expiry
-- 1689 msecs since expiry
-- 1706 msecs since expiry
-- 1706 msecs since expiry
-- 1719 msecs since expiry
-- 1729 msecs since expiry
-- 1739 msecs since expiry
-- 1776 msecs since expiry
-- 1799 msecs since expiry
-- 1799 msecs since expiry
-- 1803 msecs since expiry
-- 1806 msecs since expiry
-- 1833 msecs since expiry
-- 1843 msecs since expiry
-- 1879 msecs since expiry
-- 1883 msecs since expiry
-- 1886 msecs since expiry
-- 1893 msecs since expiry
-- 1893 msecs since expiry
-- 1893 msecs since expiry
-- 1903 msecs since expiry
-- 1949 msecs since expiry
-- 1959 msecs since expiry
-- 1986 msecs since expiry
-- 2016 msecs since expiry
-- 2016 msecs since expiry
-- 2026 msecs since expiry
-- 2053 msecs since expiry
-- 2063 msecs since expiry
-- 2066 msecs since expiry
-- 2083 msecs since expiry
-- 2109 msecs since expiry
-- 2113 msecs since expiry
-- 2123 msecs since expiry
-- 2139 msecs since expiry
-- 2159 msecs since expiry
-- 2186 msecs since expiry
-- 2203 msecs since expiry
-- 2206 msecs since expiry
-- 2223 msecs since expiry
-- 2226 msecs since expiry
-- 2233 msecs since expiry
-- 2246 msecs since expiry
-- 2256 msecs since expiry
-- 2266 msecs since expiry
-- 2289 msecs since expiry
-- 2306 msecs since expiry
-- 2346 msecs since expiry
-- 2359 msecs since expiry
-- 2379 msecs since expiry
-- 2379 msecs since expiry
-- 2383 msecs since expiry
-- 2389 msecs since expiry
-- 2419 msecs since expiry
-- 2429 msecs since expiry
-- 2436 msecs since expiry
-- 2453 msecs since expiry
-- 2469 msecs since expiry
-- 2483 msecs since expiry
-- 2513 msecs since expiry
-- 2519 msecs since expiry
-- 2526 msecs since expiry
-- 2533 msecs since expiry
-- 2539 msecs since expiry
-- 2543 msecs since expiry
-- 2543 msecs since expiry
-- 2546 msecs since expiry
-- 2556 msecs since expiry
-- 2563 msecs since expiry
-- 2573 msecs since expiry
-- 2596 msecs since expiry
-- 2613 msecs since expiry
-- 2619 msecs since expiry
-- 2626 msecs since expiry
-- 2633 msecs since expiry
-- 2659 msecs since expiry
-- 2663 msecs since expiry
-- 2676 msecs since expiry
-- 2719 msecs since expiry
-- 2769 msecs since expiry
-- 2776 msecs since expiry
-- 2776 msecs since expiry
-- 2779 msecs since expiry
-- 2786 msecs since expiry
-- 2793 msecs since expiry
-- 2826 msecs since expiry
-- 2846 msecs since expiry
-- 2883 msecs since expiry
-- 2883 msecs since expiry
-- 2889 msecs since expiry
-- 2903 msecs since expiry
-- 2923 msecs since expiry
-- 2929 msecs since expiry
-- 2956 msecs since expiry
-- 2959 msecs since expiry
-- 2959 msecs since expiry
-- 2959 msecs since expiry
-- 2983 msecs since expiry
-- 2986 msecs since expiry
-- 2986 msecs since expiry
-- 2989 msecs since expiry
-- 3036 msecs since expiry
-- 3043 msecs since expiry
-- 3053 msecs since expiry
-- 3069 msecs since expiry
-- 3089 msecs since expiry
-- 3129 msecs since expiry
-- 3133 msecs since expiry
-- 3159 msecs since expiry
-- 3173 msecs since expiry
-- 3176 msecs since expiry
-- 3179 msecs since expiry
-- 3229 msecs since expiry
-- 3256 msecs since expiry
-- 3269 msecs since expiry
-- 3273 msecs since expiry
-- 3283 msecs since expiry
-- 3283 msecs since expiry
-- 3303 msecs since expiry
-- 3326 msecs since expiry
-- 3326 msecs since expiry
-- 3339 msecs since expiry
-- 3339 msecs since expiry
-- 3366 msecs since expiry
-- 3369 msecs since expiry
-- 3399 msecs since expiry
-- 3403 msecs since expiry
-- 3413 msecs since expiry
-- 3453 msecs since expiry
-- 3466 msecs since expiry
-- 3469 msecs since expiry
-- 3 msecs since expiry
20-Feb-2024 10:46:30.324 REFUSED unexpected RCODE resolving 'cloud.Jensen.com.cn/NS/IN': 39.96.153.53#53
-- 0 msecs since expiry
-- 0 msecs since expiry
20-Feb-2024 10:46:30.524 REFUSED unexpected RCODE resolving 'cloud.Jensen.com.cn/NS/IN': 39.96.153.32#53
-- 0 msecs since expiry
```
So, there are multiple issues circling around the TTL-based cleaning.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4589Adjust SyncPublish Interval for dnssec-policy to minimize delay2024-02-20T05:29:16ZAzizbek KadirovAdjust SyncPublish Interval for dnssec-policy to minimize delayWhen enabling the dnssec-policy for a zone in BIND9, I've noticed that the default SyncPublish interval is set to 1 day + 5 minutes.
Steps to reproduce:
1. Create a zone:
```plaintext
zone "example.com" {
type master;
file "/var/cac...When enabling the dnssec-policy for a zone in BIND9, I've noticed that the default SyncPublish interval is set to 1 day + 5 minutes.
Steps to reproduce:
1. Create a zone:
```plaintext
zone "example.com" {
type master;
file "/var/cache/bind/zones/example.com.zone";
dnssec-policy "default";
inline-signing yes;
key-directory "/var/cache/bind/keys/example.com";
};
```
2. reload bind with `rndc reload`
3. 3 files generated: .key, .private, .state.
4. Inside file, in metadata we can see following:
```plaintext
; This is a key-signing key, keyid 9061, for example.com.
; Created: 20240219101033 (Mon Feb 19 15:10:33 2024)
; Publish: 20240219101033 (Mon Feb 19 15:10:33 2024)
; Activate: 20240219101033 (Mon Feb 19 15:10:33 2024)
; SyncPublish: 20240220111533 (Tue Feb 20 16:15:33 2024)
```
5. It appears more efficient to reduce this interval to just +5 minutes. Currently, the delay incurred by the default interval might lead to potential synchronization issues or delays in propagating changes. By minimizing the interval to +5 minutes, we can ensure timely synchronization of DNSSEC-related updates without unnecessary delay. I couldn't find how to reduce SyncPublish time using custom dnssec-policyhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4588CID 486508: Control flow issues in lib/ns/query.c2024-02-21T10:51:33ZMichal NowakCID 486508: Control flow issues in lib/ns/query.cCoverity Scan claims a control flow issue in `lib/ns/query.c`.
```cpp
/lib/ns/query.c: 6307 in fetch_callback()
6301 * Return an error to the client, or just drop.
6302 */
6303 if (fetch_canceled) {
6304 CTRACE...Coverity Scan claims a control flow issue in `lib/ns/query.c`.
```cpp
/lib/ns/query.c: 6307 in fetch_callback()
6301 * Return an error to the client, or just drop.
6302 */
6303 if (fetch_canceled) {
6304 CTRACE(ISC_LOG_ERROR, "fetch cancelled");
6305 query_error(client, DNS_R_SERVFAIL, __LINE__);
6306 } else {
>>> CID 486508: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "query_next(client, ISC_R_CA...".
6307 query_next(client, ISC_R_CANCELED);
6308 }
6309
6310 /*
6311 * Free any persistent plugin data that was allocated to
6312 * service the client, then detach the client object.
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/kea/-/issues/3253Perfmon-Hook-Task-3 Implement MonitioredDurationStore and AlarmStore2024-03-18T21:40:45ZThomas MarkwalderPerfmon-Hook-Task-3 Implement MonitioredDurationStore and AlarmStoreComplete Hook Task 3: implement MonitioredDurationStore and AlarmStore classes. See
https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/performance-monitor#perfmon-hook-tasksComplete Hook Task 3: implement MonitioredDurationStore and AlarmStore classes. See
https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/performance-monitor#perfmon-hook-taskskea2.5.7Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4583BIND Upgrade2024-02-15T12:44:12ZGitLab Support BotBIND UpgradeHello,
Our bind version seems below. How can we upgrade bind version?
And if we upgrade bind version, is there any problem?
[root@ns2 ~]# named -v
BIND 9.11.36-RedHat-9.11.36-11.el8_9 (Extended Support Version) <id:68dbd5b>
Thanks
SemraHello,
Our bind version seems below. How can we upgrade bind version?
And if we upgrade bind version, is there any problem?
[root@ns2 ~]# named -v
BIND 9.11.36-RedHat-9.11.36-11.el8_9 (Extended Support Version) <id:68dbd5b>
Thanks
Semrahttps://gitlab.isc.org/isc-projects/bind9/-/issues/4580Add resolver.arpa to the built in empty zones2024-03-29T09:34:44ZMark AndrewsAdd resolver.arpa to the built in empty zonesRFC 9462 adds resolver.arpa to the lists of empty zones.
```
6.4. Handling Non-DDR Queries for resolver.arpa
DNS resolvers that support DDR by responding to queries for _dns.resolver.arpa. MUST treat resolver.arpa as a
locally served z...RFC 9462 adds resolver.arpa to the lists of empty zones.
```
6.4. Handling Non-DDR Queries for resolver.arpa
DNS resolvers that support DDR by responding to queries for _dns.resolver.arpa. MUST treat resolver.arpa as a
locally served zone per [RFC6303]. In practice, this means that resolvers SHOULD respond to queries of any
type other than SVCB for _dns.resolver.arpa. with NODATA and queries of any type for any domain name under
resolver.arpa with NODATA.
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4577bind 9.18.24 on Ubuntu 20.04 doesn't start due to "type=notify" in named.service2024-02-14T09:58:47ZPascal Ernsterbind 9.18.24 on Ubuntu 20.04 doesn't start due to "type=notify" in named.service### Summary
When installing `bind9 1:9.18.24-1+ubuntu20.04.1+deb.sury.org+1` from ISC's PPA on Ubuntu 20.04, the `named.service` unit hangs during the post-install phase of the package installation, and more generally, always when the `...### Summary
When installing `bind9 1:9.18.24-1+ubuntu20.04.1+deb.sury.org+1` from ISC's PPA on Ubuntu 20.04, the `named.service` unit hangs during the post-install phase of the package installation, and more generally, always when the `named.service` unit is started. This is caused by the `type=notify` line that is present in the `named.service` unit although the actual support for systemd notify is only present in bind's 9.19.x version branch. After a 90 seconds, the unit runs into a timeout, and the `bind9` package is left in an unconfigured/semi-configured state in apt/aptitude.
Note: Ubuntu's `bind` package was installed and running on my machine, and I encountered this bug today when I tried to migrate to the `bind9` package from ISC's PPA. To be sure that this is not caused by any remains from the previous installation, I have completely purged all bind-related packages, manually deleted the `bind` user and the `/etc/bind`, `/var/cache/bind` and `/var/lib/bind` directories. Even after this cleanup, I still encountered this bug when trying to install `bind9 1:9.18.24-1+ubuntu20.04.1+deb.sury.org+1`. I've used the following workaround to solve to issue for me until the bug is fixed in the PPA package:
#### Temporary workaround for other users encountering the same bug
Prior to installing the package, run `sudo systemctl edit named.service`, then enter the following two lines and save the file:
```
[Service]
Type=simple
```
You should now be able to install/reconfigure the `bind9` package and to start `named.service` without issues.
### BIND version affected
```
named -V
BIND 9.18.24-1+ubuntu20.04.1+deb.sury.org+1-Ubuntu (Extended Support Version) <id:>
running on Linux x86_64 5.4.0-173-generic #191-Ubuntu SMP Fri Feb 2 13:55:07 UTC 2024
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/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' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--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-gw9jNu/bind9-9.18.24=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.4.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.40.0
linked to libnghttp2 version: 1.40.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
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
1. Try to install the `bind9` 9.18.24 package from ISC's Ubuntu 20.04 PPA, for example using `apt install bind9`
2. Notice that the package installation fails/aborts during the post-install phase after about 90 seconds.
3. Check the ouput of `journalctl -ru named | grep --extended-regexp '(timeout|timed out)'`
### What is the current *bug* behavior?
The systemd unit `named.service` times out after 90 seconds.
### What is the expected *correct* behavior?
The systemd unit `named.service` shouldn't time out.
### Relevant configuration files
The bug occurs even with the unchanged config that ships with the package.
### Relevant logs
Excerpt from `journalctl -u named.service`:
```
Feb 13 19:06:53 ns systemd[1]: Starting BIND Domain Name Server...
Feb 13 19:06:53 ns named[6454]: starting BIND 9.18.24-1+ubuntu20.04.1+deb.sury.org+1-Ubuntu (Extended Support Version) <id:>
Feb 13 19:06:53 ns named[6454]: running on Linux x86_64 5.4.0-173-generic #191-Ubuntu SMP Fri Feb 2 13:55:07 UTC 2024
Feb 13 19:06:53 ns named[6454]: built with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable>
Feb 13 19:06:53 ns named[6454]: running as: named -f -u bind
Feb 13 19:06:53 ns named[6454]: compiled by GCC 9.4.0
Feb 13 19:06:53 ns named[6454]: compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
Feb 13 19:06:53 ns named[6454]: linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
Feb 13 19:06:53 ns named[6454]: compiled with libuv version: 1.44.2
Feb 13 19:06:53 ns named[6454]: linked to libuv version: 1.44.2
Feb 13 19:06:53 ns named[6454]: compiled with libxml2 version: 2.9.10
Feb 13 19:06:53 ns named[6454]: linked to libxml2 version: 20910
Feb 13 19:06:53 ns named[6454]: compiled with json-c version: 0.13.1
Feb 13 19:06:53 ns named[6454]: linked to json-c version: 0.13.1
Feb 13 19:06:53 ns named[6454]: compiled with zlib version: 1.2.11
Feb 13 19:06:53 ns named[6454]: linked to zlib version: 1.2.11
Feb 13 19:06:53 ns named[6454]: ----------------------------------------------------
Feb 13 19:06:53 ns named[6454]: BIND 9 is maintained by Internet Systems Consortium,
Feb 13 19:06:53 ns named[6454]: Inc. (ISC), a non-profit 501(c)(3) public-benefit
Feb 13 19:06:53 ns named[6454]: corporation. Support and training for BIND 9 are
Feb 13 19:06:53 ns named[6454]: available at https://www.isc.org/support
Feb 13 19:06:53 ns named[6454]: ----------------------------------------------------
Feb 13 19:06:53 ns named[6454]: adjusted limit on open files from 524288 to 1048576
Feb 13 19:06:53 ns named[6454]: found 1 CPU, using 1 worker thread
Feb 13 19:06:53 ns named[6454]: using 1 UDP listener per interface
Feb 13 19:06:53 ns named[6454]: DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
Feb 13 19:06:53 ns named[6454]: DS algorithms: SHA-1 SHA-256 SHA-384
Feb 13 19:06:53 ns named[6454]: HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
Feb 13 19:06:53 ns named[6454]: TKEY mode 2 support (Diffie-Hellman): yes
Feb 13 19:06:53 ns named[6454]: TKEY mode 3 support (GSS-API): yes
Feb 13 19:06:53 ns named[6454]: loading configuration from '/etc/bind/named.conf'
[…]
Feb 13 19:08:23 ns systemd[1]: named.service: start operation timed out. Terminating.
Feb 13 19:08:23 ns named[6454]: no longer listening on 127.0.0.1#53
Feb 13 19:08:23 ns named[6454]: no longer listening on […]#53
Feb 13 19:08:23 ns named[6454]: no longer listening on ::1#53
Feb 13 19:08:23 ns named[6454]: no longer listening on […]#53
Feb 13 19:08:23 ns named[6454]: shutting down
Feb 13 19:08:23 ns named[6454]: stopping command channel on 127.0.0.1#953
Feb 13 19:08:23 ns named[6454]: stopping command channel on ::1#953
Feb 13 19:08:23 ns named[6454]: exiting
Feb 13 19:08:23 ns systemd[1]: named.service: Failed with result 'timeout'.
Feb 13 19:08:23 ns systemd[1]: Failed to start BIND Domain Name Server.
Feb 13 19:08:24 ns systemd[1]: named.service: Scheduled restart job, restart counter is at 1.
Feb 13 19:08:24 ns systemd[1]: Stopped BIND Domain Name Server.
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4576#error "isc/stdatomic.h does not support your compiler"2024-02-13T21:49:44ZMarcus Kool#error "isc/stdatomic.h does not support your compiler"<!--
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 make sure that you make the new issue
confident...<!--
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 make sure that you make the new issue
confidential by clicking the checkbox at the bottom!
-->
### Summary
When compiling a plugin outside the bind source tree a fatal error is thrown by
#error "isc/stdatomic.h does not support your compiler"
### BIND version affected
<!--
Make sure you are testing with the **latest** supported version of BIND
for a given branch. Many bugs have been fixed over time!
See https://kb.isc.org/docs/supported-platforms for the current list.
The latest source is available from https://www.isc.org/download/#BIND
Paste the output of `named -V` here.
-->
all 9.18.x versions
### Steps to reproduce
<!--
This is extremely important! Be precise and use itemized lists, please.
Even if a default configuration is affected, please include the full configuration
files _you were testing with_.
Example:
1. Use _attached_ configuration file
2. Start BIND server with command: `named -g -c named.conf ...`
3. Simulate legitimate clients using command `dnsperf -S1 -d legit-queries ...`
4. Simulate attack traffic using command `dnsperf -S1 -d attack-queries ...`
-->
1. copy a plugin to outside the bind tree
2. make sure the plugin includes isc/log.h which triggers the inclusion of isc/stdatomic.h
3. use gcc 5.0 or higher
### What is the current *bug* behavior?
<!-- What actually happens. -->
The copiler issues a fatal error:
```
In file included from /local/src/bind/urlfilterdb-isc-bind-918/lib/isc/include/isc/atomic.h:19,
from /local/src/bind/urlfilterdb-isc-bind-918/lib/isc/include/isc/types.h:16,
from /local/src/bind/urlfilterdb-isc-bind-918/lib/isc/include/isc/log.h:25,
from ufdb-bind-log.h:12,
from ufdb-bind-log.c:19:
/local/src/bind/urlfilterdb-isc-bind-918/lib/isc/include/isc/stdatomic.h:29:2: error: #error "isc/stdatomic.h does not support your compiler"
29 | #error "isc/stdatomic.h does not support your compiler"
| ^~~~~
```
### What is the expected *correct* behavior?
<!-- What you should see instead. -->
compilation is successful
### Relevant configuration files
<!-- Paste any relevant configuration files here - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential issue, it is advisable to
obscure key secrets; this can be done automatically by using
`named-checkconf -px`. -->
### Relevant logs
<!-- Paste any relevant logs here - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise. -->https://gitlab.isc.org/isc-projects/bind9/-/issues/4572TLS forwarder lookup fails in resolver.c when TLS CA certificate not available2024-02-21T20:41:29ZTobias WolterTLS forwarder lookup fails in resolver.c when TLS CA certificate not available### Summary
When configuring a forwarder with a TLS configuration that specifies a CA file to verify the remote certificate, BIND dies at the RUNTIME_CHECK in resolver.c when it cannot read the CA file.
### BIND version affected
BIND ...### Summary
When configuring a forwarder with a TLS configuration that specifies a CA file to verify the remote certificate, BIND dies at the RUNTIME_CHECK in resolver.c when it cannot read the CA file.
### BIND version affected
BIND 9.19.19-1+0~20231220.107+debian12~1.gbpfc5ec0-Debian (Development Release) <id:>
### Steps to reproduce
1. Use the provided configuration snippet in any working configuration.
2. Do *not* have a `/certificates` directory.
3. Look up something from test.example.com.
### What is the current *bug* behavior?
BIND crashes in the resolver library due to the TLS context not being set up correctly.
### What is the expected *correct* behavior?
BIND complains about not being able to read about the CA certificate on startup.
### Relevant configuration files
* named.conf (excerpt):
```
tls auth1 {
ca-file "/certificates/ca.crt";
remote-hostname "auth1";
};
tls auth2 {
ca-file "/certificates/ca.crt";
remote-hostname "auth2";
};
zone test.example.com {
type forward;
forwarders port 853 { 172.23.23.11 tls auth1; 172.23.23.12 tls auth2; };
forward only;
};
```
### Relevant logs
```
recursive-2 | 12-Feb-2024 08:57:44.370 client @0x713184c1c000 172.23.23.23#45455 (foo.test.example.com): query: foo.test.example.com IN A +E(0)K (172.23.23.14)
recursive-2 | fetch: foo.test.example.com/A
recursive-2 | QNAME minimization - minimized, qmintype 2 qminname corp
recursive-2 | resolver.c:2175:fctx_query(): fatal error:
recursive-2 | RUNTIME_CHECK(result == ISC_R_SUCCESS) failed
recursive-2 | exiting (due to fatal error in library)
recursive-2 exited with code 139
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4571findnsec3proofs failed to disassociate all rdatasets returned by dns_ncache_c...2024-03-08T08:24:37ZMark Andrewsfindnsec3proofs failed to disassociate all rdatasets returned by dns_ncache_currentThese are not currently reference counted by if they where it would introduce a memory/reference leak.These are not currently reference counted by if they where it would introduce a memory/reference leak.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4570CID 486327: Control flow issues (UNREACHABLE)2024-03-08T08:20:30ZMark AndrewsCID 486327: Control flow issues (UNREACHABLE)Just need to be removed.
```
** CID 486327: Control flow issues (UNREACHABLE)
/lib/isc/netmgr/netmgr.c: 750 in isc___nmsocket_init()
____________________________________________________________________________________________________...Just need to be removed.
```
** CID 486327: Control flow issues (UNREACHABLE)
/lib/isc/netmgr/netmgr.c: 750 in isc___nmsocket_init()
________________________________________________________________________________________________________
*** CID 486327: Control flow issues (UNREACHABLE)
/lib/isc/netmgr/netmgr.c: 750 in isc___nmsocket_init()
744 sock->statsindex = tcp6statsindex;
745 break;
746 default:
747 UNREACHABLE();
748 }
749 break;
CID 486327: Control flow issues (UNREACHABLE)
This code cannot be reached: "switch (family) {
case 2:...".
750 switch (family) {
751 case AF_INET:
752 sock->statsindex = tcp4statsindex;
753 break;
754 case AF_INET6:
755 sock->statsindex = tcp6statsindex;
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4569** CID 486326: Memory - corruptions (OVERRUN)2024-03-08T08:23:03ZMark Andrews** CID 486326: Memory - corruptions (OVERRUN)This is cosmetic but should be addressed. sizeof(type.sa) is smaller than sizeof(type) and sizeof(type.sin6) so
while this overruns type.sa it doesn't actually overrun the union.
```
** CID 486326: Memory - corruptions (OVERRUN)
/lib/...This is cosmetic but should be addressed. sizeof(type.sa) is smaller than sizeof(type) and sizeof(type.sin6) so
while this overruns type.sa it doesn't actually overrun the union.
```
** CID 486326: Memory - corruptions (OVERRUN)
/lib/dns/resconf.c: 248 in add_server()
________________________________________________________________________________________________________
*** CID 486326: Memory - corruptions (OVERRUN)
/lib/dns/resconf.c: 248 in add_server()
242 if (res->ai_addrlen > sizeof(address->type)) {
243 isc_mem_put(mctx, address, sizeof(*address));
244 result = ISC_R_RANGE;
245 goto cleanup;
246 }
247 address->length = (unsigned int)res->ai_addrlen;
CID 486326: Memory - corruptions (OVERRUN)
Overrunning struct type sockaddr of 16 bytes by passing it to a function which accesses it at byte offset 27 using argument "res->ai_addrlen" (which evaluates to 28). [Note: The source code implementation of the function has been overridden by a builtin model.]
248 memmove(&address->type.sa, res->ai_addr, res->ai_addrlen);
249 ISC_LINK_INIT(address, link);
250 ISC_LIST_APPEND(*nameservers, address, link);
251
252 cleanup:
253 freeaddrinfo(res);
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)