ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-04-06T12:27:32Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3658journal performance improvements - use asynchronous I/O2023-04-06T12:27:32ZPetr Špačekpspacek@isc.orgjournal performance improvements - use asynchronous I/OCurrently journal I/O is done synchronously, including fsync(). `fsync` is very slow (see #3556) and we probably cannot get rid of it completely, so I think we should use asynchronous I/O for journal processing. That would allow the serv...Currently journal I/O is done synchronously, including fsync(). `fsync` is very slow (see #3556) and we probably cannot get rid of it completely, so I think we should use asynchronous I/O for journal processing. That would allow the server to process normal queries while waiting for journal operations.
TODO: Test IXFR-in and querying the server in parallel.https://gitlab.isc.org/isc-projects/kea/-/issues/2628CI step missing-git-attribute doesn't detect if the .gitattribute file is mis...2023-01-26T18:25:44ZAndrei Pavelandrei@isc.orgCI step missing-git-attribute doesn't detect if the .gitattribute file is missing entirelyAt least it checks the contents correctly when the file exists.
But if the file is missing, it should be reported.
This [patch](https://gitlab.isc.org/isc-projects/kea/uploads/f8b68c012b2b1969593676e32dc51c7f/a.patch) was suggested as ...At least it checks the contents correctly when the file exists.
But if the file is missing, it should be reported.
This [patch](https://gitlab.isc.org/isc-projects/kea/uploads/f8b68c012b2b1969593676e32dc51c7f/a.patch) was suggested as a fix in another issue.outstandinghttps://gitlab.isc.org/isc-projects/stork/-/issues/895Fix golangci-lint dependency installation on alpine2022-12-06T14:47:22ZDan TheisenFix golangci-lint dependency installation on alpineWhile running `rake prepare:dev` on Alpine Linux, I discovered that the current rake script appears to be fetching a prebuilt golangci-lint tarball. This should be fixed by instead using `go install`While running `rake prepare:dev` on Alpine Linux, I discovered that the current rake script appears to be fetching a prebuilt golangci-lint tarball. This should be fixed by instead using `go install`outstandingDan TheisenDan Theisenhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/271Consider including bind unpacked sources2022-11-04T15:53:04ZSantiagoConsider including bind unpacked sourcesFor packaging purposes, I think it would be easier to have the included bind source unpacked, instead of a tar.
It would make it easier to e.g. update generated configuration files with `autoreconf` (c.f. #256)For packaging purposes, I think it would be easier to have the included bind source unpacked, instead of a tar.
It would make it easier to e.g. update generated configuration files with `autoreconf` (c.f. #256)https://gitlab.isc.org/isc-projects/bind9/-/issues/3653update-policy logic logging/debugging2022-11-04T07:04:22ZJorisupdate-policy logic logging/debugging### Description
Currently debugging update-policy rules is opaque, only the decision is available.
It would be beneficial if it was possible to trace the individual steps taken, eg which rule was expanded to what (wildcard expansion, k...### Description
Currently debugging update-policy rules is opaque, only the decision is available.
It would be beneficial if it was possible to trace the individual steps taken, eg which rule was expanded to what (wildcard expansion, key names vs fqdn names) to which result.
### Request
Logging at the right trace level could be something like below. Note I'm by far not an expert in the update policies, my example might way off.
```update-policy
grant wrong-key-name name example.com ANY;
=> identity key wrong-key-name not found, aborted
grant key-name name example.com NS;
=> update request does not match name example.com, aborted
grant key-name name example.com MX;
=> update request does not match type, aborted
grant updater-key.example.com name example.com ANY;
=> identity host updater-key.example.com not found, aborted [ a keyname that looks like a fqdn? ]
=> request denied```
Similarly key/kerberos failures could be logged too.
### Links / references
In #235 a similar request is made, this elaborates the scope and suggested solution.https://gitlab.isc.org/isc-projects/kea/-/issues/2627Dynamic DNS in options are not in example DHCPv4 configuration file2023-07-31T13:34:54ZMichael CasadevallDynamic DNS in options are not in example DHCPv4 configuration file**Describe the bug**
Options relating to DDNS in DHCPv4 are not present in the included examples. To get DDNS working with Kea, I had to manually look up and add options like this
```
"dhcp-ddns": {
"enable-updates": true,
...**Describe the bug**
Options relating to DDNS in DHCPv4 are not present in the included examples. To get DDNS working with Kea, I had to manually look up and add options like this
```
"dhcp-ddns": {
"enable-updates": true,
},
"ddns-qualifying-suffix": "ddns.restless.systems",
```
DDNS is methoded in other places, but none of the actual config stanzas appear to be in the file, nor is there a conscience guide showing which flags need to be set, as well as having clients. Furthermore, default behavior is not well documented. For instance, without ddns-qualifying-suffix, my client sent a hostname of "kali", and Kea DHCP attempted to do a UPDATE with that hostname as is.
That could easily leave to unexpected behavior, and security concerns and should be clearly documented.
**Expected behavior**
- Clearer documentation on what must be set in DHCP4 (and 6) for DDNS
- Better documentation on default behaviors
**Environment:**
- Kea version: which release? if it's compiled from git, which revision. Use kea-dhcp4 -V to find out.
- OS: [e.g. Ubuntu 16.04 x64]
- Which features were compiled in (in particular which backends)
- If/which hooks where loaded in
**Environment:**
- Kea version: 2.2.0, compiled from tarball on site
- Ubuntu 22.04.1
**Additional Information**
This was done as part of a livestream learning how to use Kea, documenting this behavior.
**Contacting you**
GitLab is fine, can provide more ways if needed.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2626Dynamic DNS updates are not retried in case of SERVFAIL2022-12-01T15:01:27ZMichael CasadevallDynamic DNS updates are not retried in case of SERVFAIL**Describe the bug**
When testing Dynamic DNS setups, Kea DHCP doesn't retry SERVFAIL or other failure modes relating to UPDATE after a lease is created even if a new DHCPREQUEST/ACK handshack is forced on the client. Only be deleting th...**Describe the bug**
When testing Dynamic DNS setups, Kea DHCP doesn't retry SERVFAIL or other failure modes relating to UPDATE after a lease is created even if a new DHCPREQUEST/ACK handshack is forced on the client. Only be deleting the lease database and then rerunning a client got the update filed.
**To Reproduce**
Steps to reproduce the behavior:
1. Configure Kea to use DDNS updates via TSIG to BIND
2. Cause a SERVFAIL or other update failure condition (i.e., wrong key)
3. Attach client that is NOT in the lease table to get a lease
4. Confirm that Kea tried and failed to do DDNS
5. Fix the SERVFAIL condition
6. Renew the lease on the client, DDNS is not updated.
**Expected behavior**
DDNS is retried on updates with client renewal should the SERVFAIL
**Environment:**
- Kea version: 2.2.0, compiled from tarball on site
- Ubuntu 22.04.1
**Additional Information**
This was done as part of a livestream learning how to use Kea documenting the failure in real time.Llinks and timestamps available on request.
**Contacting you**
GitLab is fine, can provide more ways if needed.outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3649Feature request: configurable TCP timeouts on zone refresh queries2023-06-15T13:22:31ZCathy AlmondFeature request: configurable TCP timeouts on zone refresh queriesThere is nothing that can be configured to reduce the timeout when failing to reach an authoritative server with a refresh query over TCP (BIND default is "try-tcp-refresh yes;")
Customer input is :
```
Basically, if my slave is trying ...There is nothing that can be configured to reduce the timeout when failing to reach an authoritative server with a refresh query over TCP (BIND default is "try-tcp-refresh yes;")
Customer input is :
```
Basically, if my slave is trying to reach out to a third-party master and doesn't get a response in 10-15 seconds, I want it to move on to the next listed master in hopes of better results versus waiting for 2 minutes
```
A 'sort of' workaround for this is to allow the UDP timeout to happen ("try-tcp-refresh no;") but that takes away the possibility of being able to reach servers and to pull a zone transfer in the situation where UDP doesn't work, but TCP does.
We have configurable TCP timeouts for other BIND functions, but not for this.
See [Support ticket #21044](https://support.isc.org/Ticket/Display.html?id=21044)https://gitlab.isc.org/isc-projects/bind9/-/issues/3635Implement support for DNS over QUIC2023-02-15T19:00:14ZJeremy SakladImplement support for DNS over QUIC### Description
DNS-over-QUIC, specified in [RFC 9250][RFC 9250], has considerable advantages over the already-implemented options.
* With the debatable exception of DoH and HTTP/3, it is the only standardized encrypted DNS protocol to...### Description
DNS-over-QUIC, specified in [RFC 9250][RFC 9250], has considerable advantages over the already-implemented options.
* With the debatable exception of DoH and HTTP/3, it is the only standardized encrypted DNS protocol to operate over UDP.
* It avoids issues such as head-of-line blocking and potential for amplification attacks.
* It avoids the overhead of DNS-over-HTTPS.
### Request
DNS-over-QUIC should be offered wherever DNS-over-HTTPS or DNS-over-TLS is, at minimum. Its use should be encouraged over the others where applicable.
[RFC 9250][RFC 9250] emphasizes the following scopes of usage:
> * the "stub to recursive resolver" scenario (also called the "stub to recursive" scenario in this document)
> * the "recursive resolver to authoritative nameserver" scenario (also called the "recursive to authoritative" scenario in this document), and
> * the "nameserver to nameserver" scenario (mainly used for zone transfers (XFR) [RFC1995][RFC 1995] [RFC5936][RFC 5936]).
I believe that covers every function of BIND.
---
While not specific to DNS-over-QUIC, the implementation should be designed with future support for non-standard ports and SVBC records in mind. 53/udp is explicitly banned for use with this protocol, but it should eventually be possible to use any other non-standard port rather than 853/udp.
[RFC 1995]: https://www.rfc-editor.org/info/rfc1995
[RFC 5936]: https://www.rfc-editor.org/info/rfc5936
[RFC 9250]: https://www.rfc-editor.org/info/rfc9250Not plannedhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/270dhcrelay error2022-11-01T15:50:00ZmyNameBorisdhcrelay errorIf there are more than 3000 interfaces, then I get an error:
```
Unable to register fd with library out of range
Can't register I/O handle for vlan3051.101: out of range
```If there are more than 3000 interfaces, then I get an error:
```
Unable to register fd with library out of range
Can't register I/O handle for vlan3051.101: out of range
```https://gitlab.isc.org/isc-projects/kea/-/issues/2623Add commands to [B]LQ hook2023-05-19T16:20:15ZFrancis DupontAdd commands to [B]LQ hookAdd commands to manipulate BLQ tables from the [B]LQ hook.Add commands to manipulate BLQ tables from the [B]LQ hook.outstandingFrancis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3629Slow retries after timeouts2022-11-16T16:07:31Zgrzchr15Slow retries after timeoutsMeasurements from Neustar/UltraDNS for some DNS servers including BIND9,They think there is weird behavior:
https://ripe85.ripe.net/wp-content/uploads/presentations/96-dknight-fewnsmanyips-ripe85-dnswg.pdf
Page 8
Video: https://ripe85....Measurements from Neustar/UltraDNS for some DNS servers including BIND9,They think there is weird behavior:
https://ripe85.ripe.net/wp-content/uploads/presentations/96-dknight-fewnsmanyips-ripe85-dnswg.pdf
Page 8
Video: https://ripe85.ripe.net/archive/video/dave-knight_fewer-name-servers-more-addresses_main-20221027-112204.mp4 time 7:17 onwards
Measurements from Neustar/UltraDNS for some DNS servers including BIND9
- Bind Strongly prefers IPv6 - they think there is weird behavior.
- If one address is broken, penalize all higher numbered addresses until piling onto the last one?
- Slow to get an answer when retryingŠtěpán BalážikŠtěpán Balážikhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/269run option_unittest:parse_X failed and report core dump2023-07-01T07:07:02ZMingshuai Renrenmingshuai@huawei.comrun option_unittest:parse_X failed and report core dump---
name: Bug report
about: option_unittest:parse_X failed
---
**To Reproduce**
Steps to reproduce the behavior:
1. git clone https://gitlab.isc.org/isc-projects/dhcp.git
2. cd dhcp
3. ./configure --build=aarch64-openEuler-linux-gnu -...---
name: Bug report
about: option_unittest:parse_X failed
---
**To Reproduce**
Steps to reproduce the behavior:
1. git clone https://gitlab.isc.org/isc-projects/dhcp.git
2. cd dhcp
3. ./configure --build=aarch64-openEuler-linux-gnu --host=aarch64-openEuler-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-srv-lease-file=/var/lib/dhcpd/dhcpd.leases --with-srv6-lease-file=/var/lib/dhcpd/dhcpd6.leases --with-cli-lease-file=/var/lib/dhclient/dhclient.leases --with-cli6-lease-file=/var/lib/dhclient/dhclient6.leases --with-srv-pid-file=/var/run/dhcpd.pid --with-srv6-pid-file=/var/run/dhcpd6.pid --with-cli-pid-file=/var/run/dhclient.pid --with-cli6-pid-file=/var/run/dhclient6.pid --with-relay-pid-file=/var/run/dhcrelay.pid --with-ldap --with-ldapcrypto --with-ldap-gssapi --disable-static --enable-log-pid --enable-paranoia --enable-early-chroot --enable-binary-leases --with-systemd --with-atf
4. make
5. make check
6. option_unittest:parse_X failed and the log is show as follow
![image](/uploads/10d1193d5f9326409ea37ac1fde4b83e/image.png)
**Expected behavior**
all test passed
**Environment:**
- ISC DHCP version: dhcp-4.4.3
- OS: [openEuler-22.03-LTS]https://gitlab.isc.org/isc-projects/stork/-/issues/891Feature request: stork-server.pid file in /var/run2022-11-22T14:31:31ZmikygeeFeature request: stork-server.pid file in /var/runHello,
I'm wondering how I'll be able to stop or restart the stork server.
Usually, when you start a service, to software creates a /var/run/stork-server.pid file that it containing the PID.
When I want to kill the service i just need...Hello,
I'm wondering how I'll be able to stop or restart the stork server.
Usually, when you start a service, to software creates a /var/run/stork-server.pid file that it containing the PID.
When I want to kill the service i just need to kill -15 \`cat /var/run/stork-server.pid\`
Do the stork client and server do that (can create a file containing their PID ?)
Regardsbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2622`run_script` hook should contain all DHCP options2022-12-01T14:53:51Zvps-eric`run_script` hook should contain all DHCP optionsI propose that the `run_script` hook be expanded to include all (or more) options of the DHCPv4 packet. As it stands, [only option 82 is returned](https://gitlab.isc.org/isc-projects/kea/-/blob/master/src/hooks/dhcp/run_script/run_script...I propose that the `run_script` hook be expanded to include all (or more) options of the DHCPv4 packet. As it stands, [only option 82 is returned](https://gitlab.isc.org/isc-projects/kea/-/blob/master/src/hooks/dhcp/run_script/run_script.cc#L373-383):
```
RunScriptImpl::extractOption(vars,
pkt4->getOption(DHO_DHCP_AGENT_OPTIONS),
prefix, suffix);
RunScriptImpl::extractSubOption(vars,
pkt4->getOption(DHO_DHCP_AGENT_OPTIONS),
RAI_OPTION_AGENT_CIRCUIT_ID,
prefix, suffix);
RunScriptImpl::extractSubOption(vars,
pkt4->getOption(DHO_DHCP_AGENT_OPTIONS),
RAI_OPTION_REMOTE_ID,
prefix, suffix);
```
Not having looked in-depth, this seems like a place to add a loop over all the option constants, and additionally over each suboption (if applicable). This might be completely unrealistic, however.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/890Bug: Could not build:ui on Openbsd2022-10-28T09:52:30ZmikygeeBug: Could not build:ui on OpenbsdHello,
I'm not able to build the ui on openbsd
```
# rake31 build:ui --trace
** Invoke webui/tsconfig.spec.json (first_time, not_needed)
** Invoke /usr/local/bin/npx (first_time, not_needed)
** Invoke /usr/local/bin/npm (not_needed)
** ...Hello,
I'm not able to build the ui on openbsd
```
# rake31 build:ui --trace
** Invoke webui/tsconfig.spec.json (first_time, not_needed)
** Invoke /usr/local/bin/npx (first_time, not_needed)
** Invoke /usr/local/bin/npm (not_needed)
** Execute webui/dist/stork
/usr/local/bin/npx ng build --configuration production
npm ERR! could not determine executable to run
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2022-10-26T14_40_41_809Z-debug-0.log
rake aborted!
Command failed with status (1): [/usr/local/bin/npx ng build --configuratio...]
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/file_utils.rb:67:in `block in create_shell_runner'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/file_utils.rb:57:in `sh'
/usr/local/stork/rakelib/20_build.rake:55:in `block (2 levels) in <top (required)>'
/usr/local/stork/rakelib/20_build.rake:54:in `chdir'
/usr/local/stork/rakelib/20_build.rake:54:in `block in <top (required)>'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/task.rb:281:in `block in execute'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/task.rb:281:in `each'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/task.rb:281:in `execute'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/task.rb:219:in `block in invoke_with_call_chain'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/task.rb:199:in `synchronize'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/task.rb:199:in `invoke_with_call_chain'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/task.rb:243:in `block in invoke_prerequisites'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/task.rb:241:in `each'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/task.rb:241:in `invoke_prerequisites'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/task.rb:218:in `block in invoke_with_call_chain'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/task.rb:199:in `synchronize'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/task.rb:199:in `invoke_with_call_chain'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/task.rb:188:in `invoke'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/application.rb:160:in `invoke_task'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/application.rb:116:in `block (2 levels) in top_level'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/application.rb:116:in `each'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/application.rb:116:in `block in top_level'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/application.rb:125:in `run_with_threads'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/application.rb:110:in `top_level'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/application.rb:83:in `block in run'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/application.rb:186:in `standard_exception_handling'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/lib/rake/application.rb:80:in `run'
/usr/local/lib/ruby/gems/3.1/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/bin/rake31:25:in `load'
/usr/local/bin/rake31:25:in `<main>'
Tasks: TOP => build:ui => webui/dist/stork
```https://gitlab.isc.org/isc-projects/stork/-/issues/889Feature Request: Possibility to connect to the postgresql database using Unix...2023-10-17T12:34:25ZmikygeeFeature Request: Possibility to connect to the postgresql database using Unix socketsHello,
According to the documentation and to this discussion #887, it's not possible that the stork server uses unix sockets to connect to the database.
It's sometimes a good choice to rely on unix sockets instead of tcp/ip (should be f...Hello,
According to the documentation and to this discussion #887, it's not possible that the stork server uses unix sockets to connect to the database.
It's sometimes a good choice to rely on unix sockets instead of tcp/ip (should be faster and more secure)
It would be nice to have this implementation within the stork server.
Regardsbackloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3626[question] RFC 6763 Support2022-11-25T17:02:11Zcaglarkarahan[question] RFC 6763 Support### Summary
I am currently interested in DNS-based Service Discovery (RFC 6763). There is some of possible configuration for dns-sd like b._dns-sd._udp or lb._dns-sd._udp in version of bind9. But I cannot see any information about DNS-S...### Summary
I am currently interested in DNS-based Service Discovery (RFC 6763). There is some of possible configuration for dns-sd like b._dns-sd._udp or lb._dns-sd._udp in version of bind9. But I cannot see any information about DNS-SD support (RFC 6763) in documentation from https://downloads.isc.org/isc/bind9/9.16.27/doc/arm/html/index.html. Does Bind9 has RFC 6763 Support?
### BIND version used
Bind9.16.27https://gitlab.isc.org/isc-projects/bind9/-/issues/3624Release Checklist for BIND 9.16.35, 9.16.35-S1, 9.18.9, 9.19.72022-11-21T11:47:56ZMichał KępieńRelease Checklist for BIND 9.16.35, 9.16.35-S1, 9.18.9, 9.19.7## Release Schedule
**Code Freeze:** Wednesday, November 2nd, 2022
**Tagging Deadline:** Monday, November 7th, 2022
**Public Release:** Wednesday, November 16th, 2022
## Documentation Review Links
**Closed issues assigned to the mil...## Release Schedule
**Code Freeze:** Wednesday, November 2nd, 2022
**Tagging Deadline:** Monday, November 7th, 2022
**Public Release:** Wednesday, November 16th, 2022
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.19.7](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=created_asc&state=closed&milestone_title=November%202022%20%289.16.35,%209.16.35-S1,%209.18.9,%209.19.7%29¬%5Blabel_name%5D%5B%5D=Release%20Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.19)
- [9.18.9](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=created_asc&state=closed&milestone_title=November%202022%20%289.16.35,%209.16.35-S1,%209.18.9,%209.19.7%29¬%5Blabel_name%5D%5B%5D=Release%20Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18)
- [9.16.35](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=created_asc&state=closed&milestone_title=November%202022%20%289.16.35,%209.16.35-S1,%209.18.9,%209.19.7%29¬%5Blabel_name%5D%5B%5D=Release%20Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16)
**Merge requests merged into the milestone without a release note:**
- [9.19.7](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=November%202022%20%289.16.35,%209.16.35-S1,%209.18.9,%209.19.7%29¬[label_name][]=Release%20Notes&target_branch=main)
- [9.18.9](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=November%202022%20%289.16.35,%209.16.35-S1,%209.18.9,%209.19.7%29¬[label_name][]=Release%20Notes&target_branch=v9_18)
- [9.16.35](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=November%202022%20%289.16.35,%209.16.35-S1,%209.18.9,%209.19.7%29¬[label_name][]=Release%20Notes&target_branch=v9_16)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.19.7](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=November%202022%20%289.16.35,%209.16.35-S1,%209.18.9,%209.19.7%29&label_name[]=No%20CHANGES&target_branch=main)
- [9.18.9](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=November%202022%20%289.16.35,%209.16.35-S1,%209.18.9,%209.19.7%29&label_name[]=No%20CHANGES&target_branch=v9_18)
- [9.16.35](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=November%202022%20%289.16.35,%209.16.35-S1,%209.18.9,%209.19.7%29&label_name[]=No%20CHANGES&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.
- [x] ***(QA)*** Update GitLab settings for all maintained branches to disallow merging to them.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is in effect.
### Before the Tagging Deadline
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Add a release marker to `CHANGES`.
- [x] ***(QA)*** Add a release marker to `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update BIND 9 version in `configure.ac` (9.18+) or `version` (9.16).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org` (9.16).
- [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)*** Check that the formatting is correct for HTML and PDF versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Verify GitLab CI results for the tags created and sign off on the releases to be published.
- [x] ***(QA)*** Update GitLab settings for all maintained branches to allow merging to them again.
- [x] ***(QA)*** Prepare and merge MRs resetting the release notes and updating the version string for each maintained branch.
- [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] ***(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 published release tags (non-linearly) back into the their relevant development/maintenance branches.
- [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. Black, PyLint, Sphinx) 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.November 2022 (9.16.35, 9.16.35-S1, 9.18.9, 9.19.7)Michal NowakMichal Nowak2022-11-16https://gitlab.isc.org/isc-projects/kea/-/issues/2616Sanity checks for Kea 2.3.2 rc22022-11-28T13:59:30ZjenkinsSanity checks for Kea 2.3.2 rc2We are now at step SANITY CHECKS of Kea 2.3.2 rc2.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-co...We are now at step SANITY CHECKS of Kea 2.3.2 rc2.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks) and according to your imagination.
Before starting, please state what you are checking in a thread/discussion (not as comment).
When you finish a check, state in the same thread/discussion what the result is.
This way we know what is covered upfront and we can avoid repeating ourselves.
#### Tarballs on repo.isc.org
* `/data/shared/sweng/kea/releases/2.3.2-rc2`
* `/data/shared/sweng/kea/releases/premium-2.3.2-rc2`
* `/data/shared/sweng/kea/releases/subscription-2.3.2-rc2`
* `/data/shared/sweng/kea/releases/enterprise-2.3.2-rc2`
```
SHA256 (kea-2.3.2.tar.gz) = a7ce6beb06cea0f92495043f96d5313167d2153775277bc39da67918391610a0
SHA256 (kea-enterprise-2.3.2.tar.gz) = 2cf38f817590284f71d6d971a1efc189399c4bb761b932420b1193987433eb30
SHA256 (kea-premium-2.3.2.tar.gz) = 4442915b9447fd4dd398edf056675b1712f7027e54276368700304170ae3d568
SHA256 (kea-subscription-2.3.2.tar.gz) = 9acd0960a60a4215d2ac7c33b3bd6ef07dc0d69b7702b777880dd8106f162da2
```
#### Packages on packages.aws.isc.org
* [APK: 2.3.2-r20221026061952](https://packages.aws.isc.org/#browse/search/raw=format%3Draw%20AND%20name.raw%3D*r20221026061952.apk)
* [deb: 2.3.2-isc20221026061952](https://packages.aws.isc.org/#browse/search/apt=format%3Dapt%20AND%20version%3D2.3.2-isc20221026061952)
* [RPM: 2.3.2-isc20221026061952.\[os\]](https://packages.aws.isc.org/#browse/search/yum=format%3Dyum%20AND%20version%3D2.3.2-isc20221026061952*)
You can find the name for all the packages attached as build artifacts in the pkg job: https://jenkins.aws.isc.org/job/kea-dev/job/pkg/962/
Instructions for installing packages are at point 9 of [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks).Wlodzimierz WencelWlodzimierz Wencel