ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-12-01T12:31:46Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2315BIND 9.11.22 - 9.11.25 fails to build for AEP HSM native pkcs112020-12-01T12:31:46ZCathy AlmondBIND 9.11.22 - 9.11.25 fails to build for AEP HSM native pkcs11[Support ticket #17347](https://support.isc.org/Ticket/Display.html?id=17347)
./configure --enable-threads --enable-native-pkcs11 --with-ecdsa -with-pkcs11=/opt/Keyper/PKCS11Provider/pkcs11.so
I think it's the --enable-native-pkcs11 AN...[Support ticket #17347](https://support.isc.org/Ticket/Display.html?id=17347)
./configure --enable-threads --enable-native-pkcs11 --with-ecdsa -with-pkcs11=/opt/Keyper/PKCS11Provider/pkcs11.so
I think it's the --enable-native-pkcs11 AND using the AEP Keyper flavour of native pkcs11 that is setting the switch so that we fail the build
The build fail is this:
```
pkcs11rsa_link.c: In function 'pkcs11rsa_verify':
pkcs11rsa_link.c:1081:4: error: a label can only be part of a statement and a declaration is not a statement
```
This is in the flavour of pkcs11rsa_verify() that is inside the else section of #ifndef PK11_RSA_PKCS_REPLACE
By my reading of /lib/isc/include/pk11/site.h, we're defining PK11_RSA_PKCS_REPLACE if we're working with an AEP pkcs11 set of libs (but not apparently for anything else).
Here's the offending bit of code in `/lib/dns/pkcs11rsa_link.c` (the define for 'bits' was added by issue #2037 )
```
case CKA_PUBLIC_EXPONENT:
unsigned int bits;
INSIST(keyTemplate[6].type == attr->type);
```
From what I'm reading about this compiler error, the problem is that the C language standard says that labels can only be followed by statements. What we've got here is a declarations - and that's not perceived as a statement in C.
Apparently, the workaround is to add an empty statement - it's been suggested that comment after the label will do the trick (though I am not in a position to verify that) - but if yes, then this should work:
```
case CKA_PUBLIC_EXPONENT: /* Empty statement to make compiler happy */
unsigned int bits;
INSIST(keyTemplate[6].type == attr->type);
```
Please can someone look at this soonest!December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/kea/-/issues/1581siaddr in NAK2020-12-21T14:12:33ZFrancis Dupontsiaddr in NAKThis is about a failing system test (tests.dhcpv4.fields.test_v4_fields.test_v4_message_fields_siaddr_correct_nak_configured_local) which checks if Kea sets the siaddr fiedld in NAKs.
I do not know if the test or Kea is wrong.
The RFC ...This is about a failing system test (tests.dhcpv4.fields.test_v4_fields.test_v4_message_fields_siaddr_correct_nak_configured_local) which checks if Kea sets the siaddr fiedld in NAKs.
I do not know if the test or Kea is wrong.
The RFC 2131 describes the siaddr field as:
```
siaddr 4 IP address of next server to use in bootstrap;
returned in DHCPOFFER, DHCPACK by server.
```
so a priori it is correct to not return it (i.e. leave it to 0.0.0.0) in DHCPNAK responses. BTW these responses are very low in informations both because they are useless and for security.
Other references to siaddr in the RFC are:
```
DHCP clarifies the interpretation of the 'siaddr' field as the
address of the server to use in the next step of the client's
bootstrap process. A DHCP server may return its own address in the
'siaddr' field, if the server is prepared to supply the next
bootstrap service (e.g., delivery of an operating system executable
image).
```
and in the Table 3:
```
Field DHCPOFFER DHCPACK DHCPNAK
----- --------- ------- -------
'siaddr' IP address of next IP address of next 0
bootstrap server bootstrap server
```
so if there is no other argument about this point I think we can conclude that Kea is right and the system test (and similar tests) should be fixed or removed.https://gitlab.isc.org/isc-projects/kea/-/issues/1580Backport #1469 missing upgrade_X.A_to_Y.B from Makefile (install and distclea...2020-11-27T15:13:49ZRazvan BecheriuBackport #1469 missing upgrade_X.A_to_Y.B from Makefile (install and distclean) to 1.8.2Backport #1469 missing upgrade_X.A_to_Y.B from Makefile (install and distclean) to 1.8.2Backport #1469 missing upgrade_X.A_to_Y.B from Makefile (install and distclean) to 1.8.2kea1.8.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1579Backport #802: CQL cass_cluster_set_reconnect_wait_time is now deprecated2020-11-28T09:06:03ZFrancis DupontBackport #802: CQL cass_cluster_set_reconnect_wait_time is now deprecatedkea1.8.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2314Bind 9.17.7 host -C error2020-12-03T14:41:59ZPeter DaviesBind 9.17.7 host -C error
### Summary
`host -C` either returns "host: isc_nm_udpconnect: network unreachable" or core dumps on Ubuntu 19.10 and Fedora 25.
This does not appear to affect CentOS Linux 8.
### BIND version used
host 9.17.7 - compiled with '--e...
### Summary
`host -C` either returns "host: isc_nm_udpconnect: network unreachable" or core dumps on Ubuntu 19.10 and Fedora 25.
This does not appear to affect CentOS Linux 8.
### BIND version used
host 9.17.7 - compiled with '--enable-fixed-rrset' '--enable-dnstap' '--enable-querytrace'
### Steps to reproduce
Host -C <some-domain>
### What is the current *bug* behavior?
Ubuntu 19.10
peter@haparanda:~/git/kea$ host -C google.com
host: isc_nm_udpconnect: network unreachable
peter@haparanda:~/git/kea$ host -C google.com
Segmentation fault (core dumped)
Fedora 25
[root@mombassa log]# host -C google.com
host: isc_nm_udpconnect: network unreachable
[root@mombassa log]# host -C google.com
host: isc_nm_udpconnect: network unreachable
[root@mombassa log]# host -C google.com
Segmentation fault (core dumped)
### What is the expected *correct* behavior?
It should return a soa record for each name server in the domain:
(07:39:42 <~/Cisco/Cisco_17336>) 0 $ host -C google.com
Nameserver 2001:4860:4802:34::a:
google.com has SOA record ns1.google.com. dns-admin.google.com. 344392775 900 900 1800 60
Nameserver 216.239.34.10:
google.com has SOA record ns1.google.com. dns-admin.google.com. 344392775 900 900 1800 60
Nameserver 2001:4860:4802:36::a:
google.com has SOA record ns1.google.com. dns-admin.google.com. 344392775 900 900 1800 60
Nameserver 216.239.36.10:
google.com has SOA record ns1.google.com. dns-admin.google.com. 344392775 900 900 1800 60
Nameserver 2001:4860:4802:38::a:
google.com has SOA record ns1.google.com. dns-admin.google.com. 344392775 900 900 1800 60
Nameserver 216.239.38.10:
google.com has SOA record ns1.google.com. dns-admin.google.com. 344392775 900 900 1800 60
Nameserver 2001:4860:4802:32::a:
google.com has SOA record ns1.google.com. dns-admin.google.com. 344392775 900 900 1800 60
Nameserver 216.239.32.10:
google.com has SOA record ns1.google.com. dns-admin.google.com. 344392775 900 900 1800 60December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2313Set reasonable values to SO_RCVBUF and SO_SNDBUF2021-06-21T07:28:40ZOndřej SurýSet reasonable values to SO_RCVBUF and SO_SNDBUFThe values of SO_RCVBUF and SO_SNDBUF needs to be set to a reasonable number, so we prevent processing client requests that would timeout anyway (e.g. smaller is better).The values of SO_RCVBUF and SO_SNDBUF needs to be set to a reasonable number, so we prevent processing client requests that would timeout anyway (e.g. smaller is better).June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Cathy AlmondCathy Almondhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2312Lint generated manual pages2021-03-03T10:57:44ZMichal NowakLint generated manual pagesFor man page generation we rely on Sphinx and DocBook (`v9_11`) and although we don't control the manual page output, we may lint them with `mandoc -T lint` and thus try harder in CI to produce legible content.
On `main` and `v9_16` onl...For man page generation we rely on Sphinx and DocBook (`v9_11`) and although we don't control the manual page output, we may lint them with `mandoc -T lint` and thus try harder in CI to produce legible content.
On `main` and `v9_16` only three *types* of warnings and no errors are produced:
```
$ find doc/man/ -not -path '*/_build/*' -name "*.[0-9]" -exec mandoc -Tlint "{}" \;
WARNING: skipping paragraph macro: sp after SH
WARNING: unknown font, skipping request: ft C
WARNING: skipping paragraph macro: sp after SS
```
There are more types of warnings and one type of error on `v9_11`.
We could filter out these and rely on `mandoc -T lint` as a sanity check of generated man pages.
The case of https://gitlab.isc.org/isc-projects/bind9/-/issues/2310 seems to be covered (though probably only by a chance):
```
$ find /tmp/mozilla_newman0/bind-9.11.24 -name '*.[0-9]' -not -path '*/tests/*' -not -path '*/contrib/*' -exec mandoc -Tlint -Werror {} \;
$ find /tmp/mozilla_newman0/bind-9.11.25 -name '*.[0-9]' -not -path '*/tests/*' -not -path '*/contrib/*' -exec mandoc -Tlint -Werror {} \;
mandoc: /tmp/mozilla_newman0/bind-9.11.25/bin/named/named.8:189:2: ERROR: skipping unknown macro: .\}
mandoc: /tmp/mozilla_newman0/bind-9.11.25/bin/named/lwresd.8:194:2: ERROR: skipping unknown macro: .\}
```
The risk here is inherent from the fact that we don't control the generated output and `mandoc` may fail CI job, even-thought the content is legible by `man(1)` program "standards".March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/kea/-/issues/1578in HA hot-standby auto failover logs with off by 1 error2021-01-08T21:01:02ZWlodzimierz Wencelin HA hot-standby auto failover logs with off by 1 errorSmall error in HA hot-standby (load-balancing may be affected too but not tested). When server is configured with `"max-unacked-clients": 4,` standby server actually needs 5 clients with higher elapsed time/sec field to switch to `partne...Small error in HA hot-standby (load-balancing may be affected too but not tested). When server is configured with `"max-unacked-clients": 4,` standby server actually needs 5 clients with higher elapsed time/sec field to switch to `partner-down`kea1.9.4Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1577HA load balancing sometimes drop pkgs2020-11-26T17:01:53ZWlodzimierz WencelHA load balancing sometimes drop pkgsaffected: HA load-balancing in ST, MT mode, v4 and v6, with memfile, mysql, pgsql
configuration attached
[kea-dhcp6.conf1](/uploads/60c494b6270f7e1ffd52f3688776d617/kea-dhcp6.conf1)
[kea-dhcp6.conf](/uploads/c541b03ae04838db1faaed84d78...affected: HA load-balancing in ST, MT mode, v4 and v6, with memfile, mysql, pgsql
configuration attached
[kea-dhcp6.conf1](/uploads/60c494b6270f7e1ffd52f3688776d617/kea-dhcp6.conf1)
[kea-dhcp6.conf](/uploads/c541b03ae04838db1faaed84d789b41b/kea-dhcp6.conf)
logs:
[kea.log](/uploads/b57a83cc372c468a0f2d910651c032c1/kea.log)
[kea.log-CA](/uploads/8c97c1b65c2ba2cadb37a2c5912bb8aa/kea.log-CA)
[kea.log](/uploads/41b859db7e2c35236a9703f307940a38/kea.log)
[kea.log-CA](/uploads/4eb9f2c675a206e72614565e7b37c9d3/kea.log-CA)
What happens:
- client sends discover/solicit
- server gets discover/solicit and decide that this message is for him, and proceed with assigning lease
- server send offer/advertise
- client gets offer/advertise sends back request to the server
- server gets request and decide that this is not for him, drops request :(https://gitlab.isc.org/isc-projects/bind9/-/issues/2311Release Checklist for BIND 9.11.26, BIND 9.11.26-S1, BIND 9.16.10, BIND 9.16....2021-01-04T06:08:24ZMichał KępieńRelease Checklist for BIND 9.11.26, BIND 9.11.26-S1, BIND 9.16.10, BIND 9.16.10-S1, BIND 9.17.8## Release Schedule
**Code Freeze:** Wednesday, December 2nd, 2020
**Tagging Deadline:** Monday, December 7th, 2020
**Public Release:** Wednesday, December 16th, 2020
## Documentation Review Links
**Closed issues assigned to the mil...## Release Schedule
**Code Freeze:** Wednesday, December 2nd, 2020
**Tagging Deadline:** Monday, December 7th, 2020
**Public Release:** Wednesday, December 16th, 2020
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.17.8](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
- [9.16.10](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
- [9.11.26](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.11)
**Merge requests merged into the milestone without a release note:**
- [9.17.8](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)¬[label_name][]=Release%20Notes&target_branch=main)
- [9.16.10](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)¬[label_name][]=Release%20Notes&target_branch=v9_16)
- [9.11.26](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)¬[label_name][]=Release%20Notes&target_branch=v9_11)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.17.8](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)&label_name[]=No%20CHANGES&target_branch=main)
- [9.16.10](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)&label_name[]=No%20CHANGES&target_branch=v9_16)
- [9.11.26](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)&label_name[]=No%20CHANGES&target_branch=v9_11)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
### Before the Tagging Deadline
- [x] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Update API files for libraries with new version information.
- [x] ***(QA)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(QA)*** Update `CHANGES`.
- [x] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update `README.md`.
- [x] ***(QA)*** Update `version`.
- [x] ***(QA)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription Edition.
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public packages (`*.deb`, RPMs).
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Merge the automatically prepared `prep 9.x.y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_x`).
- [x] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- [x] ***(QA)*** Sanitize all confidential issues assigned to the release milestone and make them public.
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Michał KępieńMichał Kępień2020-12-16https://gitlab.isc.org/isc-projects/kea/-/issues/1576Forensic Logging: Option 82 values on renewals2021-05-07T15:39:09ZPeter DaviesForensic Logging: Option 82 values on renewalsForensic Logging: Option 82 values on renewals
Forensic logging correctly shows option 82 values on lease assignment
as: "... connected via relay at address: 10.0.0.1, identified by circuit-id: 01:02:03:04 and remote-id: 01:02:...Forensic Logging: Option 82 values on renewals
Forensic logging correctly shows option 82 values on lease assignment
as: "... connected via relay at address: 10.0.0.1, identified by circuit-id: 01:02:03:04 and remote-id: 01:02:03:04:05:06, ..."
However a number of dhcp client learn these values and include them in their renewal requests.
It would be of use to have these values presented if they were present as they would on an assignment.
An example of an assignment message:
2020-11-10 21:43:37 EET Address: 10.0.0.249 has been assigned for 1 hrs 0 mins 0 secs to a device with hardware address: hwtype=1 01:02:03:04:05:06, client-id: 01:02:03:04:05:06 connected via relay at address: 10.0.0.1, identified by circuit-id: 01:02:03:04:05:06 and remote-id: 01:02:03:04:05:06, context: { "ISC": { "relay-agent-info": "0x0102030405060708090A0B0C0D0E0F10111213141617191A1B1C1D1E1F202122232425262728292A2B" } }
An example of a renewal message: (with option 82 information)
2020-11-10 21:33:46 EET Address: 10.10.0.249 has been renewed for 1 hrs 0 mins 0 secs to a device with hardware address: hwtype=1 01:02:03:04:05:06, client-id: ff:24:6b:47:95:00:03:00:01:01:02:03:04:05:06, context: { "ISC": { "relay-agent-info": "0x0102030405060708090A0B0C0D0E0F10111213141617191A1B1C1D1E1F202122232425262728292A2B" } }
[RT #17277](https://support.isc.org/Ticket/Display.html?id=17277)kea1.9.8https://gitlab.isc.org/isc-projects/bind9/-/issues/2310BIND 9.11.25 has wrong formatted man pages2021-03-03T10:57:44ZPetr MenšíkBIND 9.11.25 has wrong formatted man pages### Summary
Manual pages from BIND 9.11.25 tarball are not well formatted
### BIND version used
BIND 9.11.25 source archive. No tag v9_11_25 is published on gitlab, could not compare exact commit.
man-db-2.9.0-3.fc32.x86_64
### Steps...### Summary
Manual pages from BIND 9.11.25 tarball are not well formatted
### BIND version used
BIND 9.11.25 source archive. No tag v9_11_25 is published on gitlab, could not compare exact commit.
man-db-2.9.0-3.fc32.x86_64
### Steps to reproduce
```
tar xzf bind-9.11.25.tar.gz
man bind-9.11.25/bin/named/named.8
```
### What is the current *bug* behavior?
```
NAMED(8) BIND9 NAMED(8)
.SH "NAME" named - Internet domain name server
.SH "SYNOPSIS"
.HP 144u
```
All generated manual pages have spaces before .SH, .PP etc. sections of man. At least man from Fedora cannot cope with it and display those sections when
### What is the expected *correct* behavior?
The same output as done on v9_11 branch
```
NAMED(8) BIND9 NAMED(8)
NAME
named - Internet domain name server
SYNOPSIS
named [[-4] | [-6]] [-c config-file] [-d debug-level] [-D string] [-E engine-name] [-f] [-g] [-L logfile] [-M option] [-m flag] [-n #cpus] [-p port]
[-s] [-S #max-socks] [-t directory] [-U #listeners] [-u user] [-v] [-V] [-X lock-file] [-x cache-file]
```
All manual pages seems to have the same issue, not just named.8.
### Relevant configuration files
none
### Relevant logs and/or screenshots
none
### Possible fixes
regenerate all pages with proper indentationDecember 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2309dig core dump on SIGINT2020-11-26T09:30:10ZPeter Daviesdig core dump on SIGINT
### Summary
dig core dumps when killed
### BIND version used
DiG 9.17.7
### Steps to reproduce
dig to a name server that does not reply in a timely fashion and kill the process with the Ctl/C.
```
root@haparanda:/home/named/log# d...
### Summary
dig core dumps when killed
### BIND version used
DiG 9.17.7
### Steps to reproduce
dig to a name server that does not reply in a timely fashion and kill the process with the Ctl/C.
```
root@haparanda:/home/named/log# dig @173.37.137.80 .
^Cdighost.c:4262: REQUIRE(isc_refcount_current(&recvcount) == 0) failed, back trace
/usr/local/lib/libisc.so.1706(+0x3d3e9) [0x7f67f2fca3e9]
/usr/local/lib/libisc.so.1706(isc_assertion_failed+0x10) [0x7f67f2fca320]
dig(+0x1728a) [0x56374da2028a]
dig(+0xc5fd) [0x56374da155fd]
dig(+0x6bb0) [0x56374da0fbb0]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f67f2afc1e3]
dig(+0x6bee) [0x56374da0fbee]
Aborted (core dumped)
```
### What is the current *bug* behavior?
Core dumps
### What is the expected *correct* behavior?
silent exit
### Relevant configuration files
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
(If you can, link to the line of code that might be responsible for the
problem.)December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2308RUNTIME_CHECK(tresult == 0) failed when reloading a catalog zone2021-10-28T10:31:03ZDan MahoneyRUNTIME_CHECK(tresult == 0) failed when reloading a catalog zone<!--
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
RUNTIME_CHECK(tresult == 0) failed when reloading a catalog zone
### BIND version used
```
BIND 9.14.8 (Stable Release) <id:5d87f66>
running on FreeBSD amd64 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC
built by make with '--localstatedir=/var' '--disable-linux-caps' '--with-libxml2=/usr/local' '--with-readline=-L/usr/local/lib -ledit' '--with-dlopen=yes' '--with-openssl=/usr' '--sysconfdir=/usr/local/etc/namedb' '--with-dlz-filesystem=yes' '--disable-dnstap' '--disable-fixed-rrset' '--without-geoip2' '--without-gssapi' '--with-libidn2=/usr/local' '--with-libjson=/usr/local' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python' '--disable-querytrace' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-tcp-fastopen' '--with-tuning=default' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.0' 'build_alias=amd64-portbld-freebsd12.0' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)
compiled with OpenSSL version: OpenSSL 1.1.1a-freebsd 20 Nov 2018
linked to OpenSSL version: OpenSSL 1.1.1a-freebsd 20 Nov 2018
compiled with libxml2 version: 2.9.9
linked to libxml2 version: 20909
compiled with libjson-c version: 0.13.1
linked to libjson-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /usr/local/etc/namedb/named.conf
rndc configuration: /usr/local/etc/namedb/rndc.conf
DNSSEC root key: /usr/local/etc/namedb/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Have been trying to reproduce, and cannot. Putting it here to note it.
This happened when I told named to retransfer my catalog zone, and then do an rndc reconfig. RNDC reported the connection had been closed, and I found in the logs:
### What is the current *bug* behavior?
Named crashes.
### What is the expected *correct* behavior?
Not a crash
### Relevant configuration files
```
options {
catalog-zones {
zone "catalog.example"
default-masters { red.ac.te.d; }
in-memory no
zone-directory "/usr/local/etc/namedb/catzones"
min-update-interval 10;
};
```
Pretty standard stuff.
### Relevant logs and/or screenshots
```
Nov 24 20:03:35 he 1 2020-11-24T20:03:35.194329+00:00 he.gushi.org named 12049 - - catz: catz_delzone_taskaction: zone 'redacted.com' deleted
Nov 24 20:04:02 he 1 2020-11-24T20:04:02.087641+00:00 he.gushi.org named 12049 - - /usr/local/etc/namedb/named.conf:13: catz: catalog zone 'catalog.example' will not be reconfigured
Nov 24 20:04:02 he 1 2020-11-24T20:04:02.088032+00:00 he.gushi.org named 12049 - - ./server.c:2961: fatal error:
Nov 24 20:04:02 he 1 2020-11-24T20:04:02.088049+00:00 he.gushi.org named 12049 - - RUNTIME_CHECK(tresult == 0) failed
Nov 24 20:04:02 he 1 2020-11-24T20:04:02.088059+00:00 he.gushi.org named 12049 - - exiting (due to fatal error in library)
Nov 24 20:04:02 he kernel: pid 12049 (named), uid 53: exited on signal 6
Nov 24 20:04:13 he 1 2020-11-24T20:04:13.666558+00:00 he.gushi.org named 200 - - starting BIND 9.14.8 (Stable Release) <id:5d87f66>
```
### Possible fixes
As above, server.c:2961November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2307"dig @localhost" does not fall back to 127.0.0.1 if ::1 is not answering2022-04-26T13:32:59ZMichał Kępień"dig @localhost" does not fall back to 127.0.0.1 if ::1 is not answeringThis started happening after !4115. It seems that each UDP query does
time out after 5 seconds, but `dig` never tries the "next server"
(127.0.0.1) after its "first pick" (::1) fails to respond.
The problem is easily reproducible with ...This started happening after !4115. It seems that each UDP query does
time out after 5 seconds, but `dig` never tries the "next server"
(127.0.0.1) after its "first pick" (::1) fails to respond.
The problem is easily reproducible with the following `named.conf`:
```
options {
listen-on port 5300 { 127.0.0.1; };
listen-on-v6 { none; };
};
```
Test with: `dig @localhost isc.org.` - it will time out even though it
should not. This is a change in behavior that was caught by [automated
RPM tests][1].
[1]: https://gitlab.isc.org/isc-private/rpms/bind/-/pipelines/57751April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/kea/-/issues/1574make shell tests and shell scripts more robust2021-01-28T10:33:49ZAndrei Pavelandrei@isc.orgmake shell tests and shell scripts more robustMainly I would like to add `set -eu` on all shell scripts so that they don't fail silently i.e. with a success error code e.g. like they did in [ut-basic#119](https://jenkins.isc.org/job/kea-dev/job/ut-basic/119/).
```
[2020-11-23T02:06...Mainly I would like to add `set -eu` on all shell scripts so that they don't fail silently i.e. with a success error code e.g. like they did in [ut-basic#119](https://jenkins.isc.org/job/kea-dev/job/ut-basic/119/).
```
[2020-11-23T02:06:45.668Z] Executing kea-shell (echo | /home/jenkins/workspace/kea-dev/ut-basic/src/bin/shell/kea-shell --host 127.0.0.1 --port 8081 --auth-user pet --auth-password meow list-commands > /home/jenkins/workspace/kea-dev/ut-basic/src/bin/shell/tests/shell-stdout.txt)
[2020-11-23T02:06:45.668Z] sh: fail: unknown operand
```
For the same test `shell_process_tests.sh`, on my computer, it runs in bash since it's missing a shebang so I get a different error:
```
Executing kea-shell (echo | /home/andrei/work/isc/kea/src/bin/shell/kea-shell --host 127.0.0.1 --port 8081 --auth-user pet --auth-password meow list-commands > /home/andrei/work/isc/kea/src/bin/shell/tests/shell-stdout.txt)
/home/andrei/work/isc/kea/src/bin/shell/tests/basic_auth_tests.sh: line 119: [: ==: unary operator expected
```
Regardless, the test passes even though there is an undefiend variable there.
Adding a `#!/bin/sh` shebang to all scripts is another action I would like to take.
And adding all scripts to Gitlab CI.
And so on...kea1.9.3Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2306Compilation broken on systems without <sys/un.h>2020-11-26T15:52:36ZMichal NowakCompilation broken on systems without <sys/un.h>Looking into https://gitlab.isc.org/isc-projects/bind9/-/issues/1770 I noticed that on systems without `<sys/un.h>` (`ISC_PLATFORM_HAVESYSUNH` undefined), the compilation fails with:
```
ssu_external.c: In function ‘ux_socket_connect’:
s...Looking into https://gitlab.isc.org/isc-projects/bind9/-/issues/1770 I noticed that on systems without `<sys/un.h>` (`ISC_PLATFORM_HAVESYSUNH` undefined), the compilation fails with:
```
ssu_external.c: In function ‘ux_socket_connect’:
ssu_external.c:59:31: warning: unused parameter ‘path’ [-Wunused-parameter]
59 | ux_socket_connect(const char *path) {
| ~~~~~~~~~~~~^~~~
getaddrinfo.c: In function ‘get_local’:
getaddrinfo.c:1243:32: error: invalid application of ‘sizeof’ to incomplete type ‘struct sockaddr_un’
1243 | ai = ai_alloc(AF_LOCAL, sizeof(*slocal));
| ^
getaddrinfo.c:1249:16: error: invalid use of undefined type ‘struct sockaddr_un’
1249 | strlcpy(slocal->sun_path, name, sizeof(slocal->sun_path));
| ^~
getaddrinfo.c:1249:47: error: invalid use of undefined type ‘struct sockaddr_un’
1249 | strlcpy(slocal->sun_path, name, sizeof(slocal->sun_path));
| ^~
```
I don't know what operating systems might be affected, probably none (even Solaris 10 has it), one can "emulate" it like this and rebuild with `autoreconf -fi`:
```patch
--- a/configure.ac
+++ b/configure.ac
@@ -1799,9 +1799,9 @@ AS_IF([test "$enable_linux_caps" = "yes"],
AC_SUBST([LIBCAP_LIBS])
AC_CHECK_HEADERS(sys/un.h,
-ISC_PLATFORM_HAVESYSUNH="#define ISC_PLATFORM_HAVESYSUNH 1"
-,
ISC_PLATFORM_HAVESYSUNH="#undef ISC_PLATFORM_HAVESYSUNH"
+,
+ISC_PLATFORM_HAVESYSUNH="#define ISC_PLATFORM_HAVESYSUNH 1"
)
AC_SUBST(ISC_PLATFORM_HAVESYSUNH)
```
I tried for a short while and followed the compiler in fixing warnings and disabling code with `#ifdef ISC_PLATFORM_HAVESYSUNH` but I end up with either failing `tsiggss` system test or crashing `named`.December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2305Did we set the max-recursion-queries limit too low in our CVE-2020-8616 fix?2020-12-16T20:50:12ZMichael McNallyDid we set the max-recursion-queries limit too low in our CVE-2020-8616 fix?A [Support customer](https://support.isc.org/Ticket/Display.html?id=17319) has reported to us that the first time they query google.de on a server with a cold cache they get a SERVFAIL. Subsequent queries succeed. They asked us about t...A [Support customer](https://support.isc.org/Ticket/Display.html?id=17319) has reported to us that the first time they query google.de on a server with a cold cache they get a SERVFAIL. Subsequent queries succeed. They asked us about this because the behavior differed from an earlier version of BIND which did not exhibit the issue.
After some troubleshooting, it turns out that, due to a combination of factors -- some specific to the domain but also some applying to the server, they are hitting the max-recursion-queries limit of 75 queries that was set as part of the remediation for [CVE-2020-8616](https://kb.isc.org/docs/cve-2020-8616) (intended to prevent an exploit, demonstrated as a proof-of-concept by the researchers who reported it, that could send a server chasing a huge number of queries when processing a referral.)
The situation reported by the customer seems to demonstrate that a server with a not-very-unusual configuration can hit the limit while processing a common, fairly high-profile zone. Should we then adjust the limit, make changes to the log message visibility when the limit is hit, and/or make other changes?December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/kea/-/issues/1572Backport #1542: `lease4-update` command has no effect and falsely reports suc...2020-11-28T09:06:57ZTomek MrugalskiBackport #1542: `lease4-update` command has no effect and falsely reports success on multithreaded v4We need to backport #1542 to 1.8 branch. Note there are patches available as attachments in #1542 or the fix can be cherry-picked from !1015.We need to backport #1542 to 1.8 branch. Note there are patches available as attachments in #1542 or the fix can be cherry-picked from !1015.kea1.8.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/stork/-/issues/460Record Kea configuration hash and detect no config change2020-12-04T12:53:59ZMarcin SiodelskiRecord Kea configuration hash and detect no config changeStork is periodically pulling configurations from Kea. To prevent repeating CPU intensive examination of the received config we should first compare the hashes of the existing and new config. That way we can easily detect whether the con...Stork is periodically pulling configurations from Kea. To prevent repeating CPU intensive examination of the received config we should first compare the hashes of the existing and new config. That way we can easily detect whether the configuration remains the same and skip the update altogether. When the config change has been detected, we can also emit an event.
This will to some degree address #353.0.14Marcin SiodelskiMarcin Siodelski