ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-01-26T07:44:14Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/26492.3.3 release checklist2023-01-26T07:44:14ZAndrei Pavelandrei@isc.org2.3.3 release checklist---
name: a.b.c release checklist
about: Create a new issue using this checklist for each release.
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaRelease...---
name: a.b.c release checklist
about: Create a new issue using this checklist for each release.
---
# 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 those checks and updates can be made before the actual freeze.
For new stable releases or maintenance releases, please don't use `kea-dev` build farm. Use dedicated build farm for each release cycle.
1. 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. [ ] Check [Performance Test Results](https://jenkins.isc.org/job/kea-dev/job/performance/KeaPerformanceReport/) in Jenkins for drops in performance.
1. Check versioning, ask the development team if:
- the library versions are being updated
- `KEA_HOOKS_VERSION` is being updated
- [x] create an issue for that for developers in Gitlab
- script: [./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. [x] Check that a previously released schema has not been changed.
1. [x] 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. Prepare Release Notes
1. [x] Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should be created under "release notes" directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-2.1.0
1. [x] Finish release notes and conduct its review. Also please notify @sgoldlust or @vicky that release notes are ready for review.
1. [x] Run [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/) as running parameter `TarballOrPkg` select `packages` and [release-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/) to test repositories for correctness.
1. If a new Cloudsmith repository is used, then:
1. [ ] Make sure freeradius packages are uploaded to the Cloudsmith repository or copied from a previous repository.
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.
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) <br>
Example command: `GITLAB_TOKEN='...' ./update-code-for-release.py 1.9.7 'Apr 28, 2021' ~/isc/repos/kea/` <br>
Help: `GITLAB_TOKEN="..." update-code-for-release.py --help`<br>
This script makes the following changes and actions:
1. run prepare_kea_release.sh that does:
1.1. add release entries in ChangeLogs
1.2. update Kea version in configure.ac
1.3. update copyright years in files that were changed in current year
1.4. sort message files
1.5. regenerate message files headers
2. regenerate parsers using Bison from Docker<br>
using with --upload:
3. create an issue in GitLab for release changes in kea repo
4. create branches and merge requests for kea and kea-premium
5. commit the changes in both repos
6. checkout created branches in both repos
7. commit and push the changes to GitLab server
1. Check manually User's Guide sections:
1. Chapter 1. Introduction
1. [x] 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. 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. Chapter 3. Installation
1. [x] 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. [ ] 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. [x] 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 all of the installed binaries has man page
1. if not, is it in the tarball?
1. are man page 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 "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. final if the last rc number was ok, this will push the selected tarball to repo.isc.org, to a directory with no suffixes
1. Submit the job that will automatically:
1. Upload the tarballs <br>
and if this is not the final version:
1. Create a GitLab issue for sanity checks, put there the announcement
1. Send Sanity Checks announcement via email to dhcp-team@isc.org and to DHCP channel on Mattermost.<br>
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
1. [x] Update Release Notes with ChangeLog entries
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 "Release_Candidate" pick final <br>
This job will also:
- open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) requesting signing final tarballs on repo.isc.org
- create Git tags `Kea-a.b.c` in Kea main and premium repositories
- send a signing request issue link on the DHCP Mattermost channel
Wait until tarballs are signed.
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" link
1. Pick your selected pkg build in Packages field, and select `PrivPubRepos: "both"`, `TestProdRepos: "production"`, `TarballOrPkg: "both"` and click Build button.
1. When it finishes run check: [releases-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/).
1. [x] Update ReadTheDocs
1. Trigger rebuilding docs 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. For stable releases, change the default version to point to this stable release.
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.2.2): <br>
Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button and edit description: <br>
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] 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` or
* `a.y.0-git` where `y == b + 1` or
* `x.1.0-git` where `x == a + 1`
1. [x] Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist issue.
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Wait for the signing ticket from the release engineer.
- [x] ***(Support)*** Confirm that the tarballs have the checksums mentioned on the signing ticket.
- [x] ***(Support)*** Sign the tarballs.
- [x] ***(Support)*** Upload signature files to repo.isc.org.
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *kea-announce*.
- [x] ***(Support)*** Write email to *kea-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [ ] ***(Support)*** 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. Then update support customers that this new private repo exists.
- [x] ***(Support)*** Update tickets in case of waiting for support customers.
- [ ] ***(QA)*** Inform Marketing of the release.
- [ ] ***(Marketing)*** If a new Cloudsmith repository is used, update the Zapier scripts.
- [ ] ***(Marketing)*** 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.
- [ ] ***(Marketing)*** Announce on social media.
- [x] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [ ] ***(Marketing)*** Write blog article (if a major release).
- [ ] ***(Marketing)*** Update [Kea page on web site if any new hooks](https://www.isc.org/kea/).
- [ ] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [ ] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
- [ ] ***(Marketing)*** Update [Kea documentation page in KB](https://kb.isc.org/docs/en/kea-administrator-reference-manual).kea2.3.3Wlodzimierz WencelWlodzimierz Wencel2022-11-30https://gitlab.isc.org/isc-projects/bind9/-/issues/3700consider deprecating "dialup" option2023-08-04T09:42:20ZPetr Špačekpspacek@isc.orgconsider deprecating "dialup" optionIt is unclear if [dialup](https://bind9.readthedocs.io/en/v9_19_7/reference.html#namedconf-statement-dialup) statement is useful in practice, and at the same time it adds fair amount of logic to zone refresh/notify handling.
Consider th...It is unclear if [dialup](https://bind9.readthedocs.io/en/v9_19_7/reference.html#namedconf-statement-dialup) statement is useful in practice, and at the same time it adds fair amount of logic to zone refresh/notify handling.
Consider the fun of finding out how following flags interact:
`lib/dns/zone.c`:
```c
19964 void
19965 dns_zone_setdialup(dns_zone_t *zone, dns_dialuptype_t dialup) {
19966 REQUIRE(DNS_ZONE_VALID(zone));
19967
19968 LOCK_ZONE(zone);
19969 DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_DIALNOTIFY |
19970 DNS_ZONEFLG_DIALREFRESH |
19971 DNS_ZONEFLG_NOREFRESH);
19972 switch (dialup) {
19973 case dns_dialuptype_no:
19974 break;
19975 case dns_dialuptype_yes:
19976 DNS_ZONE_SETFLAG(zone, (DNS_ZONEFLG_DIALNOTIFY |
19977 DNS_ZONEFLG_DIALREFRESH |
19978 DNS_ZONEFLG_NOREFRESH));
19979 break;
19980 case dns_dialuptype_notify:
19981 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_DIALNOTIFY);
19982 break;
19983 case dns_dialuptype_notifypassive:
19984 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_DIALNOTIFY);
19985 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_NOREFRESH);
19986 break;
19987 case dns_dialuptype_refresh:
19988 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_DIALREFRESH);
19989 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_NOREFRESH);
19990 break;
19991 case dns_dialuptype_passive:
19992 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_NOREFRESH);
19993 break;
19994 default:
19995 UNREACHABLE();
19996 }
19997 UNLOCK_ZONE(zone);
19998 }
```August 2023 (9.16.43, 9.16.43-S1, 9.18.18, 9.18.18-S1, 9.19.16)https://gitlab.isc.org/isc-projects/bind9/-/issues/3694Deprecate setting alternate transfer source2022-12-02T12:56:00ZMatthijs Mekkingmatthijs@isc.orgDeprecate setting alternate transfer sourceThis was an undocumented BIND 8 feature that was ported to BIND 9 in the early days. But there is no good use case for it.
See #3714 for the corresponding option removal issue.This was an undocumented BIND 8 feature that was ported to BIND 9 in the early days. But there is no good use case for it.
See #3714 for the corresponding option removal issue.December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3693crash when restarting server with active statschannel connection2022-12-02T11:34:37ZOndřej Surýcrash when restarting server with active statschannel connection### Summary
### BIND version used
- ~"Affects v9.19" : 9128e540f096c915846037c4db41824692513abf
- ~"Affects v9.18" : v9_18_9 is also affected
### Steps to reproduce
1. Start named
2. $ telnet ::1 8080
3. SIGINT the server
4. Enjoy fi...### Summary
### BIND version used
- ~"Affects v9.19" : 9128e540f096c915846037c4db41824692513abf
- ~"Affects v9.18" : v9_18_9 is also affected
### Steps to reproduce
1. Start named
2. $ telnet ::1 8080
3. SIGINT the server
4. Enjoy fireworks
### What is the current *bug* behavior?
Crash on assertion:
```
httpd.c:902: REQUIRE(httpd->readhandle == handle) failed, back trace
```
### What is the expected *correct* behavior?
Does not crash.
### Relevant configuration files
```
statistics-channels {
inet ::1 port 8080;
};
```December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/2647BLQ error cases2022-12-02T21:46:34ZFrancis DupontBLQ error casesNeed to decide what to do on errors:
- unpack errors on query messages
- malformed query messages (missing a required option: on UDP such query messages are dropped on the floor)
- new query types with lease backends not supporting th...Need to decide what to do on errors:
- unpack errors on query messages
- malformed query messages (missing a required option: on UDP such query messages are dropped on the floor)
- new query types with lease backends not supporting them (I propose to reply with NotAllowed, see #2646 too)
Need too to implement a reasonable shutdown handling.kea2.3.4Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2645Extend lease_query config syntax.2023-07-17T13:58:23ZFrancis DupontExtend lease_query config syntax.Both premium and core (the second for the doc) ticket.Both premium and core (the second for the doc) ticket.kea2.3.4Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3683use after free in catalog zone processing2022-12-07T01:56:15ZMark Andrewsuse after free in catalog zone processingI was in the process of adding tls restricted transfers to the catz system
test and hadn't properly modified everything (see attached diff) and ns2
dropped core from what looks like a use after free error.
The end of ns2/named.run:
```
...I was in the process of adding tls restricted transfers to the catz system
test and hadn't properly modified everything (see attached diff) and ns2
dropped core from what looks like a use after free error.
The end of ns2/named.run:
```
17-Nov-2022 19:11:31.886 received message from 10.53.0.1#5300
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25047
;; flags: qr aa; QUESTION: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;catalog1.example. IN IXFR
;; ANSWER SECTION:
catalog1.example. 3600 IN SOA . . 64 86400 3600 86400 3600
catalog1.example. 3600 IN SOA . . 63 86400 3600 86400 3600
catalog1.example. 3600 IN SOA . . 64 86400 3600 86400 3600
1ba056ba375209a66a2c9a0617b1df714b998112.zones.catalog1.example. 3600 IN PTR tls1.example.
catalog1.example. 3600 IN SOA . . 64 86400 3600 86400 3600
17-Nov-2022 19:11:31.886 transfer of 'catalog1.example/IN/default' from 10.53.0.1#5300: got incremental response
17-Nov-2022 19:11:31.886 writing to journal
17-Nov-2022 19:11:31.886 del catalog1.example. 3600 IN SOA . . 63 86400 3600 86400 3600
17-Nov-2022 19:11:31.886 add catalog1.example. 3600 IN SOA . . 64 86400 3600 86400 3600
17-Nov-2022 19:11:31.886 add 1ba056ba375209a66a2c9a0617b1df714b998112.zones.catalog1.example. 3600 IN PTR tls1.example.
17-Nov-2022 19:11:31.886 dns_zone_verifydb: zone catalog1.example/IN/default: enter
17-Nov-2022 19:11:31.886 catz.c:2041:dns_catz_dbupdate_callback(): fatal error:
17-Nov-2022 19:11:31.886 pthread_mutex_lock(): Invalid argument (22)
17-Nov-2022 19:11:31.886 exiting (due to fatal error in library)
```
```
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x000000019869ce28 __pthread_kill + 8
1 libsystem_pthread.dylib 0x00000001986cf43c pthread_kill + 292
2 libsystem_c.dylib 0x0000000198617454 abort + 124
3 named 0x000000010446a42c library_fatal_error + 356 (main.c:278)
4 libisc-9.19.8-dev.dylib 0x00000001049cec7c isc_error_fatal + 72 (error.c:70)
5 libdns-9.19.8-dev.dylib 0x0000000104535c6c dns_catz_dbupdate_callback + 312 (catz.c:2041)
6 libdns-9.19.8-dev.dylib 0x000000010453a37c dns_db_closeversion + 264 (db.c:412)
7 libdns-9.19.8-dev.dylib 0x00000001046b514c ixfr_commit + 164 (xfrin.c:478)
8 libdns-9.19.8-dev.dylib 0x00000001046b4b54 xfr_rr + 1444 (xfrin.c:631)
9 libdns-9.19.8-dev.dylib 0x00000001046b3f54 xfrin_recv_done + 2544 (xfrin.c:1412)
10 libisc-9.19.8-dev.dylib 0x00000001049b4420 isc__nm_async_readcb + 408 (netmgr.c:2253)
11 libisc-9.19.8-dev.dylib 0x00000001049b2180 isc__nm_readcb + 332 (netmgr.c:2226)
12 libisc-9.19.8-dev.dylib 0x00000001049bd040 isc__nm_tcpdns_processbuffer + 636 (tcpdns.c:851)
13 libisc-9.19.8-dev.dylib 0x00000001049b2da8 processbuffer + 60 (netmgr.c:1722)
14 libisc-9.19.8-dev.dylib 0x00000001049b2c6c isc__nm_process_sock_buffer + 52 (netmgr.c:1743)
15 libisc-9.19.8-dev.dylib 0x00000001049bd340 isc__nm_tcpdns_read_cb + 604 (tcpdns.c:914)
16 libuv.1.dylib 0x00000001056de570 uv__stream_io + 1020
17 libuv.1.dylib 0x00000001056e57c0 uv__io_poll + 1744
18 libuv.1.dylib 0x00000001056d5d00 uv_run + 252
19 libisc-9.19.8-dev.dylib 0x00000001049e5504 loop_run + 460 (loop.c:270)
20 libisc-9.19.8-dev.dylib 0x00000001049e3c08 loop_thread + 44 (loop.c:297)
21 libisc-9.19.8-dev.dylib 0x00000001049e3ac0 isc_loopmgr_run + 456 (loop.c:477)
22 named 0x0000000104469fc4 main + 424 (main.c:1545)
23 libdyld.dylib 0x00000001986ed430 start + 4
```
[diff](/uploads/eaa1cbd5b7f3ab504554a35d53217359/diff)December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3678stale-serve and RPZ put in SERVFAIL cache unexpected record2023-05-30T13:33:10ZMaksym Odinintsevstale-serve and RPZ put in SERVFAIL cache unexpected record### Summary
When I enable serve-stale, and disable access to external upstream servers (recursion), I see unexpected records in SERVFAIL cache. I see SERVFAIL record for records what should be rewritten with RPZ trigger instead of reque...### Summary
When I enable serve-stale, and disable access to external upstream servers (recursion), I see unexpected records in SERVFAIL cache. I see SERVFAIL record for records what should be rewritten with RPZ trigger instead of requested record.
### BIND version used
```
BIND 9.18.1-1ubuntu1.2-Ubuntu (Stable Release) <id:>
running on Linux x86_64 5.15.0-1022-aws #26-Ubuntu SMP Thu Oct 13 12:59:25 UTC 2022
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-option-checking' '--disable-silent-rules' '--libdir=${prefix}/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' '--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' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-2lYtkE/bind9-9.18.1=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 11.2.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.43.0
linked to libuv version: 1.43.0
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
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
linked to maxminddb version: 1.5.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
Configure a minimal BIND 9 recursive resolver with a response policy zone, and then attempt to resolve `321.test.myctl.com.`:
`dig 321.test.myctl.com A @127.0.0.1`
filter upstreams via iptables (for example), and attempt to resolve it again, you will receive SERVFAIL:
```
; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> 321.test.myctl.com A @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20981
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 8f82c8b75e5cd86b0100000063725d504d726ced8e1e2034 (good)
;; QUESTION SECTION:
;321.test.myctl.com. IN A
;; Query time: 4999 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Mon Nov 14 15:22:56 UTC 2022
;; MSG SIZE rcvd: 75
```
dump named db via `rndc dumpdb` and look for SERVFAIL cache:
```
; SERVFAIL cache
;
; test.myctl.com/A [ttl 968]
```
In named.log we can see:
```
resolver: debug 1: fetch: 321.test.myctl.com/A
resolver: debug 1: fetch: 321.test.myctl.com/A
serve-stale: info: 321.test.myctl.com resolver failure, stale answer used
serve-stale: info: test.myctl.com resolver failure, stale answer unavailable
query-errors: info: client @0x7feb441e9f48 127.0.0.1#44401 (321.test.myctl.com): query failed (SERVFAIL) for 321.test.myctl.com/IN/A at query.c:5925
serve-stale: info: 321.test.myctl.com resolver failure, stale answer used
serve-stale: info: test.myctl.com resolver failure, stale answer unavailable
query-errors: info: client @0x7feb44209ef8 127.0.0.1#48831 (321.test.myctl.com): query failed (SERVFAIL) for 321.test.myctl.com/IN/A at query.c:5925
general: info: received control channel command 'dumpdb'
general: info: dumpdb started
```
Ask the same query second time, anew can see how it was resolved successfully:
```
; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> 321.test.myctl.com A @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31429
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: bdf9d11efa69889d0100000063725d5303f554388f84744c (good)
;; QUESTION SECTION:
;321.test.myctl.com. IN A
;; ANSWER SECTION:
321.test.myctl.com. 30 IN CNAME test.myctl.com.
test.myctl.com. 293 IN CNAME test-cname-a.myctl.com.
test-cname-a.myctl.com. 30 IN A 127.0.0.1
;; ADDITIONAL SECTION:
test.rpz.local. 1 IN SOA localhost. root.localhost. 1 604800 86400 2419200 86400
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Mon Nov 14 15:22:59 UTC 2022
;; MSG SIZE rcvd: 205
```
In named.log file we can see that:
```
serve-stale: info: 321.test.myctl.com query within stale refresh time, stale answer used
rpz: info: client @0x7feb441e9f48 127.0.0.1#43954 (321.test.myctl.com): rpz QNAME Local-Data rewrite test.myctl.com/A/IN via test.myctl.com.test.rpz.local
resolver: debug 1: fetch: test-cname-a.myctl.com/A
serve-stale: info: 321.test.myctl.com query within stale refresh time, stale answer used
rpz: info: client @0x7feb44209ef8 127.0.0.1#59298 (321.test.myctl.com): rpz QNAME Local-Data rewrite test.myctl.com/A/IN via test.myctl.com.test.rpz.local
resolver: debug 1: fetch: test-cname-a.myctl.com/A
serve-stale: info: test-cname-a.myctl.com resolver failure, stale answer used
serve-stale: info: test-cname-a.myctl.com resolver failure, stale answer used
```
If we disable serve-stale in config then we see only asked queries in SERVFAIL cache:
```
; SERVFAIL cache
;
; 321.test.myctl.com/A [ttl 976]
```
### What is the current *bug* behavior?
`test.myctl.com` existence in the SERVFAIL cache is unexpected. If load it pretty high to subdomains with RPZ and CNAMEs, this record will be presented almost always in SERVFAIL cache, and any queries to `test.myctl.com` will fail.
### What is the expected *correct* behavior?
I'd expect SERVFAILS only for exact requested queries, instead of something in between, or even answer with stale-data.
### Relevant configuration files
```
logging {
channel "standard_var_log" {
file "/var/log/named/named.log" versions 3 size 104857600;
severity debug 1;
print-time yes;
print-severity yes;
print-category yes;
};
channel "query_var_log" {
file "/var/log/named/querylog" versions 200 size 262144000;
print-time yes;
};
category "default" {
"standard_var_log";
};
category "lame-servers" {
"null";
};
category "queries" {
"query_var_log";
};
};
options {
directory "/var/cache/bind";
listen-on-v6 {
"any";
};
dnssec-validation no;
response-policy {
zone "test.rpz.local" max-policy-ttl 86400;
} break-dnssec yes qname-wait-recurse no;
stale-answer-enable yes;
stale-answer-client-timeout off;
stale-cache-enable yes;
};
zone "." {
type hint;
file "/usr/share/dns/root.hints";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
zone "test.rpz.local" in {
type master;
file "/etc/bind/db.rpz.local";
allow-query {
"localhost";
};
allow-transfer {
"localhost";
};
forwarders {
};
};
zone "myctl.com" in {
type master;
file "/etc/bind/myctl.com.local";
allow-query {
"localhost";
};
allow-transfer {
"localhost";
};
forwarders {
};
};
```
```
# cat myctl.com.local
; BIND reverse data file for empty rfc1918 zone
;
; DO NOT EDIT THIS FILE - it is used for multiple zones.
; Instead, copy it, edit named.conf, and use that copy.
;
$ORIGIN .
$TTL 86400
myctl.com IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
IN NS ns-canada.topdns.com.
IN NS ns-usa.topdns.com.
IN NS ns-uk.topdns.com.
$ORIGIN myctl.com
test-cname-a NS ns-canada.topdns.com.
NS ns-usa.topdns.com.
NS ns-uk.topdns.com.
test NS ns-canada.topdns.com.
NS ns-usa.topdns.com.
NS ns-uk.topdns.com.
$ORIGIN test.myctl.com
$TTL 300
* CNAME test.myctl.com.
```
```
# cat db.rpz.local
; BIND reverse data file for empty rfc1918 zone
;
; DO NOT EDIT THIS FILE - it is used for multiple zones.
; Instead, copy it, edit named.conf, and use that copy.
;
$TTL 900
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
IN NS localhost.
$TTL 293
test.myctl.com CNAME test-cname-a.myctl.com.
```January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3676Deprecate and remove "Operating System Resource Limits"2022-12-07T18:50:32ZOndřej SurýDeprecate and remove "Operating System Resource Limits"From ARM:
```
Operating System Resource Limits
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The server's usage of many system resources can be limited. Scaled
values are allowed when specifying resource limits. For example, ``1G``
can be used inst...From ARM:
```
Operating System Resource Limits
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The server's usage of many system resources can be limited. Scaled
values are allowed when specifying resource limits. For example, ``1G``
can be used instead of ``1073741824`` to specify a limit of one
gigabyte. ``unlimited`` requests unlimited use, or the maximum available
amount. ``default`` uses the limit that was in force when the server was
started. See the description of ``size_spec`` in :ref:`configuration_file_elements`.
The following options set operating system resource limits for the name
server process. Some operating systems do not support some or any of the
limits; on such systems, a warning is issued if an unsupported
limit is used.
``coresize``
This sets the maximum size of a core dump. The default is ``default``.
``datasize``
This sets the maximum amount of data memory the server may use. The default is
``default``. This is a hard limit on server memory usage; if the
server attempts to allocate memory in excess of this limit, the
allocation will fail, which may in turn leave the server unable to
perform DNS service. Therefore, this option is rarely useful as a way
to limit the amount of memory used by the server, but it can be
used to raise an operating system data size limit that is too small
by default. To limit the amount of memory used by the
server, use the ``max-cache-size`` and ``recursive-clients`` options
instead.
``files``
This sets the maximum number of files the server may have open concurrently.
The default is ``unlimited``.
``stacksize``
This sets the maximum amount of stack memory the server may use. The default is
``default``.
```
These are options that are better left to be managed by the environment, and not from within the `named`, just deprecate these options in 9.18 and remove the options from 9.19+.December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/3674nsupdate -t timeout does not work2023-04-03T16:19:30ZPetr Špačekpspacek@isc.orgnsupdate -t timeout does not work### Summary
nsupdate option -t is broken and does not have any effect in v9.18 and v9.19 branches. It works in v9.16.
### BIND version used
Versions affected:
- ~"Affects v9.18": 9.18.10-dev 59cb6fa
- ~"Affects v9.19": 9.19.8-dev 48a9...### Summary
nsupdate option -t is broken and does not have any effect in v9.18 and v9.19 branches. It works in v9.16.
### BIND version used
Versions affected:
- ~"Affects v9.18": 9.18.10-dev 59cb6fa
- ~"Affects v9.19": 9.19.8-dev 48a9265
Not affected:
- ~"v9.16": 9.16.36-dev 0fcec7a22c07d9f6fedb097d164c227cfc06db79
### Steps to reproduce
Setup "something" which accepts UDP packets or TCP connections and does not respond.
In short, use `nsupdate -t`, either using TCP or TCP.
#### TCP
```
socat tcp6-listen:5301 -
time nsupdate -L 99 -p 5301 -v -t 1 /tmp/n/upd
```
- observe time to timeout - 30+ seconds
#### UDP
```
socat udp6-listen:5353 - &
time /tmp/main/bin/nsupdate -p 5353 -L 99 -t 1 /tmp/n/upd
```
nsupdate input file (content is not important): [upd](/uploads/db8018d4524417395dc1f2c96d8e1a75/upd)
### What is the current *bug* behavior?
- Explicitly specified timeout value 1 is ignored.
- Default timeout 300 seconds (specified in man page) is also ignored.
### What is the expected *correct* behavior?
Timeouts work.
### Relevant logs and/or screenshots
- [main-tcp.log](/uploads/a97aafe817c004a10ee6e95668627a4a/main-tcp.log)
- [main-udp.log](/uploads/7ef5f9e83f3210b18cde3b5eb1bac673/main-udp.log)
Please note the TCP is also suspicious because it seems it retries over the same connection? Huh?
Based on man page description of `-u` I would expect retries to apply only to UDP.April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3673Delay trust anchor management until all zones are loaded2023-04-29T07:36:54ZMark AndrewsDelay trust anchor management until all zones are loadedIf you have a trust anchor that requires a zone to be loaded for the DNSKEY to be fetched you can get spurious `Failed to create fetch for DNSKEY update.` logged if the timing is wrong.
Using !7049 and logging why dns_resolver_createfet...If you have a trust anchor that requires a zone to be loaded for the DNSKEY to be fetched you can get spurious `Failed to create fetch for DNSKEY update.` logged if the timing is wrong.
Using !7049 and logging why dns_resolver_createfetch fails we see:
```
11-Nov-2022 12:38:26.400 fetch: sub.foo/DNSKEY
11-Nov-2022 12:38:26.400 zone 78.100.IN-ADDR.ARPA/IN: loaded; checking validity
11-Nov-2022 12:38:26.400 fctx 0x121eb3010(sub.foo/DNSKEY): create
11-Nov-2022 12:38:26.400 dns_zone_verifydb: zone 74.100.IN-ADDR.ARPA/IN: enter
dns_resolver_createfetch(sub.foo, DNSKEY) -> zone not loaded
11-Nov-2022 12:38:26.400 managed-keys-zone: Failed to create fetch for sub.foo DNSKEY update
22 12:38:26.400 managed-keys-zone: Failed to create fetch for DNSKEY update
```
The serve is authoritative for `foo` but it has not loaded at this point in the start up so named can't determine where to send the DNSKEY request.
this should self correct but is not optimal. Waiting for all the zones to load then initiating trust anchor management should avoid errors like this.March 2023 (9.16.39, 9.16.39-S1, 9.18.13, 9.18.13-S1, 9.19.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/3670Firefox cannot read stats channel - too many headers in request2022-11-17T11:46:39ZPetr Špačekpspacek@isc.orgFirefox cannot read stats channel - too many headers in request### Summary
Firefox web browser sends so many headers that it exceeds the hardcoded header-count limit of 10 and causes connection to the statics channel to be reset.
### BIND version used
- 9.19.8-dev 48a9265
### Steps to reproduce
...### Summary
Firefox web browser sends so many headers that it exceeds the hardcoded header-count limit of 10 and causes connection to the statics channel to be reset.
### BIND version used
- 9.19.8-dev 48a9265
### Steps to reproduce
- get Firefox 106.0.5
- try to open the stats channel using HTTP URL
### What is the current *bug* behavior?
Error message:
> The connection was reset
> The connection to the server was reset while the page was loading.
### Relevant configuration files
```
statistics-channels {
inet ::1 port 8080;
};
```
### Relevant logs and/or screenshots
No logs from `named` - and I think that's a bug by itself.
Firefox on my machine sends at least 13 HTTP headers in the request.
### Possible fixes
- Bump the number
- Add logging, pleaseDecember 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/3668Private-key-format v1.2 with algorithm HMAC-MD5 broken on upgrade 9.18.7 -> 9...2023-09-05T15:40:30ZGert DoeringPrivate-key-format v1.2 with algorithm HMAC-MD5 broken on upgrade 9.18.7 -> 9.18.8<!--
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
Upgrading bind-tools 9.18.7 to 9.18.8 broke our calls to nsupdate, with nsupdate now refusing to read the existing key.
```
$ nsupdate -k Kdyn.space.net.+157+31584.private -v /tmp/upd.txt
09-Nov-2022 19:19:30.108 Kdyn.space.net.+157+31584.private:1: unknown option 'Private-key-format:'
09-Nov-2022 19:19:30.109 Kdyn.space.net.+157+31584.private:4: unexpected token near end of file
could not read key from Kdyn.space.net.+157+31584.{private,key}: unexpected token
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
...
update failed: REFUSED
```
### BIND version used
```
$ nsupdate -V
nsupdate 9.18.8
```
### Steps to reproduce
This is a standard nsupdate key, containing (key itself redacted)
```
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: XXXXXXXX==
```
and a standard update script containing
```
server newton.space.net
zone dyn.space.net
update delete openvpn-ma-nomatch.openvpn-tcp.dyn.space.net A
update add openvpn-ma-nomatch.openvpn-tcp.dyn.space.net 300 A 10.40.68.10
show
send
zone 68.40.10.in-addr.arpa
update delete 10.68.40.10.in-addr.arpa PTR
update add 10.68.40.10.in-addr.arpa 300 PTR openvpn-ma-nomatch.openvpn-tcp.dyn.space.net.
show
send
```
... this works fine with 9.18.7, and does not work with 9.18.8
### What is the current *bug* behavior?
nsupdate complains about not being able to parse the key (see above), and sends an unsigned packet
### What is the expected *correct* behavior?
no error message, send a signed update
### Relevant configuration files
(Paste any relevant configuration files - 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 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
git bisect leads me to
```
commit 0bbc0c61e3c98aded2e2b230b52c1d66c8bbd5fe (HEAD)
Author: Mark Andrews <marka@isc.org>
Date: Thu Sep 15 19:18:53 2022 +1000
Convert DST_ALG defines to enum and group HMAC algorithms
The HMACs and GSSAPI are just using unallocated values.
Moving them around shouldn't cause issues.
Only the dnssec system test knew the internal number in use for hmacmd5.
```
which moves HMAC_MD5 from 157 to 160 - not sure why that upsets nsupdate, or why that magic number would be exposed anywhere, but this is the commit that breaks things...July 2023 (9.18.17, 9.18.17-S1, 9.19.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/3667deprecate auto-dnssec feature in favor of dnssec-policy2023-02-18T03:56:51ZPetr Špačekpspacek@isc.orgdeprecate auto-dnssec feature in favor of dnssec-policyAs discussed in person in Porto, I think it's high time to deprecate [auto-dnssec](https://bind9.readthedocs.io/en/latest/dnssec-guide.html#semi-automatic-signing) in ~"v9.18" branch. Doing so _now_ would give users 3 years of warning be...As discussed in person in Porto, I think it's high time to deprecate [auto-dnssec](https://bind9.readthedocs.io/en/latest/dnssec-guide.html#semi-automatic-signing) in ~"v9.18" branch. Doing so _now_ would give users 3 years of warning before ~"v9.18" is out of support.
IMHO in ~"v9.19" we should remove it altogether ASAP.
There is a question what to do with zones which use `auto-dnssec` on upgrade. I think it would be wrong to just skip over the config statement and pretend it is not configured because it would be major break in user's expectation. I think in this case it should be hard error (from ~"v9.19" onwards, of course.)December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3665"dupsigs" system test intermittently causes named to hang2023-04-06T14:54:39ZMichał Kępień"dupsigs" system test intermittently causes named to hanghttps://gitlab.isc.org/isc-private/bind9/-/jobs/2888774
It appears that `named` did not shut down upon receiving a SIGTERM
signal. Core dump was preserved.
<details>
<summary>Click to expand/collapse full test output</summary>
```
S:...https://gitlab.isc.org/isc-private/bind9/-/jobs/2888774
It appears that `named` did not shut down upon receiving a SIGTERM
signal. Core dump was preserved.
<details>
<summary>Click to expand/collapse full test output</summary>
```
S:dupsigs:2022-11-07T23:09:10+0000
T:dupsigs:1:A
A:dupsigs:System test dupsigs
I:dupsigs:PORTRANGE:5300 - 5399
keys/signing.test/Ksigning.test.+008+01243.key
keys/signing.test/Ksigning.test.+008+01243.private
keys/signing.test/Ksigning.test.+008+18273.key
keys/signing.test/Ksigning.test.+008+18273.private
keys/signing.test/Ksigning.test.+008+31045.key
keys/signing.test/Ksigning.test.+008+31045.private
keys/signing.test/Ksigning.test.+008+34155.key
keys/signing.test/Ksigning.test.+008+34155.private
keys/signing.test/Ksigning.test.+008+39696.key
keys/signing.test/Ksigning.test.+008+39696.private
keys/signing.test/Ksigning.test.+008+48211.key
keys/signing.test/Ksigning.test.+008+48211.private
keys/signing.test/Ksigning.test.+008+49109.key
keys/signing.test/Ksigning.test.+008+49109.private
keys/signing.test/Ksigning.test.+008+50088.key
keys/signing.test/Ksigning.test.+008+50088.private
keys/signing.test/Ksigning.test.+008+52456.key
keys/signing.test/Ksigning.test.+008+52456.private
keys/signing.test/Ksigning.test.+008+54099.key
keys/signing.test/Ksigning.test.+008+54099.private
keys/signing.test/Ksigning.test.+008+57000.key
keys/signing.test/Ksigning.test.+008+57000.private
keys/signing.test/Ksigning.test.+008+49109.key
keys/signing.test/Ksigning.test.+008+49109.private
keys/signing.test/Ksigning.test.+008+01243.key
keys/signing.test/Ksigning.test.+008+01243.private
keys/signing.test/Ksigning.test.+008+01243.key
keys/signing.test/Ksigning.test.+008+01243.private
keys/signing.test/Ksigning.test.+008+18273.key
keys/signing.test/Ksigning.test.+008+18273.private
keys/signing.test/Ksigning.test.+008+01243.key
keys/signing.test/Ksigning.test.+008+01243.private
keys/signing.test/Ksigning.test.+008+18273.key
keys/signing.test/Ksigning.test.+008+18273.private
keys/signing.test/Ksigning.test.+008+54099.key
keys/signing.test/Ksigning.test.+008+54099.private
keys/signing.test/Ksigning.test.+008+18273.key
keys/signing.test/Ksigning.test.+008+18273.private
keys/signing.test/Ksigning.test.+008+54099.key
keys/signing.test/Ksigning.test.+008+54099.private
keys/signing.test/Ksigning.test.+008+57000.key
keys/signing.test/Ksigning.test.+008+57000.private
keys/signing.test/Ksigning.test.+008+50088.key
keys/signing.test/Ksigning.test.+008+50088.private
KSK=Ksigning.test.+008+49109
ZSK0=Ksigning.test.+008+01243
ZSK1=Ksigning.test.+008+18273
ZSK2=Ksigning.test.+008+54099
ZSK3=Ksigning.test.+008+57000
ZSK4=Ksigning.test.+008+50088
I:dupsigs:starting servers
=============== 0 ============
at serial 1996072701 key 1243 status added with flags (0,0)
at serial 1996072701 key 18273 status added with flags (0,0)
at serial 1996072701 key 49109 status added with flags (0,0)
at serial 1996072752 key 49109 status changed from (0,0) to (0,1)
=============== 35 ============
at serial 1996072701 key 1243 status added with flags (0,0)
at serial 1996072701 key 18273 status added with flags (0,0)
at serial 1996072701 key 49109 status added with flags (0,0)
at serial 1996072752 key 49109 status changed from (0,0) to (0,1)
I:dupsigs:failed
=============== 70 ============
at serial 1996072701 key 1243 status added with flags (0,0)
at serial 1996072701 key 18273 status added with flags (0,0)
at serial 1996072701 key 49109 status added with flags (0,0)
at serial 1996072752 key 49109 status changed from (0,0) to (0,1)
I:dupsigs:failed
=============== 105 ============
at serial 1996072701 key 1243 status added with flags (0,0)
at serial 1996072701 key 18273 status added with flags (0,0)
at serial 1996072701 key 49109 status added with flags (0,0)
at serial 1996072752 key 49109 status changed from (0,0) to (0,1)
I:dupsigs:failed
I:dupsigs:exit status: 3
I:dupsigs:stopping servers
I:dupsigs:ns1 didn't die when sent a SIGTERM
I:dupsigs:stopping servers failed
I:dupsigs:Core dump(s) found: dupsigs/ns1/core.6262
R:dupsigs:FAIL
D:dupsigs:backtrace from dupsigs/ns1/core.6262:
D:dupsigs:--------------------------------------------------------------------------------
D:dupsigs:Core was generated by `/builds/isc-private/bind9/bin/named/.libs/named -D dupsigs-ns1 -X named.lock -m'.
D:dupsigs:Program terminated with signal SIGABRT, Aborted.
D:dupsigs:#0 0x00007fc0aa3755c0 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffcdf293790, remaining=remaining@entry=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
D:dupsigs:[Current thread is 1 (Thread 0x7fc0a8091840 (LWP 6262))]
D:dupsigs:#0 0x00007fc0aa3755c0 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffcdf293790, remaining=remaining@entry=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
D:dupsigs:#1 0x00007fc0aa3a0414 in usleep (useconds=useconds@entry=10000) at ../sysdeps/posix/usleep.c:32
D:dupsigs:#2 0x00007fc0aaac7f03 in isc__taskmgr_destroy (managerp=managerp@entry=0x5567f5431d40 <named_g_taskmgr>) at task.c:1091
D:dupsigs:#3 0x00007fc0aaaa7ab2 in isc_managers_destroy (netmgrp=0x5567f5431d20 <named_g_nm>, taskmgrp=0x5567f5431d40 <named_g_taskmgr>) at managers.c:85
D:dupsigs:#4 0x00005567f53cdb1a in destroy_managers () at ./main.c:1742
D:dupsigs:#5 cleanup () at ./main.c:1478
D:dupsigs:#6 main (argc=<optimized out>, argv=<optimized out>) at ./main.c:1742
D:dupsigs:--------------------------------------------------------------------------------
D:dupsigs:full backtrace from dupsigs/ns1/core.6262 saved in dupsigs/ns1/core.6262-backtrace.txt
D:dupsigs:core dump dupsigs/ns1/core.6262 archived as dupsigs/ns1/core.6262.gz
E:dupsigs:2022-11-07T23:26:34+0000
```
</details>April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3662Extend mkeys system test to handle islands of trust2023-03-16T11:04:00ZMark AndrewsExtend mkeys system test to handle islands of trustThere are two scenarios to be tested.
1) island of trust where the DNSKEYs are found by recursion from the root.
2) island of trust where the DNSKEYs are found from an intermediate zone loaded on the server.
Also extend error reporting...There are two scenarios to be tested.
1) island of trust where the DNSKEYs are found by recursion from the root.
2) island of trust where the DNSKEYs are found from an intermediate zone loaded on the server.
Also extend error reporting to include DNSKEY name.March 2023 (9.16.39, 9.16.39-S1, 9.18.13, 9.18.13-S1, 9.19.11)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3655message decompresion can be slow2022-11-22T09:42:52ZPetr Špačekpspacek@isc.orgmessage decompresion can be slowVersion: e004ca4
Artificial DNS message full of compression pointers can cause `named` to spend lots of time in decompression loop. Flame chart then looks like this:
![512b_prereqs.svg](/uploads/719c28c1600753ffef4f264b731ed752/512b_pr...Version: e004ca4
Artificial DNS message full of compression pointers can cause `named` to spend lots of time in decompression loop. Flame chart then looks like this:
![512b_prereqs.svg](/uploads/719c28c1600753ffef4f264b731ed752/512b_prereqs.svg)
Reproducer:
1. get DNSPerf version with https://github.com/DNS-OARC/dnsperf/pull/201 (new option -B)
2. Fire at named with crafted DNS message. Here is binary in format for dnsperf: [tcpnotify.bin](/uploads/d0fe09936d516148a2c43914a7ae26de/tcpnotify.bin). Raw example DNS message is here: [512notify.bin](/uploads/9242d4ad0b0df44a31b45007084ae00c/512notify.bin).
3. Observe throughput going down, compared to 512-byte [message without lots of decompression](/uploads/13b7daee22cc83264b283b340b2d3e9c/tcpupd1rr512b.bin).December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3652reference manual update-policies unmatched parenthesis2022-11-07T12:48:42ZJorisreference manual update-policies unmatched parenthesis### Summary
In the _BIND 9 Administrator Reference Manual_ Configuration reference there are multiple references to the update-policy grammer where the paranthesis is unmatched:
` update-policy ( local | { ( deny | grant ) <string...### Summary
In the _BIND 9 Administrator Reference Manual_ Configuration reference there are multiple references to the update-policy grammer where the paranthesis is unmatched:
` update-policy ( local | { ( deny | grant ) <string> ( 6to4-self | external | krb5-self | krb5-selfsub | krb5-subdomain | ms-self | ms-selfsub | ms-subdomain | name | self | selfsub | selfwild | subdomain | tcp-self | wildcard | zonesub ) [ <string> ] <rrtypelist>; ... };`
I believe a closing parenthesis is required between the last and penultimate character, forming <rrtypelist>; ... }**)**;
The wrong block is reiterated multiple times, at least in "Zone Types", "Dynamic Update Policies", "view Block grammar" and "update-policy" grammer.
See for example https://bind9.readthedocs.io/en/v9_19_6/reference.html#dynamic-update-policies
### BIND version used
Verified in v9_16 and v9_19_6 (latest at the time of writing).
### Steps to reproduce
Open https://bind9.readthedocs.io/en/v9_19_6/reference.html#dynamic-update-policies
Find the grammer line for update-policy
Paste it in a code syntax highlighting editor
Observe there is no closing match for the '(' before 'local'
### What is the current *bug* behavior?
May confuse users
### What is the expected *correct* behavior?
See above
### Relevant configuration files
Not applicable
### Relevant logs and/or screenshots
Not applicable
### Possible fixes
See above, add closing parenthesis.November 2022 (9.16.35, 9.16.35-S1, 9.18.9, 9.19.7)https://gitlab.isc.org/isc-projects/bind9/-/issues/3651update danger to check for Approved2022-12-06T10:48:19ZEvan Huntupdate danger to check for ApprovedWe've started using Approve rather than LGTM to mark merge requests as ready to merge, but danger will still report:
```
elif "LGTM (Merge OK)" not in mr_labels:
warn(
"This merge request is currently in review. "
"I...We've started using Approve rather than LGTM to mark merge requests as ready to merge, but danger will still report:
```
elif "LGTM (Merge OK)" not in mr_labels:
warn(
"This merge request is currently in review. "
"It should not be merged until it is marked with the *LGTM* label."
)
```
I'd fix it myself, but I'm so unfamiliar with the gitlab API, I don't even know how Mr. Labels got set in the first place.December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3643Shutdown crash INSIST(__v > 0 && __v < (4294967295U)) in views system test2022-11-07T10:06:21ZMichal NowakShutdown crash INSIST(__v > 0 && __v < (4294967295U)) in views system testJob [#2874705](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2874705) failed for fd77c37820af3a6251ef46e1d13b8e01f0f31630 on shutdown with:
```
02-Nov-2022 07:19:46.747 zone_shutdown: zone example038.com/IN (unsigned): shutting down
0...Job [#2874705](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2874705) failed for fd77c37820af3a6251ef46e1d13b8e01f0f31630 on shutdown with:
```
02-Nov-2022 07:19:46.747 zone_shutdown: zone example038.com/IN (unsigned): shutting down
02-Nov-2022 07:19:46.747 calling free_rbtdb(example038.com)
02-Nov-2022 07:19:46.747 calling free_rbtdb(example017.com)
02-Nov-2022 07:19:46.747 zone.c:5783: INSIST(__v > 0 && __v < (4294967295U)) failed, back trace
```
```
D:views:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D views-ns2 -X named.lock -m'.
D:views:Program terminated with signal SIGABRT, Aborted.
D:views:#0 0x00007efe79bfdc4c in __pthread_kill_implementation () from /lib64/libc.so.6
D:views:[Current thread is 1 (Thread 0x7efe767bd640 (LWP 6646))]
D:views:#0 0x00007efe79bfdc4c in __pthread_kill_implementation () from /lib64/libc.so.6
D:views:#1 0x00007efe79bad9c6 in raise () from /lib64/libc.so.6
D:views:#2 0x00007efe79b977f4 in abort () from /lib64/libc.so.6
D:views:#3 0x00007efe7ae5fdf0 in abort () from /lib64/libtsan.so.2
D:views:#4 0x0000000000425700 in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at main.c:237
D:views:#5 0x00007efe7a888345 in isc_assertion_failed (file=file@entry=0x7efe7a80a95b "zone.c", line=line@entry=5783, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7efe7a7cf108 "__v > 0 && __v < (4294967295U)") at assertions.c:48
D:views:#6 0x00007efe7a76dd90 in dns_zone_attach (source=source@entry=0x7b7c00058600, target=target@entry=0x7b5c00054a60) at zone.c:5783
D:views:#7 0x00007efe7a77afe6 in zone_refreshkeys (zone=zone@entry=0x7b7c00058600) at zone.c:11359
D:views:#8 0x00007efe7a7a9ea0 in zone_maintenance (zone=0x7b7c00058600) at zone.c:11607
D:views:#9 zone_timer (task=<optimized out>, event=<optimized out>) at zone.c:15312
D:views:#10 0x00007efe7a8b7ad0 in task_run (task=0x7b3000000b40) at task.c:821
D:views:#11 isc_task_run (task=0x7b3000000b40) at task.c:901
D:views:#12 0x00007efe7a862e0c in isc__nm_async_task (worker=worker@entry=0x7ba400000000, ev0=ev0@entry=0x7b4800117300) at netmgr/netmgr.c:846
D:views:#13 0x00007efe7a86e11e in process_netievent (worker=worker@entry=0x7ba400000000, ievent=ievent@entry=0x7b4800117300) at netmgr/netmgr.c:918
D:views:#14 0x00007efe7a86edef in process_queue (worker=worker@entry=0x7ba400000000, type=type@entry=NETIEVENT_TASK) at netmgr/netmgr.c:1011
D:views:#15 0x00007efe7a86fb65 in process_all_queues (worker=0x7ba400000000) at netmgr/netmgr.c:765
D:views:#16 async_cb (handle=0x7ba400000360) at netmgr/netmgr.c:794
D:views:#17 0x00007efe79f6318f in uv__async_io (loop=0x7ba400000010, w=0x7ba4000001d8, events=1) at /usr/src/libuv-v1.44.1/src/unix/async.c:163
D:views:#18 0x00007efe79f7f5d7 in uv__io_poll (loop=0x7ba400000010, timeout=-1) at /usr/src/libuv-v1.44.1/src/unix/epoll.c:374
D:views:#19 0x00007efe79f63c2d in uv_run (loop=0x7ba400000010, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.44.1/src/unix/core.c:391
D:views:#20 0x00007efe7a86f202 in nm_thread (worker0=0x7ba400000000) at netmgr/netmgr.c:696
D:views:#21 0x00007efe7a8c2fd0 in isc__trampoline_run (arg=0x7b0c00002160) at trampoline.c:189
D:views:#22 0x00007efe7ae383f0 in __tsan_thread_start_func () from /lib64/libtsan.so.2
D:views:#23 0x00007efe79bfbe2d in start_thread () from /lib64/libc.so.6
D:views:#24 0x00007efe79c80364 in clone () from /lib64/libc.so.6
```
Full back trace and `views/ns2/named.run` are in the saved job.
isc-projects/bind9#3080 is a similar but closed-fixed issue in `rndc`.November 2022 (9.16.35, 9.16.35-S1, 9.18.9, 9.19.7)Evan HuntEvan Hunt