ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-10-23T11:04:48Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1436Document DHCPv6 options set by Kea2020-10-23T11:04:48ZTomek MrugalskiDocument DHCPv6 options set by KeaThere's a long list of v6 options that Kea supports, but they're not listed as supported, because they can't be configured explicitly. However, support requested a documentation for similar options in v4 (see #1323) and @tomek added it. ...There's a long list of v6 options that Kea supports, but they're not listed as supported, because they can't be configured explicitly. However, support requested a documentation for similar options in v4 (see #1323) and @tomek added it. We should have a similar list for v6.
It's actually easy to do: checkout old branch (e.g. v1_4_0) and look at doc/guide/dhcp6-srv.xml for comments around line 1344.kea1.9.1https://gitlab.isc.org/isc-projects/kea/-/issues/1435Backport #1431 (remove mutli-threading experimental message)2020-11-27T06:38:00ZTomek MrugalskiBackport #1431 (remove mutli-threading experimental message)We should remove the experimental message from 1.8.x branch.We should remove the experimental message from 1.8.x branch.kea1.8.1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1434HA hook with mysql backend not working2020-11-05T16:25:38ZMichal HynekHA hook with mysql backend not workingHello, I Have problem with HA (in my case hot-standby). Server is unable to sync leases.
```
2020-09-25 09:51:32.806 DEBUG [kea-dhcp4.dhcpsrv/34387.140540437956480] DHCPSRV_MYSQL_GET_ADDR4 obtaining IPv4 lease for address 100.104.3.2
202...Hello, I Have problem with HA (in my case hot-standby). Server is unable to sync leases.
```
2020-09-25 09:51:32.806 DEBUG [kea-dhcp4.dhcpsrv/34387.140540437956480] DHCPSRV_MYSQL_GET_ADDR4 obtaining IPv4 lease for address 100.104.3.2
2020-09-25 09:51:32.806 DEBUG [kea-dhcp4.dhcpsrv/34387.140540437956480] DHCPSRV_MYSQL_UPDATE_ADDR4 updating IPv4 lease for address 100.104.3.2
2020-09-25 09:51:32.806 WARN [kea-dhcp4.ha-hooks/34387.140540437956480] HA_LEASE_SYNC_FAILED synchronization failed for lease: { "cltt": 1600979173, "fqdn-fwd": true, "fqdn-rev": true, "hostname": "lt_pohorany_137_eap1", "hw-address": "c4:ad:34:ce:99:64", "ip-address": "100.104.3.2", "state": 0, "subnet-id": 10010400, "valid-lft": 432000 }, reason: unable to update lease for address 100.104.3.2 as it does not exist
```
mysql debug:
```
2020-09-25T07:51:32.806428Z 370 Execute SELECT address, hwaddr, client_id, valid_lifetime, expire, subnet_id, fqdn_fwd, fqdn_rev, hostname, state, user_context FROM lease4 WHERE address = 1684538114
2020-09-25T07:51:32.806540Z 370 Execute UPDATE lease4 SET address = 1684538114, hwaddr = 'ĭ4Ιd', client_id = NULL, valid_lifetime = 432000, expire = '2020-09-29 22:26:13', subnet_id = 10010400, fqdn_fwd = 1, fqdn_rev = 1, hostname = 'lt_pohorany_137_eap1', state = 0, user_context = NULL WHERE address = 1684538114 AND expire = '1970-01-01 01:00:00'
```
you can see it tries to match weird expire value '1970-01-01 01:00:00' but in database is:
```
mysql> SELECT * FROM dhcp.lease4 WHERE address=1684538114;
+------------+--------+-----------+----------------+---------------------+-----------+----------+----------+----------------------+-------+--------------+
| address | hwaddr | client_id | valid_lifetime | expire | subnet_id | fqdn_fwd | fqdn_rev | hostname | state | user_context |
+------------+--------+-----------+----------------+---------------------+-----------+----------+----------+----------------------+-------+--------------+
| 1684538114 | ĭ4Ιd | NULL | 432000 | 2020-09-27 10:26:13 | 10010400 | 1 | 1 | lt_pohorany_137_eap1 | 0 | NULL |
+------------+--------+-----------+----------------+---------------------+-----------+----------+----------+----------------------+-------+--------------+
1 row in set (0.00 sec)
```
Time is synchronized on both server. Same timezone selected.
**Expected behavior**
- Lease on remote site will update
**Environment:**
- Kea version: 1.8.0 + libdhcp_lease_cmds + libdhcp_ha
- OS: Debian x64
- Mysql server: 5.7.31 (Percona Server)kea1.9.1Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1433hammer: problem with building centos 8 and passing attempts argument2021-05-04T10:55:36ZMichal Nowikowskihammer: problem with building centos 8 and passing attempts argumentkea1.9.0Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/414Partner down in Kea HA is reported awkwardly2022-11-16T11:54:51ZTomek MrugalskiPartner down in Kea HA is reported awkwardlyHere's what I did:
1. started demo as usual `rake docker_up`
1. added agent-kea-ha1, agent-kea-ha2
1. used traffic generator to stop kea-dhcp4 on agent-kea-ha2
1. After a while this was shown in the dashboard:
![stork-partner-down](/up...Here's what I did:
1. started demo as usual `rake docker_up`
1. added agent-kea-ha1, agent-kea-ha2
1. used traffic generator to stop kea-dhcp4 on agent-kea-ha2
1. After a while this was shown in the dashboard:
![stork-partner-down](/uploads/8c3fa57bbcb46f66136c670cb172648b/stork-partner-down.png)
The problem is "Detected failure w/HA" for agent-kea-ha2. It says "never".
This is not a major problem, more like confusion. The HA state correctly says "partner down", so there's indication. It's just one column contradicts another.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1432hammer: building centos 8 fails due to network issues2021-05-04T10:55:36ZMichal Nowikowskihammer: building centos 8 fails due to network issuessolution: add retries on network operationssolution: add retries on network operationskea1.9.0Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2186rndc thaw does not correctly process zone changes2022-03-01T09:47:44ZJean-Christophe Manciotrndc thaw does not correctly process zone changes- Debian bullseye
- bind9 9.17.5
For instance, when changing $TTL from 604800 (1 week) to 3600 in ```/etc/bind/db.sdxlive.com```, when no RR (other than SOA) has a defined TTL:
```
# rndc freeze sdxlive.com
in /etc/bind/zone-file:
$TTL ...- Debian bullseye
- bind9 9.17.5
For instance, when changing $TTL from 604800 (1 week) to 3600 in ```/etc/bind/db.sdxlive.com```, when no RR (other than SOA) has a defined TTL:
```
# rndc freeze sdxlive.com
in /etc/bind/zone-file:
$TTL 604800 --> $TTL 3600
# rndc thaw sdxlive.com
```
Most RRs keep their original TTL:
```
# bind-get-all-resource-records.sh sdxlive.com|grep " 604800 "
zone sdxlive.com/IN: loaded serial 2020092411 (DNSSEC signed)
OK
sdxlive.com. 604800 IN NS ns1.sdxlive.com.
sdxlive.com. 604800 IN RRSIG NS 13 2 604800 20201011132540 20200911124442 33345 sdxlive.com. WgQwG0FpqPOPiTZKi65qn01Fe4g3qRkQ0OybOLawl7PlWWKc9XdYMTwf 7AP3c/fKnE0l0BujSSir8HKf4IBVjw==
sdxlive.com. 604800 IN A 176.139.106.168
sdxlive.com. 604800 IN RRSIG A 13 2 604800 20201011132540 20200911124442 33345 sdxlive.com. sqeyUzMxZ6JlK+hr6XlLKBJHAZmmVo+ku8oElfuc+6rH8Cr+uKNovK6F Awu76tmcURpR5grYDA0vsC5Cl3B0aQ==
sdxlive.com. 604800 IN MX 1 mail.sdxlive.com.
sdxlive.com. 604800 IN RRSIG MX 13 2 604800 20201011132540 20200911124442 33345 sdxlive.com. xZiYSxYb4gX3e2ZbcC2cmEHT7IKUT/c+wil3ZioViRsW+4RLH/LAJ6Mp eC9+ooWgN7jjArM4EvEQCl6xkuln3Q==
and so on...
```
Same issue if I begin with a ```rndc sync -clean sdxlive.com``` before the zone freeze.
Am I missing something?Not plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/1431Misleading multithread msg being generated on startup2020-11-04T20:08:17ZPeter DaviesMisleading multithread msg being generated on startupKea 1.8.0
When multithreading is enabled Kea logs the following message:
DHCP4_MULTI_THREADING_WARNING The multi-threading feature is experimental. Don't use in production environment." is multi-threading still a experimental feature?
T...Kea 1.8.0
When multithreading is enabled Kea logs the following message:
DHCP4_MULTI_THREADING_WARNING The multi-threading feature is experimental. Don't use in production environment." is multi-threading still a experimental feature?
This text ought to be amended.kea1.9.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2185nsdname-wait-recurse speed test fails under tsan2020-10-02T08:38:18ZMark Andrewsnsdname-wait-recurse speed test fails under tsan```
7640I:rpzrecurse:checking 'nsdname-wait-recurse no' is faster than 'nsdname-wait-recurse yes' (72)
7641I:rpzrecurse:timing 'nsdname-wait-recurse yes' (default)
7642I:rpzrecurse:elapsed time 0 seconds
7643I:rpzrecurse:timing 'nsdname-...```
7640I:rpzrecurse:checking 'nsdname-wait-recurse no' is faster than 'nsdname-wait-recurse yes' (72)
7641I:rpzrecurse:timing 'nsdname-wait-recurse yes' (default)
7642I:rpzrecurse:elapsed time 0 seconds
7643I:rpzrecurse:timing 'nsdname-wait-recurse no'
7644I:rpzrecurse:elapsed time 0 seconds
7645I:rpzrecurse:failed
```October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/stork/-/issues/413Stork not pulling lease stats for DHCP42023-03-15T16:52:51ZleecgenesisStork not pulling lease stats for DHCP4---
name: Stork not pulling lease stats for DHCP4
about: Stork colocated on a single kea-dhcp4/6 host running Kea 1.8.0 and Stork 0.11 is not reporting DHCP4 lease statistics.
---
**Describe the bug**
I have a single DHCP VM built with...---
name: Stork not pulling lease stats for DHCP4
about: Stork colocated on a single kea-dhcp4/6 host running Kea 1.8.0 and Stork 0.11 is not reporting DHCP4 lease statistics.
---
**Describe the bug**
I have a single DHCP VM built with Kea version 1.8.0 and Stork 0.11 running on CentOS 7 using prebuilt packages. It's sole purpose is to serve as a DHCP helper for a small regional network. It's currently got 3 IPv4 ranges and 4 IPv6 ranges. The IPv4 ranges contain approximately 1000 IPv4 addresses, and the IPv6 ranges are /64's with prefix delegation handing out /56's from a larger /48 block.
Stork is working fine, on non-standard ports, however the DHCP4 statistics never report. IPv6 statistics, including leases AND prefix-delegations report just fine. Looking at the stdout for the isc-stork-server process, I see the following repeating errors every minute:
statspuller.go:59 missing key total-addreses in LocalSubnet 4 stats
statspuller.go:59 missing key total-addreses in LocalSubnet 5 stats
statspuller.go:59 missing key total-addreses in LocalSubnet 6 stats
Additionally,
**To Reproduce**
Steps to reproduce the behavior:
1. Install Kea 1.8.0, Stork 0.11 from package manager in CentOS 7.
2. Configure kea-ctrl-agent, kea-dhcp4, kea-dhcp6, and agent.env, server.env as attached.
3. DHCP Processes work, clients receive addresses and IPv6 Prefix Delegations.
4. Kea functions as expected.
5. Stork does NOT display DHCP4 statistics, DOES display DHCP6 statistics.
**Expected behavior**
I expect stork to display both DHCP4 and DHCP6 statistics for all discovered ranges.
**Environment:**
- Kea version: 1.8.0
- Stork: 0.11.0
- OS: CentOS 7.8
- Kea: Using MySQL backend, but memfile and PSQL backend also compiled in.
- Kea: Using libdhcp_stat_cmds.so and libdhcp_lease_cmds.so on both DHCP4 and DHCP6.
[agent.env](/uploads/d8037ffb05b4d499d03d5114cd04d819/agent.env)
[kea-ctrl-agent.conf](/uploads/f5c4d0cfeca2c8f72c17160f842bc189/kea-ctrl-agent.conf)
[kea-dhcp4.conf](/uploads/56f052faff28a147b0ca5f0dddbcb249/kea-dhcp4.conf)
[kea-dhcp6.conf](/uploads/91598b56fcd21981d1a9da2cf27a7524/kea-dhcp6.conf)
[server.env](/uploads/6e79c09f7caa83e28275697779c5f8da/server.env)0.13Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2184Add RFC8906 to list of RFCs in doc/arm/general.rst2020-09-24T11:55:10ZSuzanne GoldlustAdd RFC8906 to list of RFCs in doc/arm/general.rstNow that RFC8906 has been officially accepted/published, I want to add it to the list of RFCs in the ARM.Now that RFC8906 has been officially accepted/published, I want to add it to the list of RFCs in the ARM.October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/kea/-/issues/1430flex_option should be able to generate option data according to a specified p...2020-09-28T12:47:01ZRazvan Becheriuflex_option should be able to generate option data according to a specified patternkea1.9.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1429hammer: add support for building kea on Alpine 3.122021-05-04T10:55:36ZMichal Nowikowskihammer: add support for building kea on Alpine 3.12kea1.9.1Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1428Multiple reservations for the same IP2022-10-25T13:30:06ZTomek MrugalskiMultiple reservations for the same IPA new use case has been brought to our attention. A new device with two NICs is being powered. Each NIC has its own MAC address. However, at any given time only one of those NICs is connected and powered up. Sadly, it's not possible to d...A new use case has been brought to our attention. A new device with two NICs is being powered. Each NIC has its own MAC address. However, at any given time only one of those NICs is connected and powered up. Sadly, it's not possible to determine this a'priori which interface will be connected. The intention here to have the same IP address assigned, regardless which NIC will be used.
Under normal circumstances, it is a configuration error to have more than one reservation for the same IP. However, the use case above provides an external constraint that ensures this conflict will never be observed, as there is always only one of the two reservations that will be in use.
The goal of this ticket is to make such operation possible.
While we will start this work in %"kea1.9.0", given the imminent code freeze this Friday, the solution will likely be available in %"kea1.9.1"
[Support ticket #17096](https://support.isc.org/Ticket/Display.html?id=17096)kea1.9.1Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2183DNS Flag Day 20202022-04-26T13:13:00ZOndřej SurýDNS Flag Day 2020This is a issue to make the necessary changes for DNS Flag Day 2020.This is a issue to make the necessary changes for DNS Flag Day 2020.October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/1427bump up library versions and HOOKS_VERSION if needed (kea 1.9.0 release)2020-09-23T12:07:48ZMichal Nowikowskibump up library versions and HOOKS_VERSION if needed (kea 1.9.0 release)if not needed, please close this issueif not needed, please close this issuekea1.9.0https://gitlab.isc.org/isc-projects/kea/-/issues/14261.9.0 release changes2021-05-04T10:55:36ZMichal Nowikowski1.9.0 release changeskea1.9.0Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2182statschannel python test leave no forensic traces to work out what went wrong.2023-11-02T17:00:03ZMark Andrewsstatschannel python test leave no forensic traces to work out what went wrong.Job [#1177271](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1177271) failed for 7a822740e09fd56900383d35889892827dcf94c6:Job [#1177271](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1177271) failed for 7a822740e09fd56900383d35889892827dcf94c6:Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2181Follow-up from "Draft: Resolve "ThreadSanitizer: lock-order-inversion (potent...2021-03-04T14:18:10ZMark AndrewsFollow-up from "Draft: Resolve "ThreadSanitizer: lock-order-inversion (potential deadlock) in pthread_mutex_lock""The following discussion from !4150 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4150#note_164756): (+7 comments)
> Since this is the destroy code protected b...The following discussion from !4150 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4150#note_164756): (+7 comments)
> Since this is the destroy code protected by the reference counter, why do we need the lock at all here?https://gitlab.isc.org/isc-projects/bind9/-/issues/2180ThreadSanitizer: data race bin/named/server.c:9678:25 in view_loaded2020-09-30T14:49:25ZOndřej SurýThreadSanitizer: data race bin/named/server.c:9678:25 in view_loaded```
WARNING: ThreadSanitizer: data race
Write of size 4 at 0x000000000001 by thread T1:
#0 view_loaded bin/named/server.c:9678:25
#1 call_loaddone lib/dns/zt.c:308:3
#2 doneloading lib/dns/zt.c:582:3
#3 zone_asyncload l...```
WARNING: ThreadSanitizer: data race
Write of size 4 at 0x000000000001 by thread T1:
#0 view_loaded bin/named/server.c:9678:25
#1 call_loaddone lib/dns/zt.c:308:3
#2 doneloading lib/dns/zt.c:582:3
#3 zone_asyncload lib/dns/zone.c:2322:3
#4 dispatch lib/isc/task.c:1152:7
#5 run lib/isc/task.c:1344:2
Previous read of size 4 at 0x000000000001 by thread T2:
#0 named_server_status bin/named/server.c:11903:14
#1 named_control_docommand bin/named/control.c:272:12
#2 control_command bin/named/controlconf.c:390:17
#3 dispatch lib/isc/task.c:1152:7
#4 run lib/isc/task.c:1344:2
Location is heap block of size 409 at 0x000000000011 allocated by main thread:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:713:8
#2 mem_get lib/isc/mem.c:622:8
#3 mem_allocateunlocked lib/isc/mem.c:1268:8
#4 isc___mem_allocate lib/isc/mem.c:1288:7
#5 isc__mem_allocate lib/isc/mem.c:2453:10
#6 isc___mem_get lib/isc/mem.c:1037:11
#7 isc__mem_get lib/isc/mem.c:2432:10
#8 named_server_create bin/named/server.c:9978:27
#9 setup bin/named/main.c:1256:2
#10 main bin/named/main.c:1523:2
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
SUMMARY: ThreadSanitizer: data race bin/named/server.c:9678:25 in view_loaded
```October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Mark AndrewsMark Andrews