ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-01-02T15:56:26Zhttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/59remove debug output before 0.3 release2024-01-02T15:56:26ZDarren Ankneyremove debug output before 0.3 releaseremove these debug messages of the `_GET` and `_POST` content
```
Tue Jan 2 10:02:03 2024] [::1]:57852 [200]: POST /?validate=true&form=ReservationSetupForm
[Tue Jan 2 10:02:03 2024] [::1]:57852 Closing
[Tue Jan 2 10:36:33 2024] [::1]...remove these debug messages of the `_GET` and `_POST` content
```
Tue Jan 2 10:02:03 2024] [::1]:57852 [200]: POST /?validate=true&form=ReservationSetupForm
[Tue Jan 2 10:02:03 2024] [::1]:57852 Closing
[Tue Jan 2 10:36:33 2024] [::1]:58130 Accepted
_GET:
Array
(
[validate] => true
[form] => SharedNetworkSetupForm
)
_POST:
Array
(
[ConfType] => dhcp4
)
[Tue Jan 2 10:36:33 2024] [::1]:58130 [200]: POST /?validate=true&form=SharedNetworkSetupForm
[Tue Jan 2 10:36:33 2024] [::1]:58130 Closing
[Tue Jan 2 10:36:34 2024] [::1]:58131 Accepted
_GET:
Array
(
[validate] => true
[form] => SubnetSetupForm
)
_POST:
Array
(
[ConfType] => dhcp4
)
[Tue Jan 2 10:36:34 2024] [::1]:58131 [200]: POST /?validate=true&form=SubnetSetupForm
[Tue Jan 2 10:36:34 2024] [::1]:58131 Closing
[Tue Jan 2 10:36:35 2024] [::1]:58132 Accepted
_GET:
Array
(
[validate] => true
[form] => LoggerSetupForm
)
_POST:
Array
(
[ConfType] => dhcp4
)
[Tue Jan 2 10:36:35 2024] [::1]:58132 [200]: POST /?validate=true&form=LoggerSetupForm
[Tue Jan 2 10:36:35 2024] [::1]:58132 Closing
[Tue Jan 2 10:36:38 2024] [::1]:58133 Accepted
[Tue Jan 2 10:36:38 2024] [::1]:58133 [200]: POST /?SHOWCONF=true
[Tue Jan 2 10:36:38 2024] [::1]:58133 Closing
```0.3https://gitlab.isc.org/isc-projects/bind9/-/issues/4505Implement kTLS support in BIND2024-02-14T17:13:53ZArtem BoldarievImplement kTLS support in BIND
Recent versions of Linux and FreeBSD support TLS encryption by kernel (kTLS). One of the benefits of it is that when TLS encryption is performed by kernel, it might use additional hardware features otherwise not available in the user sp...
Recent versions of Linux and FreeBSD support TLS encryption by kernel (kTLS). One of the benefits of it is that when TLS encryption is performed by kernel, it might use additional hardware features otherwise not available in the user space, including offloading TLS encryption to the NICs that support that (e.g. [NVIDIA Mellanox ConnectX-6 Dx](https://www.nvidia.com/en-us/networking/ethernet/connectx-6-dx/)), almost completely freeing the CPU from this task, because even in the case of hardware acceleration of encryption within the CPU, it still requires some cycles from it. Also, using it might reduce memory copying in some cases.
Of course, kernel space encryption is more limited compared to the one provided by OpenSSL and its derivatives in the user space: these limitations are imposed by hardware - e.g. NICs might not support anything but AES 128 (aka `TLS_AES_128_GCM_SHA256`), as it is the only cipher mandatory for TLS v1.3). If it is good enough for WEB servers, it should be good enough for DNS, too.
Even when kTLS is used, the handshake itself happens in the user space (e.g. using OpenSSL) with negotiated parameters passed to the kernel using `setsockopt()` calls on a TCP socket descriptor.
OpenSSL provides support for kTLS encryption natively since version 3.X (see `SSL_OP_ENABLE_KTLS` [option](https://www.openssl.org/docs/manmaster/man3/SSL_set_options.html)) but, as far as I understand it, it does so only when OpenSSL manages the underlying TCP socket file descriptor natively: not our case, as we are using LibUV for that. However, considering that the idea of kTLS is that with it enabled, we are supposed to pass unencrypted data to `send()` and `recv()`, that is kTLS-enabled socket from the higher level perspective works (mostly) as a TCP socket, we might try the following approach to implement kTLS, that *might* work:
1. We use our existing code (`tlsstream.c`) to handle handshake, just like we do now;
2. After completing the handshake, we pass the negotiated information to the kernel. OpenSSL might have some interfaces for that. In the worst case, we might need to do that by hand using. `setsockopt()`;
3. Then, we add new code paths to `tlsstream.c` to bypass TLS connection objects (`isc_tls_t`) and use the underlying TCP connection directly, which, by now, works in "kTLS-mode", providing transparent TLS encryption;
4. Control messages, like TLS shutdown, will require additional care.
That is how I see the initial plan that might or might not work. There can (and, likely, will) be unforeseen obstacles that might turn out to overcomplicate the code base so much that it might make it unfeasible to implement, like adding a kTLS-only transport. Furthermore, that might require some assistance from LibUV. That will require some trial and error.
That is mostly written with Linux in mind. If the kTLS interface in FreeBSD is similar enough (it seems so at the first glance), we should support both platforms.
The issue is created mostly to dump the information from my mind and keep kTLS under our radar: we might want to do that, as at least `dnsdist` has experimental support for it. It will be even more important in the future, as it seems now that encrypted DNS transport will be even more important to the point of replacing the good ol' Do53 at some point.
For sure, it is not a 9.20 material - rather 9.21-9.22 if we are lucky, as it is a big feature. Also, I foresee a similar concept eventually appearing for QUIC, too (kQUIC?). Also, I am aquiet certain that we *will* need #3504 for this (implemented here: !8576).
See also:
1. https://docs.kernel.org/networking/tls.html
2. https://man.freebsd.org/cgi/man.cgi?query=ktls&apropos=0&sektion=0&manpath=FreeBSD+13.0-RELEASE+and+Ports&arch=default&format=html
3. https://delthas.fr/blog/2023/kernel-tls/ - mostly discusses it in the context of HTTP and `sendfile()` acceleration, but contains many references on the topic.
4. https://docs.nvidia.com/networking/display/ofedv512580/kernel+transport+layer+security+(ktls)+offloadsLong-termArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4503Possible pytest RNDC interface improvements2023-12-21T18:03:30ZŠtěpán BalážikPossible pytest RNDC interface improvementsReview of !8357, which provides a first cut of the pytest RNDC interface, shown multiple suggestion for possible improvements.
I am now dumping them here in a form of checklist so they don't get buried in the now resolved MR comments:
...Review of !8357, which provides a first cut of the pytest RNDC interface, shown multiple suggestion for possible improvements.
I am now dumping them here in a form of checklist so they don't get buried in the now resolved MR comments:
- [ ] Find a way to the the `*.in` files templating in pure Python. This is needed for the elimination of the `setup.sh` scripts. This will probably require depending on `jinja` explicitly.
- [ ] Add an "rndc null" before every reconfiguration to show which file is used (NamedInstance.add_mark_to_log() as it may be generically useful?)
- [ ] Extend `NamedInstance` with some kind of `query` method. This is needed as a replacement for the calls to `dig` which are common in system tests.
- [ ] There are now two objects representing the ports used in tests: dictionary returned by the `ports` fixture and the new `NamedPorts` class. Unify them. Discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8357#note_411674).
- [ ] Consider switch from `NamedTuple` to `dataclass` (Python 3.7 feature, requires a external dependency on some distros we run) as discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8357#note_411004).
- [ ] `NamedInstance.rndc(…)` method probably ought to be `async`. Discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8357#note_411007)
Feel free to add others!Long-termŠtěpán BalážikŠtěpán Balážikhttps://gitlab.isc.org/isc-projects/stork/-/issues/1266Inconsistent IDs2024-01-23T14:18:17ZManuelInconsistent IDsHey everybody,
today I noticed a strange error message in Stork.
Everything is working fine, but looks to me as if this is a logic flaw.
We have multiple kea servers with a private subnet but unique ids.
Why would that be a problem?
...Hey everybody,
today I noticed a strange error message in Stork.
Everything is working fine, but looks to me as if this is a logic flaw.
We have multiple kea servers with a private subnet but unique ids.
Why would that be a problem?
Thanks!
![image](/uploads/9eb80b5bda7df51180e51795217d0474/image.png)outstandingMarcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/3189Follow-up on #3019: limits are incompatbile with retry-on-startup2024-03-28T07:35:17ZAndrei Pavelandrei@isc.orgFollow-up on #3019: limits are incompatbile with retry-on-startupThe limits library needs the lease manager initialized in dhcpX_srv_configured in order to check for JSON support and to do some recounting. When `retry-on-startup` is configured for the lease database, and a retry is triggered, the leas...The limits library needs the lease manager initialized in dhcpX_srv_configured in order to check for JSON support and to do some recounting. When `retry-on-startup` is configured for the lease database, and a retry is triggered, the lease manager is not yet available, so an exception is thrown and the reconfiguration aborts, instead of actually retrying.
We should make limits compatible with retry-on-startup. Through some lazy recounting mechanism. @razvan's idea was a callback in `LeaseMgrFactory` that gets called on instantiation.https://gitlab.isc.org/isc-projects/bind9/-/issues/4489dnssec-guide should mention use of validate-except2023-12-13T12:29:01ZStacey Marshalldnssec-guide should mention use of validate-except### Description
Add use of `validate-except { string; }` to DNSSEC guide.
From discussion on bind9 users list, the recommendation to not use `dnssec-validation no` but instead use `validate-except { string; }` would ideally be mentione...### Description
Add use of `validate-except { string; }` to DNSSEC guide.
From discussion on bind9 users list, the recommendation to not use `dnssec-validation no` but instead use `validate-except { string; }` would ideally be mentioned in the DNSSEC guide (bind9/doc/dnssec-guide) within the ARM.
### Request
Within DNSSEC guide where `dnssec-validation` is discussed for troubleshooting, add some information about the use of `validate-except { string; }` with some examples.
Suggest too that dnssec-validation](https://bind9.readthedocs.io/en/v9.18.20/reference.html#namedconf-statement-dnssec-validation) statement also mention `validate-except`. Yes I see [validate-except](https://bind9.readthedocs.io/en/v9.18.20/reference.html#namedconf-statement-validate-except) is immediately below it, but without the dotted line it may not be seen.
### Links / references
https://lists.isc.org/pipermail/bind-users/2023-December/108172.htmlhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4482Remove the "dnssec-must-be-secure" feature2023-12-07T10:23:58ZMichał KępieńRemove the "dnssec-must-be-secure" featureSee #4263 for the deprecation issue.
Full removal is expected to happen in the 9.21/9.22 development cycle
and it should only affect the development branch.See #4263 for the deprecation issue.
Full removal is expected to happen in the 9.21/9.22 development cycle
and it should only affect the development branch.BIND 9.21.x2024-12-01https://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/55tune host reservations ancillary configuration options2023-12-05T15:13:58ZDarren Ankneytune host reservations ancillary configuration optionsAs noted here, https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#fine-tuning-dhcpv4-host-reservation there are options to make Kea perform better by restricting reservation lookups based on where they appear in the configuration...As noted here, https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#fine-tuning-dhcpv4-host-reservation there are options to make Kea perform better by restricting reservation lookups based on where they appear in the configuration. Cause kea-quick-config to make some of these decisions based on where the reservations are during the output of the configuration.0.3https://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/54Add setting of reservations inside of subnets2023-12-05T15:18:43ZDarren AnkneyAdd setting of reservations inside of subnetsHost reservations, as noted here: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#host-reservations-in-dhcpv4 are meant to only contain an IP address if they are specified at the subnet level. Re-use the host reservation mech...Host reservations, as noted here: https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp4-srv.html#host-reservations-in-dhcpv4 are meant to only contain an IP address if they are specified at the subnet level. Re-use the host reservation mechanism to add reservations in the subnet area. Allow IP address to be set here but only if it is part of the enclosing subnet.0.3https://gitlab.isc.org/isc-projects/bind9/-/issues/4470ns_interfacemgr_t listenon queue set incorrectly2024-03-28T08:28:47Zliu chaofengns_interfacemgr_t listenon queue set incorrectly<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confident...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confidential!
-->
### Summary
ns_interfacemgr_t listenon queue set incorrectly
### BIND version used
master branch
### Steps to reproduce
1. config named.conf like below
options {
...
listen-on port 53 { 127.0.0.1; };
listen-on port 10053 { 127.0.0.1; };
...
}
2. then start the named process
3. run "netstat -lpn|grep named" found the 53 and 10053 has already listened.
4. the ns_interfacemgr_t has a listenon queue
struct ns_interfacemgr {
...
ISC_LIST(isc_sockaddr_t) listenon;
....
}
5. I dump the listenon queue, found that there is only 127.0.0.1#53,
127.0.0.1#10053 is not in the listenon queue.
### What is the current *bug* behavior?
I think this behavior maybe a bug,
### What is the expected *correct* behavior?
the listenon should contain 127.0.0.1#53 and 127.0.0.1#10053
### Relevant configuration files
options {
...
listen-on port 53 { 127.0.0.1; };
listen-on port 10053 { 127.0.0.1; };
...
}
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/dhcp/-/issues/1018Unable to add forward map2023-11-23T03:54:46Zwolverin-aUnable to add forward mapHello
After upgrading the debian version from 8 to 10, isc-dhcp-server (4.4.1-2+deb10u3) stopped updating zones on the bind9 (1:9.10.3.dfsg.P4-12.3+deb9u12) server on Debian 9
There are such errors in the logs
```plaintext
Nov 22 15:0...Hello
After upgrading the debian version from 8 to 10, isc-dhcp-server (4.4.1-2+deb10u3) stopped updating zones on the bind9 (1:9.10.3.dfsg.P4-12.3+deb9u12) server on Debian 9
There are such errors in the logs
```plaintext
Nov 22 15:00:12 server dhcpd[]: DDNS: cleaning up lease pointer for a cancel cb=0x55c12b059300
Nov 22 15:00:30 server dhcpd[]: DDNS: cleaning up lease pointer for a cancel cb=0x55c12b059a20
Nov 22 15:00:30 server dhcpd[]: Unable to add forward map from secretar.xxxxxx.ru to 192.168.yy.xxx: operation canceled
Nov 22 15:01:03 server dhcpd[]: DDNS: cleaning up lease pointer for a cancel cb=0x55c12b058540
Nov 22 15:01:03 server dhcpd[]: Can't remove reverse map on xxx.yy.168.192.in-addr.arpa.: operation canceled
Nov 22 15:02:23 server dhcpd[]: DDNS: cleaning up lease pointer for a cancel cb=0x55c12b059300
Nov 22 15:02:23 server dhcpd[]: Can't remove reverse map on xxx.yy.168.192.in-addr.arpa.: operation canceled
```
nsupdate like **nsupdate -k dhcpd.key** is work
my config
```
# grep -v ^# dhcpd.conf
ddns-update-style standard;
ddns-updates on;
ddns-domainname "domainame.ru";
do-forward-updates on;
update-static-leases on;
update-conflict-detection true;
include "/etc/dhcp/dhcpd.key";
zone domainname.ru {
primary 192.168.yy.2;
key dhcpd-key;
}
zone yy.168.192.in-addr.arpa {
primary 192.168.yy.2;
key dhcpd-key;
}
option domain-name "domainname.ru";
option domain-name-servers 192.168.yy.2;
option local-pac-server code 252 = text;
option local-pac-server "http://proxy/proxy.pac\000";
default-lease-time 36000; # 10h
max-lease-time 86400; # 24h
authoritative;
log-facility local7;
shared-network networkname {
subnet 192.168.yy.0 netmask 255.255.255.0 {
range 192.168.yy.10 192.168.yy.250;
option broadcast-address 192.168.yy.255;
option routers 192.168.yy.2;
option ntp-servers 192.168.yy.2;
filename "pxelinux.0";
next-server 192.168.yy.1;
}
}
host hostname {
hardware ethernet 00:11:0a:f8:xx:xx;
fixed-address 192.168.yy.xxx;
}
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4426Feature request - client.bind chaos class queries2023-11-20T10:39:24ZRay BellisFeature request - client.bind chaos class queriesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4403Resolve spike in memory when named starts2023-12-05T15:58:58ZMatthijs Mekkingmatthijs@isc.orgResolve spike in memory when named starts9.19 resolver does better parallelization of work with cold cache, and thus consumes a more memory and CPU resources right after startup.
We should investigate if it works fine in face of limited resources, e.g. when the initial memory ...9.19 resolver does better parallelization of work with cold cache, and thus consumes a more memory and CPU resources right after startup.
We should investigate if it works fine in face of limited resources, e.g. when the initial memory spike exceeds available memory.
![all-groups-resmon.memory.current-docker](/uploads/b5fa63c677bb0c903ffca45b994375ac/all-groups-resmon.memory.current-docker.png)
![all-groups-resmon.cpu.usage_percent.cg-docker](/uploads/314f7c9f1c396f303bdd6397dd2dc73a/all-groups-resmon.cpu.usage_percent.cg-docker.png)
![all-groups-latency-since_0-until_150](/uploads/3ba559d2fd3a18335eaf45796874482c/all-groups-latency-since_0-until_150.png)BIND 9.19.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/keama/-/issues/55keama-leases step 3: web ui for leases2023-10-24T09:00:35ZTomek Mrugalskikeama-leases step 3: web ui for leasesOnce #53 and #54 is done, the final integration step will be to come up with some web interface for leases. This should extend existing interface for configs.Once #53 and #54 is done, the final integration step will be to come up with some web interface for leases. This should extend existing interface for configs.4.5.1https://gitlab.isc.org/isc-projects/keama/-/issues/54keama-leases step 2: system tests2023-10-24T09:00:36ZTomek Mrugalskikeama-leases step 2: system testsOnce #53 is done, the next step is turn the example data into proper system tests. I'm sure there are also some sharp edges that need some polishing.Once #53 is done, the next step is turn the example data into proper system tests. I'm sure there are also some sharp edges that need some polishing.4.5.1https://gitlab.isc.org/isc-projects/keama/-/issues/53keama-leases step 1: move the source code2024-02-08T13:50:33ZTomek Mrugalskikeama-leases step 1: move the source codeWe have an experimental solution for for [migrating leases](https://gitlab.isc.org/isc-projects/keama-leases). This should be integrated with the keama web interface. This ticket covers the first step - move the code to common repo.We have an experimental solution for for [migrating leases](https://gitlab.isc.org/isc-projects/keama-leases). This should be integrated with the keama web interface. This ticket covers the first step - move the code to common repo.https://gitlab.isc.org/isc-projects/dhcp/-/issues/1017KEAME leases python script2023-10-22T14:47:28Zvladimir9876KEAME leases python script---
name: Bug report
about: Create a report to help us improve
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/...---
name: Bug report
about: Create a report to help us improve
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/ instead or send mail to
security-office(at)isc(dot)org. If you really need to report it here, please set the confidential
field to true.
**Describe the bug**
dhcp2kea.py doesn't support ISC DHCP HA leases
**To Reproduce**
Steps to reproduce the behavior:
1. # python3 dhcp2kea.py /var/lib/dhcpd/dhcpd.leases
Traceback (most recent call last):
File "dhcp2kea.py", line 329, in <module>
print(leases,file=f) # writing
File "dhcp2kea.py", line 98, in __str__
max_life = (self.ver==4) and (v["ends"]-v["starts"]) or v["max-life"]
KeyError: 'ends'
**Expected behavior**
A clear and concise description of what you expected to happen:
No errors reported.
**Environment:**
- ISC DHCP version: 4.2.5
- OS: CentOS 7
**Additional Information**
Add any other context about the problem here. In particular, feel free to share your config file and
logs from around the time error occurred. Don't be shy to send more logs than you think are
relevant. It is easy to grep large log files. It is tricky to guess what may have happened without
any information.
Make sure you anonymize your config files (at the very lease make sure you obfuscate your database
credentials, but you may also replace your actual IP addresses and host names with example.com
and 10.0.0.0/8 or 2001:db8::/32).
**Some initial questions**
The script doesn't handle leases in the 'backup' state
**Is your feature request related to a problem? Please describe.**
KEAME leases migration tool is not working with DHCP HA leases
**Describe the solution you'd like**
# diff -u dhcp2kea.py dhcp2kea.py.ok
--- dhcp2kea.py 2023-10-22 07:42:53.735809274 -0700
+++ dhcp2kea.py.ok 2023-10-22 07:42:08.098860761 -0700
@@ -92,8 +92,8 @@
s = s4 if self.ver == 4 else s6
self.written = 0
for k,v in self.leases.items():
- if "binding state" in v and v["binding state"].startswith("free"): # ticket #4
- continue # skip free and backup leases
+ if "binding state" in v and (v["binding state"].startswith("free") or v["binding state"].startswith("backup")): # ticket #4
+ continue # skip free and backup leases
self.written += 1
max_life = (self.ver==4) and (v["ends"]-v["starts"]) or v["max-life"]
if "valid_lifetime" in v :
**Describe alternatives you've considered**
I just modified the line 95 in the script
**Additional context**
Add any other context about the feature request here.
**Funding its development**
ISC DHCP is run by ISC, which is a small non-profit organization without any government funding or
any permanent sponsorship organizations. Are you able and willing to participate financially in the
development costs?
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature
as generic as possible, so it can be used in wide variety of situations. That means the proposed
solution may be a bit different that you initially thought. Are you willing to take part in the
design discussions? Are you willing to test an unreleased engineering code?
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as
e-mail, jabber id or a telephone, we may send you a message on github with questions when we have
them.https://gitlab.isc.org/isc-projects/kea-docker/-/issues/33Podman and Kubernetes compatibility2024-02-15T11:39:44ZJason BerryPodman and Kubernetes compatibilityI just learned of Kea today and it is fantastic to see a container focused repository.
I'm just wondering if the existing image formats conform to OCI standards or are indeed Docker specific?
If you search for Kea+Podman online you wil...I just learned of Kea today and it is fantastic to see a container focused repository.
I'm just wondering if the existing image formats conform to OCI standards or are indeed Docker specific?
If you search for Kea+Podman online you will find SUSE ALP (Adaptable Linux Platform) which focuses on containerized workloads handled by Podman. I'm singling out this distribution as they have [documentation for running Kea](https://documentation.suse.com/alp/dolomite/html/alp-dolomite/available-alp-workloads.html#kea-dhcp-running-with-podman) with images provided by their own image repository. It is obviously possible to use Kea in Podman, I just haven't had a chance to source the Dockerfile/Containerfile used to build these images.
If the Dockerfile provided by ISC are not OCI compatible, then would it be possible to add [Containerfile](https://github.com/containers/buildah/discussions/3170) and change the name of the Repository to Kea-Containers?https://gitlab.isc.org/isc-projects/keama-leases/-/issues/22dhcp2kea fails with small lease file.2023-10-18T14:16:30ZPatrick Bulteeldhcp2kea fails with small lease file.I am playing around with Kea and migrating my home isc-dhcp server to kea. I was trying to migrate the small lease file (40k) and I got the following error.
```
python3 dhcp2kea.py "subnet_id=1" /var/lib/dhcp/dhcpd.leases
Traceback (mos...I am playing around with Kea and migrating my home isc-dhcp server to kea. I was trying to migrate the small lease file (40k) and I got the following error.
```
python3 dhcp2kea.py "subnet_id=1" /var/lib/dhcp/dhcpd.leases
Traceback (most recent call last):
File "/home/pbulteel/keama-leases/dhcp2kea/dhcp2kea.py", line 329, in <module>
print(leases,file=f) # writing
File "/home/pbulteel/keama-leases/dhcp2kea/dhcp2kea.py", line 105, in __str__
, v["hardware ethernet"] # hwaddr
KeyError: 'hardware ethernet'
```
At some point, I might test this on our production lease file which is 1.7G.https://gitlab.isc.org/isc-projects/bind9/-/issues/4371All the things that need to be fixed before 9.202024-03-27T14:02:04ZMatthijs Mekkingmatthijs@isc.orgAll the things that need to be fixed before 9.20This is an overarching issue for keeping track on all the things that need to be completed before the 9.20.0 release.
### Features
- [ ] #1128 Offline KSK (:gear: @matthijs)
- [x] #1129 HSM support via pkcs11-provider
- [x] #4363 Enfor...This is an overarching issue for keeping track on all the things that need to be completed before the 9.20.0 release.
### Features
- [ ] #1128 Offline KSK (:gear: @matthijs)
- [x] #1129 HSM support via pkcs11-provider
- [x] #4363 Enforce stricter NSEC3 parameter limits
- [x] #4388 Accepting PROXYv2
- [x] #4241 Expose data about 'first time' zone maintenance in-progress
- [ ] #2099 Implement ZoneMD signature generation and verification. (:gear: !5217 @marka, @each)
### Config incompatibilities
- [x] #4364 named-compilezone defaults
- [x] #4373 safer "dnssec-validation yes"
- [x] #4447 "stale-answer-client-timeout" must be zero (:gear: !8699 @aram)
### Refactoring
- [x] #4411 QPDB lite (:gear: !8726 @matthijs, @each)
- [x] #4251 system test runner
### Bugs
- [x] #4340 "max-cache-size" is a no-op since BIND 9.19.16
- [x] #4213 BIND shutdown hang in checkds/ns9/ in cross-version-config-tests job
- [x] #4060 named doesn't shut down after receiving rndc stop command
- [x] #4211 AssertionError: named crashed, shutdown crash
- [ ] #4403 Resolve spike in memory at start of named (:gear: @ondrej)
- [ ] #4481 TCP issue (:gear: isc-private/bind9!639 @ondrej)
- [ ] #4475 Data races in isc_buffer_peekuint8, rdataset_settrust, and memmove (:gear: !8645 @marka)
- [x] #4625 DNSSEC validation incompatibility
- [ ] #4652 Server crash caused by external UDP queriesBIND 9.19.x2024-05-02