Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-28T09:49:32Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3323Fix undefined behaviors reported by UBSan2024-03-28T09:49:32ZAndrei Pavelandrei@isc.orgFix undefined behaviors reported by UBSanThree types of UBs are reported at https://reports.kea.isc.org/tests_status/ut-ubsan.html. I think all of them are worth fixing.
- `runtime error: constructor call on misaligned address * for type '*', which requires * byte alignment`
-...Three types of UBs are reported at https://reports.kea.isc.org/tests_status/ut-ubsan.html. I think all of them are worth fixing.
- `runtime error: constructor call on misaligned address * for type '*', which requires * byte alignment`
- `runtime error: load of value *, which is not a valid value for type '*'`
- `runtime error: member call on misaligned address * for type '*', which requires * byte alignment`https://gitlab.isc.org/isc-projects/kea/-/issues/3315hooks should use their own IOService instance and register it with the main I...2024-03-29T08:37:22ZRazvan Becheriuhooks should use their own IOService instance and register it with the main IOServicerelated to https://gitlab.isc.org/isc-projects/kea/-/issues/3308
to properly load and run IOService poll so that configuration errors are detected before configuration is applied and to unload hooks and safely call all close callbacks, ...related to https://gitlab.isc.org/isc-projects/kea/-/issues/3308
to properly load and run IOService poll so that configuration errors are detected before configuration is applied and to unload hooks and safely call all close callbacks, a "local" IOService instance should be used by each hook. this guarantees that there can be no handlers referencing objects created in the hook that are called after hook unload.
hooks that use main io service:
premium:
* gss_tsig
* forensic_log
* lease_query
* ping_check
* radius
core:
* high_availability
* mysql_cb
* pbsql_cb
* run_script
all hooks requiring IOService should do the following:
```plaintext
int unload() {
if (getMainIOService()) {
getMainIOService()->unregisterExternalIOService(getIOService());
}
getIOService()->stop();
getIOService()->restart();
try {
getIOService()->poll();
} catch (...) {
}
...
}
int dhcp4_srv_configured(CalloutHandle& handle) {
handle.getArgument("io_context", getMainIOService());
if (!getMainIOService()) {
// Should not happen!
handle.setStatus(isc::hooks::CalloutHandle::NEXT_STEP_DROP);
const string error("Error: io_context is null");
handle.setArgument("error", error);
return (1);
}
...
getMainIOService()->registerExternalIOService(getIOService());
...
}
int dhcp6_srv_configured(CalloutHandle& handle) {
handle.getArgument("io_context", getMainIOService());
if (!getMainIOService()) {
// Should not happen!
handle.setStatus(isc::hooks::CalloutHandle::NEXT_STEP_DROP);
const string error("Error: io_context is null");
handle.setArgument("error", error);
return (1);
}
...
getMainIOService()->registerExternalIOService(getIOService());
...
}
void
IOService::registerExternalIOService(IOServicePtr io_service) {
external_io_services_.push_back(io_service);
}
void
IOService::unregisterExternalIOService(IOServicePtr io_service) {
auto it = std::find(external_io_services_.begin(), external_io_services_.end(), io_service);
if (it != external_io_services_.end()) {
external_io_services_.erase(it);
}
}
void
IOService::pollExternalIO() {
for (auto& io_service : external_io_services_) {
io_service->poll();
}
}
```
built on top of #3281
I confirm it fixes the crash in https://gitlab.isc.org/isc-projects/kea/-/issues/3308https://gitlab.isc.org/isc-projects/kea/-/issues/3314RBAC: Omitting configuration option results in logged error2024-03-26T21:44:52ZDarren AnkneyRBAC: Omitting configuration option results in logged errorThe configuration directive `"response-filters"` seems to be de facto required whereas the ARM seems to imply that this parameter should be optional as it shows examples where the parameter is not present (see the extensive example). It...The configuration directive `"response-filters"` seems to be de facto required whereas the ARM seems to imply that this parameter should be optional as it shows examples where the parameter is not present (see the extensive example). It doesn't actually say whether the parameter is required or optional, however.
Omitting the directive causes this error:
```
[kea-ctrl-agent.callouts/401411.129873316435840] HOOKS_CALLOUT_EXCEPTION exception thrown by callout on hook response registered by library with index 1 (callout address 0x761e7c475880): unable to find callout context associated with the current library index (1) (callout duration: 0.047 ms)
```
The error does not seem to cause any harm as the operations still seem to be performed. This can fill up the logs though if there is a lot of API access (such as in the case of Stork).
Adding the directive to the roles configuration(s) removes the error.
[SF1816](https://isc.lightning.force.com/lightning/r/Case/500S6000007Ho67IAC/view)Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/3312D2 can enounters write errors sending to DNS2024-03-28T14:59:45ZThomas MarkwalderD2 can enounters write errors sending to DNSDuring tests for #3295 which used a single bind9 DNS server I discoverd that under enough load for a long enough period of time D2 begins to encounter errors writing to the DNS server:
2024-03-26 15:00:22.965 ERROR [kea-dhcp-ddns.asiodn...During tests for #3295 which used a single bind9 DNS server I discoverd that under enough load for a long enough period of time D2 begins to encounter errors writing to the DNS server:
2024-03-26 15:00:22.965 ERROR [kea-dhcp-ddns.asiodns/4711.140284993357696] ASIODNS_SEND_DATA error 101 sending data using UDP to 175.16.1.1(53)
Error code 101 is Network Unreachable.
When this occurs, excuting "nsupdate" from the command line of D2's host produces similar result:
```
tmark@ubuserver:kea $ nsupdate -v $HOME/n.txt
; Communication with 175.16.1.1#53 failed: operation canceled
could not reach any name server
```
I do not, at this time, know the root cause of these write failures. Excuting
an nsupdate from another VM is successful.
In addition to the write failures themselves, I believe there is an error in how IOFetch handles these errors. It appears that the fetch is allowed to proceed to executing a read after the send has failed, rather that calling IOFetch::stop() as is done for read TIME_OUTs. There seems little point executing a read that will only timeout. This has the affect of causing D2 to do 3 send(fail)/read(timeout) cycles.
Bottom line is there are two questions:
1. What causes the Network Unreachable errors?
2. Should IOFetch() fail on send failures (perhaps by callng stop()) rather than proceed to read after failed send?
The testing referred to above was done with:
1. Centos 7 VM running perfdhcp:
perfdhcp -4 -r 20 -R 10000000 -p 600 -l enp0s10 -W 5000000
2. Centos 7 VM running BIND9 9.11.2:
```rndc -c /opt/bind9/bind-9.11.2/local/servers/42620/rndc.conf status
version: BIND 9.11.2 <id:0a2b929>
running on cthird: Linux x86_64 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017
boot time: Tue, 26 Mar 2024 13:00:27 GMT
last configured: Tue, 26 Mar 2024 13:00:27 GMT
configuration file: /opt/bind9/bind-9.11.2/local/servers/42620/named.conf
CPUs found: 4
worker threads: 4
UDP listeners per interface: 3
number of zones: 6 (0 automatic)
debug level: 100
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
recursive clients: 0/900/1000
tcp clients: 0/150
server is up and running
```lsb_release -a
3. Ubuntu VM 22.02 running kea-dhcp4 and kea-dhcp-ddns, configs attached:
[kea-d2.conf](/uploads/1ec60a23a57c33f03ee4621d6a15c048/kea-d2.conf)
[kea-ddns4.conf](/uploads/7300d3f06194bd7b2310daaed278d722/kea-ddns4.conf)
```https://gitlab.isc.org/isc-projects/kea/-/issues/3311kea-dhcp4 and 6: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be remov...2024-03-25T21:07:26ZHarry G. Coinkea-dhcp4 and 6: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.On both dhcp 4 and 6, over many upgrades in the past month this warning remains:
kea-dhcp4: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.
Likely on the next major db client upgrade, mysql and maria...On both dhcp 4 and 6, over many upgrades in the past month this warning remains:
kea-dhcp4: WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.
Likely on the next major db client upgrade, mysql and mariadb will no longer answer kea requests.
Probably worth fixing 'real soon now', before conditions of time pressure arise from total failure.https://gitlab.isc.org/isc-projects/kea/-/issues/3310Documentation should include more examples with IPv6 addresses in URLs2024-03-25T12:34:33ZFrancis DupontDocumentation should include more examples with IPv6 addresses in URLsThe reason is the syntax is no so trivial... I suggest to add at least one in ARM (hooks-ha.rst) and in kea6 examples.The reason is the syntax is no so trivial... I suggest to add at least one in ARM (hooks-ha.rst) and in kea6 examples.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3305config test should also run poll after loading hooks2024-03-22T14:46:13ZRazvan Becheriuconfig test should also run poll after loading hooksthe fix in https://gitlab.isc.org/isc-projects/kea/-/issues/2692 does not consider testing the configuration when using -T as command line parameterthe fix in https://gitlab.isc.org/isc-projects/kea/-/issues/2692 does not consider testing the configuration when using -T as command line parameterhttps://gitlab.isc.org/isc-projects/kea/-/issues/3302Is Host Cache required for RADIUS?2024-03-28T16:15:48ZFrancis DupontIs Host Cache required for RADIUS?The Host Cache was designed for RADIUS in order to not perform an access/auth exchange with the RADIUS server for each query: when the query comes from an already seen client (same RADIUS idenfier) the answer from the RADIUS server is av...The Host Cache was designed for RADIUS in order to not perform an access/auth exchange with the RADIUS server for each query: when the query comes from an already seen client (same RADIUS idenfier) the answer from the RADIUS server is available from the host cache. This was critical when both were designed because the access/auth exchange was synchronous (i.e. blocking until the answer is received) and single threaded (i.e. blocking the whole DHCP service). Perhaps it is less true today but the host cache is in memory when RADIUS exchanges are over the network so far slower, and the Host Cache also handles negative answers so covers (excepting for the bug described in #3269) all cases.
The Host Cache has a second function for RADIUS: when the RADIUS server returns an address (vs a pool name which is translated into a client class name directly added to the query object) a host entry for this reserved address is inserted in the Host Cache. The idea is the host lookup will be able to find it. This is not essential: the host entry can be attached to the callout handle associated to the query and got back latter as the current code does for the [re]selected subnet.kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3301Add missing YANG nodes before the 2.6.0 release2024-03-21T15:03:05ZAndrei Pavelandrei@isc.orgAdd missing YANG nodes before the 2.6.0 releaseMissing YANG nodes:
- `ddns-conflict-resolution-mode`
- `retry-on-startup`Missing YANG nodes:
- `ddns-conflict-resolution-mode`
- `retry-on-startup`kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3299Improve MT RADIUS unit tests2024-03-26T18:31:40ZAndrei Pavelandrei@isc.orgImprove MT RADIUS unit testsImprove RADIUS unit tests:
- no goal: write tests for session history: instead implement #414
- MT: see below
- async access added new ways to have a query to be dropped: add these cases
- find a way to detect accounting exchange te...Improve RADIUS unit tests:
- no goal: write tests for session history: instead implement #414
- MT: see below
- async access added new ways to have a query to be dropped: add these cases
- find a way to detect accounting exchange termination (e.g. a class counter of pending exchanges)
RADIUS could have more thorough MT unit tests:
- Start thread pool for accounting by calling the `dhcp*_srv_configured` callout. Currently it is only called for auth. Waiting for work to finish in accounting is not as trivial for auth. Auth uses the unparking for that. (see last general point)
- In both access and accounting, start a second thread pool that simulates the core Kea thread pool / DHCP clients.
- Convert more (all?) ST unit tests to MT. Currently there are only 4 MT unit tests: (v4 + v6) x (access + accounting).kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3298Make test utility class MemHostDataSource thread-safe2024-03-21T15:02:10ZAndrei Pavelandrei@isc.orgMake test utility class MemHostDataSource thread-safe`MemHostDataSource` is used in certain unit tests.
RADIUS MT unit tests required `MemHostDataSource` to be thread-safe, so the `TestHostCache` that derives it overrode all its methods and added a `lock_guard` to each.
To avoid this boi...`MemHostDataSource` is used in certain unit tests.
RADIUS MT unit tests required `MemHostDataSource` to be thread-safe, so the `TestHostCache` that derives it overrode all its methods and added a `lock_guard` to each.
To avoid this boilerplate code, ideally, `MemHostDataSource` should be made thread-safe itself.
This was not done at the time due to lack of time before the release.
When this is done, remember to remove the overridden methods from `TestHostCache`:
- `premium/src/hooks/dhcp/radius/tests/access_unittests.cc`
- `premium/src/hooks/dhcp/radius/tests/accounting_unittests.cc`
@fdupont says
> Note the mutex must be at most protected.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3297Perfmon-Hook-Task-5 Add Event Stack Processing2024-03-28T20:25:49ZThomas MarkwalderPerfmon-Hook-Task-5 Add Event Stack ProcessingComplete Hook Task 5: Add Event Stack Processing - Process event stacks into MonitoredDuration updates, implement report timer, and alarm processing
See https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/performance-monitor#perfm...Complete Hook Task 5: Add Event Stack Processing - Process event stacks into MonitoredDuration updates, implement report timer, and alarm processing
See https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/performance-monitor#perfmon-hook-taskskea2.5.8Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/3295DDNS: addresses assigned from an arpa domain that is not configured can halt ...2024-03-28T16:58:13ZDarren AnkneyDDNS: addresses assigned from an arpa domain that is not configured can halt ddns processingKea Version tested: 2.4.0 with DHCPv4. Assumedly this same problem would exist in DHCPv6 but I didn't try that. The BIND version used in the test was 9.18.24, but I don't think it probably matters what version or brand of DNS server is...Kea Version tested: 2.4.0 with DHCPv4. Assumedly this same problem would exist in DHCPv6 but I didn't try that. The BIND version used in the test was 9.18.24, but I don't think it probably matters what version or brand of DNS server is used.
It has been discovered that it is possible that `kea-dhcp-ddns` can enter a state where no ddns updates are issued under certain circumstances. The circumstances required are only an intermittently unavailable DNS server, an address range in Kea that is not in the "reverse-ddns" portion of the DDNS configuration, a high rate of DHCP queries (I tested with 200 per second), and `"ddns-update-on-renew": true` in the `kea-dhcp4` configuration. Below is the test scenario (first with a working version of the ddns configuration):
<details><summary>Kea configuration and command line</summary>
Command: `kea-dhcp4 -c kea-dhcp4-test-ddns.json`
kea-dhcp4-test-ddns.json
```
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [
"ens256"
]
},
"lease-database": {
"type": "memfile",
"persist": false
},
"calculate-tee-times": true,
"valid-lifetime": 7200,
"ddns-generated-prefix": "myhost",
"ddns-qualifying-suffix": "example.org",
"ddns-replace-client-name": "always",
"ddns-send-updates": true,
"ddns-override-client-update": true,
"ddns-override-no-update": true,
"ddns-update-on-renew": true,
"dhcp-ddns": {
"enable-updates": true,
"max-queue-size": 1024,
"ncr-format": "JSON",
"ncr-protocol": "UDP",
"sender-ip": "0.0.0.0",
"sender-port": 0,
"server-ip": "127.0.0.1",
"server-port": 53001
},
"shared-networks": [
{
"name": "my-secret-lair-level-1",
"interface": "ens256",
"subnet4": [
{
"subnet": "10.1.2.0/24",
"id": 1,
"option-data": [
{
"name": "routers",
"data": "10.1.2.1"
}
],
"pools": [
{
"pool": "10.1.2.100-10.1.2.200"
}
]
},
{
"subnet": "172.16.0.0/24",
"id": 2,
"option-data": [
{
"name": "routers",
"data": "172.16.0.1"
}
],
"pools": [
{
"pool": "172.16.0.100-172.16.0.200"
}
]
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"severity": "DEBUG",
"debuglevel": 99,
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
```
</details>
<details><summary>BIND configuration and command line</summary>
Command: `named -4 -g -c /tmp/named.conf`
named.conf
```
options {
directory "/tmp";
recursion no;
allow-update { any;};
dnssec-validation no;
};
zone "2.1.10.in-addr.arpa" {
type primary;
file "/tmp/2.1.10.in-addr.arpa";
};
zone "0.16.172.in-addr.arpa" {
type primary;
file "/tmp/0.16.172.in-addr.arpa";
};
zone "example.org" {
type primary;
file "/tmp/example.org";
};
```
example.org
```
$ORIGIN .
$TTL 86399 ; 23 hours 59 minutes 59 seconds
example.org IN SOA ns1.example.org. hostmaster.example.org. (
1 ; serial
43200 ; refresh (12 hours)
900 ; retry (15 minutes)
1814400 ; expire (3 weeks)
7200 ; minimum (2 hours)
)
NS ns1.example.org.
ns1.example.org A 192.168.20.114
```
2.1.10.in-addr.arpa
```
$ORIGIN .
$TTL 86400 ; 1 day
2.1.10.in-addr.arpa IN SOA 2.1.10.IN-ADDR.ARPA. . (
1 ; serial
30800 ; refresh (8 hours 33 minutes 20 seconds)
7200 ; retry (2 hours)
604800 ; expire (1 week)
300 ; minimum (5 minutes)
)
NS ns1.example.org.
```
0.16.172.in-addr.arpa
```
$ORIGIN .
$TTL 86400 ; 1 day
0.16.172.in-addr.arpa IN SOA 0.16.172.in-addr.arpa. . (
1 ; serial
30800 ; refresh (8 hours 33 minutes 20 seconds)
7200 ; retry (2 hours)
604800 ; expire (1 week)
300 ; minimum (5 minutes)
)
NS ns1.example.org.
```
</details>
<details><summary>Working DDNS configuration and command line</summary>
Command: `kea-dhcp-ddns -c kea-dhcp-ddns-test-ddns.json`
kea-dhcp-ddns-test-ddns.json
```
{
"DhcpDdns": {
"dns-server-timeout": 40000,
"forward-ddns": {
"ddns-domains": [
{
"dns-servers": [
{
"ip-address": "192.168.20.114",
"port": 53
}
],
"name": "example.org."
}
]
},
"reverse-ddns": {
"ddns-domains": [
{
"dns-servers": [
{
"ip-address": "192.168.20.114",
"port": 53
}
],
"name": "2.1.10.in-addr.arpa."
},
{
"dns-servers": [
{
"ip-address": "192.168.20.114",
"port": 53
}
],
"name": "0.16.172.in-addr.arpa."
}
]
},
"ip-address": "127.0.0.1",
"ncr-format": "JSON",
"ncr-protocol": "UDP",
"port": 53001,
"loggers": [
{
"severity": "DEBUG",
"debuglevel": 99,
"name": "kea-dhcp-ddns",
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
```
</details>
<details><summary>non-Working DDNS configuration and command line</summary>
Command: `kea-dhcp-ddns -c kea-dhcp-ddns-test-ddns.json`
kea-dhcp-ddns-test-ddns.json
```
{
"DhcpDdns": {
"dns-server-timeout": 40000,
"forward-ddns": {
"ddns-domains": [
{
"dns-servers": [
{
"ip-address": "192.168.20.114",
"port": 53
}
],
"name": "example.org."
}
]
},
"reverse-ddns": {
"ddns-domains": [
{
"dns-servers": [
{
"ip-address": "192.168.20.114",
"port": 53
}
],
"name": "2.1.10.in-addr.arpa."
}
//,
// {
// "dns-servers": [
// {
// "ip-address": "192.168.20.114",
// "port": 53
// }
// ],
// "name": "0.16.172.in-addr.arpa."
// }
]
},
"ip-address": "127.0.0.1",
"ncr-format": "JSON",
"ncr-protocol": "UDP",
"port": 53001,
"loggers": [
{
"severity": "DEBUG",
"debuglevel": 99,
"name": "kea-dhcp-ddns",
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
```
</details>
Perfdhcp was used to create the traffic for this test: `sudo perfdhcp -4 -r 200 -p 1800 -l ens256 -R 200`
BIND will, for some reason, stop responding intermittently during the test. The reason for that is not important for this issue. This was originally reported by a customer using some kind of off premise DNS servers that would intermittently be unavailable due to network issues. If all subnets are configured in the DDNS configuration, then DDNS will not become unresponsive when BIND becomes unresponsive.
This message might appear while BIND is unresponsive:
```DHCP_DDNS_AT_MAX_TRANSACTIONS application has 1024 queued requests but has reached maximum number of 32 concurrent transactions```
but DDNS will recover once BIND recovers.
Using the "non-Working DDNS configuration and command line", the DDNS server cannot recover and is unavailable for the remainder of the test.
The `kea-dhcp-ddns` service must be restarted before it will respond again.
I also tested this with `example.org` removed from the ddns configuration. `kea-dhcp-ddns` did not suffer a stop in processing with that zone removed. It appears to only be in the case of a missing `.arpa` zone.
<details><summary>When the `kea-dhcp-ddns` stops responding, it is during one of these failures to match reverse DNS zone</summary>
```
2024-03-19 16:56:18.347 WARN [kea-dhcp-ddns.dhcp-to-d2/1479.281473066429376] DHCP_DDNS_NO_MATCH No DNS servers match FQDN 149.0.16.172.in-addr.arpa.
2024-03-19 16:56:18.347 ERROR [kea-dhcp-ddns.dhcp-to-d2/1479.281473066429376] DHCP_DDNS_NO_REV_MATCH_ERROR Request ID 000101285974D2A2411A8BCED2CF77E9E97AD8582814F422CD88FD27E2B37B26969C5F: the configured list of reverse DDNS domains does not contain a match for: Type: 1 (CHG_REMOVE)
Forward Change: yes
Reverse Change: yes
FQDN: [myhost-172-16-0-149.example.org.]
IP Address: [172.16.0.149]
DHCID: [000101285974D2A2411A8BCED2CF77E9E97AD8582814F422CD88FD27E2B37B26969C5F]
Lease Expires On: 20240319173614
Lease Length: 2400
Conflict Resolution: yes
The request has been discarded.
```
No further logs are emitted by `kea-dhcp-ddns` until the process is restarted.
</details>
<details><summary>`kea-dhcp4` does not appear to realize anything is amiss</summary>
```
2024-03-19 16:58:41.932 DEBUG [kea-dhcp4.dhcpsrv/1487.281473627656064] DHCPSRV_QUEUE_NCR [hwtype=1 00:0c:01:02:03:23], cid=[01:00:0c:01:02:03:23]: Name change request to remove DNS entry queued: Type: 1 (CHG_REMOVE)
Forward Change: yes
Reverse Change: yes
FQDN: [myhost-10-1-2-131.example.org.]
IP Address: [10.1.2.131]
DHCID: [000101EC31CD9751563A5FD3586A0940AEDE3871AA5D6D952E92D3D5A21E173B5F146C]
Lease Expires On: 20240319173840
Lease Length: 2400
Conflict Resolution: yes
2024-03-19 16:58:41.932 DEBUG [kea-dhcp4.dhcpsrv/1487.281473669656592] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 1 (CHG_REMOVE)
Forward Change: yes
Reverse Change: yes
FQDN: [myhost-10-1-2-131.example.org.]
IP Address: [10.1.2.131]
DHCID: [000101EC31CD9751563A5FD3586A0940AEDE3871AA5D6D952E92D3D5A21E173B5F146C]
Lease Expires On: 20240319173840
Lease Length: 2400
Conflict Resolution: yes
2024-03-19 16:58:41.932 DEBUG [kea-dhcp4.dhcpsrv/1487.281473627656064] DHCPSRV_QUEUE_NCR [hwtype=1 00:0c:01:02:03:23], cid=[01:00:0c:01:02:03:23]: Name change request to add DNS entry queued: Type: 0 (CHG_ADD)
Forward Change: yes
Reverse Change: yes
FQDN: [myhost-10-1-2-131.example.org.]
IP Address: [10.1.2.131]
DHCID: [000101EC31CD9751563A5FD3586A0940AEDE3871AA5D6D952E92D3D5A21E173B5F146C]
Lease Expires On: 20240319173841
Lease Length: 2400
Conflict Resolution: yes
2024-03-19 16:58:41.932 DEBUG [kea-dhcp4.dhcpsrv/1487.281473669656592] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 0 (CHG_ADD)
Forward Change: yes
Reverse Change: yes
FQDN: [myhost-10-1-2-131.example.org.]
IP Address: [10.1.2.131]
DHCID: [000101EC31CD9751563A5FD3586A0940AEDE3871AA5D6D952E92D3D5A21E173B5F146C]
Lease Expires On: 20240319173841
Lease Length: 2400
Conflict Resolution: yes
```
as the log messages appear the same whether `kea-dhcp-ddns` is doing anything or not.
</details>
[SF1804](https://isc.lightning.force.com/lightning/r/Case/500S60000074PjmIAE/view)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3294Deletion of v6 reservation over API by address causes all v6 reservations to ...2024-03-22T09:52:31ZAndrew MulheirnDeletion of v6 reservation over API by address causes all v6 reservations to disappear---
name: Deletion of v6 reservation over API by address causes all v6 reservations to disappear
about: Kea 2.4.1
---
**Describe the bug**
I am using the API to add and remove reservations for v4 and v6.
I find that removing a v4 re...---
name: Deletion of v6 reservation over API by address causes all v6 reservations to disappear
about: Kea 2.4.1
---
**Describe the bug**
I am using the API to add and remove reservations for v4 and v6.
I find that removing a v4 reservation by IP address works as expected, but removing a v6 reservation results in all reservations being deleted.
**To Reproduce**
Steps to reproduce the behavior:
1. Create two v6 reservations in the database
2. send a 'reservation-del' to the dhcp6 process via the API to remove one address
3. run a 'reservation-get-all' and receive the message ```"text": "0 IPv6 host(s) found."```
4. Perform the same sequence with v4 and it succeeds
5. Check the postgres database contents and see that the v6 reservations table is empty
Note that if I do a deletion specifying the flex-id or DUID of a reservation, only that single reservation is removed.
**Expected behavior**
I am expecting that a single IPv6 reservation is deleted.
**Environment:**
- Kea version: 2.4.1
- OS: Ubuntu 22.04.4 LTS
- Installed from kea packages on cloudsmith
- Flex-id, HA, host commands and lease commands are in use.
**Additional Information**
reservation-get-all result over api:
```
[
{
"arguments": {
"hosts": [
{
"client-classes": [],
"flex-id": "67622D6C6F6E39382D7273773030313A78652D302F302F33",
"hostname": "123123.vorboss.lab",
"ip-addresses": [
"2a00:e340:1102::3"
],
"option-data": [],
"prefixes": [
"2a00:e340:1103:300::/56"
],
"subnet-id": 1
},
{
"client-classes": [],
"flex-id": "67622D6C6F6E39382D7273773030313A78652D302F302F34",
"hostname": "123124.vorboss.lab",
"ip-addresses": [
"2a00:e340:1102::4"
],
"option-data": [],
"prefixes": [
"2a00:e340:1103:400::/56"
],
"subnet-id": 1
}
]
},
"result": 0,
"text": "2 IPv6 host(s) found."
}
]
```
Deletion sent:
```
{
"command": "reservation-del",
"service": ["dhcp6"],
"arguments": {
"subnet-id": 1,
"ip-address": "2a00:e340:1102::4"
}
}
```
Debug from kea-ctrl-agent:
```
INFO COMMAND_RECEIVED Received command 'reservation-del'
DEBUG HOOKS_CALLOUTS_BEGIN begin all callouts for hook $reservation_del
INFO HOST_CMDS_RESERV_DEL reservation-del command called (parameters: { "ip-address": "2a00:e340:1102::4", "subnet-id": 1 })
INFO HOST_CMDS_RESERV_DEL_SUCCESS reservation-del command success (parameters: { "ip-address": "2a00:e340:1102::4", "subnet-id": 1 })
DEBUG HOOKS_CALLOUT_CALLED hooks library with index 2 has called a callout on hook $reservation_del that has address 0x7ff2f67cecb0 (callout duration: 3.743 ms)
DEBUG HOOKS_CALLOUTS_COMPLETE completed callouts for hook $reservation_del (total callouts duration: 3.743 ms)
```
Subsequent reservation-get-all:
```
[
{
"arguments": {
"hosts": []
},
"result": 3,
"text": "0 IPv6 host(s) found."
}
]
```
**Contacting you**
My work email is andrew.mulheirn@vorboss.comkea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/32932.5.7 release checklist2024-03-27T15:37:01ZMarcin Godzina2.5.7 release checklist# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of these checks and updates can be made before the actual fr...# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of these checks and updates can be made before the actual freeze. For new stable releases or maintenance releases, please don't use the `kea-dev` build farm; use a dedicated build farm for each release cycle.
1. [x] Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.aws.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/Kea_20Build_20Checks/)
1. [x] Check [Performance Test Results](https://jenkins.aws.isc.org/job/kea-dev/job/performance/lastSuccessfulBuild/artifact/qa-dhcp/kea/performance-jenkins/report.html) in Jenkins for drops in performance.
1. [x] Create a Gitlab issue for bumping up library versions and `KEA_HOOKS_VERSION` and notify developers.
* In case of no developers available, it can be done by running: [./tools/bump-lib-versions.sh](https://gitlab.isc.org/isc-projects/kea/-/blob/master/tools/bump-lib-versions.sh) Kea-q.w.e Kea-a.b.c (where `a.b.c` is the version to be released and `q.w.e` is the version previous to that).
1. [x] Look at the issue numbers in commit descriptions. Add to ChangeLog a mention about any change with visible impact that had not been mentioned already.
1. [x] If any changes have been done to database schemas, then:
1. [x] Check that a previously released schema has not been changed.
1. [x] Check that the additions to `dhcpdb_create.*sql`, and nothing more nor less than what was added in this release, is present in a `upgrade_*_to_*.sh.in` script that should also have been added in this release.
1. [x] Prepare release notes.
1. [x] Create release note on Kea GitLab wiki and notify @tomek. It should be created under the `Release-Notes` directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/Release-Notes/release-notes-2.3.4
1. [x] Finish release notes and conduct its review.
1. [x] Notify support that release notes are ready for review. To avoid conflicts in edits wait with next step after review is done.
1. [x] Notify @sgoldlust or @vicky that release notes are ready for review. Due to time difference please do this at least 36 hours before planned release.
1. [x] Check that packages can be uploaded to cloudsmith.
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick the latest pkg build in the `Packages` field, and the corresponding tarball build in the `Tarball` field, leave the rest as they are `PrivPubRepos: "private"`, `TarballOrPkg: "packages"`, `TestProdRepos: "testing"` and click `Build`.
1. If a new Cloudsmith repository is used, then:
1. [ ] Make sure access tokens have been synchronized from previous Cloudsmith repositories and to the [check-pkgs.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/pkgs-check/check-pkgs.py) QA tool.
1. [x] Check if ReadTheDocs can build Kea documentation. Alternatively, look for failures in emails if you know that the ReadTheDocs webhook is working.
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds) and wait for the build to complete.
The following steps may involve changing files in the repository.
1. [x] Run [update-code-for-release.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/update-code-for-release.py) \
Example command: `GITLAB_TOKEN='...' ./update-code-for-release.py 2.3.4 --repo-dir ~/isc/repos/kea/`. \
Help: `GITLAB_TOKEN='...' ./update-code-for-release.py --help`. \
The script requires an explicit flag for stable and maintenances releases e.g. `--repo-branch v2_4`. \
The script makes the following changes and actions:
1. Runs [prepare_kea_release.sh](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/prepare_kea_release.sh) that:
1. Adds release entries in ChangeLogs.
1. Updates Kea version in configure.ac.
1. Updates copyright years in files that were changed in current year.
1. Sorts message files.
1. Regenerates message files headers.
1. Regenerates parsers using Bison from Docker
1. [x] Run the script again with the `--upload-only` flag which:
1. Creates an issue in GitLab for release changes in kea repo.
1. Creates branches and merge requests for kea and kea-premium.
1. Commits the changes in both repos.
1. Checks out created branches in both repos.
1. Commits and pushes the changes to GitLab server.
1. [x] Check manually User's Guide sections:
1. [x] Chapter 1. Introduction
1. [x] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [x] Did we add any additional 3rd party software? Update if needed.
1. [x] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. [x] Chapter 2. Quick Start
1. [x] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. [x] Chapter 3. Installation
1. [x] Check installation hierarchy (this is also automatically checked at the end of [ut-extended job](https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/)).
1. [x] Check and update Build Requirements.
1. [x] Check configure options against what `./configure -h` says.
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whitespaces, etc.
1. [x] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [x] If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the MR to master.
## Build selection, tarballs upload and sanity checks
This is the last moment to freeze code! :snowflake:
1. [x] Go to [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/) Jenkins job and pick the last tarball built - it will be a release candidate.
1. [x] Check tarball before requesting sanity checks from the development team.
1. Download tarballs from picked Jenkins build
1. Check hook libraries.
1. Are there any new hook libraries installed in this release?
1. Are they in the proper tarball? Premium or subscription?
1. Do they have their own package?
1. Check sizes - is the new package reasonable?
1. Check installation tree, compare it with the previous release
1. Check installed libraries.
1. which were updated? (save results)
1. Do any of the libraries from the current release have lower version than in the previous release?
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if each of the installed binaries has a man page.
1. If not, is the binary included in the tarball? That might explain it.
1. Are man pages up to date?
1. Check if documentation is properly formatted, has correct versions and dates.
1. It's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid.
1. [x] Upload tarballs to repo.isc.org using Jenkins and send sanity checks request.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
1. In field `Release_Candidate` pick:
1. `rc1` if this is the first selected build for release, it will push the selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
1. next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in an error)
1. Submit the job that will automatically:
1. Upload the tarballs.
1. Create a GitLab issue for sanity checks, put the announcement there.
1. Send Sanity Checks announcement on the Kea/DHCP channel on Mattermost.\
The announcement includes:
- a link to chapter 4 Sanity Checks of the release process: [KeaReleaseProcess - SanityChecks](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks)
- a link to the GitLab issue
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
## Releasing Tarballs and Packages
Now it's time to publish the code.
1. [x] Update Release Notes with ChangeLog entries.
1. [x] Mark Jenkins jobs with release artifacts to be kept forever and update description of build by adding there version of released kea (e.g. `Kea-2.3.4`).
1. Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button and edit description:
1. [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/).
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/).
1. [x] Upload final tarballs to repo.isc.org.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
1. In field `Release_Candidate` pick `final`. This job will also:
- Open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) for signing final tarballs on repo.isc.org.
- Create Git tags `Kea-a.b.c` in Kea main and premium repositories.
- Create Gitlab releases `Kea-a.b.c` in Kea main and premium repositories.
1. [x] Sign tarballs with the personal key, by running [sign_kea_and_upload_asc.sh](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/sign_kea_and_upload_asc.sh) which signs, verifies signatures and uploads them.
- If release engineer does NOT have signing key, please contact team member.
1. [x] Confirm that the tarballs have the checksums mentioned on the signing ticket.
1. [x] Wait for clearance from Security Officer to proceed with the public release (if applicable). If this is a security release, next steps will be impacted by CVE checklist.
1. [x] Login to repo.isc.org and upload final tarball to public ftp using the make-available script.
* Example command: `make-available --public --symlink=cur/2.3 /data/shared/sweng/kea/releases/2.3.4`.
* [x] For premium tarballs use `--private` option.
* For more information use `--debug` option.
* To overwrite existing content, use `--force` option.
* If you did a mistake, contact ASAP someone from the ops team to remove incorrectly uploaded tarballs.
* [x] save links to all premium tarballs and put them into signing ticket as a comment.
1. [x] Upload final RPM & DEB packages, tarballs and sign files to cloudsmith.io:
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick your selected pkg build in the `Packages` field, the corresponding tarball build in the `Tarball` field, `PrivPubRepos: "both"`, `TarballOrPkg: "both"`, `TestProdRepos: "production"` and click `Build`.
- This step also verifies sign files.
1. When it finishes run check: [releases-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/).
1. [x] Check that Docker images can be uploaded to Cloudsmith. Run [build-upload-docker](https://jenkins.aws.isc.org/job/kea-dev/job/build-upload-docker/).
* Make sure the right package job is selected under `Packages`.
* Tick `Upload`.
* Leave `TestProdRepos` to `testing`.
* Leave `versionTag` ticked.
* Tick `latestTag` if this is a stable or a maintenance release.
* If this is a stable or maintenance release, change `KeaDockerBranch` to the appropriate branch.
* Press `Build`.
1. [x] Build and upload Docker images to Cloudsmith. Run [build-upload-docker](https://jenkins.aws.isc.org/job/kea-dev/job/build-upload-docker/) with the same actions as above except change `TestProdRepos` to `production`.
1. [x] Update ReadTheDocs:
1. Trick ReadTheDocs into pulling the latest tags. Click `Build version` on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. If it's a stable release, change the default version to point to this stable release. `Admin -> Advanced Settings -> Default version* -> Kea-a.b.c`.
1. [x] Create an issue and a merge request to bump up Kea version in `configure.ac` to next development version which could be, based on just released version `a.b.c`:
* `a.b.z-git` where `z == c + 1` most of the time, or
* `a.y.0-git` where `y == b + 2` if a new development series starts, or
* `x.1.0-git` where `x == a + 1` when the released minor version `b` is 9 and `a.b.c` was the last version in the development series and a new development version is coming up next.
1. [x] Contact Marketing team, and find a member who will continue work on this release:
1. [ ] Assign this ticket to person who will continue.
1. [x] Share link to signing ticket either directly or as a comment in this issue.
## Marketing
1. [x] Publish links to downloads on ISC website.
1. [ ] Update the supported versions document in the Salesforce portal (if there are stable versions released), and update the Kea document in the portal.
1. [ ] If it is a new `major.minor` version, SWENG will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Verify that the KB on installing from Cloudsmith has also been updated, then update the Kea document in the SF portal and notify support customers that this new private repo exists.
1. [ ] If a new Cloudsmith repository is used, make sure that the Zapier scripts are updated.
* If those are not updated, there was an error made during preparation for new stable release. Please contact QA team and coordinate fix.
1. [x] Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version.
1. [x] Write release email to _kea-announce_.
1. [ ] Write email to _kea-users_ (if a major release).
1. [ ] Announce on social media.
1. [x] Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea\_(software)).
1. [ ] Write blog article (if a major release).
1. [ ] Update [Kea page on website if any new hooks](https://www.isc.org/kea/).
1. [ ] Update Kea Premium and Kea Subscription data sheets if any new hooks.
1. [ ] Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
1. [ ] Contact Support team, find a person who will continue this release and assign this issue to them.
## Support
1. [x] Update tickets in case of waiting for support customers.
1. [ ] Close this ticketkea2.5.7https://gitlab.isc.org/isc-projects/kea/-/issues/3290Clarify application of the ha-scopes command in the actual deployments2024-03-14T15:02:26ZMarcin GodzinaClarify application of the ha-scopes command in the actual deployments`ha-scopes` command can modify servers scopes without changing its role and other HA parameters.
It can be a powerful tool, but its use can put the server in a state that will be very confusing for the Administrator.
I think this comman...`ha-scopes` command can modify servers scopes without changing its role and other HA parameters.
It can be a powerful tool, but its use can put the server in a state that will be very confusing for the Administrator.
I think this command requires more documentation and warnings about its usage.
For example: \
We have a hot standby pair and send the `ha-scopes` command to the `standby` server, enabling scopes of both servers.
This results in `primary` and `standby` servers replying to DHCP traffic. But the second server still reports as in a `standby` state.
This can lead to massive confusion for Administrators.kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3289DHCPv4: bad option 81 data (invalid FQDN) causes halt in further processing o...2024-03-14T15:00:06ZDarren AnkneyDHCPv4: bad option 81 data (invalid FQDN) causes halt in further processing of packetA packet with option 81 attached with an empty label causes further processing of the client's DHCPv4 packet to cease and the packet to be dropped.
This is very simple to reproduce with the following
<details><summary>Simple configurat...A packet with option 81 attached with an empty label causes further processing of the client's DHCPv4 packet to cease and the packet to be dropped.
This is very simple to reproduce with the following
<details><summary>Simple configuration</summary>
```
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [
"ens256"
]
},
"lease-database": {
"type": "memfile",
"persist": false
},
"calculate-tee-times": true,
"option-data": [
{
"name": "domain-name-servers",
"data": "10.0.0.1"
}
],
"subnet4": [
{
"subnet": "10.1.2.0/24",
"id": 1,
"option-data": [
{
"name": "routers",
"data": "10.1.2.1"
}
],
"pools": [
{
"pool": "10.1.2.100-10.1.2.200"
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"severity": "DEBUG",
"debuglevel": 99,
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
```
</details>
and sending packets with malformed FQDN using `perfdhcp`:
```
perfdhcp -4 -r 1 -p 10 -l ens256 -R 1 -o 81,0100002E656D7074792E6C6162656C2E6578616D706C652E636F6D
```
<details><summary>Messages like this are logged</summary>
```
2024-03-13 11:21:28.124 DEBUG [kea-dhcp4.packets/52340.281473684041744] DHCP4_BUFFER_RECEIVED received buffer from 10.1.2.6:67 to 255.255.255.255:67 over interface ens256
2024-03-13 11:21:28.124 DEBUG [kea-dhcp4.options/52340.281473642041216] DHCP4_BUFFER_UNPACK parsing buffer received from 10.1.2.6 to 255.255.255.255 over interface ens256
2024-03-13 11:21:28.124 DEBUG [kea-dhcp4.bad-packets/52340.281473642041216] DHCP4_PACKET_DROP_0001 failed to parse packet from 10.1.2.6 to 255.255.255.255, received over interface ens256, reason: failed to parse the domain-name in DHCPv4 Client FQDN Option: non terminating empty label in .empty.label.example.com, hwaddr=00:0c:01:02:03:04
```
</details>
Clients with such incorrect FQDNs in option 81 are not able to get an IP address. Option 81 content from such clients is probably not useable and should perhaps be ignored but the client should still get an IP address possibly? This type of error in option 81 was allowed in ISC DHCP and so this is a problem for those migrating to Kea from ISC DHCP.
Attached a pcap of the DHCP packets generated by `perfdhcp`: [fqdn-test.pcap](/uploads/810d5aa88d78f58f1c4b39d6b1eec3d1/fqdn-test.pcap)
[SF1790](https://isc.lightning.force.com/lightning/r/Case/500S6000006lxqtIAA/view)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3288add couple sentences describing what tools/kea-breeder/kb.py does and why2024-03-14T14:58:34ZWlodzimierz Wenceladd couple sentences describing what tools/kea-breeder/kb.py does and whyExtend help message or just add comments to explain what is the purpose of `tools/kea-breeder/kb.py` scriptExtend help message or just add comments to explain what is the purpose of `tools/kea-breeder/kb.py` scriptkea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3286Allow absolute values for DDNS RR TTLs (to correctly meet RFC 4702, Section 5)2024-03-21T14:54:27ZRobin EdserAllow absolute values for DDNS RR TTLs (to correctly meet RFC 4702, Section 5)We are currently preparing a migration from `dhcpd` to Kea and are struggling a bit with DNS TTLs for DDNS entries created with Kea. We have a requirement from the organisation to have our default lease time be `2 days` / `172800 seconds...We are currently preparing a migration from `dhcpd` to Kea and are struggling a bit with DNS TTLs for DDNS entries created with Kea. We have a requirement from the organisation to have our default lease time be `2 days` / `172800 seconds`, but in combination with a short TTL of `300 seconds` because our Juniper firewall rules are almost entirely name based.
Since Kea only calculates the TTL we are currently having to set `ddns-ttl-percent` to `.00174` to get a `301 second` TTL. However since we are setting this globally, the result is that any client classes where we explicitly want much shorter lease than the default to get a `1 second` TTL.
RFC 4702, Section 5 does also mention that TTLs should also be configurable as an absolute time interval:
> We recognize that individual administrators
will have varying requirements: DHCP servers and clients SHOULD allow
administrators to configure TTLs and upper and lower bounds on the
TTL values, either as an absolute time interval or as a percentage of
the lease time.
This is something that would be ideal for us and hopefully useful for others. I hope it can be considered.
Thank you to the Kea devs and ISC for all your hard work :heart:next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3283CableLabs option (RFC3495): Inconsistent "option_def" usage in client class d...2024-03-28T17:32:26ZPeter DaviesCableLabs option (RFC3495): Inconsistent "option_def" usage in client class definitionsInconsistent "option_def" usage in client class definitions:
Using Kea 2.5.6 - I have yet to try with 2.4.1.
The following "option-def" statement is accepted in the global scope of a
configuration file:
```
...
"opt...Inconsistent "option_def" usage in client class definitions:
Using Kea 2.5.6 - I have yet to try with 2.4.1.
The following "option-def" statement is accepted in the global scope of a
configuration file:
```
...
"option-def": [ {
"name": "Option_122", "code": 122, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" }
],
...
```
However, if this "option-def" is defined within a client class as:
```
...
"client-classes": [{
"name": "Docsis_Class", "test": "substring(option[60].hex,0,6) == 'docsis'",
"option-def": [ {
"name": "Option_122", "code": 122, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" } ],
"option-data": [ {
"name": "Option_122_1", "data": "10.0.0.68", "code": 1, "space": "Option_122_Space" }, {
"name": "Option_122_2", "data": "10.0.0.69", "code": 2, "space": "Option_122_Space" } ]
}],
...
```
The following message is generated, and Kea exits:
```
Error encountered: Not allowed option definition for code '122' in space 'dhcp4'
```
If the "Option_122" "option-def" is changed to private option "224" as:
```
...
"client-classes": [{
"name": "Docsis_Class", "test": "substring(option[60].hex,0,6) == 'docsis'",
"option-def": [ {
"name": "Option_122", "code": 224, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" } ],
"option-data": [ {
"name": "Option_122_1", "data": "10.0.0.68", "code": 1, "space": "Option_122_Space" }, {
"name": "Option_122_2", "data": "10.0.0.69", "code": 2, "space": "Option_122_Space" } ]
}],
...
```
Then the following error is generated, and Kea exits:
```
Error encountered: Not allowed option definition for code '1' in space 'Option_122_Space'
```
[SF00001775](https://isc.lightning.force.com/lightning/r/Case/500S6000006TLtj/view)kea2.5.8