ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-07-12T20:08:35Zhttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/10remove PHP from the project2023-07-12T20:08:35ZDarren Ankneyremove PHP from the projectre-implement the validation of the steps (and associated helper functions) in javascript so that PHP will not be required for the project. As a side effect, a web server would no longer be required for the project to work.re-implement the validation of the steps (and associated helper functions) in javascript so that PHP will not be required for the project. As a side effect, a web server would no longer be required for the project to work.futurehttps://gitlab.isc.org/isc-projects/kea/-/issues/2976Implement the ISC DHCP stash-agent-options in Kea2024-03-28T14:24:33ZFrancis DupontImplement the ISC DHCP stash-agent-options in KeaSee #218 for details but the idea is to handle v4 renew/rebind queries as they went thought a relay. As far as I can remember the idea is to use the hint (requested or client address) from the query to look up the lease and extract the R...See #218 for details but the idea is to handle v4 renew/rebind queries as they went thought a relay. As far as I can remember the idea is to use the hint (requested or client address) from the query to look up the lease and extract the RAI from its user context. Requires some design but on the paper this should do the job...
Note this is for v4 only because v6 requires a specific setup on both the client and the server for direct unicast queries so the problem never occurs in the real world.kea2.5.8https://gitlab.isc.org/isc-projects/bind9/-/issues/4205OpenAPI Description Document for the JSON statistics channel2023-07-12T15:31:13ZMarkus KötterOpenAPI Description Document for the JSON statistics channel### Description
Using the JSON statistics channel is easier when parsing of the data is accomplished using a description document.
### Request
I prepared the following description document - it validates and works.
Possible improveme...### Description
Using the JSON statistics channel is easier when parsing of the data is accomplished using a description document.
### Request
I prepared the following description document - it validates and works.
Possible improvements include:
- not using additionalProperties: { type: integer } for the statistics,
- document the statistic values (https://gitlab.isc.org/isc-projects/bind9/-/issues/3878)
- require properties
Would be great if you could include this next to https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bin/named/bind9.xsl and have the webserver serve it as bind9.yaml similar to https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bin/named/statschannel.c#L3138 for ease of use.
### Links / references
As I'm unable to fork the repo and create a MR (project limit reached), it is embedded inline.
```yaml
openapi: "3.0.0"
info:
version: "0.1"
title: OpenAPI Description Document for Bind9 JSON statistics channel
servers:
- url: /
paths:
/json:
get:
operationId: summary
responses:
'200':
description: The Summary
content:
application/json:
schema:
$ref: "#/components/schemas/Summary"
/json/v1/status:
# /json/v1:
get:
operationId: status
responses:
'200':
description: The Status
content:
application/json:
schema:
$ref: "#/components/schemas/Status"
/json/v1/server:
get:
operationId: server
responses:
'200':
description: The Status
content:
application/json:
schema:
$ref: "#/components/schemas/Server"
/json/v1/zones:
get:
operationId: zones
responses:
'200':
description: The Zones
content:
application/json:
schema:
$ref: "#/components/schemas/Views"
/json/v1/net:
get:
operationId: net
responses:
'200':
description: The Sockstats
content:
application/json:
schema:
$ref: "#/components/schemas/Sockstats"
/json/v1/mem:
get:
operationId: mem
responses:
'200':
description: The Memory Statistics
content:
application/json:
schema:
$ref: "#/components/schemas/Memory"
/json/v1/traffic:
get:
operationId: traffic
responses:
'200':
description: The Traffic Statistics
content:
application/json:
schema:
$ref: "#/components/schemas/Traffic"
components:
schemas:
Status:
type: object
additionalProperties: False
properties:
json-stats-version:
type: string
boot-time:
type: string
format: date-time
config-time:
type: string
format: date-time
current-time:
type: string
format: date-time
version:
type: string
Server:
type: object
additionalProperties: False
allOf:
- $ref: "#/components/schemas/Status"
- $ref: "#/components/schemas/Views"
properties:
opcodes:
type: object
additionalProperties:
type: integer
rcodes:
type: object
additionalProperties:
type: integer
qtypes:
type: object
additionalProperties:
type: integer
nsstats:
type: object
additionalProperties:
type: integer
zonestats:
type: object
additionalProperties:
type: integer
Views:
type: object
additionalProperties: False
allOf:
- $ref: "#/components/schemas/Status"
properties:
views:
type: object
additionalProperties:
$ref: "#/components/schemas/View"
View:
type: object
additionalProperties: False
properties:
zones:
type: array
items:
$ref: "#/components/schemas/Zone"
resolver:
type: object
additionalProperties: False
properties:
stats:
type: object
additionalProperties:
type: integer
qtypes:
type: object
additionalProperties:
type: integer
cache:
type: object
additionalProperties:
type: integer
cachestats:
type: object
additionalProperties:
type: integer
adb:
type: object
additionalProperties:
type: integer
Zone:
type: object
additionalProperties: False
properties:
name:
type: string
class:
type: string
serial:
type: integer
type:
type: string
loaded:
type: string
Sockstats:
type: object
additionalProperties: False
allOf:
- $ref: "#/components/schemas/Status"
properties:
sockstats:
type: object
additionalProperties:
type: integer
Memory:
type: object
additionalProperties: False
allOf:
- $ref: "#/components/schemas/Status"
properties:
memory:
type: object
additionalProperties: False
properties:
TotalUse:
type: integer
InUse:
type: integer
Malloced:
type: integer
ContextSize:
type: integer
Lost:
type: integer
contexts:
type: array
items:
$ref: "#/components/schemas/MemoryContext"
MemoryContext:
type: object
additionalProperties: False
properties:
id:
type: string
name:
type: string
references:
type: integer
total:
type: integer
inuse:
type: integer
maxinuse:
type: integer
malloced:
type: integer
maxmalloced:
type: integer
pools:
type: integer
hiwater:
type: integer
lowater:
type: integer
Traffic:
type: object
additionalProperties: False
allOf:
- $ref: "#/components/schemas/Status"
properties:
traffic:
type: object
additionalProperties:
$ref: "#/components/schemas/TrafficData"
TrafficData:
type: object
additionalProperties:
type: integer
TaskMgr:
type: object
additionalProperties: False
properties:
taskmgr:
type: object
additionalProperties: False
properties:
thread-model:
type: string
default-quantum:
type: integer
tasks:
type: array
items:
$ref: "#/components/schemas/Task"
Task:
type: object
additionalProperties: False
properties:
id:
type: string
name:
type: string
references:
type: integer
state:
type: string
quantum:
type: integer
events:
type: integer
Summary:
type: object
additionalProperties: False
allOf:
- $ref: "#/components/schemas/Status"
- $ref: "#/components/schemas/Server"
- $ref: "#/components/schemas/Views"
- $ref: "#/components/schemas/Memory"
- $ref: "#/components/schemas/Sockstats"
- $ref: "#/components/schemas/Traffic"
- $ref: "#/components/schemas/TaskMgr"
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4204Deprecate and remove the "tkey-gssapi-credential" option2023-07-11T10:49:40ZMichał KępieńDeprecate and remove the "tkey-gssapi-credential" optionThe `CHANGES` entry accompanying the introduction of the
`tkey-gssapi-keytab` option ([back from 2010][1]) suggests that this
option is intended to supersede `tkey-gssapi-credential`:
2987. [func] Improve ease of configuring TKEY/G...The `CHANGES` entry accompanying the introduction of the
`tkey-gssapi-keytab` option ([back from 2010][1]) suggests that this
option is intended to supersede `tkey-gssapi-credential`:
2987. [func] Improve ease of configuring TKEY/GSS updates by
adding a "tkey-gssapi-keytab" option. If set,
updates will be allowed with any key matching
a principal in the specified keytab file.
"tkey-gssapi-credential" is no longer required
and is expected to be deprecated. (Contributed
by Andrew Tridgell of the Samba project.)
[RT #22629]
Given that the documentation for TKEY-related configuration knobs is
already tricky to plow through for someone not well-versed in GSSAPI
(like yours truly), I guess having multiple ways of configuring that
machinery is a cherry on top.
If I am reading the documentation correctly, I think `tkey-domain` could
perhaps also be ripped out, but the relationship between all the moving
parts is not quite clear to me.
[1]: 71bd858d8ed62672e7c23999dc7c02fd16a55089Not plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/2974New localize DHCP server command2023-09-01T14:23:21ZFrancis DupontNew localize DHCP server commandThe idea is to add a new command which returns the selected subnet (id and text) with eventually the shared network from supplied parametes as an IP address, client classes (for guards) or interface name.The idea is to add a new command which returns the selected subnet (id and text) with eventually the shared network from supplied parametes as an IP address, client classes (for guards) or interface name.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2972Empty hardware addresses not handled by PostgreSQL lease manager.2023-08-31T13:54:12ZFrancis DupontEmpty hardware addresses not handled by PostgreSQL lease manager.The PostgreSQL lease manager creates a type 1 (ETHER) hardware address on empty value for v4 leases instead to leave a null pointer (aka "none").
Minor bug so leaving it to next triage.The PostgreSQL lease manager creates a type 1 (ETHER) hardware address on empty value for v4 leases instead to leave a null pointer (aka "none").
Minor bug so leaving it to next triage.backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4202Running the "mkeys" system test around the top of the hour may cause it to fail2024-02-29T15:26:10ZMichał KępieńRunning the "mkeys" system test around the top of the hour may cause it to failhttps://gitlab.isc.org/isc-private/bind9/-/jobs/3509369
The `mkeys` system test failed silently on the following step:
2023-07-06 15:00:59 INFO:mkeys I:mkeys_tmp_5qq267_u:revoke key with bad signature, check revocation is ignor...https://gitlab.isc.org/isc-private/bind9/-/jobs/3509369
The `mkeys` system test failed silently on the following step:
2023-07-06 15:00:59 INFO:mkeys I:mkeys_tmp_5qq267_u:revoke key with bad signature, check revocation is ignored (19)
This means that it was more than likely `set -e` that triggered the
failure. Unfortunately, the `mkeys` system test is written in a way
that does not make debugging easy when `set -e` is in effect. There are
a *lot* of steps in the relevant check and each of them could trigger
the failure:
<details>
<summary>Click to expand/collapse</summary>
```sh
n=$((n+1))
echo_i "revoke key with bad signature, check revocation is ignored ($n)"
ret=0
revoked=$($REVOKE -K ns1 "$original")
rkeyid=$(keyfile_to_key_id "$revoked")
rm -f ns1/root.db.signed.jnl
# We need to activate at least one valid DNSKEY to prevent dnssec-signzone from
# failing. Alternatively, we could use -P to disable post-sign verification,
# but we actually do want post-sign verification to happen to ensure the zone
# is correct before we break it on purpose.
$SETTIME -R none -D none -K ns1 "$standby1" > /dev/null
$SIGNER -Sg -K ns1 -N unixtime -O full -o . -f signer.out.$n ns1/root.db > /dev/null 2>/dev/null
cp -f ns1/root.db.signed ns1/root.db.tmp
BADSIG="SVn2tLDzpNX2rxR4xRceiCsiTqcWNKh7NQ0EQfCrVzp9WEmLw60sQ5kP xGk4FS/xSKfh89hO2O/H20Bzp0lMdtr2tKy8IMdU/mBZxQf2PXhUWRkg V2buVBKugTiOPTJSnaqYCN3rSfV1o7NtC1VNHKKK/D5g6bpDehdn5Gaq kpBhN+MSCCh9OZP2IT20luS1ARXxLlvuSVXJ3JYuuhTsQXUbX/SQpNoB Lo6ahCE55szJnmAxZEbb2KOVnSlZRA6ZBHDhdtO0S4OkvcmTutvcVV+7 w53CbKdaXhirvHIh0mZXmYk2PbPLDY7PU9wSH40UiWPOB9f00wwn6hUe uEQ1Qg=="
# Less than a second may have passed since ns1 was started. If we call
# dnssec-signzone immediately, ns1/root.db.signed will not be reloaded by the
# subsequent "rndc reload ." call on platforms which do not set the
# "nanoseconds" field of isc_time_t, due to zone load time being seemingly
# equal to master file modification time.
sleep 1
sed -e "/ $rkeyid \./s, \. .*$, . $BADSIG," signer.out.$n > ns1/root.db.signed
mkeys_reload_on 1 || ret=1
mkeys_refresh_on 2 || ret=1
mkeys_status_on 2 > rndc.out.$n 2>&1 || ret=1
# one key listed
count=$(grep -c "keyid: " rndc.out.$n) || true
[ "$count" -eq 1 ] || { echo_i "'keyid:' count ($count) != 1"; ret=1; }
# it's the original key id
count=$(grep -c "keyid: $originalid" rndc.out.$n) || true
[ "$count" -eq 1 ] || { echo_i "'keyid: $originalid' count ($count) != 1"; ret=1; }
# not revoked
count=$(grep -c "REVOKE" rndc.out.$n) || true
[ "$count" -eq 0 ] || { echo_i "'REVOKE' count ($count) != 0"; ret=1; }
# trust is still current
count=$(grep -c "trust" rndc.out.$n) || true
[ "$count" -eq 1 ] || { echo_i "'trust' count != 1"; ret=1; }
count=$(grep -c "trusted since" rndc.out.$n) || true
[ "$count" -eq 1 ] || { echo_i "'trusted since' count != 1"; ret=1; }
if [ $ret != 0 ]; then echo_i "failed"; fi
status=$((status+ret))
```
</details>
However, it is possible to look at the presence/absence of certain files
among the test artifacts and also to look at file timestamps, so that
some scenarios can be ruled out. In this case, `ns1/root.db.tmp` did
not exist, so execution did not reach the `cp -f` line. This meant that
only `dnssec-revoke`, `dnssec-settime`, and `dnssec-signzone` could have
failed. However, since there were three key files in `ns1` newer than
the `$original` one (meaning that `dnssec-revoke` and `dnssec-settime`
did their job), `dnssec-signzone` was the primary suspect. I ran its
invocation from the test manually on the artifacts and...
```
$ dnssec-signzone -Sg -K ns1 -N unixtime -O full -o . -f signer.out.19 ns1/root.db
Fetching ./ECDSAP384SHA384/25503 (KSK) from key repository.
Fetching ./ECDSAP256SHA256/37163 (KSK) from key repository.
Fetching ./ECDSAP384SHA384/24825 (ZSK) from key repository.
dnssec-signzone: warning: Serial number would not advance, using increment method instead
Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Missing ZSK for algorithm ECDSAP256SHA256
Missing self-signed KSK for algorithm ECDSAP384SHA384
No correct ECDSAP256SHA256 signature for . NSEC
No correct ECDSAP256SHA256 signature for . SOA
No correct ECDSAP256SHA256 signature for . NS
No correct ECDSAP256SHA256 signature for example NSEC
No correct ECDSAP256SHA256 signature for example TXT
No correct ECDSAP256SHA256 signature for a.root-servers.nil NSEC
No correct ECDSAP256SHA256 signature for a.root-servers.nil A
No correct ECDSAP256SHA256 signature for tld NSEC
The zone is not fully signed for the following algorithms:
ECDSAP256SHA256
ECDSAP384SHA384
.
DNSSEC completeness test failed.
Zone verification failed (failure)
```
But wait, how is it even possible that this zone is signed using
multiple algorithms?
```
$ git grep -F _ALGORITHM bin/tests/system/mkeys/ | wc -l
13
$ git grep -F _ALGORITHM bin/tests/system/mkeys/ | grep -vF DEFAULT_ALGORITHM
$
```
The `*_ALGORITHM` environment variables are set by
`bin/tests/system/get_algorithms.py`. The script is written in a way
that allows the algorithms used to be chosen randomly from a specific
set. The `mkeys` test takes advantage of that feature and sets
`ALGORITHM_SET` to `ecc_default`. The script tries to ensure a stable
set of algorithms is used for each system test run by [seeding its RNG
with a value derived from the current time][1]. This works most of the
time, but if we get really unlucky, `setup.sh` can be run during one
"time slot" while `tests.sh` is run during another. This is exactly
what happened in this case:
```
------------------------------ Captured log setup ------------------------------
2023-07-06 14:59:58 INFO:mkeys switching to tmpdir: /builds/isc-private/bind9/bin/tests/system/mkeys_tmp_5qq267_u
2023-07-06 14:59:58 INFO:mkeys test started: mkeys/tests_sh_mkeys.py
2023-07-06 14:59:58 INFO:mkeys using port range: <20583, 20602>
------------------------------ Captured log call -------------------------------
2023-07-06 15:00:14 INFO:mkeys I:mkeys_tmp_5qq267_u:check for signed record (1)
2023-07-06 15:00:14 INFO:mkeys I:mkeys_tmp_5qq267_u:check positive validation with valid trust anchor (2)
2023-07-06 15:00:14 INFO:mkeys I:mkeys_tmp_5qq267_u:check for failed validation due to wrong key in managed-keys (3)
...
```
(Note that when the `test started: ...` line is logged, the script
actually runs `setup.sh` first. `tests.sh` is run afterwards.)
This problem happens very rarely, so I am not sure if we need to do
anything about it, but it felt right to open an issue so that others are
aware that this is a thing. `mkeys` is the only system test that
currently sets the `ALGORITHM_SET` variable, so exposure is minimal. If
we migrate more tests to variable algorithms, this might become a more
pressing issue to address.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/bf8acd455693edef03881fd2180c5561bc0db66d/bin/tests/system/get_algorithms.py#L171-175May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4199dig (and other tools) may send queries with QID=0, which confuses Net::DNS2023-11-02T16:30:30ZMichał Kępieńdig (and other tools) may send queries with QID=0, which confuses Net::DNSUnless specified manually using `+qid=<value>`, `dig` uses a random
query ID for the DNS messages it sends out:
https://gitlab.isc.org/isc-projects/bind9/-/blob/bf8acd455693edef03881fd2180c5561bc0db66d/bin/dig/dighost.c#L2334
In partic...Unless specified manually using `+qid=<value>`, `dig` uses a random
query ID for the DNS messages it sends out:
https://gitlab.isc.org/isc-projects/bind9/-/blob/bf8acd455693edef03881fd2180c5561bc0db66d/bin/dig/dighost.c#L2334
In particular, the value chosen can be 0. While QID=0 is perfectly
legal protocol-wise, it seems that some code bases, e.g. Net::DNS, are
unable to properly handle queries with QID=0. Here is an example:
https://gitlab.isc.org/isc-private/bind9/-/jobs/3509123
```
2023-07-06 14:14:45 INFO:serve-stale I:serve-stale_tmp_iwl06k82:disable responses from authoritative server (89)
2023-07-06 14:14:57 INFO:serve-stale I:serve-stale_tmp_iwl06k82:failed
```
`bin/tests/system/serve-stale_tmp_iwl06k82/dig.out.test89`:
```
;; Warning: ID mismatch: expected ID 0, got 46879
;; communications error to 10.53.0.2#19223: timed out
; <<>> DiG 9.19.15 <<>> +time +tries -p 19223 @10.53.0.2 txt disable
; (1 server found)
;; global options: +cmd
;; no servers could be reached
```
This looked weird to me, so I started `ans2/ans2.pl` manually and sent a
query to it using `dig @10.53.0.2 -p 5300 disable. TXT +qid=0 +tries=1`.
Guess what:
```
;; Warning: ID mismatch: expected ID 0, got 27885
;; communications error to 10.53.0.2#5300: timed out
; <<>> DiG 9.19.15 <<>> @10.53.0.2 -p 5300 disable. TXT +qid=0 +tries=1
; (1 server found)
;; global options: +cmd
;; no servers could be reached
```
Looking at [Net::DNS sources][1], the documentation says:
```
=head2 id
print "query id = ", $packet->header->id, "\n";
$packet->header->id(1234);
Gets or sets the query identification number.
A random value is assigned if the argument value is undefined.
```
However, the above seems to be imprecise: apparently if the ID is
*defined*, but *set to 0*, Net::DNS treats it as an undefined value.
This causes the `$packet->header->id` call to return a random value
instead of 0 for queries with QID=0, breaking responses to such queries.
I don't see any reasonable way to work around this problem in our Perl
code (apart from converting it to Python). Adding `+qid` to every `dig`
invocation in the system test suite also seems over the top for working
around something this silly. However, until we do something about this,
we might be seeing a whole class of surprising failures in the system
test suite caused by this behavior.
[1]: https://www.net-dns.org/svn/net-dns/trunk/lib/Net/DNS/Header.pmNot plannedhttps://gitlab.isc.org/isc-projects/stork/-/issues/1114Replace fpm with nfpm2023-07-04T13:29:57ZSlawek FigielReplace fpm with nfpmI found a Go replacement for the `fpm` program we use to build the packages: [nfpm](https://github.com/goreleaser/nfpm).
We need to check if it can build valid APK packages. If yes, we should discuss using it instead `fpm`.
Additionall...I found a Go replacement for the `fpm` program we use to build the packages: [nfpm](https://github.com/goreleaser/nfpm).
We need to check if it can build valid APK packages. If yes, we should discuss using it instead `fpm`.
Additionally, introducing it will reduce the Ruby-related tools in the project.backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4193unit test `task_test` fails intermittently under TSAN2023-07-03T13:43:05ZTom Krizekunit test `task_test` fails intermittently under TSANThere are two failure modes of `task_test` unit test when running with TSAN.
The first happens in [`unit:gcc:tsan`](https://gitlab.isc.org/isc-private/bind9/-/jobs/3501215):
```
lib/isc/tests/task_test:main -> broken: Dubious test pr...There are two failure modes of `task_test` unit test when running with TSAN.
The first happens in [`unit:gcc:tsan`](https://gitlab.isc.org/isc-private/bind9/-/jobs/3501215):
```
lib/isc/tests/task_test:main -> broken: Dubious test program: reported all tests as passed but returned exit code 66 [13.181s]
----- lib/isc/tests/task_test:main -----
TAP version 13
1..13
ok 1 - manytasks
ok 2 - all_events
ok 3 - basic
ok 4 - create_task
ok 5 - pause_unpause
ok 6 - post_shutdown
ok 7 - privilege_drop
ok 8 - privileged_events
ok 9 - purge
ok 10 - purgeevent
ok 11 - purgerange
ok 12 - task_shutdown
ok 13 - task_exclusive
# ok - tests
lib/isc/tests/task_test:main -> passed
R:FAIL:status:1
```
The second happens in [`unit:clang:tsan`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3499807) and [`unit:gcc:asan`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3499127):
```
lib/isc/tests/task_test:main -> broken: Received signal 6 [14.000s]
----- lib/isc/tests/task_test:main -----
1..13
ok 1 - manytasks
ok 2 - all_events
ok 3 - basic
ok 4 - create_task
ok 5 - pause_unpause
ok 6 - post_shutdown
ok 7 - privilege_drop
ok 8 - privileged_events
ok 9 - purge
ok 10 - purgeevent
ok 11 - purgerange
ok 12 - task_shutdown
ok 13 - task_exclusive
# ok - tests
lib/isc/tests/task_test:main -> passed
R:FAIL:status:1
```Not plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/2961Remove support for the deprecated auto-generated subnet IDs feature2023-08-10T13:36:06ZAndrei Pavelandrei@isc.orgRemove support for the deprecated auto-generated subnet IDs feature[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#ipv4-subnet-identifier):
> It is one of the reasons why auto-generated subnet identifiers are deprecated starting from Kea version 2.4.0.
The deprecatio...[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#ipv4-subnet-identifier):
> It is one of the reasons why auto-generated subnet identifiers are deprecated starting from Kea version 2.4.0.
The deprecation happened in Kea 2.4. Kea 2.4 shipped with the deprecation warning in the ARM. Kea 2.5 can have the feature removed.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2960Remove support for the deprecated libreload command2023-08-10T13:36:06ZAndrei Pavelandrei@isc.orgRemove support for the deprecated libreload command[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/install.html#libreload-command):
> The libreload command was deprecated in Kea 2.3.4. The code to handle this command is still there, but there are reports of it being b...[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/install.html#libreload-command):
> The libreload command was deprecated in Kea 2.3.4. The code to handle this command is still there, but there are reports of it being buggy and not really usable. Kea 2.3 and 2.4 versions will produce a warning when this command is used, and it will be removed entirely sometime in the 2.5 branch.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2959Remove support for the deprecated reservation-mode config flag2023-08-10T13:36:06ZAndrei Pavelandrei@isc.orgRemove support for the deprecated reservation-mode config flag[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#address-reservation-types):
> Since Kea 1.9.1, reservation mode has been replaced by three boolean flags, reservations-global, reservations-in-subnet, and...[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#address-reservation-types):
> Since Kea 1.9.1, reservation mode has been replaced by three boolean flags, reservations-global, reservations-in-subnet, and reservations-out-of-pool, which allow the configuration of host reservations both globally and in a subnet.
The deprecation happened in Kea 1.9. Kea 2.0 shipped with the deprecation warning in the ARM. Kea 2.1 could have had support for these parameters removed.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2958Remove support for the deprecated dhcp-ddns config flags2023-08-10T13:36:06ZAndrei Pavelandrei@isc.orgRemove support for the deprecated dhcp-ddns config flags[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#ddns-for-dhcpv4):
> [the D2 parameters] have been moved out of the dhcp-ddns section so that they may be specified at the global, shared-network, and/or s...[As mentioned in the ARM](https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#ddns-for-dhcpv4):
> [the D2 parameters] have been moved out of the dhcp-ddns section so that they may be specified at the global, shared-network, and/or subnet levels.
The deprecation happened in Kea 1.7. Kea 1.8 shipped with the deprecation warning in the ARM. Kea 1.9 could have had support for these parameters removed.
As a side note, the quotes statement contradicts another one in the ARM that says:
> These parameters can only be specified within the top-level dhcp-ddns section in the kea-dhcp4 configuration.
Also `ncr-format"` has an extraneous quote around that part of the ARM.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2957dhcpdb_create.pgsql erroneously creates dhcp4_server_modification_ts index on...2024-03-22T13:05:49ZJohn W. O'Briendhcpdb_create.pgsql erroneously creates dhcp4_server_modification_ts index on dhcp6_server table---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhcpdb_create.pgsql erroneously creates the dhcp4_server_modification_ts index on the dhcp6_server table
**To Reproduce**
Steps to reproduce the b...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhcpdb_create.pgsql erroneously creates the dhcp4_server_modification_ts index on the dhcp6_server table
**To Reproduce**
Steps to reproduce the behavior:
1. Initialize a PostgreSQL database using dhcpdb_create.pgsql
2. Inspect the dhcp4_server_modification_ts index
3. See that it is associated with the dhcp6_server table
**Expected behavior**
A clear and concise description of what you expected to happen:
The dhcp4_server_modification_ts index should be associated with the dhcp4_server table.
**Environment:**
- Kea version: 2.2.0
- OS: FreeBSD 13.2-RELEASE amd64
- Compiled with pgsql backend
- Loaded hooks: pgsql_cb
**Additional Information**
```
kea=> \di dhcp4_server_modification_ts
List of relations
Schema | Name | Type | Owner | Table
--------+------------------------------+-------+-------+--------------
public | dhcp4_server_modification_ts | index | kea | dhcp6_server
(1 row)
```
This appears to have been introduced as a [copy/paste error in version 7.0 of the schema](https://gitlab.isc.org/isc-projects/kea/-/blob/Kea-2.3.8/src/share/database/scripts/pgsql/dhcpdb_create.pgsql#L1398). I could identify no correspond bug in the MySQL schema.
**Contacting you**
* SMS/Signal: (available upon request)
* GitHub/GitLab: neirbowj
* Mastodon: [@neirbowj@mastodon.online](https://mastodon.online/@neirbowj)kea2.5.8https://gitlab.isc.org/isc-projects/bind9/-/issues/4186Name Buffer Truncation2023-06-29T13:04:00ZMarkus VervierName Buffer Truncation
### Summary
A truncation of the name of memory pools was found which might lead to unintended behavior
or incorrect debugging output.
A memory pool structure `isc_mempool` has a member field name with a capacity of 16 bytes as
shown i...
### Summary
A truncation of the name of memory pools was found which might lead to unintended behavior
or incorrect debugging output.
A memory pool structure `isc_mempool` has a member field name with a capacity of 16 bytes as
shown in the following listing from file `lib/isc/mem.c`:
~~~c
struct isc_mempool {
/* always unlocked */
unsigned int magic;
isc_mem_t *mctx;
/*%< our memory context */
ISC_LINK(isc_mempool_t) link; /*%< next pool in this mem context */
element *items;
/*%< low water item list */
size_t size;
/*%< size of each item on this pool */
size_t allocated;
/*%< # of items currently given out */
size_t freecount;
/*%< # of items on reserved list */
size_t freemax;
/*%< # of items allowed on free list */
size_t fillcount;
/*%< # of items to fetch on each fill */
/*%< Stats only. */
size_t gets; /*%< # of requests to this pool */
/*%< Debugging only. */
char name[16]; /*%< printed name in stats reports */
};
~~~
In the function `dns_zonemgr_create()` a string of size 16 without the terminating NUL byte is passed
on to function `isc_mem_setname()`, leading to silent truncation of the last character in that string
as shown in the following listing:
~~~c
for (size_t i = 0; i < zmgr->workers; i++) {
isc_mem_create(&zmgr->mctxpool[i]);
isc_mem_setname(zmgr->mctxpool[i], "zonemgr-mctxpool");
,→
// MARK truncation / off by one (namebuffer is 16 bytes only)
}
~~~
This issue is informational since the truncation has no security implications, but could lead to
incorrect assumptions or functionality defects.
### BIND version used
BIND 9.19.13 (Development Release) <id:66a3c6b>
### Possible fixes
X41 recommends either increase the buffer size or shorten the name value, but to also add an
assertion to the `isc_mem_create()` function that ensures the name size is larger than zero and less
than 16 bytes without the terminating NUL byte.Not plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/2953migrate hammer installations from mysql to mariadb2023-11-07T10:25:44ZWlodzimierz Wencelmigrate hammer installations from mysql to mariadbhammer install mysql in ubuntu and debian systems, change it for mariadbhammer install mysql in ubuntu and debian systems, change it for mariadbnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2943strict check for prefix and prefix length for ipv6 PDs in lease and host cons...2023-07-01T15:01:21ZRazvan Becheriustrict check for prefix and prefix length for ipv6 PDs in lease and host constructorsThe safest way to make sure Kea internally does not construct a PD lease with invalid prefix and prefix length is to add the check in lease and host constructors.
Currently (after the merge of #2725) the possibility to send invalid PD l...The safest way to make sure Kea internally does not construct a PD lease with invalid prefix and prefix length is to add the check in lease and host constructors.
Currently (after the merge of #2725) the possibility to send invalid PD leases to clients comes from the database (either lease or host) which are maintained consistent when using KEA API, but the user can always add entries using database CLI and the data will reach the clients unchecked.
This proposal is robust and simple.
If some flexibility is needed in UTs, a 'test' flag can be set in a static/global variable which can disable these checks.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2940return hash in config-set response from CA2023-06-29T13:33:06ZTomek Mrugalskireturn hash in config-set response from CAThe #2707 introduced hash being returned by `config-set` response for DHCPv4, DHCPv6 and D2. This ticket is about adding the same functionality for Ctrl Agent. This is a completion of the task started in #2707.The #2707 introduced hash being returned by `config-set` response for DHCPv4, DHCPv6 and D2. This ticket is about adding the same functionality for Ctrl Agent. This is a completion of the task started in #2707.next-stable-2.6https://gitlab.isc.org/isc-projects/bind9/-/issues/4164Investigate performance impact of UDP_GRO2023-06-27T07:06:24ZPetr Špačekpspacek@isc.orgInvestigate performance impact of UDP_GRO### Description
Mention of UDP_GRO in [Linux udp man page](https://man.archlinux.org/man/udp.7) sounds worth investigating:
> #### UDP_GRO (since Linux 5.0)
> Enables UDP receive offload. If enabled, the socket may receive multiple dat...### Description
Mention of UDP_GRO in [Linux udp man page](https://man.archlinux.org/man/udp.7) sounds worth investigating:
> #### UDP_GRO (since Linux 5.0)
> Enables UDP receive offload. If enabled, the socket may receive multiple datagrams worth of data as a single large buffer, together with a cmsg(3) that holds the segment size. This option is the inverse of segmentation offload. It reduces receive cost by handling multiple datagrams worth of data as a single large packet in the kernel receive path, even when that exceeds MTU. This option should not be used in code intended to be portable.
More reading:
https://developers.redhat.com/articles/2021/11/05/improve-udp-performance-rhel-85
### Request
- Investigate if UDP receipt is even a bottleneck.
- Investigate if UDP_GRO makes a difference and is worth messing with (I supposed in libuv).
### Links / referencesLong-term