ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-11-17T16:00:17Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/418problem with missing users menu and not visible dashboard for regular user2020-11-17T16:00:17ZMichal Nowikowskiproblem with missing users menu and not visible dashboard for regular user0.12Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/stork/-/issues/417Sanity checks for 0.12.02022-02-02T09:51:29ZMichal NowikowskiSanity checks for 0.12.0Please do sanity checks according to steps below:
1. Please, get the tarball and check it, run tests.<br>
tarball: https://gitlab.isc.org/isc-projects/stork/-/jobs/1207366/artifacts/browse
2. Start demo locally (rake docker_up) ...Please do sanity checks according to steps below:
1. Please, get the tarball and check it, run tests.<br>
tarball: https://gitlab.isc.org/isc-projects/stork/-/jobs/1207366/artifacts/browse
2. Start demo locally (rake docker_up) and follow the steps from https://gitlab.isc.org/isc-projects/stork/-/wikis/Demo
3. Install server and agent locally e.g. in VMs from binary packages:<br>
debs: https://gitlab.isc.org/isc-projects/stork/-/jobs/1207367/artifacts/browse<br>
rpms: https://gitlab.isc.org/isc-projects/stork/-/jobs/1207368/artifacts/browse0.12https://gitlab.isc.org/isc-projects/kea/-/issues/1458suboptimal retrieval of host reservation in the case of db backends2022-06-24T09:41:05ZRazvan Becheriusuboptimal retrieval of host reservation in the case of db backendsin void AllocEngine::findReservation(ClientContext[4|6]& ctx)
```
void
AllocEngine::findReservation(ClientContext[4|6]& ctx) {
ctx.hosts_.clear();
// If there is no subnet, there is nothing to do.
if (!ctx.subnet_) {
...in void AllocEngine::findReservation(ClientContext[4|6]& ctx)
```
void
AllocEngine::findReservation(ClientContext[4|6]& ctx) {
ctx.hosts_.clear();
// If there is no subnet, there is nothing to do.
if (!ctx.subnet_) {
return;
}
auto subnet = ctx.subnet_;
std::map<SubnetID, ConstHostPtr> host_map;
SharedNetwork[4|6]Ptr network;
subnet->getSharedNetwork(network);
if (subnet->getHostReservationMode() == Network::HR_GLOBAL) {
ConstHostPtr ghost = findGlobalReservation(ctx);
if (ghost) {
ctx.hosts_[SUBNET_ID_GLOBAL] = ghost;
// @todo In theory, to support global as part of HR_ALL,
// we would just keep going, instead of returning.
return;
}
}
// If the subnet belongs to a shared network it is usually going to be
// more efficient to make a query for all reservations for a particular
// client rather than a query for each subnet within this shared network.
// The only case when it is going to be less efficient is when there are
// more host identifier types in use than subnets within a shared network.
// As it breaks RADIUS use of host caching this can be disabled by the
// host manager.
const bool use_single_query = network &&
!HostMgr::instance().getDisableSingleQuery() &&
(network->getAllSubnets()->size() > ctx.host_identifiers_.size());
if (use_single_query) {
for (auto id_pair : ctx.host_identifiers_) {
ConstHostCollection hosts = HostMgr::instance().getAll(id_pair.first,
&id_pair.second[0],
id_pair.second.size());
// Store the hosts in the temporary map, because some hosts may
// belong to subnets outside of the shared network. We'll need
// to eliminate them.
for (auto host = hosts.begin(); host != hosts.end(); ++host) {
if ((*host)->getIPv[4|6]SubnetID()) {
host_map[(*host)->getIPv[4|6]SubnetID()] = *host;
}
}
}
}
// We can only search for the reservation if a subnet has been selected.
while (subnet) {
// Only makes sense to get reservations if the client has access
// to the class and host reservations are enabled.
if (subnet->clientSupported(ctx.query_->getClasses()) &&
(subnet->getHostReservationMode() != Network::HR_DISABLED)) {
// Iterate over configured identifiers in the order of preference
// and try to use each of them to search for the reservations.
for (auto id_pair : ctx.host_identifiers_) {
if (use_single_query) {
if (host_map.count(subnet->getID()) > 0) {
ctx.hosts_[subnet->getID()] = host_map[subnet->getID()];
break;
}
} else {
// Attempt to find a host using a specified identifier.
ConstHostPtr host = HostMgr::instance().get[4|6](subnet->getID(),
id_pair.first,
&id_pair.second[0],
id_pair.second.size());
// If we found matching host for this subnet.
if (host) {
ctx.hosts_[subnet->getID()] = host;
break;
}
}
}
}
// We need to get to the next subnet if this is a shared network. If it
// is not (a plain subnet), getNextSubnet will return NULL and we're
// done here.
subnet = subnet->getNextSubnet(ctx.subnet_, ctx.query_->getClasses());
}
}
```
vs
```
void
AllocEngine::findReservation(ClientContext[4|6]& ctx) {
ctx.hosts_.clear();
// If there is no subnet, there is nothing to do.
if (!ctx.subnet_) {
return;
}
auto subnet = ctx.subnet_;
std::map<SubnetID, ConstHostPtr> host_map;
SharedNetwork[4|6]Ptr network;
subnet->getSharedNetwork(network);
if (subnet->getHostReservationMode() == Network::HR_GLOBAL) {
ConstHostPtr ghost = findGlobalReservation(ctx);
if (ghost) {
ctx.hosts_[SUBNET_ID_GLOBAL] = ghost;
// @todo In theory, to support global as part of HR_ALL,
// we would just keep going, instead of returning.
return;
}
}
// If the subnet belongs to a shared network it is usually going to be
// more efficient to make a query for all reservations for a particular
// client rather than a query for each subnet within this shared network.
// The only case when it is going to be less efficient is when there are
// more host identifier types in use than subnets within a shared network.
// As it breaks RADIUS use of host caching this can be disabled by the
// host manager.
***
// Can not call getAll[4|6] because RADIUS does not support it.
// While the performance is acceptable for RADIUS and CfgHosts, doing
// network->getAllSubnets()->size() * ctx.host_identifiers_.size() for
// db backends is suboptimal, as getAll[4|6] is supported.
// This results in
// network->getAllSubnets()->size() * ctx.host_identifiers_.size()
// roundtrips vs network->getAllSubnets()->size() number of roundtrips
// Should this function be implemented as a Host virtual function?
***
const bool use_single_query = network &&
!HostMgr::instance().getDisableSingleQuery() &&
(network->getAllSubnets()->size() > ctx.host_identifiers_.size());
if (use_single_query) {
for (auto id_pair : ctx.host_identifiers_) {
ConstHostCollection hosts = HostMgr::instance().getAll(id_pair.first,
&id_pair.second[0],
id_pair.second.size());
// Store the hosts in the temporary map, because some hosts may
// belong to subnets outside of the shared network. We'll need
// to eliminate them.
for (auto host = hosts.begin(); host != hosts.end(); ++host) {
if ((*host)->getIPv[4|6]SubnetID()) {
host_map[(*host)->getIPv[4|6]SubnetID()] = *host;
}
}
}
}
// We can only search for the reservation if a subnet has been selected.
while (subnet) {
// Only makes sense to get reservations if the client has access
// to the class and host reservations are enabled.
if (subnet->clientSupported(ctx.query_->getClasses()) &&
(subnet->getHostReservationMode() != Network::HR_DISABLED)) {
// Iterate over configured identifiers in the order of preference
// and try to use each of them to search for the reservations.
ConstHostCollection subnet_hosts;
if (!use_single_query) {
subnet_hosts = HostMgr::instance().getAll[4|6](subnet->getID());
}
for (auto id_pair : ctx.host_identifiers_) {
if (use_single_query) {
if (host_map.count(subnet->getID()) > 0) {
ctx.hosts_[subnet->getID()] = host_map[subnet->getID()];
}
} else {
ConstHostPtr host;
for (auto current : subnet_hosts) {
if (current->getIdentifierType() != id_pair.first) {
continue;
}
if (current->getIdentifier() != id_pair.second) {
continue;
}
host = current;
break;
}
// If we found matching host for this subnet.
if (host) {
ctx.hosts_[subnet->getID()] = host;
break;
}
}
}
}
// We need to get to the next subnet if this is a shared network. If it
// is not (a plain subnet), getNextSubnet will return NULL and we're
// done here.
subnet = subnet->getNextSubnet(ctx.subnet_, ctx.query_->getClasses());
}
}
```
Things to note:
1. the following comment is misleading:
```
// If the subnet belongs to a shared network it is usually going to be
// more efficient to make a query for all reservations for a particular
// client rather than a query for each subnet within this shared network.
// The only case when it is going to be less efficient is when there are
// more host identifier types in use than subnets within a shared network.
// As it breaks RADIUS use of host caching this can be disabled by the
// host manager.
```
2. the following check is wrong, because it uses the slow path for db backends when using global subnets:
```
const bool use_single_query = network &&
!HostMgr::instance().getDisableSingleQuery() &&
(network->getAllSubnets()->size() > ctx.host_identifiers_.size());
```
because of the RADIUS limitation, there are still network->getAllSubnets()->size() * ctx.host_identifiers_.size() calls.
This is optimal for CfgHosts and it is a limitation for RADIUS, but it is very bad on db backends as it does a lot of roundtrips (slower than actual in RAM filtering by calling getAll[4|6] and keeping hosts with matching identifiers).
Because there is no easy way to optimize this, maybe this function can be implemented as a virtual function in each backend:
CfgHosts and Radius can use current implementation by calling get[4|6] for each subnet and for each identifier type, and mysql, postgresql and cassandra can call getAll[4|6] for each subnet and filter the identifiers in ram (effectively lowering the number of roundtrips).
It can also be implemented by adding a flag just like in case of RADIUS, 'getDisableSingleQuery', like 'getAllQueryEnabled', but , by using this approach, there is no way RADIUS can function with a db backend in an optimal way.kea1.9.4Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2201libuv needs set_tcp_maxseg() equivalent2022-04-04T12:01:14ZMark Andrewslibuv needs set_tcp_maxseg() equivalentApril 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/stork/-/issues/416Changes for release 0.122020-10-07T08:51:39ZMichal NowikowskiChanges for release 0.120.12Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2200The fuzzer dns_message_parse.c is leaking memory.2020-10-07T09:00:14ZMark AndrewsThe fuzzer dns_message_parse.c is leaking memory.Job [#1203280](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1203280) failed for f0a66cb5aadd741c799f80079a86389d0423c3a3:
```
==12100==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1017 byte(s) in 9 object(s) allocated...Job [#1203280](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1203280) failed for f0a66cb5aadd741c799f80079a86389d0423c3a3:
```
==12100==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1017 byte(s) in 9 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a7d7 in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:451:11
#6 0x7f7780ad7c5a in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2029:4
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c6e409 in towire_ptr /builds/isc-projects/bind9/lib/dns/./rdata/generic/ptr_12.c:105:10
#9 0x7f7780c67f9a in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Direct leak of 904 byte(s) in 8 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a7d7 in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:451:11
#6 0x7f7780ad7820 in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2047:3
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c78caa in towire_nsec /builds/isc-projects/bind9/lib/dns/./rdata/generic/nsec_47.c:112:2
#9 0x7f7780c6826a in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Direct leak of 339 byte(s) in 3 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a7d7 in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:451:11
#6 0x7f7780ad7820 in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2047:3
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c6e409 in towire_ptr /builds/isc-projects/bind9/lib/dns/./rdata/generic/ptr_12.c:105:10
#9 0x7f7780c67f9a in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Direct leak of 113 byte(s) in 1 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a7d7 in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:451:11
#6 0x7f7780ad7820 in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2047:3
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c78689 in towire_rrsig /builds/isc-projects/bind9/lib/dns/./rdata/generic/rrsig_46.c:350:2
#9 0x7f7780c67aea in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Indirect leak of 6667 byte(s) in 59 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a7d7 in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:451:11
#6 0x7f7780ad7820 in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2047:3
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c78689 in towire_rrsig /builds/isc-projects/bind9/lib/dns/./rdata/generic/rrsig_46.c:350:2
#9 0x7f7780c67aea in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Indirect leak of 5537 byte(s) in 49 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a7d7 in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:451:11
#6 0x7f7780ad7820 in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2047:3
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c78caa in towire_nsec /builds/isc-projects/bind9/lib/dns/./rdata/generic/nsec_47.c:112:2
#9 0x7f7780c6826a in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Indirect leak of 1140 byte(s) in 57 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a50d in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:417:9
#6 0x7f7780ad7820 in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2047:3
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c78689 in towire_rrsig /builds/isc-projects/bind9/lib/dns/./rdata/generic/rrsig_46.c:350:2
#9 0x7f7780c67aea in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Indirect leak of 1017 byte(s) in 9 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a7d7 in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:451:11
#6 0x7f7780ad7820 in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2047:3
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c6e409 in towire_ptr /builds/isc-projects/bind9/lib/dns/./rdata/generic/ptr_12.c:105:10
#9 0x7f7780c67f9a in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Indirect leak of 903 byte(s) in 27 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a50d in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:417:9
#6 0x7f7780ad7820 in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2047:3
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c78caa in towire_nsec /builds/isc-projects/bind9/lib/dns/./rdata/generic/nsec_47.c:112:2
#9 0x7f7780c6826a in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Indirect leak of 678 byte(s) in 6 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a7d7 in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:451:11
#6 0x7f7780ad7820 in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2047:3
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c74f5e in towire_in_srv /builds/isc-projects/bind9/lib/dns/./rdata/in_1/srv_33.c:192:10
#9 0x7f7780c67e05 in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Indirect leak of 452 byte(s) in 4 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a7d7 in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:451:11
#6 0x7f7780ad7c5a in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2029:4
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c6e409 in towire_ptr /builds/isc-projects/bind9/lib/dns/./rdata/generic/ptr_12.c:105:10
#9 0x7f7780c67f9a in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Indirect leak of 392 byte(s) in 13 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a50d in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:417:9
#6 0x7f7780ad7c5a in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2029:4
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c6e409 in towire_ptr /builds/isc-projects/bind9/lib/dns/./rdata/generic/ptr_12.c:105:10
#9 0x7f7780c67f9a in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Indirect leak of 254 byte(s) in 6 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a50d in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:417:9
#6 0x7f7780ad7820 in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2047:3
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c6e409 in towire_ptr /builds/isc-projects/bind9/lib/dns/./rdata/generic/ptr_12.c:105:10
#9 0x7f7780c67f9a in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Indirect leak of 226 byte(s) in 2 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a7d7 in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:451:11
#6 0x7f7780ad7820 in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2047:3
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c7640f in towire_in_kx /builds/isc-projects/bind9/lib/dns/./rdata/in_1/kx_36.c:121:10
#9 0x7f7780c67c00 in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Indirect leak of 226 byte(s) in 2 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a7d7 in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:451:11
#6 0x7f7780ad7820 in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2047:3
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c77266 in towire_dname /builds/isc-projects/bind9/lib/dns/./rdata/generic/dname_39.c:93:10
#9 0x7f7780c68256 in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Indirect leak of 33 byte(s) in 1 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a50d in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:417:9
#6 0x7f7780ad7820 in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2047:3
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c7640f in towire_in_kx /builds/isc-projects/bind9/lib/dns/./rdata/in_1/kx_36.c:121:10
#9 0x7f7780c67c00 in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Indirect leak of 29 byte(s) in 1 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a50d in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:417:9
#6 0x7f7780ad7820 in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2047:3
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c74f5e in towire_in_srv /builds/isc-projects/bind9/lib/dns/./rdata/in_1/srv_33.c:192:10
#9 0x7f7780c67e05 in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
Indirect leak of 27 byte(s) in 1 object(s) allocated from:
#0 0x496b2d in malloc (/builds/isc-projects/bind9/fuzz/.libs/dns_message_parse+0x496b2d)
#1 0x7f77819380f0 in default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:713:8
#2 0x7f7781928251 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:622:8
#3 0x7f77819382c7 in isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1044:9
#4 0x7f7781921460 in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2432:10
#5 0x7f778086a50d in dns_compress_add /builds/isc-projects/bind9/lib/dns/compress.c:417:9
#6 0x7f7780ad7820 in dns_name_towire2 /builds/isc-projects/bind9/lib/dns/name.c:2047:3
#7 0x7f7780ad6b5a in dns_name_towire /builds/isc-projects/bind9/lib/dns/name.c:1930:10
#8 0x7f7780c77266 in towire_dname /builds/isc-projects/bind9/lib/dns/./rdata/generic/dname_39.c:93:10
#9 0x7f7780c68256 in dns_rdata_towire /builds/isc-projects/bind9/lib/dns/rdata.c:804:2
#10 0x7f7780d837b3 in towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:492:13
#11 0x7f7780d824f5 in dns_rdataset_towiresorted /builds/isc-projects/bind9/lib/dns/rdataset.c:554:10
#12 0x7f7780a2329c in dns_message_rendersection /builds/isc-projects/bind9/lib/dns/message.c:2129:15
#13 0x4c776f in render_message /builds/isc-projects/bind9/fuzz/dns_message_parse.c:119:2
#14 0x4c6582 in LLVMFuzzerTestOneInput /builds/isc-projects/bind9/fuzz/dns_message_parse.c:164:11
#15 0x4c8614 in test_one_file /builds/isc-projects/bind9/fuzz/main.c:51:3
#16 0x4c88f8 in test_all_from /builds/isc-projects/bind9/fuzz/main.c:87:3
#17 0x4c80bd in main /builds/isc-projects/bind9/fuzz/main.c:123:2
#18 0x7f777fdcf09a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
SUMMARY: AddressSanitizer: 19954 byte(s) leaked in 258 allocation(s).
FAIL dns_message_parse (exit status: 134)
```October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2199assertions.c:112:2: warning: ‘%s’ directive argument is null2020-10-07T09:34:47ZMichal Nowakassertions.c:112:2: warning: ‘%s’ directive argument is nullOn `v9_11` compiling with `--without-dlopen` produces warning:
```
gcc -I/home/newman/isc/ws/bind9-private -I../.. -I./unix/include -I./pthreads/include -I./x86_32/include -I./include -I./include -I/home/newman/isc/ws/bind9-private/lib...On `v9_11` compiling with `--without-dlopen` produces warning:
```
gcc -I/home/newman/isc/ws/bind9-private -I../.. -I./unix/include -I./pthreads/include -I./x86_32/include -I./include -I./include -I/home/newman/isc/ws/bind9-private/lib/dns/include -I../../lib/dns/include -D_REENTRANT -DOPENSSL -DPK11_LIB_LOCATION=\"undefined\" -D_GNU_SOURCE -g -O2 -I/usr/include/libxml2 -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -fno-delete-null-pointer-checks -c assertions.c
assertions.c: In function ‘default_callback’:
assertions.c:112:2: warning: ‘%s’ directive argument is null [-Wformat-overflow=]
112 | fprintf(stderr, "%s:%d: %s(%s) %s%s\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
113 | file, line, isc_assertion_typetotext(type), cond,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
114 | isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
115 | ISC_MSG_FAILED, "failed"), logsuffix);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
assertions.c:112:2: warning: ‘%s’ directive argument is null [-Wformat-overflow=]
```October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)https://gitlab.isc.org/isc-projects/kea/-/issues/1457Pools in example configurations conflict2020-11-16T08:18:24ZAndrei Pavelandrei@isc.orgPools in example configurations conflictI know pools are the first thing an administrator changes in a real environment, but then there are developers who try to come up with a fast local setup and take inspiration from example configurations. And then they stumble upon
`
DHC...I know pools are the first thing an administrator changes in a real environment, but then there are developers who try to come up with a fast local setup and take inspiration from example configurations. And then they stumble upon
`
DHCP6_INIT_FAIL [..] subnet configuration failed: a pool of type IA_PD, with the following address range: 2001:db8::-2001:db8:ff:ffff:ffff:ffff:ffff:ffff overlaps with an existing pool in the subnet: 2001:db8::/32 to which it is being added
`
This is the case for `kea6/all-keys.json`, but there might be others. Pools can be easily changed to not come into conflict, so let's do that.kea1.9.2Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1456Minor bug in inheritance2020-12-09T14:19:27ZFrancis DupontMinor bug in inheritancegetGlobalProperty does not work as expected with Triplet return type so for instance maximum and minimum lifetimes are not inherited from global values when a subnet is added by the configuration backend.
Note when this will be fixed we...getGlobalProperty does not work as expected with Triplet return type so for instance maximum and minimum lifetimes are not inherited from global values when a subnet is added by the configuration backend.
Note when this will be fixed we should be able to get rid of the syntax inheritance i.e. here of deriveParameters.kea1.9.3Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1455Automating code formatting2021-01-24T15:25:46ZAndrei Pavelandrei@isc.orgAutomating code formattingI've attempted this [once before](https://github.com/isc-projects/kea/pull/46). I'm ghost, for the shame of being rejected I had deleted my account. Kidding. But trying this one more time.
Essentially this means a `.clang-format` file d...I've attempted this [once before](https://github.com/isc-projects/kea/pull/46). I'm ghost, for the shame of being rejected I had deleted my account. Kidding. But trying this one more time.
Essentially this means a `.clang-format` file describing how code should be formatted placed at the root of the Kea repository.
The file needs to be in the root of the repository so that editors can pick up on it. vim, vscode, sublime, clion, eclipse all know to look there for it by default or with the right plugin installed. Select the code you contributed -> Format Selection. Furthermore, this is a project-specific set of settings, if you work on other projects you might not want them formatted the same way which is why it is not suited as a global set of settings. If this were to be placed in a separate repository, it would have to be copied to Kea each time. Personally, I have two practices which make this too laborius.
One - I clean my git repository very often `git clean -dffx .`, usually before each new build.
Two - I clone a separate directory for each issue, having to copy the `.clang-format` each time.
`clang-format` is de facto accepted as the best code formatter for C++.
This [.clang-format](/uploads/ff468ff6c120b060e35b055e16d3b179/.clang-format) is by design very close to [the coding guidelines](https://gitlab.isc.org/isc-projects/kea/-/wikis/Processes/coding-guidelines). It takes away the worry of having to know the coding guidelines by heart.
I noticed that [libockless](https://gitlab.isc.org/isc-projects/libockless) has one too.
What are your thoughts?kea1.9.4Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1454PDExclude example in kea6/all-keys.json is invalid2020-10-16T10:42:33ZAndrei Pavelandrei@isc.orgPDExclude example in kea6/all-keys.json is invalidUsing the pool which contains the `"excluded-prefix"` and `"excluded-prefix-len"` fields found in `all-keys.json` would result in
`
DHCP6_INIT_FAIL failed to initialize Kea server: configuration error using file '/etc/kea-dhcp6.conf': E...Using the pool which contains the `"excluded-prefix"` and `"excluded-prefix-len"` fields found in `all-keys.json` would result in
`
DHCP6_INIT_FAIL failed to initialize Kea server: configuration error using file '/etc/kea-dhcp6.conf': Excluded prefix (48) must be longer than the delegated prefix length (64
`
which, mind you, is also missing a bracket at the end.kea1.9.1Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1453Some .cc files are missing config.h include2020-11-09T12:14:37ZAndrei Pavelandrei@isc.orgSome .cc files are missing config.h includePer the coding guidelines
> top level config.h generated by autoconf should also be included before other generic header files
This doesn't imply that all of them should have it, but there doesn't seem to be a reason why a number of 32...Per the coding guidelines
> top level config.h generated by autoconf should also be included before other generic header files
This doesn't imply that all of them should have it, but there doesn't seem to be a reason why a number of 32 non-generated `.cc` files are missing the `config.h` include. This is dangerous because you could be missing a defined macro in some code and not realize it.kea1.9.2Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2198CID 309658: Null pointer dereferences (REVERSE_INULL) in lib/dns/zone.c2020-10-07T08:59:06ZMichal NowakCID 309658: Null pointer dereferences (REVERSE_INULL) in lib/dns/zone.cCoverity Scan identified null pointer dereference on [`main`](https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=36270434&defectInstanceId=11118673&mergedDefectId=309658) and later on [`v9_16`](https://scan8.coverity.com...Coverity Scan identified null pointer dereference on [`main`](https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=36270434&defectInstanceId=11118673&mergedDefectId=309658) and later on [`v9_16`](https://scan8.coverity.com/reports.htm#v38342/p12582/fileInstanceId=36271991&defectInstanceId=11118776&mergedDefectId=309658):
```
*** CID 309658: Null pointer dereferences (REVERSE_INULL)
/lib/dns/zone.c: 13461 in create_query()
13455 if (qname != NULL) {
13456 dns_message_puttempname(message, &qname);
13457 }
13458 if (qrdataset != NULL) {
13459 dns_message_puttemprdataset(message, &qrdataset);
13460 }
>>> CID 309658: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "message" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
13461 if (message != NULL) {
13462 dns_message_detach(&message);
13463 }
13464 return (result);
13465 }
13466
```
Adding to %"October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.17.6)" milestone as this slipped-in this milestone.October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)https://gitlab.isc.org/isc-projects/kea/-/issues/1452Document installing FreeRADIUS from packages2023-07-17T13:58:20ZTomek MrugalskiDocument installing FreeRADIUS from packagesSee the background for this report in [support#16875](https://support.isc.org/Ticket/Display.html?id=16875).
In essence, the error observed was:
```
HOOKS_OPEN_ERROR failed to open hook library /usr/lib64/kea/hooks/libdhcp_radius.so: /...See the background for this report in [support#16875](https://support.isc.org/Ticket/Display.html?id=16875).
In essence, the error observed was:
```
HOOKS_OPEN_ERROR failed to open hook library /usr/lib64/kea/hooks/libdhcp_radius.so: /usr/lib64/kea/hooks/libdhcp_radius.so: undefined symbol: rc_acct_async
DHCP4_PARSER_FAIL failed to create or run parser for configuration element hooks-libraries: hooks libraries failed to validate - library or libraries in error are: /usr/lib64/kea/hooks/libdhcp_radius.so(/etc/kea/kea-dhcp4.conf:10:5)
```
However, the underlying problem is that incorrect FreeRADIUS version was installed. It was a plain FreeRADIUS, without Francis' patch. This should be better explained in the docs. Something along "if you see this error, please install the patched FreeRADIUS version".kea2.4.0Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/1451Allow linking with libgtest.so2024-01-22T08:32:18ZAndrei Pavelandrei@isc.orgAllow linking with libgtest.soCurrently Kea reports that googletest is missing even though `libgtest.so` is available. It only looks for `libgtest.a`. On Fedora 32 and maybe other distributions, only `libgtest.so` is provided with the out-of-the-box installed package...Currently Kea reports that googletest is missing even though `libgtest.so` is available. It only looks for `libgtest.a`. On Fedora 32 and maybe other distributions, only `libgtest.so` is provided with the out-of-the-box installed package and it would be nice to link with it rather than having to build googletest from sources.kea1.9.1Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1450Log every authentication attempt2020-12-04T13:12:42ZVicky Riskvicky@isc.orgLog every authentication attemptIt is important to log every authentication attempt, whether successful or failed, and the userID used.
Then, in the log for api calls, we should also add the authenticated userID who made that api call.
This was either not implemented ...It is important to log every authentication attempt, whether successful or failed, and the userID used.
Then, in the log for api calls, we should also add the authenticated userID who made that api call.
This was either not implemented in the basic authentication ticket, or it is not working.
see https://support.isc.org/Ticket/Display.html?id=17184kea1.9.1Vicky Riskvicky@isc.orgVicky Riskvicky@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/415Basic access control Stork user -> Kea access2022-11-03T14:54:25ZVicky Riskvicky@isc.orgBasic access control Stork user -> Kea accessThe Kea administrator would like to be able to control who can access Kea. This includes individual Stork users, as Stork is just one channel for accessing Kea.
At the moment Stork is read-only, but it won't always be, and even control...The Kea administrator would like to be able to control who can access Kea. This includes individual Stork users, as Stork is just one channel for accessing Kea.
At the moment Stork is read-only, but it won't always be, and even controlling read-only access is important.
So it would be desirable if Stork would forward the userID of the authenticated Stork user to the Stork agent, and for this userID to be used to control the user's access to Kea, based on the privileges assigned to that user in Kea.
It is also as important as controlling access to log that access, with a time/date stamp, and what commands/api calls were executed. When there is write access (in the future) via Stork to make configuration changes, it will be particularly critical to identify who changed the configuration at what time.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1449Same vendor-specific-option has been attached multiple times under option 17 ...2020-12-04T09:00:28ZShubham GaurSame vendor-specific-option has been attached multiple times under option 17 if always-send flag is set true.---
name: Bug report
about: Setting "always-send" flag to true results in multiple instances of vendor-specific-option attached.
Further, these instances keep on incrementing within subsequent frames.
---
# Environment Specifica...---
name: Bug report
about: Setting "always-send" flag to true results in multiple instances of vendor-specific-option attached.
Further, these instances keep on incrementing within subsequent frames.
---
# Environment Specification
```
OS: CentOS 7 Virtual Machine
Server: kea-server-1.8 hosted over CentOS 8 Container
Client: isc-dhclient-4.3.6 configured over CentOS 8 Container
```
# Problem Description
I'm configuring dhcpv6 server with kea 1.8 stable version. I want to encapsulate vendor-specific information within option 17.
I faced certain issues and came across a workaround which had success with some undesirable behaviour.
1. Option defined under vendor option space (Eg vendor-12345) is not being sent automatically as part of option 17.
1. Forcing these options resulted in attaching and incrementing that vendor-specific-option within subsequent frames.
# Wireshark feeds
* Here, I have provided the snippet of Wireshark capture. The complete capture can be found in attachments.
```
Frame 4: 186 bytes on wire (1488 bits), 186 bytes captured (1488 bits)
Ethernet II, Src: 02:42:ac:12:00:02 (02:42:ac:12:00:02), Dst: 02:42:ac:12:00:03 (02:42:ac:12:00:03)
Internet Protocol Version 6, Src: fe80::42:acff:fe12:2, Dst: fe80::42:acff:fe12:3
User Datagram Protocol, Src Port: 547, Dst Port: 546
DHCPv6
Message type: Advertise (2)
Transaction ID: 0x01e550
Vendor-specific Information
Option: Vendor-specific Information (17)
Length: 20
Value: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Enterprise ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
option
Option code: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Option length: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Option data: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Frame 14: 202 bytes on wire (1616 bits), 202 bytes captured (1616 bits)
Ethernet II, Src: 02:42:ac:12:00:02 (02:42:ac:12:00:02), Dst: 02:42:ac:12:00:03 (02:42:ac:12:00:03)
Internet Protocol Version 6, Src: fe80::42:acff:fe12:2, Dst: fe80::42:acff:fe12:3
User Datagram Protocol, Src Port: 547, Dst Port: 546
DHCPv6
Message type: Advertise (2)
Transaction ID: 0x613d68
Vendor-specific Information
Option: Vendor-specific Information (17)
Length: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Value: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Enterprise ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
option
Option code: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Option length: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Option data: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
option
Option code: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Option length: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Option data: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
option
Option code: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Option length: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Option data: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
```
# Configurations & logs
[dhclient.conf](/uploads/87b37a1704f3ef58939d139606a57247/dhclient.conf)
[file-v2.pcap](/uploads/88d4a2a176591769166072cb2b4d96c8/file-v2.pcap)
[kea-dhcp6.conf](/uploads/ed6ed11c2a9ac3286fc236f68b7e3bc7/kea-dhcp6.conf)
## Help required
* Filing this scenario as a bug since I could not find any documentation to resolve this issue or meet my requirements.
* I have attached the configuration files. Please verify the same; whether, I have wrongly configured any option or missing out any option, that has to be handled within the conf file.
> PS: Testing env has been set up over container network. Logs/ Pcaps has been attached for the same.kea1.9.3Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/dhcp/-/issues/140Client Link-Layer Address Option in DHCPv62020-11-12T20:22:29ZChristian RebischkeClient Link-Layer Address Option in DHCPv6---
name: Client Link-Layer Address Option in DHCPv6
about: Add Client Link-Layer Address Option in DHCPv6
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? **not sur...---
name: Client Link-Layer Address Option in DHCPv6
about: Add Client Link-Layer Address Option in DHCPv6
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? **not sure**
- Are you sure your feature is not already implemented in the latest Kea version? Perhaps it's a **not sure**
good time to consider migration? **not sure**
- Are you sure what you would like to do is not possible using some other mechanisms? **not sure**
- Have you discussed your idea on dhcp-users or dhcp-workers mailing lists? **no**
**Is your feature request related to a problem? Please describe.**
I would like to see this feature in ISC-DHCP: https://tools.ietf.org/html/rfc6939
**Describe the solution you'd like**
See above
**Describe alternatives you've considered**
There is no real alternative right now, as far as I am aware.
**Additional context**
none
**Funding its development**
Sorry, I can't fund.
**Participating in development**
I would be willing to donate a PR, but my C skills are a little bit rusty and I would need some 'direction' where I need to add this feature. How complicated is this to add? The RFC seems pretty short.
**Contacting you**
christian.rebischke@avency.dehttps://gitlab.isc.org/isc-projects/kea/-/issues/1448Load kea config from another kea server2021-09-30T15:18:17ZPeter DaviesLoad kea config from another kea serverLoad kea config from another kea server
I would appear we have all the necessary mechanisms to enable a secondary HA server to load its configuration from the primary.
This feature could be enabled with a command line parameter that co...Load kea config from another kea server
I would appear we have all the necessary mechanisms to enable a secondary HA server to load its configuration from the primary.
This feature could be enabled with a command line parameter that could instruct the server to look and retrieve its config from a server/address before loading its local config.
In this way users running into issues caused by mismatching configurations and typos.
The interface name and "this-server-name" would need to be syntherzied somehow.Kea1.9-backlog