ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-09-02T11:56:58Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2427CID 316514: Uninitialized variables (UNINIT)2021-09-02T11:56:58ZMichal NowakCID 316514: Uninitialized variables (UNINIT)```
*** CID 316514: Uninitialized variables (UNINIT)
/lib/lwres/lwconfig.c: 320 in lwres_conf_parsenameserver()
314 return (LWRES_R_FAILURE); /* Extra junk on line. */
315
316 res = lwres_create_addr(word, &address, 1);...```
*** CID 316514: Uninitialized variables (UNINIT)
/lib/lwres/lwconfig.c: 320 in lwres_conf_parsenameserver()
314 return (LWRES_R_FAILURE); /* Extra junk on line. */
315
316 res = lwres_create_addr(word, &address, 1);
317 if (res == LWRES_R_SUCCESS &&
318 ((address.family == LWRES_ADDRTYPE_V4 && ctx->use_ipv4 == 1) ||
319 (address.family == LWRES_ADDRTYPE_V6 && ctx->use_ipv6 == 1))) {
>>> CID 316514: Uninitialized variables (UNINIT)
>>> Using uninitialized value "address". Field "address.link" is uninitialized.
320 confdata->nameservers[confdata->nsnext++] = address;
321 }
322
323 return (LWRES_R_SUCCESS);
324 }
325
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2426CID 316504: Untrusted loop bound (TAINTED_SCALAR)2022-03-01T09:57:30ZMichal NowakCID 316504: Untrusted loop bound (TAINTED_SCALAR)```
*** CID 316504: (TAINTED_SCALAR)
/lib/dns/rdata/generic/rrsig_46.c: 233 in totext_rrsig()
227
228 /*
229 * Time signed.
230 */
231 when = uint32_fromregion(&sr);
232 isc_region_consume(&sr, 4);
>>> ...```
*** CID 316504: (TAINTED_SCALAR)
/lib/dns/rdata/generic/rrsig_46.c: 233 in totext_rrsig()
227
228 /*
229 * Time signed.
230 */
231 when = uint32_fromregion(&sr);
232 isc_region_consume(&sr, 4);
>>> CID 316504: (TAINTED_SCALAR)
>>> Passing tainted expression "when" to "dns_time32_totext", which uses it as a loop boundary.
233 RETERR(dns_time32_totext(when, target));
234 RETERR(str_totext(" ", target));
235
236 /*
237 * Footprint.
238 */
/lib/dns/rdata/generic/rrsig_46.c: 225 in totext_rrsig()
219
220 /*
221 * Sig exp.
222 */
223 exp = uint32_fromregion(&sr);
224 isc_region_consume(&sr, 4);
>>> CID 316504: (TAINTED_SCALAR)
>>> Passing tainted expression "exp" to "dns_time32_totext", which uses it as a loop boundary.
225 RETERR(dns_time32_totext(exp, target));
226 RETERR(str_totext(" ", target));
227
228 /*
229 * Time signed.
230 */
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2425CID 316505: Insecure data handling (TAINTED_SCALAR)2022-03-01T09:57:33ZMichal NowakCID 316505: Insecure data handling (TAINTED_SCALAR)```
*** CID 316505: Insecure data handling (TAINTED_SCALAR)
/lib/dns/journal.c: 972 in journal_find()
966 return (ISC_R_SUCCESS);
967 }
968
969 current_pos = j->header.begin;
970 index_find(j, serial, &current...```
*** CID 316505: Insecure data handling (TAINTED_SCALAR)
/lib/dns/journal.c: 972 in journal_find()
966 return (ISC_R_SUCCESS);
967 }
968
969 current_pos = j->header.begin;
970 index_find(j, serial, ¤t_pos);
971
>>> CID 316505: Insecure data handling (TAINTED_SCALAR)
>>> Using tainted variable "current_pos.serial" as a loop boundary.
972 while (current_pos.serial != serial) {
973 if (DNS_SERIAL_GT(current_pos.serial, serial)) {
974 return (ISC_R_NOTFOUND);
975 }
976 result = journal_next(j, ¤t_pos);
977 if (result != ISC_R_SUCCESS) {
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2424CID 316506: Insecure data handling (TAINTED_SCALAR)2022-03-01T09:57:36ZMichal NowakCID 316506: Insecure data handling (TAINTED_SCALAR)```
*** CID 316506: Insecure data handling (TAINTED_SCALAR)
/lib/dns/journal.c: 1855 in read_one_rr()
1849 */
1850 if (isc_buffer_remaininglength(&j->it.source) != rdlen) {
1851 FAIL(DNS_R_FORMERR);
1852 }
1853 ...```
*** CID 316506: Insecure data handling (TAINTED_SCALAR)
/lib/dns/journal.c: 1855 in read_one_rr()
1849 */
1850 if (isc_buffer_remaininglength(&j->it.source) != rdlen) {
1851 FAIL(DNS_R_FORMERR);
1852 }
1853 isc_buffer_setactive(&j->it.source, rdlen);
1854 dns_rdata_reset(&j->it.rdata);
>>> CID 316506: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted expression "j->it.source.active" to "dns_rdata_fromwire", which uses it as a loop boundary.
1855 CHECK(dns_rdata_fromwire(&j->it.rdata, rdclass, rdtype, &j->it.source,
1856 &j->it.dctx, 0, &j->it.target));
1857 j->it.ttl = ttl;
1858
1859 j->it.xpos += sizeof(journal_rawrrhdr_t) + rrhdr.size;
1860 if (rdtype == dns_rdatatype_soa) {
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2423CID 316507: Insecure data handling (TAINTED_SCALAR)2021-03-02T13:57:07ZMichal NowakCID 316507: Insecure data handling (TAINTED_SCALAR)```
*** CID 316507: Insecure data handling (TAINTED_SCALAR)
/lib/dns/rdata/generic/nsec3param_51.c: 241 in tostruct_nsec3param()
235 region.length = rdata->length;
236 nsec3param->hash = uint8_consume_fromregion(&region);
237...```
*** CID 316507: Insecure data handling (TAINTED_SCALAR)
/lib/dns/rdata/generic/nsec3param_51.c: 241 in tostruct_nsec3param()
235 region.length = rdata->length;
236 nsec3param->hash = uint8_consume_fromregion(®ion);
237 nsec3param->flags = uint8_consume_fromregion(®ion);
238 nsec3param->iterations = uint16_consume_fromregion(®ion);
239
240 nsec3param->salt_length = uint8_consume_fromregion(®ion);
>>> CID 316507: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted expression "nsec3param->salt_length" to "mem_maybedup", which uses it as an offset.
241 nsec3param->salt = mem_maybedup(mctx, region.base,
242 nsec3param->salt_length);
243 if (nsec3param->salt == NULL) {
244 return (ISC_R_NOMEMORY);
245 }
246 isc_region_consume(®ion, nsec3param->salt_length);
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2422CID 316508: Insecure data handling (TAINTED_SCALAR)2022-03-01T09:57:39ZMichal NowakCID 316508: Insecure data handling (TAINTED_SCALAR)```
*** CID 316508: Insecure data handling (TAINTED_SCALAR)
/lib/dns/journal.c: 1714 in dns_journal_iter_init()
1708
1709 result = journal_next(j, &pos);
1710 if (result == ISC_R_NOMORE) {
1711 result = ISC_R...```
*** CID 316508: Insecure data handling (TAINTED_SCALAR)
/lib/dns/journal.c: 1714 in dns_journal_iter_init()
1708
1709 result = journal_next(j, &pos);
1710 if (result == ISC_R_NOMORE) {
1711 result = ISC_R_SUCCESS;
1712 }
1713 CHECK(result);
>>> CID 316508: Insecure data handling (TAINTED_SCALAR)
>>> Using tainted variable "pos.serial" as a loop boundary.
1714 } while (pos.serial != end_serial);
1715
1716 /*
1717 * For each RR, subtract the length of the RR header,
1718 * as this would not be present in IXFR messages.
1719 * (We don't need to worry about the transaction header
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2421CID 316509: Untrusted value as argument (TAINTED_SCALAR)2021-03-02T13:57:03ZMichal NowakCID 316509: Untrusted value as argument (TAINTED_SCALAR)```
*** CID 316509: (TAINTED_SCALAR)
/lib/dns/rdata/generic/nsec3_50.c: 312 in tostruct_nsec3()
306 if (nsec3->salt == NULL) {
307 return (ISC_R_NOMEMORY);
308 }
309 isc_region_consume(&region, nsec3->salt_length)...```
*** CID 316509: (TAINTED_SCALAR)
/lib/dns/rdata/generic/nsec3_50.c: 312 in tostruct_nsec3()
306 if (nsec3->salt == NULL) {
307 return (ISC_R_NOMEMORY);
308 }
309 isc_region_consume(®ion, nsec3->salt_length);
310
311 nsec3->next_length = uint8_consume_fromregion(®ion);
>>> CID 316509: (TAINTED_SCALAR)
>>> Passing tainted expression "nsec3->next_length" to "mem_maybedup", which uses it as an offset.
312 nsec3->next = mem_maybedup(mctx, region.base, nsec3->next_length);
313 if (nsec3->next == NULL) {
314 goto cleanup;
315 }
316 isc_region_consume(®ion, nsec3->next_length);
317
/lib/dns/rdata/generic/nsec3_50.c: 305 in tostruct_nsec3()
299 region.length = rdata->length;
300 nsec3->hash = uint8_consume_fromregion(®ion);
301 nsec3->flags = uint8_consume_fromregion(®ion);
302 nsec3->iterations = uint16_consume_fromregion(®ion);
303
304 nsec3->salt_length = uint8_consume_fromregion(®ion);
>>> CID 316509: (TAINTED_SCALAR)
>>> Passing tainted expression "nsec3->salt_length" to "mem_maybedup", which uses it as an offset.
305 nsec3->salt = mem_maybedup(mctx, region.base, nsec3->salt_length);
306 if (nsec3->salt == NULL) {
307 return (ISC_R_NOMEMORY);
308 }
309 isc_region_consume(®ion, nsec3->salt_length);
310
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2420CID 316510: Memory - corruptions (USE_AFTER_FREE)2021-01-28T21:42:48ZMichal NowakCID 316510: Memory - corruptions (USE_AFTER_FREE)```
*** CID 316510: Memory - corruptions (USE_AFTER_FREE)
/bin/named/statschannel.c: 2353 in generatexml()
2347
2348 cleanup:
2349 isc_log_write(named_g_lctx, NAMED_LOGCATEGORY_GENERAL,
2350 NAMED_LOGMODULE_SE...```
*** CID 316510: Memory - corruptions (USE_AFTER_FREE)
/bin/named/statschannel.c: 2353 in generatexml()
2347
2348 cleanup:
2349 isc_log_write(named_g_lctx, NAMED_LOGCATEGORY_GENERAL,
2350 NAMED_LOGMODULE_SERVER, ISC_LOG_ERROR,
2351 "failed generating XML response");
2352 if (writer != NULL) {
>>> CID 316510: Memory - corruptions (USE_AFTER_FREE)
>>> Calling "xmlFreeTextWriter" frees pointer "writer" which has already been freed.
2353 xmlFreeTextWriter(writer);
2354 }
2355 if (doc != NULL) {
2356 xmlFreeDoc(doc);
2357 }
2358 return (ISC_R_FAILURE);
```February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2419CID 316511: Insecure data handling (TAINTED_SCALAR)2022-03-01T09:57:42ZMichal NowakCID 316511: Insecure data handling (TAINTED_SCALAR)```
*** CID 316511: Insecure data handling (TAINTED_SCALAR)
/lib/dns/rdata/generic/hip_55.c: 496 in casecompare_hip()
490 key_len = uint16_fromregion(&r1);
491 isc_region_consume(&r1, 2); /* key length */
492 isc_region_...```
*** CID 316511: Insecure data handling (TAINTED_SCALAR)
/lib/dns/rdata/generic/hip_55.c: 496 in casecompare_hip()
490 key_len = uint16_fromregion(&r1);
491 isc_region_consume(&r1, 2); /* key length */
492 isc_region_consume(&r2, 4);
493
494 INSIST(r1.length >= (unsigned)(hit_len + key_len));
495 INSIST(r2.length >= (unsigned)(hit_len + key_len));
>>> CID 316511: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted expression "hit_len + key_len" to "memcmp", which uses it as an offset.
496 order = memcmp(r1.base, r2.base, hit_len + key_len);
497 if (order != 0) {
498 return (order);
499 }
500 isc_region_consume(&r1, hit_len + key_len);
501 isc_region_consume(&r2, hit_len + key_len);
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2418CID 316512: Untrusted loop bound (TAINTED_SCALAR)2022-03-01T09:57:44ZMichal NowakCID 316512: Untrusted loop bound (TAINTED_SCALAR)```
*** CID 316512: (TAINTED_SCALAR)
/lib/dns/rdata/generic/sig_24.c: 199 in totext_sig()
193
194 /*
195 * Time signed.
196 */
197 when = uint32_fromregion(&sr);
198 isc_region_consume(&sr, 4);
>>> ...```
*** CID 316512: (TAINTED_SCALAR)
/lib/dns/rdata/generic/sig_24.c: 199 in totext_sig()
193
194 /*
195 * Time signed.
196 */
197 when = uint32_fromregion(&sr);
198 isc_region_consume(&sr, 4);
>>> CID 316512: (TAINTED_SCALAR)
>>> Passing tainted expression "when" to "dns_time32_totext", which uses it as a loop boundary.
199 RETERR(dns_time32_totext(when, target));
200 RETERR(str_totext(" ", target));
201
202 /*
203 * Footprint.
204 */
/lib/dns/rdata/generic/sig_24.c: 187 in totext_sig()
181
182 /*
183 * Sig exp.
184 */
185 exp = uint32_fromregion(&sr);
186 isc_region_consume(&sr, 4);
>>> CID 316512: (TAINTED_SCALAR)
>>> Passing tainted expression "exp" to "dns_time32_totext", which uses it as a loop boundary.
187 RETERR(dns_time32_totext(exp, target));
188
189 if ((tctx->flags & DNS_STYLEFLAG_MULTILINE) != 0) {
190 RETERR(str_totext(" (", target));
191 }
192 RETERR(str_totext(tctx->linebreak, target));
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2417CID 316513: Insecure data handling (TAINTED_SCALAR)2022-03-01T09:57:47ZMichal NowakCID 316513: Insecure data handling (TAINTED_SCALAR)```
*** CID 316513: Insecure data handling (TAINTED_SCALAR)
/lib/dns/master.c: 2618 in load_raw()
2612 * the target available region be the same if
2613 * decompression is disabled (see dctx above) and we
2614 *...```
*** CID 316513: Insecure data handling (TAINTED_SCALAR)
/lib/dns/master.c: 2618 in load_raw()
2612 * the target available region be the same if
2613 * decompression is disabled (see dctx above) and we
2614 * are not downcasing names (options == 0).
2615 */
2616 isc_buffer_init(&buf, isc_buffer_current(&target),
2617 (unsigned int)rdlen);
>>> CID 316513: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted expression "target.active" to "dns_rdata_fromwire", which uses it as a loop boundary.
2618 result = dns_rdata_fromwire(
2619 &rdata[i], rdatalist.rdclass, rdatalist.type,
2620 &target, &dctx, 0, &buf);
2621 if (result != ISC_R_SUCCESS) {
2622 goto cleanup;
2623 }
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2416tlsdns_test gets stuck on FreeBSDs intermittently2021-03-29T13:23:28ZOndřej Surýtlsdns_test gets stuck on FreeBSDs intermittentlyThe `tlsdns_test` gets stuck on the FreeBSD 11 and 12 intermittently. It's not related to the OpenSSL version and it happens only occasionally. When it happens all the threads are waiting in either yield or kevent. We might be missing...The `tlsdns_test` gets stuck on the FreeBSD 11 and 12 intermittently. It's not related to the OpenSSL version and it happens only occasionally. When it happens all the threads are waiting in either yield or kevent. We might be missing some `tls_cycle()` invocation on some rare edge condition that happens only on FreeBSD.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2415Update Coverity Scan CI job to 2020.092021-01-25T11:38:06ZMichal NowakUpdate Coverity Scan CI job to 2020.09Coverity Scan was [updated](https://community.synopsys.com/s/question/0D52H00005NeWJf/announcement-upcoming-coverity-scan-upgrade-to-coverity-202009-release) to [2020.09](https://scan.coverity.com/download). The `coverity` CI job assumes...Coverity Scan was [updated](https://community.synopsys.com/s/question/0D52H00005NeWJf/announcement-upcoming-coverity-scan-upgrade-to-coverity-202009-release) to [2020.09](https://scan.coverity.com/download). The `coverity` CI job assumes 2019.03 at few places.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/stork/-/issues/472ARM build?2023-09-26T11:21:43Zid prismARM build?---
name: Cloudsmith packaging enhancement
about: Diversify architecture support
---
I was attempting to install isc products via apt. Bind and Kea exist in the ubuntu/debian arm repos, but stork does not.
**Proposed solution**
Current...---
name: Cloudsmith packaging enhancement
about: Diversify architecture support
---
I was attempting to install isc products via apt. Bind and Kea exist in the ubuntu/debian arm repos, but stork does not.
**Proposed solution**
Currently cloudsmith packages are only for x86_64 systems. Can cloudsmith be used to build an ARM-based .deb/.rpm for release?1.13Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/kea/-/issues/1669formatting tools vs line length limits2021-02-04T16:55:45ZFrancis Dupontformatting tools vs line length limitsWe need hard and soft line limits in the formatting tools to match the code guide lines and keep the code readable... It seems the current tools do not provide soft/hard limits and tuning is a bit hard so #1455 was merged leaving this is...We need hard and soft line limits in the formatting tools to match the code guide lines and keep the code readable... It seems the current tools do not provide soft/hard limits and tuning is a bit hard so #1455 was merged leaving this issue not yet addressed.outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2414inline-signing breaking on 9.11.25 (FreeBSD 11.4)2022-03-01T09:47:38ZDan Mahoneyinline-signing breaking on 9.11.25 (FreeBSD 11.4)<!--
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 do *NOT* report it here, but send an
email to [...<!--
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 do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
Journal becomes corrupted leading to inline-signing failure.
### BIND version used
```
BIND 9.11.25 (Extended Support Version) <id:4a7e9aa>
running on FreeBSD amd64 11.4-RELEASE-p3 FreeBSD 11.4-RELEASE-p3 #0: Tue Sep 1 08:22:33 UTC 2020 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
built by make with '--localstatedir=/var' '--disable-linux-caps' '--with-randomdev=/dev/random' '--with-libxml2=/usr/local' '--with-readline=-L/usr/local/lib -ledit' '--with-dlopen=yes' '--with-gost=no' '--without-python' '--sysconfdir=/usr/local/etc/namedb' '--with-dlz-filesystem=yes' '--enable-dnstap' '--enable-filter-aaaa' '--disable-fixed-rrset' '--without-geoip2' '--without-gssapi' '--with-libidn2=/usr/local' '--enable-ipv6' '--with-libjson=/usr/local' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--disable-querytrace' '--enable-rpz-nsdname' '--enable-rpz-nsip' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--with-openssl=/usr' '--enable-threads' '--with-tuning=default' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd11.4' 'build_alias=amd64-portbld-freebsd11.4' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
compiled by CLANG FreeBSD Clang 10.0.0 (git@github.com:llvm/llvm-project.git llvmorg-10.0.0-0-gd32170dbd5b)
compiled with OpenSSL version: OpenSSL 1.0.2u-freebsd 20 Dec 2019
linked to OpenSSL version: OpenSSL 1.0.2u-freebsd 20 Dec 2019
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with libjson-c version: 0.15
linked to libjson-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.2
linked to protobuf-c version: 1.3.2
threads support is enabled
default paths:
named configuration: /usr/local/etc/namedb/named.conf
rndc configuration: /usr/local/etc/namedb/rndc.conf
DNSSEC root key: /usr/local/etc/namedb/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/pid
named lock file: /var/run/named/named.lock
```
FreeBSD 11.4, AMD64, running as a Vmware vm.
### Steps to reproduce
Issue noticed on my personal machine where named started servfailing a master zone with inline-signing enabled. All slaves failed to receive it as well.
Upon hitting this issue, I deleted the zone.signed.jnl and zone.signed and did an rndc reload which did not help. The zone.jnl appeared to be corrupted.
I've backed up the unsigned zone files and timestamps, but will ask staff whether they want me to upload them elsewhere or attach them here. (I'd prefer this ticket be private if that's the case)
This happened on its own and I can find nothing in the logs.
### What is the current *bug* behavior?
Journal gets out of sync with the main zone, refuses to update the signed copy, starts servfailing, slaves refuse to serve it.
### What is the expected *correct* behavior?
Journal staying consistent.
### Relevant configuration files
```
zone "gushi.org" {
type master;
file "/etc/namedb/m/gushi.org./gushi.org.hosts";
key-directory "/etc/namedb/m/gushi.org./keys";
inline-signing yes;
auto-dnssec maintain;
allow-transfer {
key pri-sec.gushi.org.;
redacted
};
notify yes;
also-notify {
redacted
};
};
```
#### Contents of zone directory:
```
drwxrwxrwx 4 root wheel 512 Jan 16 09:00 .
drwxrwxrwx 48 root wheel 36352 Jan 23 18:48 ..
-rw-r--r-- 1 root wheel 14915 Jan 12 20:25 gushi.org.hosts
-rw-r--r-- 1 bind wheel 512 Mar 16 2020 gushi.org.hosts.jbk
-rw-r--r-- 1 bind wheel 7498 Jan 12 20:23 gushi.org.hosts.jnl
-rw-r--r-- 1 bind wheel 52111 Jan 16 09:00 gushi.org.hosts.signed
-rw-r--r-- 1 bind wheel 1118287 Jan 16 08:49 gushi.org.hosts.signed.jnl
drwxr-xr-x 2 bind wheel 512 Jun 6 2019 keys
drwxr-xr-x 3 root wheel 512 Mar 15 2020 old
```
### Relevant logs and/or screenshots
`/var/log/messages` goes back several days, no mentions in logs:
```
Jan 19 21:00:00 prime newsyslog[98735]: logfile turned over due to size>100K
```
Before and after attempting to update the serial of the zone with zsu and reload yielded:
Before:
```
$TTL 3600
gushi.org. IN SOA ns.gushi.org. root.gushi.org. (
2021011113 ; serial number
7200 ; refresh
7200 ; retry
604800 ; expire
3600 ; minimum TTL
)
root@prime:/var/named/etc/namedb/m/gushi.org. # zsu -v -v -f gushi.org.hosts
```
Zone header:
```
$TTL 3600
gushi.org. IN SOA ns.gushi.org. root.gushi.org. (
2021012400 ; serial number
7200 ; refresh
7200 ; retry
604800 ; expire
3600 ; minimum TTL
)
root@prime:/var/named/etc/namedb/m/gushi.org. # rndc reload gushi.org
rndc: 'reload' failed: out of range
root@prime:/var/named/etc/namedb/m/gushi.org. # grep named /var/log/messages
Jan 24 00:34:04 <daemon.err> prime named[9378]: zone gushi.org/IN (unsigned): journal rollforward failed: journal out of sync with zone
Jan 24 00:34:04 <daemon.err> prime named[9378]: zone gushi.org/IN (unsigned): not loaded due to errors.
Jan 24 00:34:44 <daemon.err> prime named[9378]: zone gushi.org/IN (unsigned): journal rollforward failed: journal out of sync with zone
Jan 24 00:34:44 <daemon.err> prime named[9378]: zone gushi.org/IN (unsigned): not loaded due to errors.
## Finally, removing the .jnl file fixed things.
root@prime:/var/named/etc/namedb/m/gushi.org. # service named stop
Stopping named.
Waiting for PIDS: 9378.
root@prime:/var/named/etc/namedb/m/gushi.org. # rm gushi.org.hosts.jnl
root@prime:/var/named/etc/namedb/m/gushi.org. # service named start
Starting named.
root@prime:/var/named/etc/namedb/m/gushi.org. # rndc reload gushi.org
zone reload up-to-date
root@prime:/var/named/etc/namedb/m/gushi.org. # dig @127.0.0.1 gushi.org SOA
root@prime:/var/named/etc/namedb/m/gushi.org. # dig @127.0.0.1 gushi.org SOA
; <<>> DiG 9.16.9 <<>> @127.0.0.1 gushi.org SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5029
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 85d501bb14ab255c6d056848600d31689fb49aefd8933d7e (good)
;; QUESTION SECTION:
;gushi.org. IN SOA
;; ANSWER SECTION:
gushi.org. 3600 IN SOA ns.gushi.org. root.gushi.org. 2021012437 7200 7200 604800 3600
;; AUTHORITY SECTION:
gushi.org. 360 IN NS ns.gushi.org.
gushi.org. 360 IN NS ns2.gushi.org.
;; ADDITIONAL SECTION:
ns.gushi.org. 360 IN A 199.164.166.132
ns2.gushi.org. 360 IN A 149.20.3.253
ns.gushi.org. 360 IN AAAA 2620:137:6000:10::132
ns2.gushi.org. 360 IN AAAA 2001:4f8:1:2000::253
;; Query time: 9 msec
```
### Possible fixes
Deleting the journal is the only thing that seems to help. I kept a copy of the .jnl/.jbk files from this failure mode, but have not uploaded them. I can do so out of band, or mark this ticket private.Not plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/1668kea-admin alpine 3.11 wrong admin-utils.sh and scripts path / packaging error2021-10-07T09:51:20ZJordiekea-admin alpine 3.11 wrong admin-utils.sh and scripts path / packaging error**Describe the bug**
On the alpine linux (v3.11) latest stable version (1.8.2) distributed via Cloudsmith the path to the database scripts and the `admin-utils.sh` file are wrong. According to the script the path of these files should ...**Describe the bug**
On the alpine linux (v3.11) latest stable version (1.8.2) distributed via Cloudsmith the path to the database scripts and the `admin-utils.sh` file are wrong. According to the script the path of these files should be under `/usr/share/kea/scripts` but the package has these files actually located under `/usr/share/kea/kea/scripts`. This looks to be a packaging error. the package for alpine 3.10 is correct, but for alpine 3.11 it is not.
the contents of the isc-kea-admin package can be seen without installing here: https://cloudsmith.io/~isc/repos/kea-1-8/packages/detail/alpine/isc-kea-admin/1.8.2-risc0001520201206093433/a=noarch;d=alpine%252Fv3.11/#files
**To Reproduce**
Steps to reproduce the behavior:
1. On alpine linux version 3.11, install the repository
2. Install `isc-kea-admin`
3. Run `kea-admin` to read or modify a database
4. See an error: (this is the error when trying to initialize a mysql database, but this issue will be present for almost any command as `admin-utils.sh` is not included properly)
```
/usr/sbin/kea-admin: line 218: mysql_execute: not found
ERROR/kea-admin: mysql_init table query failed, mysql status = 127
```
**Environment:**
- Kea version: 1.8.2
- OS: alpine linux v3.11 (amd64 / x86_64)
- installed from official cloudsmith repository
**Workaround**
```sh
mv /usr/share/kea/kea/* /usr/share/kea/
```kea2.1.0Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/1667Kea 1.6.2 on Ubuntu Server 20.04 unable to start Kea with systemctl2021-10-19T07:42:43ZJRCKea 1.6.2 on Ubuntu Server 20.04 unable to start Kea with systemctlNot sure which template to use.
Kea will not start with systemctl (and therefore at boot). It errors out with:
> Unable to open database: unable to open '/var/lib/kea-leases4.csv'
It will start just fine with keactrl
Oddly, when star...Not sure which template to use.
Kea will not start with systemctl (and therefore at boot). It errors out with:
> Unable to open database: unable to open '/var/lib/kea-leases4.csv'
It will start just fine with keactrl
Oddly, when started with keactrl if you run:
` systemctl status kea-dhcp4-server`
You get the error that it is not started due to the issue above, but `keactrl status` shows it as active.
```
# keactrl status
DHCPv4 server: active
DHCPv6 server: inactive
DHCP DDNS: inactive
Control Agent: active
Kea DHCPv4 configuration file: /etc/kea/kea-dhcp4.conf
Kea DHCPv6 configuration file: /etc/kea/kea-dhcp6.conf
Kea DHCP DDNS configuration file: /etc/kea/kea-dhcp-ddns.conf
Kea Control Agent configuration file: /etc/kea/kea-ctrl-agent.conf
keactrl configuration file: /etc/kea/keactrl.conf
ERROR/keactrl: Configuration file for Kea does not exist: /etc/kea/kea-dhcp6.conf.
```
I am not using DHCP for IPv6 so that error is expected.
```
# ps -aux | grep "kea"
_kea 2337 0.0 1.0 41620 18956 ? Ss 01:23 0:00 /usr/sbin/kea-ctrl-agent -c /etc/kea/kea-ctrl-agent.conf
root 2398 0.0 1.0 41232 19732 pts/0 S 01:24 0:00 /usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf -d
```
```
# systemctl status kea-dhcp4-server
● kea-dhcp4-server.service - Kea IPv4 DHCP daemon
Loaded: loaded (/lib/systemd/system/kea-dhcp4-server.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2021-01-23 01:23:44 PST; 6min ago
Docs: man:kea-dhcp4(8)
Process: 2361 ExecStart=/usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf (code=exited, status=1/FAILURE)
Main PID: 2361 (code=exited, status=1/FAILURE)
Jan 23 01:23:44 en-dhcp systemd[1]: Started Kea IPv4 DHCP daemon.
Jan 23 01:23:44 en-dhcp kea-dhcp4[2361]: 2021-01-23 01:23:44.130 INFO [kea-dhcp4.dhcp4/2361] DHCP4_STARTING Kea DHCPv4 server version 1.6.2 starting
Jan 23 01:23:44 en-dhcp kea-dhcp4[2361]: 2021-01-23 01:23:44.132 ERROR [kea-dhcp4.dhcp4/2361] DHCP4_CONFIG_LOAD_FAIL configuration error using file: /etc/kea/kea-dhcp4.conf, reason: Unable to open database: unable to open '/var/lib/kea-leases4.csv'
Jan 23 01:23:44 en-dhcp kea-dhcp4[2361]: 2021-01-23 01:23:44.132 ERROR [kea-dhcp4.dhcp4/2361] DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using file '/etc/kea/kea-dhcp4.conf': Unable to open database:unable to open '/var/lib/kea-leases4.csv'
Jan 23 01:23:44 en-dhcp systemd[1]: kea-dhcp4-server.service: Main process exited, code=exited, status=1/FAILURE
Jan 23 01:23:44 en-dhcp systemd[1]: kea-dhcp4-server.service: Failed with result 'exit-code'.
```
So it's running, but not running? `/var/lib/kea-lease4.csv` does exist, and I verified that it is not a permissions issue by setting it to 777 (rwxrwxrwx), but I get the same error as above.
I have also tried running `keactrl stop` followed by `systemctl start kea-dhcp4-server` and get the same error as above. If I remove the lease file from the conf file (ie set persist to false), then it works and starts up fine. But I need those leases to persist in case of a reboot or power failure etc.
Lastly, my config
```
{ "Dhcp4":
{
"interfaces-config": { "interfaces": [ "enp1s0f0","sub_int1","sub_int2" ] },
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/kea-leases4.csv",
"lfc-interval": 3600
},
"valid-lifetime": 43200,
"renew-timer": 28800,
"rebind-timer": 2000,
"echo-client-id": false,
"match-client-id": true,
"authoritative": true,
"subnet4":
[
{
"subnet": "10.10.0.0/16",
"pools": [ { "pool": "10.10.60.1 - 10.10.69.255" } ],
"option-data": [
{ "name": "domain-name-servers", "data": "IP1, IP2>". },
{ "name": "routers", "data": "GW_IP" }
]
},
{
"subnet": "10.12.0.0/16",
"pools": [ { "pool": "10.12.60.0 - 10.12.69.255" } ],
"option-data": [
{"name": "domain-name-servers", "data": "IP" },
{"name": "routers", "data": "GW_IP" }
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/path/to/log/file.log",
"maxver": 8,
"maxsize": 204800,
"flush": true,
"pattern": "%d{%j %H:%M:%S.%q} %c %m\n"
}
],
"severity": "INFO"
}
]
}
}
```Kea1.9-backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/471Followed the install instructions, cannot get the KEA dhcp4 service to connect2021-01-23T09:49:01ZJRCFollowed the install instructions, cannot get the KEA dhcp4 service to connectI have just followed the instructions to install Stork (the Ubuntu package option - https://kea.readthedocs.io/projects/Stork/en/v0.14.0/install.html ). I have gone through and checked to make sure I have followed it to the T at least a ...I have just followed the instructions to install Stork (the Ubuntu package option - https://kea.readthedocs.io/projects/Stork/en/v0.14.0/install.html ). I have gone through and checked to make sure I have followed it to the T at least a dozen times, and I definitely have, the only thing I changed was the stork DB username password.
I can log into Stork and I can add the new machine, I get a green tick for the CA, but I not for DHCP4 (the target server is DHCP4 only). It says:
> There is observed issue in communication with the daemon.
On the KEA server the agent log reports:
> promkeaexporter.go:370 problem with connecting to dhcp daemon: unable to forward command to the dhcp4 service: No such file or directory. The server is likely to be offline
I am sure this is probably a config issue, but the manuals for KEA and Stork offer me no concrete way to verify that I have kea setup right for this, so I am just bashing my head against the wall on this. The documentation does not seem to indicate where on the Stork server the logs are kept, so I am struggling to even work out what the issue is, let alone where it might be.
The KEA DHCP4 server is working just fine, handing out IPs and what not.
Any help would be greatly appreciated. What am I doing wrong here?
Both server are Ubuntu 20.04LTS, completely vanilla installs, and the KEA server is a stand alone one (no HA or anything like that). Stork is set with all the defaults in the ENV file (as per the install guide).
My (sanitized) KEA config:
```
{ "Dhcp4":
{
"interfaces-config": { "interfaces": [ "enp1s0f0","sub_int1","sub_int2" ] },
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/path/to/file.csv",
"lfc-interval": 3600
},
"valid-lifetime": 43200,
"renew-timer": 28800,
"rebind-timer": 2000,
"echo-client-id": false,
"match-client-id": true,
"authoritative": true,
"subnet4":
[
{
"subnet": "10.10.0.0/16",
"pools": [ { "pool": "10.10.60.1 - 10.10.69.255" } ],
"option-data": [
{ "name": "domain-name-servers", "data": "IP1, IP2>". },
{ "name": "routers", "data": "GW_IP" }
]
},
{
"subnet": "10.12.0.0/16",
"pools": [ { "pool": "10.12.60.0 - 10.12.69.255" } ],
"option-data": [
{"name": "domain-name-servers", "data": "IP" },
{"name": "routers", "data": "GW_IP" }
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "/path/to/log/file.log",
"maxver": 8,
"maxsize": 204800,
"flush": true,
"pattern": "%d{%j %H:%M:%S.%q} %c %m\n"
}
],
"severity": "INFO"
}
]
}
}
```
And here is my KEA Control agent config:
```
{
"Control-agent": {
"http-host": "IP_of_Kea_Server",
"http-port": 8000,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/kea-dhcp4-ctrl.sock"
}
},
"hooks-libraries": [
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_stat_cmds.so"
}
],
// Logging configuration starts here. Kea uses different loggers to log various
// activities. For details (e.g. names of loggers), see Chapter 18.
"loggers": [
{
// This specifies the logging for Control Agent daemon.
"name": "kea-ctrl-agent",
"output_options": [
{
"output": "/path/to/logfile.log"
}
],
// This specifies the severity of log messages to keep. Supported values
// are: FATAL, ERROR, WARN, INFO, DEBUG
"severity": "INFO",
"debuglevel": 0
}
]
}
}
```https://gitlab.isc.org/isc-projects/kea/-/issues/1666bump lib versios for Kea 1.9.42021-01-25T15:16:22ZRazvan Becheriubump lib versios for Kea 1.9.4kea1.9.4Razvan BecheriuRazvan Becheriu