ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-03-01T12:08:01Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2539systemd unit file's PIDFile path not found for COPR package2021-03-01T12:08:01ZKenneth Portersystemd unit file's PIDFile path not found for COPR packageThe systemd unit file in the Red Hat COPR package has a PIDFile setting not found in the sample named.conf and apparently not compiled in. systemctl fails with a timeout waiting for the PIDFile to be created. It hangs for many seconds be...The systemd unit file in the Red Hat COPR package has a PIDFile setting not found in the sample named.conf and apparently not compiled in. systemctl fails with a timeout waiting for the PIDFile to be created. It hangs for many seconds before failing.
The value provided is:
PIDFile=/var/opt/isc/scls/isc-bind/run/named/named.pid
A better choice might be:
PIDFile=/run/named/named.pid
The example named.conf should include this setting.
BIND 9.16.12 (Stable Release) <id:aeb943d>
OS is CentOS 8.
Package from here:
https://copr.fedorainfracloud.org/coprs/isc/bind/
I edited the unit file's PIDFile setting (using a systemd drop-in file) and the service came up normally, using my configuration from named 9.10.Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/kea/-/issues/1797create smart pointer for parking lot - RAII handling of parking/unparking/drop2023-08-20T18:48:51ZRazvan Becheriucreate smart pointer for parking lot - RAII handling of parking/unparking/dropAny parking lot needs to either be parked and unparked or dropped.
To achieve this we need a smart pointer (to reuse the reference count), but also the following functionality:
ready() - mark that the processing of the hook point was s...Any parking lot needs to either be parked and unparked or dropped.
To achieve this we need a smart pointer (to reuse the reference count), but also the following functionality:
ready() - mark that the processing of the hook point was successful (only if the drop flag has not been set)
the destructor should check if the ready flag has been set
the constructor should set an internal dirty flag which can only be cleared by calling ready()
this is similar to the MySql/PgSql transactions.
each destructor should check if the dirty flag has been cleared. if the flag has not been cleared for the current instance, set the drop flag.
if any of the instances has not been able to clear the dirty flag resulting in the drop flag to be set, will result in dropping the packet.
```
ParkingLot {
...
bool drop_; // initialized to false on constructor
};
ParkingLotPtr : public boost::shared_ptr<ParkingLot> {
private:
ParkingLotPtr(const ParkingLotPtr&);
const ParkingLotPtr operator=(const ParkingLotPtr&);
bool dirty_;
ParkingLotPtr() : dirty_(true) {
}
~ParkingLotPtr() {
if (dirty_) {
get()->drop_ = true;
}
if (get()->drop_ && use_count() == 1) {
// drop packet
} else if (use_count() == 1) {
// ready to unpark
}
}
void ready() {
if (!get->drop_) {
dirty_ = false;
}
}
}
```
hook point:
```
{
...
ParkingLotPtr& parking_lot = callout_handle.getParkingLotPtr();
...
parking_lot->ready();
}
```
This way we can guarantee that the handling of the parking lot is always handled, and all exceptions in any hook point will drop the packet. The only thing that needs to be done by every hook point is to mark the ready flag before exiting.
This is similar to reference/dereference, but the reference count is handled by the base smart pointer.
Each hook library that creates/accesses the parking log must call getParkingLotPtr() which will generate a new ParkingLotPtr that needs to call ready before exiting scope (should be the last operation in the hook point).
We might need to protect the dirty and drop flags to be MT ready.outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2540[CVE-2021-25215] An assertion check can fail while answering queries for DNAM...2021-06-02T13:13:25ZMark Andrews[CVE-2021-25215] An assertion check can fail while answering queries for DNAME records that require the DNAME to be processed to resolve itself### CVE-specific actions
- [x] Assign a CVE identifier
- [x] [Determine CVSS score](#note_201422)
- [x] [Determine the range of BIND versions affected (including the Subscription Edition)](#note_201424)
- [x] [Determine whether ...### CVE-specific actions
- [x] Assign a CVE identifier
- [x] [Determine CVSS score](#note_201422)
- [x] [Determine the range of BIND versions affected (including the Subscription Edition)](#note_201424)
- [x] [Determine whether workarounds for the problem exists](#note_201428)
- [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)](isc-private/bind9!253)
- [explanation of code flow which triggers the problem (a system test is *not* good enough)](#note_201453)
- [x] [Prepare a private merge request containing the following items in separate commits:](isc-private/bind9!253)
- a test for the issue (may be moved to a separate merge request for deferred merging)
- a fix for the issue
- documentation updates (`CHANGES`, release notes, anything else applicable)
- [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
- [x] Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined
- [x] Ensure the merge requests containing CVE fixes are merged into `security-*` branches in CVE identifier order
---
e.g.
`test.example.com. DNAME com.`
with a query of test.example.test.example.com dname triggers the insist.
`test.example.test.example.com DNAME` adds `test.example.com. DNAME com.`
to the answer section as part of DNAME processing then proceeds to lookup
`test.example.com. DNAME` which attempts to add `test.example.com. DNAME com.`
a second time. Normally the `qctx->rdataset` would be cleared by
`query_addanswer()` but in this case it remains triggering this INSIST in query.c
```
/*
* We shouldn't ever fail to add 'rdataset'
* because it's already in the answer.
*/
INSIST(qctx->rdataset == NULL || QUERY_ANSWERED(&qctx->client->query));
```
https://wiki.isc.org/bin/view/Main/DNAMESelfResolutionApril 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/kea/-/issues/1798Remove TLS stream clear operation2021-05-14T18:10:29ZFrancis DupontRemove TLS stream clear operationThe idea is to improve the HTTPS client part: currently it relies on the SSL_clear function which both is deeply against the TLS spirit and works only for OpenSSL 1.1.
Related to #1706 and #1665The idea is to improve the HTTPS client part: currently it relies on the SSL_clear function which both is deeply against the TLS spirit and works only for OpenSSL 1.1.
Related to #1706 and #1665kea1.9.8Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2541move expired/removed zone keys to a different directory2021-03-01T09:45:27ZMichel Lespinassemove expired/removed zone keys to a different directory### Description
Currently the configured key-directory holds both current and expired zone keys. With a dnssec-policy rotating keys on a regular basis, expired keys accumulate over time, and as they are placed in the same key-directory ...### Description
Currently the configured key-directory holds both current and expired zone keys. With a dnssec-policy rotating keys on a regular basis, expired keys accumulate over time, and as they are placed in the same key-directory as current keys, it would be easy for an administrator trying to archive/remove expired keys to get it wrong and mistakenly remove keys that are still in use.
Maybe moving expired keys to a different location would help reduce the risk of such mistakes ?
### Request
- Allow specifying a different directory for expired keys to be automatically moved to.
- By default, keys in that archive directory should not show in rndc dnssec -status output.
### Links / referenceshttps://gitlab.isc.org/isc-projects/kea/-/issues/1799HAServiceTest.sendSuccessfulUpdates6MultiThreading randomly fails2023-02-27T13:40:26ZFrancis DupontHAServiceTest.sendSuccessfulUpdates6MultiThreading randomly failsCopied from the last occurrence but as far as I can remember it was the same the previous time:
```
[ RUN ] HAServiceTest.sendSuccessfulUpdates6MultiThreading
ha_service_unittest.cc:1447: Failure
Expected equality of these values:
...Copied from the last occurrence but as far as I can remember it was the same the previous time:
```
[ RUN ] HAServiceTest.sendSuccessfulUpdates6MultiThreading
ha_service_unittest.cc:1447: Failure
Expected equality of these values:
1
factory3_->getResponseCreator()->getReceivedRequests().size()
Which is: 0
ha_service_unittest.cc:1454: Failure
Value of: update_request3
Actual: false
Expected: true
[ FAILED ] HAServiceTest.sendSuccessfulUpdates6MultiThreading (2 ms)
```
System macOS Big Sur 11.2.3 Xcode 12.4 with master or close to master code - nothing special for the configuration.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1800possible race on lease_update_backlog_2021-04-15T15:31:05ZRazvan Becheriupossible race on lease_update_backlog_I am not sure if this can happen when calling HAService::communicationRecoveryHandler (main thread) which calls lease_update_backlog_.clear() and HAService::asyncSendLeaseUpdates (processing threads) which calls lease_update_backlog_.pus...I am not sure if this can happen when calling HAService::communicationRecoveryHandler (main thread) which calls lease_update_backlog_.clear() and HAService::asyncSendLeaseUpdates (processing threads) which calls lease_update_backlog_.push(...).
Main thread also calls HAService::asyncSendLeaseUpdatesFromBacklog which does lease_update_backlog_.pop() which can race with processing threads but can only end up postponing the exit from HAService::asyncSendLeaseUpdatesFromBacklog (maybe forever)?
The race might not be possible because of different transition states but it is not obvious from the code. A state diagram might be useful.
To note that operations on lease_update_backlog_ are thread safe.outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2543NID and L64 presentation format in DiG is not RFC compliant2021-03-16T14:01:33ZPieter LexisNID and L64 presentation format in DiG is not RFC compliant### Summary
The presentation format used in DiG for the L64 and NID record types is incorrect, it omits leading zeroes in each hex part.
### BIND version used
```
$ dig -v ...### Summary
The presentation format used in DiG for the L64 and NID record types is incorrect, it omits leading zeroes in each hex part.
### BIND version used
```
$ dig -v
DiG 9.16.12
```
```
$ named -V
BIND 9.16.12 (Stable Release) <id:aeb943d>
running on Linux x86_64 5.11.1-arch1-1 #1 SMP PREEMPT Tue, 23 Feb 2021 14:05:30 +0000
built by make with '--prefix=/usr' '--sysconfdir=/etc' '--sbindir=/usr/bin' '--localstatedir=/var' '--disable-static' '--enable-fixed-rrset' '--enable-full-report' '--enable-dnsrps' '--with-python=/usr/bin/python' '--with-maxminddb' '--with-openssl' '--with-libidn2' '--with-json-c' '--with-libxml2' '--with-lmdb' '--with-libtool' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DDIG_SIGCHASE -fcommon' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2'
compiled by GCC 10.2.0
compiled with OpenSSL version: OpenSSL 1.1.1i 8 Dec 2020
linked to OpenSSL version: OpenSSL 1.1.1j 16 Feb 2021
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.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
threads support is enabled
```
### Steps to reproduce
1. Create a zone with an L64 or NID record with hex digits that are not padded out, e.g.:
```
1.foo.example. 3600 IN L64 10 0000:0000:0000:0001
1.foo.example. 3600 IN NID 10 0000:0000:0000:0001
```
2. Use `dig` to query the nameserver
```
dig +norec @127.0.0.4 -p5300 1.foo.example NID +short
10 0:0:0:1
```
### What is the current *bug* behavior?
See above, the presentation value is set to `0:0:0:1`.
### What is the expected *correct* behavior?
The presentation format should be `0000:0000:0000:0001`.
[RFC 6742 section 2.1.2](https://tools.ietf.org/html/rfc6742#section-2.1.2) on NID records states:
```
- The NodeID field MUST be represented using the same syntax (i.e.,
groups of 4 hexadecimal digits, with each group separated by a
colon) that is already used for DNS AAAA records (and also used for
IPv6 interface IDs).
- The NodeID value MUST NOT be in the 'compressed' format (e.g.,
using "::") that is defined in RFC 4291, Section 2.2 (2). This
restriction exists to avoid confusion with 128-bit IPv6 addresses,
because the NID is a 64-bit field.
```
The examples in [section 2.1.3](https://tools.ietf.org/html/rfc6742#section-2.1.3) make it clear that leading zeroes are not to be omitted:
```
host1.example.com. IN NID 10 0014:4fff:ff20:ee64
host1.example.com. IN NID 20 0015:5fff:ff21:ee65
host2.example.com. IN NID 10 0016:6fff:ff22:ee66
As NodeID values use the same syntax as IPv6 interface identifiers,
when displayed for human readership, the NodeID values are presented
in the same hexadecimal format as IPv6 interface identifiers. This
is shown in the example above.
```
There is similar language in [section 2.3.2](https://tools.ietf.org/html/rfc6742#section-2.3.2) and [2.3.3](https://tools.ietf.org/html/rfc6742#section-2.3.3) on L64 records, where the examples also show that leading zeroes are expected in the presentation format.
### Relevant configuration files
None really, I tested with DiG against a PowerDNS auth with a zone that had the content shown in the reproduction steps.
### Relevant logs and/or screenshots
`drill` (`version 1.7.1 (ldns version 1.7.1)`) seems to include the leading zeroes:
```
drill @127.0.0.4 -p5300 1.foo.example NID
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 46417
;; flags: qr aa rd ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; 1.foo.example. IN NID
;; ANSWER SECTION:
1.foo.example. 3600 IN NID 10 0000:0000:0000:0001
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 0 msec
;; SERVER: 127.0.0.4
;; WHEN: Mon Mar 1 13:44:14 2021
;; MSG SIZE rcvd: 53
```
### Possible fixes
I don't know the BIND codebase, but probably the place where the conversion from internal to presentation format happens. :)https://gitlab.isc.org/isc-projects/kea/-/issues/1801Durable DDNS update queue (Persistence Manager for D2)2023-06-08T19:48:37ZVicky Riskvicky@isc.orgDurable DDNS update queue (Persistence Manager for D2)**Problem**
The DDNS update queue in the D2 process is not durable and queued requests may be lost if the process is stopped or crashes. The retry mechanism is non configurable, making two more attempts 100ms apart if the target DNS ser...**Problem**
The DDNS update queue in the D2 process is not durable and queued requests may be lost if the process is stopped or crashes. The retry mechanism is non configurable, making two more attempts 100ms apart if the target DNS server cannot be reached.
**Desired Solution**
- [ ] A durable queue persists pending updates between restarts and crashes.
- [ ] A new configuration parameter is used to set the number of seconds that the D2 process waits for a response before retrying the DNS update.
- [ ] An additional configuration parameter is used to limit the number of times that D2 process tries to send the DNS update.
This may be covered in the design of a Persistence Manager in [this wiki document](https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/ddns-design#addendum-persistencemgr-design-point8).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1802Allow multiple levels of nested sub-options in custom option space2022-09-14T08:26:49ZVicky Riskvicky@isc.orgAllow multiple levels of nested sub-options in custom option space**Problem**
A single level of sub options can be specified in custom option definition “spaces”, however multiple levels of nesting are not supported. For example, option 125.<4491>.123.1 + 2, or option 125.1.1, or CableLabs V6 options ...**Problem**
A single level of sub options can be specified in custom option definition “spaces”, however multiple levels of nesting are not supported. For example, option 125.<4491>.123.1 + 2, or option 125.1.1, or CableLabs V6 options 17.<4491>.2170 + 2171.
Sub option 2171 (CL_OPTION_CCCV6) is particularly difficult because it has its own 9 sub options that are normally under V4 Option 122.
**Desired Solution**
The custom option spaces allow the definition of multiple levels of nesting.outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2545Add standalone journal downgrade tool.2022-03-01T09:41:17ZMark AndrewsAdd standalone journal downgrade tool.This should be in python / perl. Without this users who upgrade to 9.16/9.17 will be unable to rollback if they find they need to.This should be in python / perl. Without this users who upgrade to 9.16/9.17 will be unable to rollback if they find they need to.Not plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/1803Inheritance for DHCPv6 options to work like DHCPv4 (shared network vs global HR)2021-05-13T15:09:49ZVicky Riskvicky@isc.orgInheritance for DHCPv6 options to work like DHCPv4 (shared network vs global HR)**Problem**
DHCP options for host reservations in a backend database can be specified by “shared-network-name” to override a global host reservation, however this does not appear to work for V6.
**Desired Solution**
V6 options for share...**Problem**
DHCP options for host reservations in a backend database can be specified by “shared-network-name” to override a global host reservation, however this does not appear to work for V6.
**Desired Solution**
V6 options for shared network name should override any definition that may be present in the global host reservation, as is currently the case for v4.
I tried to find related issues - possibly #39, #1253 might be relatedoutstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2546dnssec-validation to validate own authoritative zone2021-03-03T11:41:02Zadrianknorrdnssec-validation to validate own authoritative zone### Summary
I have an authoritative nameserver that serves a zone, let's say it is authoritative for example.com.
When I query example.com at any DNSSEC validating resolver, the ad flag is set.
But, when I query example.com at my author...### Summary
I have an authoritative nameserver that serves a zone, let's say it is authoritative for example.com.
When I query example.com at any DNSSEC validating resolver, the ad flag is set.
But, when I query example.com at my authoritative nameserver, the ad flag is not set.
Is this a bug or intended behavior?
### BIND version used
```
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on FreeBSD amd64 12.2-STABLE FreeBSD 12.2-STABLE r369178
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr' '--with-readline=-L/usr/local/lib -ledit' '--with-dlz-filesystem=yes' '--enable-dnstap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python' '--disable-querytrace' '--enable-tcp-fastopen' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.2' 'build_alias=amd64-portbld-freebsd12.2' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
compiled by CLANG FreeBSD Clang 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)
compiled with OpenSSL version: OpenSSL 1.1.1h-freebsd 22 Sep 2020
linked to OpenSSL version: OpenSSL 1.1.1i-freebsd 8 Dec 2020
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
compiled with protobuf-c version: 1.3.2
linked to protobuf-c version: 1.3.2
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
Set up authoritative nameserver with `dnssec-validation auto;` or `dnssec-validation yes;`.
Sign zone with OpenDNSSEC. Let bind read the signed zone file:
```
zone "example.com" {
type master;
file "signed/example.com";
};
```
### What is the current *bug* behavior?
Using `dig` and/or `drill` to query the local nameserver.
I also queried denic.de as a reference.
`dig @localhost denic.de`
Ad Flag is set.
`dig @localhost example.com`
Ad Flag **is not set**.
versus:
`dig @8.8.8.8 denic.de`
Ad Flag is set.
`dig @8.8.8.8 example.com`
Ad Flag **is set**.
### What is the expected *correct* behavior?
When executing `dig @localhost example.com`, the Ad Flag should be set.https://gitlab.isc.org/isc-projects/kea/-/issues/1804distcheck fails on CentOS 72021-04-20T08:10:05ZMichal Nowikowskidistcheck fails on CentOS 7```
../../../../src/lib/asiolink/io_asio_socket.h:31:39: fatal error: ext/coroutine/coroutine.hpp: No such file or directory
#include <ext/coroutine/coroutine.hpp>
```
more details in:
https://jenkins.aws.isc.org/view/Kea-manual/job/kea...```
../../../../src/lib/asiolink/io_asio_socket.h:31:39: fatal error: ext/coroutine/coroutine.hpp: No such file or directory
#include <ext/coroutine/coroutine.hpp>
```
more details in:
https://jenkins.aws.isc.org/view/Kea-manual/job/kea-manual/job/distcheck/4/execution/node/108/log/kea1.9.7Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1759Suggested update to the ARM (keactrl not in packages)2021-04-15T10:55:38ZPeter DaviesSuggested update to the ARM (keactrl not in packages)Suggested update to the ARM.
To add that keactrl is not bundled with rpm repositories as it is expected that the installer will be using systemd to control the kea services.Suggested update to the ARM.
To add that keactrl is not bundled with rpm repositories as it is expected that the installer will be using systemd to control the kea services.kea1.9.7Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2547Resolver benchmarking testing - corralling the generic plus the important edg...2022-06-03T10:15:14ZCathy AlmondResolver benchmarking testing - corralling the generic plus the important edge cases to include when testingOpening this issue to capture discussions on what we need to include in BIND resolver performance benchmark tests, beyond the generic case.Opening this issue to capture discussions on what we need to include in BIND resolver performance benchmark tests, beyond the generic case.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2548Resolver testing - building an Internet Simulator device2022-06-03T10:15:14ZCathy AlmondResolver testing - building an Internet Simulator deviceThis ticket is being opened to capture discussions on how to create a device to take the place of 'The Internet' for benchmarking resolver performance more realisticallyThis ticket is being opened to capture discussions on how to create a device to take the place of 'The Internet' for benchmarking resolver performance more realisticallyLong-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2549Create a BIND benchmarking package for users to download and use in their own...2022-06-03T10:15:14ZCathy AlmondCreate a BIND benchmarking package for users to download and use in their own environmentsThis feature issue ticket is to track discussions on a potential downloadable benchmark testing framework for users (performance testing is hard...)This feature issue ticket is to track discussions on a potential downloadable benchmark testing framework for users (performance testing is hard...)Long-termhttps://gitlab.isc.org/isc-projects/kea/-/issues/1807HttpConnectionPool::shutdown not thread safe2021-05-11T16:03:00ZRazvan BecheriuHttpConnectionPool::shutdown not thread safe```
void
HttpConnectionPool::shutdown(const HttpConnectionPtr& connection) {
connections_.remove(connection);
connection->shutdown();
}
```
the remove call must be in critical section (protected by instance mutex).```
void
HttpConnectionPool::shutdown(const HttpConnectionPtr& connection) {
connections_.remove(connection);
connection->shutdown();
}
```
the remove call must be in critical section (protected by instance mutex).kea1.9.7Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2550Remove dns_zone_setflag2021-05-18T23:57:02ZMark AndrewsRemove dns_zone_setflag`dns_zone_setflag` should never have existed.`dns_zone_setflag` should never have existed.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)