BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-02-25T10:34:03Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3114Release Checklist for BIND 9.16.26, 9.16.26-S12022-02-25T10:34:03ZMichał KępieńRelease Checklist for BIND 9.16.26, 9.16.26-S1## Release Schedule
**Code Freeze:**
Wednesday, 02 February 2022
**Tagging Deadline:**
Monday, 07 February 2022
**Public Release:**
Wednesday, 16 February 2022
## Documentation Review Links
**Closed issues assigned to the miles...## Release Schedule
**Code Freeze:**
Wednesday, 02 February 2022
**Tagging Deadline:**
Monday, 07 February 2022
**Public Release:**
Wednesday, 16 February 2022
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.16.26-S1](https://gitlab.isc.org/isc-private/bind9/-/issues?scope=all&state=closed&milestone_title=February+2022+%289.16.26%2C+9.16.26-S1%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16-S)
- [9.16.26](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&state=closed&milestone_title=February+2022+%289.16.26%2C+9.16.26-S1%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16)
**Merge requests merged into the milestone without a release note:**
- [9.16.26-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&state=merged&milestone_title=February+2022+%289.16.26%2C+9.16.26-S1%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=v9_16_sub)
- [9.16.26](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=February+2022+%289.16.26%2C+9.16.26-S1%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=v9_16)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been [indeed backported](https://gitlab.isc.org/isc-projects/bind9/-/issues/3114#note_264618).
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is in effect.
### Before the Tagging Deadline
- [x] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [X] ***(QA)*** ~~Update API files for libraries with new version information.~~
- [X] ***(QA)*** ~~Change software version and library versions in `configure.ac` (new major release only).~~
- [X] ***(QA)*** ~~Rebuild `configure` using Autoconf on `docs.isc.org`.~~ [Skipped](https://gitlab.isc.org/isc-projects/bind9/-/issues/3114#note_264935)
- [x] ***(QA)*** Update `CHANGES`.
- [x] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only).
- [X] ***(QA)*** ~~Update `README.md`.~~
- [x] ***(QA)*** Update `version`.
- [X] ***(QA)*** ~~Build documentation on `docs.isc.org`.~~
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is over.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, [sign tarballs](https://gitlab.isc.org/isc-private/signing/-/issues/66), and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### On the Day of Public Release
- [x] ~~***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).~~
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription Edition (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public RPMs.
- [x] ***(SwEng) *** Build Debian/Ubuntu packages.
- [x] ***(SwEng) *** Update Docker images.
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Merge the automatically prepared `prep 9.x.y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_x`).
- [x] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.February 2022 (9.16.26, 9.16.26-S1)Petr Špačekpspacek@isc.orgPetr Špačekpspacek@isc.org2022-02-16https://gitlab.isc.org/isc-projects/bind9/-/issues/3113Follow-up from "allow dns_clientinfo to store client ECS data"2023-02-27T14:15:08ZEvan HuntFollow-up from "allow dns_clientinfo to store client ECS data"The following discussion from !5555 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5555#note_257882): (+1 comment)
> Honestly, I would not change `dns_clientinf...The following discussion from !5555 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5555#note_257882): (+1 comment)
> Honestly, I would not change `dns_clientinfo_init()`, but would rather add extra function to set the ecs in the structure:
>
> ```suggestion:-2+0
> void
> dns_clientinfo_init(dns_clientinfo_t *ci, void *data, void *versionp);
>
> void
> dns_clientinfo_set_ecs(dns_clientinfo_t *ci, dns_ecs_t *ecs);
> ```
>
> That way the amount of changes to the other code would be minimized as if I count correctly, it's only three places, where we set the `ecs` data in the `dns_clientinfo` structure.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/3112[CVE-2022-0396] DoS in BIND via lingering TCP sockets stuck in CLOSE-WAIT2022-04-21T08:06:51ZDan Theisen[CVE-2022-0396] DoS in BIND via lingering TCP sockets stuck in CLOSE-WAIT<!--
THIS ISSUE TEMPLATE IS INTENDED ONLY FOR INTERNAL USE.
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 - the...<!--
THIS ISSUE TEMPLATE IS INTENDED ONLY FOR INTERNAL USE.
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).
-->
An issue in BIND can consume TCP connection slots indefinitely via a specifically crafted TCP stream sent by a client.
https://wiki.isc.org/bin/view/Main/SecurityIncident202201TCPStuckInCloseWaitDoS
### CVE-specific actions
- [x] Assign a CVE identifier: CVE-2022-0396
- [x] Determine CVSS score: 4.9 total (5.3 base), CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L/E:F/RL:O/RC:C
- [x] Determine the range of BIND versions affected (including the Subscription Edition)
- [x] Determine whether workarounds for the problem exists
- Issue can be mitigated by setting `keep-repsonse-order { "none"; };`
- [x] Create a draft of the security advisory and put the information above in there
- https://mattermost.isc.org/isc/channels/cve-2022-0396-dos-lingering-tcp-sockets/hyt7spw4dpnpf89nfra5htuexy
- [x] Prepare a detailed description of the problem which should include the following by default:
- instructions for reproducing the problem (a system test is good enough)
- The configuration option `keep-response-order { "any"; };` must be set on the server.
- A script which reproduces the issue is attached [I-root-19872-linger-repro_bind-9.16.py](/uploads/283b5c088abfc60312e0378a1899b88c/I-root-19872-linger-repro_bind-9.16.py)
- Client opens TCP socket with server with SO_LINGER sockopt set to >0
- Client must send at least ONE properly formed query to the server
- Client sends any additional garbage to server over socket
- Client closes socket and walks away
- Connection on server side stays in CLOSE-WAIT indefinitely
- https://gitlab.isc.org/isc-projects/bind9/-/issues/3112#note_265790
- [x] Prepare a private merge request containing the following items in separate commits:
- a test for the issue (may be moved to a separate merge request for deferred merging)
- https://gitlab.isc.org/isc-private/bind9/-/merge_requests/354
- a fix for the issue
- documentation updates (`CHANGES`, release notes, anything else applicable)
- https://gitlab.isc.org/isc-private/bind9/-/merge_requests/353
- [x] Ensure the merge request from the previous step is reviewed by SWENG staff and has no outstanding discussions
- [x] Ensure the documentation changes introduced by the merge request addressing the problem are reviewed by Support and Marketing staff
- [x] Prepare backports of the merge request addressing the problem for all affected (and still maintained) BIND branches (backporting might affect the issue's scope and/or description)
- [x] Prepare a standalone patch for the last stable release of each affected (and still maintained) BIND branch
### Release-specific actions
- [x] [Create/update the private issue containing links to fixes & reproducers for all CVEs fixed in a given release cycle](isc-private/bind9#49)
- [x] [Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined](!5925)
- [x] Ensure the merge requests containing CVE fixes are merged into `security-*` branches in CVE identifier order
### Post-disclosure actions
- [x] Merge a regression test reproducing the bug into all affected (and still maintained) BIND branchesMarch 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3111restore missing lines in dlz_pthread.h2022-03-04T13:33:58ZEvan Huntrestore missing lines in dlz_pthread.hJosef Möllers pointed out on bind-users that DLZ modules cannot be built in 9.16 due to some lines that were inadvertently deleted when updating the copyrights.Josef Möllers pointed out on bind-users that DLZ modules cannot be built in 9.16 due to some lines that were inadvertently deleted when updating the copyrights.February 2022 (9.16.26, 9.16.26-S1)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3110Release Checklist for BIND 9.18.02022-01-26T14:34:39ZMichał KępieńRelease Checklist for BIND 9.18.0## Release Schedule
**Code Freeze:** Wednesday, January 19th, 2022
**Tagging Deadline:** Monday, January 24th, 2022
**Public Release:** Wednesday, January 26th, 2022
## Documentation Review Links
**Closed issues assigned to the mile...## Release Schedule
**Code Freeze:** Wednesday, January 19th, 2022
**Tagging Deadline:** Monday, January 24th, 2022
**Public Release:** Wednesday, January 26th, 2022
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.18.0](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&state=closed&milestone_title=January%202022%20(9.18.0)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
**Merge requests merged into the milestone without a release note:**
- [9.18.0](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=January%202022%20(9.18.0)¬[label_name][]=Release%20Notes&target_branch=main)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.18.0](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=January%202022%20(9.18.0)&label_name[]=No%20CHANGES&target_branch=main)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is in effect.
### Before the Tagging Deadline
- [x] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Update API files for libraries with new version information.
- [x] ***(QA)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(QA)*** Update `CHANGES`.
- [x] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update `README.md`.
- [x] ***(QA)*** Update `version`.
- [x] ***(QA)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is over.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription Edition (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public RPMs.
- [x] ***(SwEng)*** Build Debian/Ubuntu packages.
- [x] ***(SwEng)*** Update Docker images.
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Merge the automatically prepared `prep 9.x.y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_x`).
- [x] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.January 2022 (9.18.0)Michał KępieńMichał Kępień2022-01-26https://gitlab.isc.org/isc-projects/bind9/-/issues/3109What are the forwarding rules for forwarding servers in named.conf?2022-01-24T08:27:20Zweijun linWhat are the forwarding rules for forwarding servers in named.conf?### Description
named.conf as the following configuration.
>
> ` forward only;
forwarders { 6.27.56.109;6.27.56.110; };
`
The {6.27.56.109;} as the next-level dns service node has been shutdown, and 6.27.56.110 is active.
When ...### Description
named.conf as the following configuration.
>
> ` forward only;
forwarders { 6.27.56.109;6.27.56.110; };
`
The {6.27.56.109;} as the next-level dns service node has been shutdown, and 6.27.56.110 is active.
When I make a forward domain name request, the following error occurs
> `; <<>> DiG 9.11.21-9.11.21-4.h9.eulerosv2r10 <<>> @127.0.0.1 lwj.233.com
; (2 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
`
### Request
I want to know the forwards rules in named.conf forwards config. It doesn't working in Round-Robin Scheduling? when one node been shutdown, and forward to the other node?
> forwarders { 6.27.56.109;6.27.56.110; };
Is any health check algrithom working in foewarders list?
### Links / references
Nonehttps://gitlab.isc.org/isc-projects/bind9/-/issues/3108bind9 fails to start on machines where glibc does not provide L1 cache size2022-02-25T13:19:31ZDustin L. Howettbind9 fails to start on machines where glibc does not provide L1 cache size### Summary
There are machines where sysconf() cannot return a value for the L1 cache size, so it returns `0`.
### BIND version used
```
# named -V
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
Aborted
```
Based...### Summary
There are machines where sysconf() cannot return a value for the L1 cache size, so it returns `0`.
### BIND version used
```
# named -V
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
Aborted
```
Based on my package manager, I believe this is bind9-9.17.22.
### Steps to reproduce
Run bind9-9.17.22 on arm32.
### What is the current *bug* behavior?
The change in https://gitlab.isc.org/isc-projects/bind9/-/commit/4f78f9d72a5dc3f6a596251e662d00cb80cd5e6d introduced a runtime assert that the compiled-in cache line size matches the runtime one.
However, on 32-bit ARM machines, glibc will not report an L1 cache line size. It appears as though sysconf() is not implemented specifically in glibc's ARM port.
It falls through to the implementation [here](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/posix/sysconf.c;h=8b74ad6184cc724b2291c35249021a059e331fcc;hb=HEAD#l1170), which returns `0`.¹
Unfortunately, this all happens after (1) we check whether sysconf is available and (2) we check whether `_SC_LEVEL1_DCACHE_LINESIZE` is available. It is available, but wrong.
¹I don't understand why it returns `0` when the documented return value in a failure is `-1`. This is discussed briefly on the [binutils mailing list](https://binutils.sourceware.narkive.com/FAQQWMTY/are-syconf-sc-xxx-issues-glibc-or-kernel-issues).
### What is the expected *correct* behavior?
`named`, `dig`, ... run.
### Relevant configuration files
None - this happens in early startup regardless of config.
### Relevant logs and/or screenshots
```
root@deneb:~# named -V
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
Aborted
root@deneb:~# dig @localhost google.com
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
Aborted
root@deneb:~# nslookup howett.net
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
Aborted
```January 2022 (9.18.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/31079.17.22 doesn't build on Raspberry Pi 3B2022-01-24T07:31:34ZWerner Wiethege9.17.22 doesn't build on Raspberry Pi 3Bmake terminates on Raspbian GNU/Linux 11 (bullseye) with
make[4]: Entering directory '/home/ww/build/bind/ww-bind-9.17.22/doc/misc'
CC cfg_test-cfg_test.o
CCLD cfg_test
CFG_GEN options
os.c:84: fatal error...make terminates on Raspbian GNU/Linux 11 (bullseye) with
make[4]: Entering directory '/home/ww/build/bind/ww-bind-9.17.22/doc/misc'
CC cfg_test-cfg_test.o
CCLD cfg_test
CFG_GEN options
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
CFG_GEN options.active
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
CFG_GEN master.zoneopt
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
The cause is a
[known problem](https://github.com/raspberrypi/Raspberry-Pi-OS-64bit/issues/195)
> It looks like the L1/L2/L3 hierarchy is missing which may have a huge impact on performance for some applications.
A patch has been [submitted](https://github.com/raspberrypi/linux/pull/4751)
> I submitted them but I'm not sure when they will be merged:https://gitlab.isc.org/isc-projects/bind9/-/issues/3106Bind 9.16 not serving ULA AAAA to private network2022-01-23T22:17:59ZDerekBind 9.16 not serving ULA AAAA to private network### Summary
I'm trying to serve AAAA records to my private network, and I've discovered that Bind 9.16.22 does not reply with records that 9.11.5 did. In testing, I set up a zone file with these records:
```testhost IN AAAA 2001:db9...### Summary
I'm trying to serve AAAA records to my private network, and I've discovered that Bind 9.16.22 does not reply with records that 9.11.5 did. In testing, I set up a zone file with these records:
```testhost IN AAAA 2001:db9::3
testhost IN AAAA 64:ff9b::1.2.3.4
testhost IN AAAA 2001:db8::3
testhost IN AAAA 2001:db7::3
testhost IN AAAA 2000:63ed:f2b7::3
testhost IN AAAA fd50:63ed:f2b7::3
```
But the reply in the newer version of bind (9.16.22) will filter out the documentation address (2001:db8::), the ULA address (fd00::), and the NAT64 address (64:ff9b::). A query thus sees the 2001:db7::, 2001:db9::, and 2000:: addresses.
This seems like an intentional change. I could not find anything that seemed to apply in the changelog, and I cannot find anything that seems to apply in the documentation to adjust this range-specific filtering.
Is it supposed to do that? Can I tell it not to do that? I'm serving names for a private network, for which I would like to use the ULA addresses.
### BIND version used
```BIND 9.16.22-Debian (Extended Support Version) <id:59bfaba>
running on Linux aarch64 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021
built by make with '--build=aarch64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=/usr/lib/aarch64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/aarch64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=aarch64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-X1cy80/bind9-9.16.22=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 10.2.1 20210110
compiled with OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
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
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
default paths:
named configuration: /etc/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
Zone file:
```$TTL 6h
$ORIGIN seaofdirac.org.
@ IN SOA ns1 hostmaster (
2022011012 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
IN NS ns1
IN NS ns2
; HOSTS
$ORIGIN seaofdirac.org.
ns1 IN AAAA fd50:63ed:f2b7::5
ns2 IN AAAA fd50:63ed:f2b7::1
testhost IN AAAA 64:ff9b::1.2.3.4
testhost IN AAAA 2001:db9::3
testhost IN AAAA 2001:db8::3
testhost IN AAAA 2001:db7::3
testhost IN AAAA 2000:63ed:f2b7::3
testhost IN AAAA fd50:63ed:f2b7::3
testhost IN A 10.0.0.3
testhost IN A 192.168.145.3
```
Zone statement in named.conf:
```zone "seaofdirac.org" {
type master;
file "/var/lib/bind/zones/seaofdirac.org.db";
allow-transfer { trusted; };
allow-update { key ddns-key.seaofdirac.org; };
};
zone "7.b.2.f.d.e.3.6.0.5.d.f.ip6.arpa" {
type master;
file "/var/lib/bind/zones/fd50.63ed.f2b7-reverse.db";
allow-transfer { trusted; };
allow-update { key ddns-key.seaofdirac.org; };
};
```
### What is the current *bug* behavior?
Asking BIND 9.16
```;; ANSWER SECTION:
testhost.seaofdirac.org. 21600 IN AAAA 2000:63ed:f2b7::3
testhost.seaofdirac.org. 21600 IN AAAA 2001:db9::3
testhost.seaofdirac.org. 21600 IN AAAA 2001:db7::3
```
### What is the expected *correct* behavior?
Asking BIND 9.11 (yes, the zone file is different there):
```;; ANSWER SECTION:
testhost.seaofdirac.org. 21600 IN AAAA 2001:db9::3
testhost.seaofdirac.org. 21600 IN AAAA 2001:db8::3
testhost.seaofdirac.org. 21600 IN AAAA 64:ff9b::3
testhost.seaofdirac.org. 21600 IN AAAA 1000::3
```
This shows resolution to addresses that are "invalid" as well as simply not globally routable.
### Relevant configuration files
named.conf.options
```options {
directory "/var/cache/bind";
listen-on {
"none";
};
listen-on-v6 {
"any";
};
allow-recursion {
"internal";
};
auth-nxdomain no;
dns64 64:ff9b::/96 {
break-dnssec yes;
clients {
!"translator";
"dns64-good-clients";
};
exclude {
::/3;
4000::/2;
8000::/1;
2001:db8::/32;
};
mapped {
!"rfc1918";
"any";
};
};
dnssec-validation auto;
dual-stack-servers {
fd50:63ed:f2b7::1;
fe80::8083:dff:fe46:8b53%2;
};
recursion yes;
response-policy {
zone "rpz.blocklist";
};
allow-query {
"internal";
};
allow-transfer {
"none";
};
};
```
I had thought the exclude statement in the dns64 block might matter, but it appears not to limit the BIND 9.11 from reporting the addresses, nor does removing it allow the BIND 9.16 to report them.
### Possible fixes
Am I just missing some configuration option?https://gitlab.isc.org/isc-projects/bind9/-/issues/3105Assertion failure on shutdown in req_senddone()2022-03-08T08:50:44ZMichal NowakAssertion failure on shutdown in req_senddone()This seems to be the same issue as isc-projects/bind9#2951 but it has the fix isc-projects/bind9!5715 in and the problem still occurs in the CI.
Job [#2240130](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2240130) failed for 710f62b...This seems to be the same issue as isc-projects/bind9#2951 but it has the fix isc-projects/bind9!5715 in and the problem still occurs in the CI.
Job [#2240130](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2240130) failed for 710f62bf39a925c9a580192ec5ce8dee1ea66a06:
```
D:inline:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D inline-ns2 -X named.lock -m'.
D:inline:Program terminated with signal SIGABRT, Aborted.
D:inline:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:inline:[Current thread is 1 (Thread 0x7f9c82efb700 (LWP 28048))]
D:inline:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:inline:#1 0x00007f9c885cc537 in __GI_abort () at abort.c:79
D:inline:#2 0x0000000000420cbc in assertion_failed (file=0x7f9c89033a11 "request.c", line=<optimized out>, type=<optimized out>, cond=<optimized out>) at main.c:238
D:inline:#3 0x00007f9c890b726a in isc_assertion_failed (file=0x2 <error: Cannot access memory at address 0x2>, line=-2098243744, line@entry=1030, type=type@entry=isc_assertiontype_require, cond=0x7f9c885e2ce1 <__GI_raise+321> "H\213\204$\b\001") at assertions.c:49
D:inline:#4 0x00007f9c88f82172 in req_senddone (eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at request.c:1030
D:inline:#5 0x00007f9c88eb8cb5 in send_done (handle=0x7f9c75389780, result=ISC_R_CANCELED, cbarg=0x0) at dispatch.c:1864
D:inline:#6 0x00007f9c890a7cbf in isc__nm_async_sendcb (worker=<optimized out>, ev0=ev0@entry=0x7f9c7538a080) at netmgr/netmgr.c:2838
D:inline:#7 0x00007f9c890a4362 in process_netievent (worker=worker@entry=0x7f9c85c49c80, ievent=ievent@entry=0x7f9c7538a080) at netmgr/netmgr.c:972
D:inline:#8 0x00007f9c8909fa81 in process_queue (worker=0x7f9c85c49c80, type=NETIEVENT_NORMAL) at netmgr/netmgr.c:1010
D:inline:#9 process_all_queues (worker=0x7f9c85c49c80) at netmgr/netmgr.c:756
D:inline:#10 async_cb (handle=0x7f9c85c49fe0) at netmgr/netmgr.c:785
D:inline:#11 0x00007f9c889bce83 in uv__async_io (loop=0x7f9c85c49c90, w=0x7f9c85c49e58, events=1) at /usr/src/libuv-v1.43.0/src/unix/async.c:163
D:inline:#12 0x00007f9c889d8b87 in uv__io_poll (loop=0x7f9c85c49c90, timeout=0) at /usr/src/libuv-v1.43.0/src/unix/epoll.c:374
D:inline:#13 0x00007f9c889bd86c in uv_run (loop=0x7f9c85c49c90, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.43.0/src/unix/core.c:389
D:inline:#14 0x00007f9c8909fbf1 in nm_thread (worker0=0x7f9c85c49c80) at netmgr/netmgr.c:691
D:inline:#15 0x00007f9c890dede5 in isc__trampoline_run (arg=0x2372760) at trampoline.c:187
D:inline:#16 0x00007f9c88774ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
D:inline:#17 0x00007f9c886a4def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
[core.28030-backtrace.txt](/uploads/454199c1540460b792772cad022aea8f/core.28030-backtrace.txt)April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/3104Add latest DNS RFCs to doc/arm/general.rst2022-01-19T18:10:17ZSuzanne GoldlustAdd latest DNS RFCs to doc/arm/general.rstSome new RFCs have been published (and listed on https://www.isc.org/rfcs/), but they haven't been added to the ARM list yet.Some new RFCs have been published (and listed on https://www.isc.org/rfcs/), but they haven't been added to the ARM list yet.https://gitlab.isc.org/isc-projects/bind9/-/issues/31039.17.21 will not compile on centos 7.42022-01-18T10:54:53Zchampiondot9.17.21 will not compile on centos 7.4```
gcc -std=gnu99 -include /root/xiejieling/bind-9.16.18/config.h -I/root/xiejieling/bind-9.16.18 -I../.. -I/root/xiejieling/bind-9.16.18/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/...```
gcc -std=gnu99 -include /root/xiejieling/bind-9.16.18/config.h -I/root/xiejieling/bind-9.16.18 -I../.. -I/root/xiejieling/bind-9.16.18/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -g -O2 -pthread -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers -fno-strict-aliasing -c pkcs11-keygen.c
pkcs11-keygen.c:79:1: 错误:用非常量的数组表达式初始化数组
static CK_BYTE pk11_ecc_prime256v1[] = PK11_ECC_PRIME256V1;
^
pkcs11-keygen.c:80:1: 错误:用非常量的数组表达式初始化数组
static CK_BYTE pk11_ecc_secp384r1[] = PK11_ECC_SECP384R1;
^
pkcs11-keygen.c:81:1: 错误:用非常量的数组表达式初始化数组
static CK_BYTE pk11_ecx_ed25519[] = PK11_ECX_ED25519;
^
pkcs11-keygen.c:82:1: 错误:用非常量的数组表达式初始化数组
static CK_BYTE pk11_ecx_ed448[] = PK11_ECX_ED448;
^
make[2]: *** [pkcs11-keygen.o] 错误 1
make[2]: 离开目录“/root/xiejieling/bind-9.16.18/bin/pkcs11”
make[1]: *** [subdirs] 错误 1
make[1]: 离开目录“/root/xiejieling/bind-9.16.18/bin”
make: *** [subdirs] 错误 1
``https://gitlab.isc.org/isc-projects/bind9/-/issues/3102ASAN error in fctx_cancelquery()2023-11-03T07:32:07ZMichał KępieńASAN error in fctx_cancelquery()Apparently #3018/!5584 was not the only scenario to fix.
https://gitlab.isc.org/isc-projects/bind9/-/jobs/2233451
<details>
<summary>Click to expand/collapse backtrace</summary>
<pre>D:forward:Core was generated by `/builds/isc-project...Apparently #3018/!5584 was not the only scenario to fix.
https://gitlab.isc.org/isc-projects/bind9/-/jobs/2233451
<details>
<summary>Click to expand/collapse backtrace</summary>
<pre>D:forward:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D forward-ns3 -X named.lock -'.
D:forward:Program terminated with signal SIGABRT, Aborted.
D:forward:#0 0x00007f82ca52984c in __pthread_kill_implementation () from /lib64/libc.so.6
D:forward:[Current thread is 1 (Thread 0x7f82c26e8640 (LWP 6446))]
D:forward:#0 0x00007f82ca52984c in __pthread_kill_implementation () from /lib64/libc.so.6
D:forward:#1 0x00007f82ca4dc6a6 in raise () from /lib64/libc.so.6
D:forward:#2 0x00007f82ca4c67d3 in abort () from /lib64/libc.so.6
D:forward:#3 0x00007f82ce2a05df in __sanitizer::Abort() () from /lib64/libasan.so.6
D:forward:#4 0x00007f82ce2ab94c in __sanitizer::Die() () from /lib64/libasan.so.6
D:forward:#5 0x00007f82ce28cd9c in __asan::ScopedInErrorReport::~ScopedInErrorReport() () from /lib64/libasan.so.6
D:forward:#6 0x00007f82ce28c666 in __asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) () from /lib64/libasan.so.6
D:forward:#7 0x00007f82ce28d22c in __asan_report_load4 () from /lib64/libasan.so.6
D:forward:#8 0x00007f82cc974fa5 in fctx_cancelquery (queryp=queryp@entry=0x7f82c26e1fb0, finish=0x7f82c26e29a8, no_response=no_response@entry=false, age_untried=age_untried@entry=false) at resolver.c:1297
D:forward:#9 0x00007f82cc99e8df in rctx_done (rctx=rctx@entry=0x7f82c26e2930, result=result@entry=ISC_R_SUCCESS) at resolver.c:9658
D:forward:#10 0x00007f82cc9af918 in resquery_response (eresult=eresult@entry=ISC_R_SUCCESS, region=region@entry=0x7f82c26e4570, arg=<optimized out>) at resolver.c:7805
D:forward:#11 0x00007f82cc5b49a5 in udp_recv (handle=<optimized out>, eresult=ISC_R_SUCCESS, region=<optimized out>, arg=<optimized out>) at dispatch.c:593
D:forward:#12 0x00007f82cd8f6f00 in isc__nm_async_readcb (worker=worker@entry=0x0, ev0=ev0@entry=0x7f82c26e4610) at netmgr/netmgr.c:2798
D:forward:#13 0x00007f82cd8f755f in isc__nm_readcb (sock=sock@entry=0x61d0000a3280, uvreq=uvreq@entry=0x61d0000a4680, eresult=eresult@entry=ISC_R_SUCCESS) at netmgr/netmgr.c:2771
D:forward:#14 0x00007f82cd934490 in udp_recv_cb (handle=handle@entry=0x61d0000a3830, nrecv=nrecv@entry=339, buf=buf@entry=0x7f82c26e4860, addr=addr@entry=0x7f82c26e48b0, flags=flags@entry=0) at netmgr/udp.c:641
D:forward:#15 0x00007f82cd93854f in isc__nm_udp_read_cb (handle=0x61d0000a3830, nrecv=339, buf=0x7f82c26e4860, addr=0x7f82c26e48b0, flags=0) at netmgr/udp.c:1047
D:forward:#16 0x00007f82cb21acc4 in uv__udp_recvmsg (handle=0x61d0000a3830) at /usr/src/libuv-v1.43.0/src/unix/udp.c:302
D:forward:#17 0x00007f82cb21a5e8 in uv__udp_io (loop=0x6280000021e0, w=0x61d0000a38b0, revents=1) at /usr/src/libuv-v1.43.0/src/unix/udp.c:178
D:forward:#18 0x00007f82cb22162b in uv__io_poll (loop=0x6280000021e0, timeout=800) at /usr/src/libuv-v1.43.0/src/unix/epoll.c:374
D:forward:#19 0x00007f82cb205c01 in uv_run (loop=0x6280000021e0, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.43.0/src/unix/core.c:389
D:forward:#20 0x00007f82cd8fad6d in nm_thread (worker0=0x6280000021d0) at netmgr/netmgr.c:691
D:forward:#21 0x00007f82cd9f87f6 in isc__trampoline_run (arg=0x60300002c6b0) at trampoline.c:187
D:forward:#22 0x00007f82ca527a87 in start_thread () from /lib64/libc.so.6
D:forward:#23 0x00007f82ca5ab8d4 in clone () from /lib64/libc.so.6
D:forward:--------------------------------------------------------------------------------</pre>
</details>
Unfortunately, the job ran over the weekend and the artifacts were no
longer available when I tried to examine them today, so I am unable to
paste the full ASAN report. However, judging from line numbers, the
problem lies here:
```c
1286 REQUIRE(queryp != NULL);
1287
1288 query = *queryp;
1289 fctx = query->fctx;
1290
1291 if (RESQUERY_CANCELED(query)) {
1292 return;
1293 }
1294
1295 FCTXTRACE("cancelquery");
1296
1297 >>> query->attributes |= RESQUERY_ATTR_CANCELED;
```
Looking at the test output, I sense this is happening on shutdown.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3101doth: enable max-age checking in system test on OpenBSD2022-01-21T07:37:17ZMichal Nowakdoth: enable max-age checking in system test on OpenBSDOpenBSD's `curl` has HTTP/2 support but because of differences in `grep` implementation, a check in `doth` test [disables](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2233880) max-age checking tests which need HTTP/2 aware `curl` an...OpenBSD's `curl` has HTTP/2 support but because of differences in `grep` implementation, a check in `doth` test [disables](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2233880) max-age checking tests which need HTTP/2 aware `curl` and are skipped with `The available version of CURL does not have HTTP/2 support` message.
`curl -V`:
```
curl 7.79.0 (x86_64-unknown-openbsd7.0) libcurl/7.79.0 LibreSSL/3.4.1 zlib/1.2.11 nghttp2/1.44.0
Release-Date: 2021-09-15
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL UnixSockets
```
But the current check won't detect it:
```
$ /usr/local/bin/curl --version | grep '^Features:.* HTTP2\( \|$\)'
$
```
This should do (also tested on Fedora 35 & FreeBSD 12.3):
```
$ /usr/local/bin/curl --version | grep -E '^Features:.* HTTP2( |$)'
Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL UnixSockets
```
The check originated here: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5585#note_250222.January 2022 (9.18.0)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3100bind-9.17.21 configure error: "EVP_DigestSignInit/EVP_DigestVerifyInit suppor...2022-01-17T10:14:58ZbboyHanbind-9.17.21 configure error: "EVP_DigestSignInit/EVP_DigestVerifyInit support in OpenSSL is mandator"my openssl version is 1.1.1,(I try to change my openssl version - 1.0.x also can't)
use command:
./configure --prefix=/usr/local/bind --with-dlz-mysql=/usr/local/mariadb/ --enable-threads --disable-chroot --enable-largefile --enable-epo...my openssl version is 1.1.1,(I try to change my openssl version - 1.0.x also can't)
use command:
./configure --prefix=/usr/local/bind --with-dlz-mysql=/usr/local/mariadb/ --enable-threads --disable-chroot --enable-largefile --enable-epoll --without-python
ERROR
config: EVP_DigestSignInit/EVP_DigestVerifyInit support in OpenSSL is mandator
see 'config.log' ...
I change my bind9 version to 9.11.36. Nothing goes wrong.https://gitlab.isc.org/isc-projects/bind9/-/issues/3099doth system test fails because it uses 'timeout'2022-01-18T10:03:12ZMark Andrewsdoth system test fails because it uses 'timeout'```
I:doth:checking max-age for positive answer (146)
I:doth:checking max-age for negative answer (147)
I:doth:checking sending a DoT query using gnutls-cli (148)
tests.sh: line 603: timeout: command not found
I:doth:failed
I:doth:exit s...```
I:doth:checking max-age for positive answer (146)
I:doth:checking max-age for negative answer (147)
I:doth:checking sending a DoT query using gnutls-cli (148)
tests.sh: line 603: timeout: command not found
I:doth:failed
I:doth:exit status: 1
I:doth:stopping servers
R:doth:FAIL
E:doth:2022-01-17T14:29:17+1100
FAIL: doth
```
`timeout` is GNU specific. `&& sleep 10 && cat /dev/null` should work if `sleep` is closing `stdout` at startup. Additionally `timeout 10 cat` reads from `stdin` which no part of the system tests should do.January 2022 (9.18.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/3098Intermittent mkeys test failure2022-01-14T13:53:30ZOndřej SurýIntermittent mkeys test failurehttps://gitlab.isc.org/isc-projects/bind9/-/jobs/2231254
```
I:mkeys:reset the root server with no keys, check for minimal update (23)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:ns2 refreshing managed keys for '_default'
...https://gitlab.isc.org/isc-projects/bind9/-/jobs/2231254
```
I:mkeys:reset the root server with no keys, check for minimal update (23)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:failed
I:mkeys:reset the root server with no signatures, check for minimal update (24)
```
I am guessing this is timing related again.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/30979.16 responds with Additional section even though "minimal-responses" is set ...2022-03-21T14:37:51ZGreg Choules9.16 responds with Additional section even though "minimal-responses" is set to yesAs reported in [20030](https://support.isc.org/Ticket/Display.html?id=20030)
An authoritative server (secondary, but it happens on a primary as well) is configured with "minimal-responses yes;". Queries to it - either recursive or non-r...As reported in [20030](https://support.isc.org/Ticket/Display.html?id=20030)
An authoritative server (secondary, but it happens on a primary as well) is configured with "minimal-responses yes;". Queries to it - either recursive or non-recursive - for a name it owns receive a response containing the answer + an Additional section. For comparison, 9.11 provides only the answer section.
This issue is, firstly, a question: why does 9.16 do this and do subsequent versions behave the same way?
Secondly, if this behaviour is unintended can it be fixed?
**Config**
```
options {
minimal-responses yes;
zone "junk" {
type primary;
file "db.junk";
};
```
**zone data**
```
@ SOA test test 2022011301 10800 3600 604800 1800
@ NS a.nsset.junk.
@ NS b.nsset.junk.
a.nsset A 1.2.3.4
b.nsset A 1.2.3.5
```
**dig output**
```
; <<>> DiG 9.16.19 <<>> @127.0.0.1 junk ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44384
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: a42ac059d64983360100000061e06294be1d9cc3a16e3adc (good)
;; QUESTION SECTION:
;junk. IN NS
;; ANSWER SECTION:
junk. 1800 IN NS b.nsset.junk.
junk. 1800 IN NS a.nsset.junk.
;; ADDITIONAL SECTION:
a.nsset.junk. 1800 IN A 1.2.3.4
b.nsset.junk. 1800 IN A 1.2.3.5
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 13 17:34:12 GMT 2022
;; MSG SIZE rcvd: 135
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3096unable to convert libuv error code in udp_send_cb to isc_result: -39: destina...2023-01-05T19:34:54ZMichal Nowakunable to convert libuv error code in udp_send_cb to isc_result: -39: destination address requiredGoing thru system test logs I noticed one more (isc-projects/bind9!5712) unmapped libuv error code on Dragonfly BSD 6.2.1:
```
netmgr/udp.c:769: unable to convert libuv error code in udp_send_cb to isc_result: -39: destination address re...Going thru system test logs I noticed one more (isc-projects/bind9!5712) unmapped libuv error code on Dragonfly BSD 6.2.1:
```
netmgr/udp.c:769: unable to convert libuv error code in udp_send_cb to isc_result: -39: destination address required
```
[zero.log](/uploads/33fc0ed314312abd72596e541f09870c/zero.log)January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/3095Invalid recvmmsg detection2022-01-21T07:43:23ZOndřej SurýInvalid recvmmsg detectionThe code in `netmgr/udp.c` uses `#ifdef` for checking whether the `recvmmsg` in libuv is available. But because the checked symbols are actually `enum` members and not preprocessor macros, the checks are always false effectively renderi...The code in `netmgr/udp.c` uses `#ifdef` for checking whether the `recvmmsg` in libuv is available. But because the checked symbols are actually `enum` members and not preprocessor macros, the checks are always false effectively rendering the `recvmmsg` support enabled only with libuv >= 1.35.0 where implicit `recvmmsg` support was added and << 1.37.0 where the `recvmmsg` use needs to be explicitly enabled with a flag to `uv_udp_init_ex()`.January 2022 (9.18.0)Ondřej SurýOndřej Surý