ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-09-19T10:22:55Zhttps://gitlab.isc.org/isc-projects/keama/-/issues/384.5.0 Release changes2023-09-19T10:22:55ZMarcin Godzina4.5.0 Release changesMarcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/keama/-/issues/37Add docker image to keama web interface.2023-09-18T07:21:27ZMarcin GodzinaAdd docker image to keama web interface.Add docker image to keama web interface.Add docker image to keama web interface.Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/46Adjust multi-threading from defaults depending on lease-database choice2023-09-21T15:13:15ZDarren AnkneyAdjust multi-threading from defaults depending on lease-database choiceDifferent lease database types (memfile persist, mysql, postgresql) have wildly different thread pool and packet queue optimal settings. See [here](https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#multi-threading-settings-with...Different lease database types (memfile persist, mysql, postgresql) have wildly different thread pool and packet queue optimal settings. See [here](https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#multi-threading-settings-with-different-database-backends) for details.
I propose to do the following:
- memfile (no persist) - do not change anything
- memfile (persist) - add multi-threading section with appropriate thread pool and packet queue size settings.
- mysql - add multi-threading section with appropriate thread pool and packet queue size settings.
- postgresql - add multi-threading section with appropriate thread pool and packet queue size settings.
Each of those has different optimal values (though it may vary some by CPU / RAM configuration as well but these get you in the ballpark).0.2Darren AnkneyDarren Ankneyhttps://gitlab.isc.org/isc-projects/stork/-/issues/1162Hadolint for Dockerfiles2023-09-19T13:45:30ZSlawek FigielHadolint for DockerfilesI propose adding the Hadolint - Docker linter to our build kit for easier following the best practices and force consistent formatting.I propose adding the Hadolint - Docker linter to our build kit for easier following the best practices and force consistent formatting.backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4320allow shorter resolver-query-timeout configuration2023-09-15T14:18:22ZPetr Špačekpspacek@isc.orgallow shorter resolver-query-timeout configuration### Use-case
Weird network setup:
* Load balancer is listed in NS RR set like this:`example.com NS load-balancer.example.com`
* The load balancer sets RD=1 and forwards query to a BIND **resolver**
* The BIND **resolver** is then configu...### Use-case
Weird network setup:
* Load balancer is listed in NS RR set like this:`example.com NS load-balancer.example.com`
* The load balancer sets RD=1 and forwards query to a BIND **resolver**
* The BIND **resolver** is then configured to talk to backend servers which are not visible in the public NS set
### Description
If/when the auths don't keep up with load from the BIND resolver "frontend", the resolver will retry several times during [resolver-query-timeout](https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-resolver-query-timeout) interval, which currently has minimum value of 10 s.
At the same time, the client which sent the original query will timeout because it is not expecting any auth to take 10 seconds to respond. This means the frontend BIND will be doing mostly pointless work, and that the client will penalize BIND-frontend in client's ADB (address database) because it will believe the BIND frontend just times out, while it will give back SERVFAIL, but only after 10 seconds.
See https://indico.dns-oarc.net/event/47/contributions/1018/ for more details.
### Request
When BIND is used in this weird scenario it's pointless to have `resolver-query-timeout` set to 10 s. It should allow configuration to be something like 0.5 seconds because communication with backends should be really fast. With such configuration BIND-frontend can give back SERVFAIL early when backends are not available and the ultimate client will not penalize the BIND-frontend for non-response.
### Links / referenceshttps://gitlab.isc.org/isc-projects/stork/-/issues/1161Linter and formatter for Ruby2023-09-22T10:07:43ZSlawek FigielLinter and formatter for RubyOut Rakefiles (written in Ruby) are no longer trivial. We should add the Ruby linter and formatter to force the consistent and proper coding style for these files.Out Rakefiles (written in Ruby) are no longer trivial. We should add the Ruby linter and formatter to force the consistent and proper coding style for these files.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3066ctrl agent: cannot listen on ipv62023-09-26T13:22:27ZJohn Doectrl agent: cannot listen on ipv6**Describe the bug**
The kea control agent cannot listen on IPv6 addresses via the `http-host` option. We've tried several IPv6 types (GUA, ULA, link local including interface scope) and notations (with brackets and without). For the no...**Describe the bug**
The kea control agent cannot listen on IPv6 addresses via the `http-host` option. We've tried several IPv6 types (GUA, ULA, link local including interface scope) and notations (with brackets and without). For the notation without brackets, the agent silently does not listen at all on an IP address, the notation with brackets, a configuration parsing error occurs.
**To Reproduce**
Steps to reproduce the behavior:
We're using a configuration e.g.
```json
{
"Control-agent": {
"http-host": "$HOST",
"http-port": 8000
// ...
}
}
```
where `$HOST` is
- (empty string) causes `ERROR [kea-ctrl-agent.dctl/433402.140592497919872] DCTL_PARSER_FAIL : Failed to convert to IP address:Failed to convert string to address '': Invalid argument`
- *http-host* line does not exist: listens on 127.0.0.1:8000
- `2001:db8::1` causes about 10 log lines of `RROR [kea-ctrl-agent.dctl/433486.140500168120192] DCTL_PARSER_FAIL : unable to setup TCP acceptor for listening to the incoming HTTP requests: open: Permission denied` and does not listen on the IPv6.
- `[2001:db8::1]` causes about 10 log lines of `ERROR [kea-ctrl-agent.dctl/433528.140127554930560] DCTL_PARSER_FAIL : Failed to convert [2001:db8::1] to IP address:Failed to convert string to address '[2001:db8::1]': Invalid argument` and does not listen on the IPv6
Since we're also loading the HA module, we configure a list of peers with the bracketed IPv6 notation (non-bracketed causes parsing errors):
```json
{
"Dhcp4": {
"hooks-libraries": [
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so",
"parameters": {}
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [
{
"this-server-name": "host1",
"mode": "hot-standby",
"heartbeat-delay": 10000,
"max-response-delay": 10000,
"max-ack-delay": 5000,
"max-unacked-clients": 5,
"peers": [
{
"name": "host1",
"url": "https://[2001:db8::1]:8000",
"trust-anchor": "/etc/kea/bundle.pem",
"cert-file": "/etc/kea/host.crt",
"key-file": "/etc/kea/host.key",
"auto-failover": true,
"basic-auth-user": "admin",
"basic-auth-password": "..."
# ...
},
{
"name": "host2",
"url": "https://[2001:db8::2]:8000",
"trust-anchor": "/etc/kea/bundle.pem",
"cert-file": "/etc/kea/host.crt",
"key-file": "/etc/kea/host.key",
"role": "standby",
"auto-failover": true,
"basic-auth-user": "admin",
"basic-auth-password": "..."
}
]
...
```
This configuration seems to be accepted correctly.
**Expected behavior**
We expect IPv6 to be fully supported for a top notch project like kea. Are we missing a configuration option?
**Environment:**
- Kea version: version 2.2.0
- OS: debian 11
- Which features were compiled in (in particular which backends)
- If/which hooks where loaded in: HAkea2.5.3https://gitlab.isc.org/isc-projects/stork/-/issues/1160Stork agent: --use-env flag is incompatible with the register command2023-09-19T13:42:56ZSlawek FigielStork agent: --use-env flag is incompatible with the register commandThe issue was reported on [our mailing list](https://lists.isc.org/pipermail/stork-users/2023-September/000177.html).
The `register` command fails if the `--use-env` flag is provided.
The environment file content:
```
STORK_AGENT_HOST...The issue was reported on [our mailing list](https://lists.isc.org/pipermail/stork-users/2023-September/000177.html).
The `register` command fails if the `--use-env` flag is provided.
The environment file content:
```
STORK_AGENT_HOST=foobar
```
The output:
```
stork-agent --use-env-file --env-file env.file register
FATA[2023-09-14 16:58:58] main.go:402 the 'env.file' environment file is invalid: cannot set 'STORK_AGENT_HOST=foobar' environment variable: no such flag -STORK_AGENT_HOST
```backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4317The primary server does not send notify information2023-09-14T09:10:44Zliangzyeu liangzeThe primary server does not send notify information<!--
My primary bind server needed to synchronize 13 zone files to 3 secondary servers, but 1-2 zone synchronization was missed each time. I found through logs that the primary bind did not send notify information to the secondary server...<!--
My primary bind server needed to synchronize 13 zone files to 3 secondary servers, but 1-2 zone synchronization was missed each time. I found through logs that the primary bind did not send notify information to the secondary server. But one solution I have is to execute rndc reload twice every time you modify the zone file to synchronize it all. What's the problem?
-->
### Summary
My primary bind server needed to synchronize 13 zone files to 3 secondary servers, but 1-2 zone synchronization was missed each time. I found through logs that the primary bind did not send notify information to the secondary server. But one solution I have is to execute rndc reload twice every time you modify the zone file to synchronize it all. What's the problem?
### BIND version used
[root@ops-sandbox-86-10 zone]# named -V
BIND 9.12.2-P1 <id:8914b83>
running on Linux x86_64 3.10.0-1062.52.2.el7.x86_64 #1 SMP Thu Jul 8 09:03:01 UTC 2021
built by make with '--prefix=/usr/local/named' '--sysconfdir=/data/named/named_53' '--enable-threads' '--enable-largefile' '--enable-epoll' '--disable-ipv6' '--with-openssl'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-16)
compiled with OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabledhttps://gitlab.isc.org/isc-projects/keama/-/issues/364.5.0 - Release checklist2023-09-21T06:09:08ZMarcin Godzina4.5.0 - Release checklist# Keama Release Checklist
1. Gitlabab pipeline results:
1. [x] Check Gitlab [build](https://gitlab.isc.org/isc-projects/keama/-/pipelines) job for failures
1. [x] Check Gitlab [pytest](https://gitlab.isc.org/isc-projects/keama/...# Keama Release Checklist
1. Gitlabab pipeline results:
1. [x] Check Gitlab [build](https://gitlab.isc.org/isc-projects/keama/-/pipelines) job for failures
1. [x] Check Gitlab [pytest](https://gitlab.isc.org/isc-projects/keama/-/pipelines) job for failures
1. Tarball preparation:
1. [x] If this is the release of the final version, please check the sanity check ticket of the previous release and make sure all comments are addressed
1. [x] bump up version in configure.ac
1. [x] bump up version in `tests/test_keama.py:test_version()` (isc-projects/keama#40)
1. [ ] Note release in changelog
1. [x] check the date in LICENSE
1. [x] Check README file (including installation details)
1. [x] update copyrights in all touched files using a simple script in [qa-dhcp](https://gitlab.isc.org/isc-private/qa-dhcp/-/tree/master/dhcp/scripts).
1. [x] Do `autoreconf -i` on a modern system, test the code compiles and push your changes.
1. Build tarball, packages and docker image
1. [x] Go to [keama-tarball](https://jenkins.aws.isc.org/view/isc-dhcp-dev/job/dhcp-dev/job/keama-tarball/) > Build with Parameters, in field `keamaBranch` put in release branch and run the job, this will build release tarball and save it as an artifact of the job
1. [x] Go to [keama-pkg](https://jenkins.aws.isc.org/view/isc-dhcp-dev/job/dhcp-dev/job/keama-pkg/) > Build with Parameters, in field `keamaBranch` put in release branch and run the job, this will build release packages and save it as an artifact of the job (`baseBranch` should be 'master' if not using custom qa-dhcp branch)
1. [x] Go to [keama-docker](https://jenkins.aws.isc.org/view/isc-dhcp-dev/job/dhcp-dev/job/keama-pkg/) > Build with Parameters, in field `keamaBranch` put in release branch and run the job, this will build release tarball and save it as an artifact of the job (`keamadockerBranch` should be 'master' if not using custom keama-docker branch)
1. [x] Go to [keama-release-notes](https://jenkins.aws.isc.org/view/isc-dhcp-dev/job/dhcp-dev/job/keama-release-notes/) > Build with Parameters, in field `version` put in release version and run the job, this will build release notes in txt format and save it as an artifact of the job.
1. [x] before tarball will be deemed as ready to release it will be `release candidate`. Each consecutive respin will have it's own name starting from `-rc1`
1. [x] open a ticket in keama repo called `release X.Y.Z-rcX sanity checks` and put there location of release tarball, packages, and docker image
1. [x] wait for team input about new tarball, if respin is needed go back to `Build tarball` point also increasing release candidate number
1. [x] if tarball is accepted create a tag of this version on a last commit in release branch and kea-docker repo
1. [x] move tarball and release notes to non release candidate location (e.g. moving to /data/shared/sweng/keama/releases/4.5.0)
1. [x] make sure that new release directory allow group write e.g. `chmod 665 /data/shared/sweng/dhcp/releases/4.3.2b1`
1. [x] upload packages to cloudsmith
1. [x] upload docker image to cloudsmith
1. [x] open tickets to address issues mentioned in sanity checks IF those were not already fixed and close sanity check ticket
1. Signing and notification
1. [x] Sign the tarball and put signature files with the tarball
1. [x] notify support about readiness of release, at this point QA and dev team work is done
1. Post release
1. [x] mark jenkins jobs to save forever.
1. [x] Bump version in `configure.ac`, `tests/test_keama.py:test_version()` (isc-projects/keama#40)and do `autoreconf -i`
1. [x] push to repo and unfreeze the code
1. Releasing tarball
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Confirm that the tarballs are signed correctly.
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *dhcp-announce*.
- [x] ***(Support)*** Write email to *dhcp-users* (if a major release).
- [x] ***(Support)*** Update tickets in case of waiting for support customers.
- [x] ***(Marketing)*** Announce on social media.
- [ ] ***(Marketing)*** Write blog article (if a major release).4.5.0https://gitlab.isc.org/isc-projects/kea/-/issues/3064performance drop during 2.3 release cycle for mysql2023-09-21T13:53:17ZWlodzimierz Wencelperformance drop during 2.3 release cycle for mysqlWe observed huge performance drop during 2.3 release cycle, Exactly between 2.3.8 and 2.3.9
![Screenshot_2023-09-14_at_09.55.50](/uploads/06cdfb127f6609246e68c58d63663a2e/Screenshot_2023-09-14_at_09.55.50.png)
![Screenshot_2023-09-14_at...We observed huge performance drop during 2.3 release cycle, Exactly between 2.3.8 and 2.3.9
![Screenshot_2023-09-14_at_09.55.50](/uploads/06cdfb127f6609246e68c58d63663a2e/Screenshot_2023-09-14_at_09.55.50.png)
![Screenshot_2023-09-14_at_09.57.01](/uploads/d9fb7fbabb11d49faa3e40efbd6f4bac/Screenshot_2023-09-14_at_09.57.01.png)
Please check [report on master](https://jenkins.aws.isc.org/job/kea-dev/job/performance/lastSuccessfulBuild/artifact/qa-dhcp/kea/performance-jenkins/report.html), during this work I was testing migration to binary addresses in mysql and this did not show performance degradation in [the report](https://jenkins.aws.isc.org/view/Kea-manual/job/kea-manual/job/performance/108/artifact/qa-dhcp/kea/performance-jenkins/report.html)next-stable-2.6https://gitlab.isc.org/isc-projects/bind9/-/issues/4313automate root.hints up-to-date check2023-09-12T13:12:02ZPetr Špačekpspacek@isc.orgautomate root.hints up-to-date check### Problem
Right now root.hints file content is hardcoded into lib/dns/rootns.c, and not checked in any automated way I know of.
### Request
Use some automated process to check content of the file. E.g. a new job in the scheduled pip...### Problem
Right now root.hints file content is hardcoded into lib/dns/rootns.c, and not checked in any automated way I know of.
### Request
Use some automated process to check content of the file. E.g. a new job in the scheduled pipeline which would check content of the file against https://www.internic.net/domain/db.cache or something like that.
### Links / referenceshttps://gitlab.isc.org/isc-projects/stork/-/issues/1159REST API call for 'config-set' seems to be not applying configuration2023-09-12T05:25:39ZSandeep GagalapallyREST API call for 'config-set' seems to be not applying configurationHello,
I am trying to apply new dhcp4 configuration using the 'config-set' command and I get an output as "Configuration successful" but I don't see the changes in effect on the configuration file or the new configuration is not updated...Hello,
I am trying to apply new dhcp4 configuration using the 'config-set' command and I get an output as "Configuration successful" but I don't see the changes in effect on the configuration file or the new configuration is not updated.
Reading through the documentation I see the change is applied in memory and a reload with keep the old config? What should i do to have the changes to config take place ?
Thanks
Sandeephttps://gitlab.isc.org/isc-projects/kea/-/issues/3062Any interface created while retrying sockets are used unfiltered2024-02-08T14:35:31ZEfe Can İçözAny interface created while retrying sockets are used unfiltered
**Describe the bug**
While retrying an interface that didn't met the socket requirements in `IfaceMgr::openSockets4` yet, if new interfaces registered to system Kea DHCP4 server listens those interfaces even they are not listed in conf...
**Describe the bug**
While retrying an interface that didn't met the socket requirements in `IfaceMgr::openSockets4` yet, if new interfaces registered to system Kea DHCP4 server listens those interfaces even they are not listed in configuration file.
**To Reproduce**
Steps to reproduce the behavior:
1. Set a dummy interface and ensure that it's down.
`ip link add dummy0 type dummy`
`ip addr add 192.168.1.1/24 dev dummy0`
`ip link set dummy0 down`
2. Run Kea dhcp4 server with the following config
{
"Dhcp4": {
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
"interfaces-config": {
"interfaces": [ "dummy0/192.168.1.1" ],
"service-sockets-max-retries": 1000,
"service-sockets-retry-wait-time": 1000
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/dhcp4.leases"
},
"subnet4": [
{
"subnet": "192.168.1.0/24",
"interface": "dummy0",
"pools": [
{
"pool": "192.168.1.4 - 192.168.1.254",
}
]
}
]
}
}
3. At this point Kea will print `DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface dummy0 is down` messages.
4. Add another interface with
`ip link add dummy1 type dummy`
`ip addr add 10.10.1.1/24 dev dummy1`
`ip link set dummy1 up`
5. Set dummy0 online to let Kea run
`ip link set dummy1 up`
6. Check open sockets by Kea
`netstat -tulpan | grep kea` which is
udp 0 0 192.168.1.1:67 0.0.0.0:* 694387/kea-dhcp4
udp 0 0 10.10.1.1:67 0.0.0.0:* 694387/kea-dhcp4
**Expected behavior**
Server should only listen _dummy0_ interface.
**Environment:**
- Kea version: 2.2.0
- OS: Ubuntu 22.04.3 x64
**Additional Information**
This issue happened also on our custom yocto build on imx8qxp with aarch64next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3061Include wildcards2023-09-21T13:48:46ZTomek MrugalskiInclude wildcardsOne Kea user wrote:
> we use puppet to define our service configurations and Kea seems to have support for including a single file, yet not a complete directory that we could fill easily. That kind of including a full directory that is ...One Kea user wrote:
> we use puppet to define our service configurations and Kea seems to have support for including a single file, yet not a complete directory that we could fill easily. That kind of including a full directory that is exclusive under control of a configuration management solution seems to be lacking and causes us to add a preparser to the deployment, which is very well possible but somewhat doesn't feel right. Are we simply not seeing "the solution" that you originally designed here?
This is a proposal to extend the syntax `<?include "file.json"?>` to be able to use wildcards and include multiple files.
Personally, I don't think this would be a very popular feature. But on the other hand, it opens up some interesting use cases.backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4309Named Crashes: Named startup crash on low-memory devices2023-09-11T07:49:34ZJingtian LiuNamed Crashes: Named startup crash on low-memory devices<!--
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
Named startup crash on low-memory devices if generate too much rr through `$GENERATE`
### BIND version used
```sh
BIND 9.19.17-dev (Development Release) <id:edd9925>
```
### Steps to reproduce
#### step1. configure named
- named.conf
```sh
options {
directory "/path/to/directory";
allow-query { any; };
listen-on port specify-a-port { any; };
};
zone "example.com." {
type primary;
file "example.db";
};
```
- example.db
```sh
$ORIGIN .
$TTL 120
@ SOA tld4. hostmaster.ns.tld4. ( 1 3600 1200 604800 60 )
NS ns
ns A 16.53.0.2
$GENERATE 0-28836000 HOST-$ MX "0 ."
```
#### step2. create a low-ram environment
```sh
ulimit -v 512000 # or 204800
```
#### step3. startup named
### What is the current *bug* behavior?
#### set 200M virtual memory
```sh
ulimit -v 204800
```
```log
#0 0x00007ffff4d97438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007ffff4d9903a in __GI_abort () at abort.c:89
#2 0x0000000000433489 in assertion_failed (file=0x7ffff7bbba8e "./jemalloc_shim.h", line=66, type=<optimized out>,
cond=0x7ffff7bbbb34 "ptr != ((void*)0)") at main.c:225
#3 0x00007ffff7b2a331 in isc_assertion_failed (file=0x63bb <error: Cannot access memory at address 0x63bb>, line=25538,
line@entry=66, type=6, type@entry=isc_assertiontype_insist, cond=0x7ffff4d97438 <__GI_raise+56> "H=")
at assertions.c:48
#4 0x00007ffff7b67178 in mallocx (size=65576, flags=0) at ./jemalloc_shim.h:66
#5 mem_get (ctx=0x706630, size=65576, flags=0) at mem.c:306
#6 isc__mem_get (ctx=ctx@entry=0x706630, size=size@entry=65576, flags=flags@entry=0,
file=0x4931de "../../lib/isc/include/isc/buffer.h", line=line@entry=1085) at mem.c:691
#7 0x000000000041b65d in isc_buffer_allocate (mctx=0x706630, dbufp=0x7ffff2c90f40, length=65512)
at ../../lib/isc/include/isc/buffer.h:1085
#8 putrr (node=node@entry=0x7ffff7e19010, type=<optimized out>, ttl=ttl@entry=0, data=data@entry=0x7ffff7e27010 "@")
at builtin.c:176
#9 0x0000000000417bde in builtin_authority (node=0x7ffff7e19010, bdb=<optimized out>) at builtin.c:489
#10 findnode (db=db@entry=0x7ffff7ff2010, name=<optimized out>, name@entry=0x8f2460, create=<optimized out>,
nodep=nodep@entry=0x7ffff2c91900) at builtin.c:897
#11 0x00007ffff7508817 in dns__db_findnode (db=db@entry=0x7ffff7ff2010, name=name@entry=0x8f2460, create=false,
nodep=nodep@entry=0x7ffff2c91900) at db.c:419
#12 0x00007ffff7860e9e in check_nsec3param (zone=zone@entry=0x8f22a0, db=db@entry=0x7ffff7ff2010) at zone.c:3881
#13 0x00007ffff78091ea in zone_postload (zone=<optimized out>, zone@entry=0x8f22a0, db=<optimized out>, loadtime=...,
result=result@entry=ISC_R_SUCCESS) at zone.c:4944
#14 0x00007ffff77d8e94 in zone_load (zone=<optimized out>, zone@entry=0x8f22a0, flags=<optimized out>, locked=false)
at zone.c:2342
#15 0x00007ffff77d9ec7 in zone_asyncload (arg=0x7601a0) at zone.c:2371
#16 0x00007ffff7b2a9e0 in isc__async_cb (handle=<optimized out>) at async.c:111
#17 0x00007ffff609f3b4 in uv__async_io (loop=0x6f3bf0, w=<optimized out>, events=<optimized out>) at src/unix/async.c:163
--Type <RET> for more, q to quit, c to continue without paging--
#18 0x00007ffff60b2a0c in uv__io_poll (loop=loop@entry=0x6f3bf0, timeout=<optimized out>) at src/unix/epoll.c:374
#19 0x00007ffff609fbd0 in uv_run (loop=loop@entry=0x6f3bf0, mode=mode@entry=UV_RUN_DEFAULT) at src/unix/core.c:406
#20 0x00007ffff7b60d96 in loop_thread (arg=arg@entry=0x6f3bd0) at loop.c:282
#21 0x00007ffff7b8b511 in thread_body (wrap=0x702200) at thread.c:85
#22 thread_run (wrap=0x702200) at thread.c:100
#23 0x00007ffff5a546ba in start_thread (arg=0x7ffff2c97700) at pthread_create.c:333
#24 0x00007ffff4e6951d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
```
#### set 500M virtual memory
```sh
ulimit -v 512000
```
```log
#0 0x00007ffff4d97438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007ffff4d9903a in __GI_abort () at abort.c:89
#2 0x000000000043366a in library_fatal_error (file=0x7ffff7bbf4eb "thread.c", line=140,
func=0x7ffff7bbf521 "isc_thread_create", format=0x7ffff7bb3e96 "%s(): %s (%d)", args=0x7fffffffdf30) at main.c:265
#3 0x00007ffff7b32404 in isc_error_fatal (file=0x6ea1 <error: Cannot access memory at address 0x6ea1>, line=28321,
line@entry=140, func=0x6 <error: Cannot access memory at address 0x6>, format=0x7ffff4d97438 <__GI_raise+56> "H=")
at error.c:69
#4 0x00007ffff7b8b434 in isc_thread_create (func=<optimized out>, arg=0x6f5550, thread=thread@entry=0x6f5560)
at thread.c:140
#5 0x00007ffff7b60abd in isc_loopmgr_run (loopmgr=0x6ef0b0) at loop.c:448
#6 0x000000000043295a in main (argc=<optimized out>, argv=<optimized out>) at main.c:1535
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4308Named Crashed: named aborted while handling dns query with certain format.2023-09-11T03:54:42ZJingtian LiuNamed Crashed: named aborted while handling dns query with certain format.<!--
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
named server crashes down due to `an assertion failure` while handling dns query with certain format.
```c
name.c:692: ENSURE(name->labels <= 127) failed
```
### BIND version used
```sh
BIND 9.19.12-dev (Development Release) <id:91c4792>
```
### Steps to reproduce
#### step1. launch a named server
Launch a named use a regular config file.
```sh
options {
directory "/path/to/directory";
allow-query { any; };
listen-on port specify-a-port { any; };
};
```
#### step2. build a dns query
The query should contain `at least one question`. To the `name field` of that question, it constains `exactly 127 labels` and each label is consists of `one ASCII control character`. Here is an eg.
```sh
$ hexdump dnsquery
0000000 76c7 0001 0100 0000 0000 0000 1f01 0401
0000010 1101 1201 0201 1901 1e01 1401 0101 0601
0000020 1b01 0601 0401 0f01 1401 7f01 0701 1b01
0000030 1901 0f01 0b01 1b01 0f01 0b01 0f01 1101
0000040 1f01 1401 0901 1401 0701 0e01 1601 0401
0000050 1501 0901 1901 0601 1101 1601 7f01 0701
0000060 1c01 7f01 1c01 7f01 0701 0e01 1601 0a01
0000070 0301 0801 1501 0201 1d01 0301 1d01 1901
0000080 0301 1b01 0c01 1f01 0801 0d01 1d01 0601
0000090 0801 1a01 1901 7f01 1201 1001 0b01 0501
00000a0 0101 0a01 1901 1d01 1301 1c01 1f01 0f01
00000b0 0d01 0201 0301 1a01 0301 0101 1201 1901
00000c0 0301 1d01 0901 1b01 0101 0b01 1701 0601
00000d0 7f01 0901 0801 1501 0b01 1701 1901 0d01
00000e0 1101 1701 0101 1501 0701 0101 1701 0101
00000f0 0c01 1801 0a01 1e01 0101 1001 0301 1401
0000100 0501 0d01 1b01 0701 1f01 0000 0001 0001
000010f
```
[dnsquery](/uploads/1e3ff1ce70619e70b709c80981e19d64/dnsquery)
#### step3. send the query to named
Send this query to named, and it will trigger an assersion failure.
### What is the current *bug* behavior?
```log
07-Sep-2023 18:06:22.485 name.c:692: ENSURE(name->labels <= 127) failed, back trace
07-Sep-2023 18:06:22.485 /home/ubuntu/bind9/lib/isc/.libs/libisc-9.19.12-dev.so(isc_backtrace+0x80) [0x7f340e1dae20]
07-Sep-2023 18:06:22.485 /home/ubuntu/bind9/bin/named/.libs/named() [0x53bcaa]
07-Sep-2023 18:06:22.485 /home/ubuntu/bind9/lib/isc/.libs/libisc-9.19.12-dev.so(isc_assertion_failed+0x57) [0x7f340e1da4b7]
07-Sep-2023 18:06:22.485 /home/ubuntu/bind9/lib/dns/.libs/libdns-9.19.12-dev.so(+0x2d51fc) [0x7f340d95d1fc]
07-Sep-2023 18:06:22.485 /home/ubuntu/bind9/lib/ns/.libs/libns-9.19.12-dev.so(+0x64702) [0x7f340d3c7702]
07-Sep-2023 18:06:22.485 /home/ubuntu/bind9/lib/ns/.libs/libns-9.19.12-dev.so(ns__query_start+0xb7d) [0x7f340d3c1abd]
07-Sep-2023 18:06:22.485 /home/ubuntu/bind9/lib/ns/.libs/libns-9.19.12-dev.so(+0x75b84) [0x7f340d3d8b84]
07-Sep-2023 18:06:22.485 /home/ubuntu/bind9/lib/ns/.libs/libns-9.19.12-dev.so(ns_query_start+0x2274) [0x7f340d3d79a4]
07-Sep-2023 18:06:22.485 /home/ubuntu/bind9/lib/ns/.libs/libns-9.19.12-dev.so(ns__client_request+0x2abb) [0x7f340d39d7cb]
07-Sep-2023 18:06:22.485 /home/ubuntu/bind9/lib/isc/.libs/libisc-9.19.12-dev.so(isc__nm_readcb+0x510) [0x7f340e195530]
07-Sep-2023 18:06:22.485 /home/ubuntu/bind9/lib/isc/.libs/libisc-9.19.12-dev.so(isc__nm_udp_read_cb+0x9fc) [0x7f340e1d440c]
07-Sep-2023 18:06:22.485 /usr/local/lib/libuv.so.1(+0x1dff3) [0x7f340c14dff3]
07-Sep-2023 18:06:22.485 /usr/local/lib/libuv.so.1(+0x1ef4b) [0x7f340c14ef4b]
07-Sep-2023 18:06:22.485 /usr/local/lib/libuv.so.1(+0x22a0c) [0x7f340c152a0c]
07-Sep-2023 18:06:22.485 /usr/local/lib/libuv.so.1(uv_run+0xc0) [0x7f340c13fbd0]
07-Sep-2023 18:06:22.485 /home/ubuntu/bind9/lib/isc/.libs/libisc-9.19.12-dev.so(+0x1091e7) [0x7f340e2331e7]
07-Sep-2023 18:06:22.485 /home/ubuntu/bind9/lib/isc/.libs/libisc-9.19.12-dev.so(isc__trampoline_run+0x74) [0x7f340e28ca94]
07-Sep-2023 18:06:22.485 /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f340b8da6ba]
07-Sep-2023 18:06:22.485 /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f340aee751d]
07-Sep-2023 18:06:22.485 exiting (due to assertion failure)
```
### What is the expected *correct* behavior?
The assertion is not supposed to be failed.https://gitlab.isc.org/isc-projects/bind9/-/issues/4307nslookup timeout is ignored after several requests2023-09-09T18:13:01ZGeoffrey McRaenslookup timeout is ignored after several requests### Summary
nslookup doesn't properly implement the timeout on lookup sometimes.
### BIND version used
```
BIND 9.18.16-1~deb12u1-Debian (Extended Support Version) <id:>
running on Linux x86_64 6.1.0-rc7-pstate #3 SMP PREEMPT_DYNAMIC ...### Summary
nslookup doesn't properly implement the timeout on lookup sometimes.
### BIND version used
```
BIND 9.18.16-1~deb12u1-Debian (Extended Support Version) <id:>
running on Linux x86_64 6.1.0-rc7-pstate #3 SMP PREEMPT_DYNAMIC Mon Dec 5 22:02:30 AEDT 2022
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-yTvTm0/bind9-9.18.16=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 12.2.0
compiled with OpenSSL version: OpenSSL 3.0.9 30 May 2023
linked to OpenSSL version: OpenSSL 3.0.9 30 May 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.52.0
linked to libnghttp2 version: 1.52.0
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
linked to maxminddb version: 1.7.1
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
1. run `nslookup`
2. perform several queries, usually only takes 3-4 before the bug exhibits.
### What is the current *bug* behavior?
nslookup doesn't wait for the timeout and immediately responds with the following before attempting again and succeeding.
```
;; communications error to 0000:0000:000:0000:000:0000:feca:e1ff#53: timed out
```
Note the IP has been redacted for security reasons, it is a valid global IPv6 address.
Wireshark confirms the request was sent, and `nslookup` did not wait for a response.
Once this occurs the first time, it happens for every single dns request until `nslookup` is restarted.
Here is the output of `nslookup -d2` when this occurs.
```
> asd.com
addlookup()
make_empty_lookup()
make_empty_lookup() = 0x7ffa2ae00000->references = 1
looking up asd.com
start_lookup()
setup_lookup(0x7ffa2ae00000)
resetting lookup counter.
cloning server list
clone_server_list()
make_server(0000:0000:000:0000:000:0000:feca:e1ff)
idn_textname: asd.com
using root origin
recursive query
add_question()
starting to render the message
done rendering
create query 0x7ffa2ae42000 linked to lookup 0x7ffa2ae00000
dighost.c:2177:lookup_attach(0x7ffa2ae00000) = 2
dighost.c:2690:new_query(0x7ffa2ae42000) = 1
do_lookup()
start_udp(0x7ffa2ae42000)
dighost.c:3301:query_attach(0x7ffa2ae42000) = 2
working on lookup 0x7ffa2ae00000, query 0x7ffa2ae42000
dighost.c:3346:query_attach(0x7ffa2ae42000) = 3
udp_ready()
udp_ready(0x7ffa2ae81000, success, 0x7ffa2ae42000)
lock_lookup dighost.c:3188
success
dighost.c:3189:lookup_attach(0x7ffa2ae00000) = 3
dighost.c:3261:query_attach(0x7ffa2ae42000) = 4
recving with lookup=0x7ffa2ae00000, query=0x7ffa2ae42000, handle=0x7ffa2ae81000
recvcount=1
have local timeout of 5000
dighost.c:3135:query_attach(0x7ffa2ae42000) = 5
sending a request
sendcount=1
dighost.c:1761:query_detach(0x7ffa2ae42000) = 4
dighost.c:3281:query_detach(0x7ffa2ae42000) = 3
dighost.c:3282:lookup_detach(0x7ffa2ae00000) = 2
unlock_lookup dighost.c:3283
send_done(0x7ffa2ae81000, success, 0x7ffa2ae42000)
sendcount=0
lock_lookup dighost.c:2765
success
dighost.c:2769:lookup_attach(0x7ffa2ae00000) = 3
dighost.c:2787:query_detach(0x7ffa2ae42000) = 2
dighost.c:2788:lookup_detach(0x7ffa2ae00000) = 2
check_if_done()
list empty
unlock_lookup dighost.c:2792
recv_done(0x7ffa2ae81000, timed out, 0x7ffa2bdff1c0, 0x7ffa2ae42000)
lock_lookup dighost.c:3955
success
recvcount=0
dighost.c:3960:lookup_attach(0x7ffa2ae00000) = 3
;; communications error to 0000:0000:000:0000:000:0000:feca:e1ff#53: timed out
create query 0x7ffa2ae421c0 linked to lookup 0x7ffa2ae00000
dighost.c:2177:lookup_attach(0x7ffa2ae00000) = 4
dighost.c:4048:new_query(0x7ffa2ae421c0) = 1
making new UDP request, 2 tries left
start_udp(0x7ffa2ae421c0)
dighost.c:3301:query_attach(0x7ffa2ae421c0) = 2
working on lookup 0x7ffa2ae00000, query 0x7ffa2ae421c0
dighost.c:3346:query_attach(0x7ffa2ae421c0) = 3
check_if_queries_done(0x7ffa2ae00000)
there is a pending query 0x7ffa2ae421c0
dighost.c:4554:query_detach(0x7ffa2ae42000) = 1
dighost.c:4562:lookup_detach(0x7ffa2ae00000) = 3
unlock_lookup dighost.c:4566
udp_ready()
udp_ready(0x7ffa2ae81480, success, 0x7ffa2ae421c0)
lock_lookup dighost.c:3188
success
dighost.c:3189:lookup_attach(0x7ffa2ae00000) = 4
dighost.c:3261:query_attach(0x7ffa2ae421c0) = 4
recving with lookup=0x7ffa2ae00000, query=0x7ffa2ae421c0, handle=0x7ffa2ae81480
recvcount=1
have local timeout of 5000
dighost.c:3135:query_attach(0x7ffa2ae421c0) = 5
sending a request
sendcount=1
dighost.c:1761:query_detach(0x7ffa2ae421c0) = 4
dighost.c:3281:query_detach(0x7ffa2ae421c0) = 3
dighost.c:3282:lookup_detach(0x7ffa2ae00000) = 3
unlock_lookup dighost.c:3283
send_done(0x7ffa2ae81480, success, 0x7ffa2ae421c0)
sendcount=0
lock_lookup dighost.c:2765
success
dighost.c:2769:lookup_attach(0x7ffa2ae00000) = 4
dighost.c:2787:query_detach(0x7ffa2ae421c0) = 2
dighost.c:2788:lookup_detach(0x7ffa2ae00000) = 3
check_if_done()
list empty
unlock_lookup dighost.c:2792
recv_done(0x7ffa2ae81480, success, 0x7ffa2bdfbe90, 0x7ffa2ae421c0)
lock_lookup dighost.c:3955
success
recvcount=0
dighost.c:3960:lookup_attach(0x7ffa2ae00000) = 4
before parse starts
after parse
printmessage()
Server: 0000:0000:000:0000:000:0000:feca:e1ff
Address: 0000:0000:000:0000:000:0000:feca:e1ff#53
clone_lookup()
make_empty_lookup()
make_empty_lookup() = 0x7ffa2ae01800->references = 1
Non-authoritative answer:
printsection()
Name: asd.com
Address: 198.46.84.198
still pending.
dighost.c:4554:query_detach(0x7ffa2ae421c0) = 1
dighost.c:4556:_cancel_lookup()
canceling pending query 0x7ffa2ae42000, belonging to 0x7ffa2ae00000
dighost.c:2817:query_detach(0x7ffa2ae42000) = 0
dighost.c:2817:destroy_query(0x7ffa2ae42000) = 0
dighost.c:1719:lookup_detach(0x7ffa2ae00000) = 3
canceling pending query 0x7ffa2ae421c0, belonging to 0x7ffa2ae00000
dighost.c:2817:query_detach(0x7ffa2ae421c0) = 0
dighost.c:2817:destroy_query(0x7ffa2ae421c0) = 0
dighost.c:1719:lookup_detach(0x7ffa2ae00000) = 2
check_if_done()
list full
pending lookup 0x7ffa2ae01800
dighost.c:4562:lookup_detach(0x7ffa2ae00000) = 1
clear_current_lookup()
lookup cleared
dighost.c:1852:lookup_detach(0x7ffa2ae00000) = 0
destroy_lookup
freeing server 0x7ffa2ae27000 belonging to 0x7ffa2ae00000
start_lookup()
setup_lookup(0x7ffa2ae01800)
cloning server list
clone_server_list()
make_server(0000:0000:000:0000:000:0000:feca:e1ff)
idn_textname: asd.com
using root origin
recursive query
add_question()
starting to render the message
done rendering
create query 0x7ffa2ae421c0 linked to lookup 0x7ffa2ae01800
dighost.c:2177:lookup_attach(0x7ffa2ae01800) = 2
dighost.c:2690:new_query(0x7ffa2ae421c0) = 1
do_lookup()
start_udp(0x7ffa2ae421c0)
dighost.c:3301:query_attach(0x7ffa2ae421c0) = 2
working on lookup 0x7ffa2ae01800, query 0x7ffa2ae421c0
dighost.c:3346:query_attach(0x7ffa2ae421c0) = 3
unlock_lookup dighost.c:4566
udp_ready()
udp_ready(0x7ffa2ae81000, success, 0x7ffa2ae421c0)
lock_lookup dighost.c:3188
success
dighost.c:3189:lookup_attach(0x7ffa2ae01800) = 3
dighost.c:3261:query_attach(0x7ffa2ae421c0) = 4
recving with lookup=0x7ffa2ae01800, query=0x7ffa2ae421c0, handle=0x7ffa2ae81000
recvcount=1
have local timeout of 5000
dighost.c:3135:query_attach(0x7ffa2ae421c0) = 5
sending a request
sendcount=1
dighost.c:1761:query_detach(0x7ffa2ae421c0) = 4
dighost.c:3281:query_detach(0x7ffa2ae421c0) = 3
dighost.c:3282:lookup_detach(0x7ffa2ae01800) = 2
unlock_lookup dighost.c:3283
send_done(0x7ffa2ae81000, success, 0x7ffa2ae421c0)
sendcount=0
lock_lookup dighost.c:2765
success
dighost.c:2769:lookup_attach(0x7ffa2ae01800) = 3
dighost.c:2787:query_detach(0x7ffa2ae421c0) = 2
dighost.c:2788:lookup_detach(0x7ffa2ae01800) = 2
check_if_done()
list empty
unlock_lookup dighost.c:2792
recv_done(0x7ffa2ae81000, success, 0x7ffa2bdfbe90, 0x7ffa2ae421c0)
lock_lookup dighost.c:3955
success
recvcount=0
dighost.c:3960:lookup_attach(0x7ffa2ae01800) = 3
before parse starts
after parse
printmessage()
still pending.
dighost.c:4554:query_detach(0x7ffa2ae421c0) = 1
dighost.c:4556:_cancel_lookup()
canceling pending query 0x7ffa2ae421c0, belonging to 0x7ffa2ae01800
dighost.c:2817:query_detach(0x7ffa2ae421c0) = 0
dighost.c:2817:destroy_query(0x7ffa2ae421c0) = 0
dighost.c:1719:lookup_detach(0x7ffa2ae01800) = 2
check_if_done()
list empty
dighost.c:4562:lookup_detach(0x7ffa2ae01800) = 1
clear_current_lookup()
lookup cleared
dighost.c:1852:lookup_detach(0x7ffa2ae01800) = 0
destroy_lookup
freeing server 0x7ffa2ae27000 belonging to 0x7ffa2ae01800
start_lookup()
check_if_done()
list empty
shutting down
dighost_shutdown()
unlock_lookup dighost.c:4566
```
### What is the expected *correct* behavior?
No communication error and bind to wait up to 5 seconds for the DNS server to respond instead of giving up instantly.
### Relevant configuration files
resolv.conf:
```
search guest.ktmba. inf.ktmba. office.redacted.com.
nameserver 0000:0000:000:0000:000:0000:feca:e1ff
```
### Relevant logs and/or screenshots
Wireshark confirming that `nslookup` did not wait at all for a timeout before retrying, resulting in the DNS server responding twice, resulting in the unreachable response for the first request `nslookup` didn't wait for.
![2023-09-09-225658_922x104_scrot](/uploads/2b23d504c1c1d2a2f32d8b5cb40d59da/2023-09-09-225658_922x104_scrot.png)https://gitlab.isc.org/isc-projects/kea/-/issues/3059need latest schema version of mysql database2023-09-08T22:24:19ZSandeep Gagalapallyneed latest schema version of mysql databasehello,
Can you please share the link for the latest schema of MySQL database. ?
I am running Kea version 2.4.0.
```
2023-09-08 17:57:11.212 ERROR [kea-dhcp4.dhcp4/7794.140675040609408] DHCP4_PARSER_COMMIT_FAIL parser failed to commit...hello,
Can you please share the link for the latest schema of MySQL database. ?
I am running Kea version 2.4.0.
```
2023-09-08 17:57:11.212 ERROR [kea-dhcp4.dhcp4/7794.140675040609408] DHCP4_PARSER_COMMIT_FAIL parser failed to commit changes: during update from config backend database: MySQL schema version mismatch: need version: 19.0 found version: 1.0
```
Thanks,
Sandeephttps://gitlab.isc.org/isc-projects/kea/-/issues/3057Update Template Classes in the ARM2024-03-22T06:23:10ZPeter DaviesUpdate Template Classes in the ARMTo save duplicating work in updating two sources of documentation it has been
suggested the the KB article about [template](https://kb.isc.org/docs/facilitating-classification-with-template-classes) classes could be moved to the ARM. ...To save duplicating work in updating two sources of documentation it has been
suggested the the KB article about [template](https://kb.isc.org/docs/facilitating-classification-with-template-classes) classes could be moved to the ARM.
The "Facilitating Classification with Template Classes" KB article contain the
following use case examples:
Example. OUI Vendor
Use case 1. Reference the spawned class directly in configuration
Use case 2. Have a class dependency on the template class or spawned class
Use case 3. Define the spawned class
Use case 4. Lease limiting and rate limiting ok
The following examples are not found in the ARM:
Use case 1. Reference the spawned class directly in configuration
Use case 2. Have a class dependency on the template class or spawned classnext-stable-2.6