ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-02-10T18:10:37Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/940Config checker: the subnet commands hook and the config backend hook are sort...2023-02-10T18:10:37ZSlawek FigielConfig checker: the subnet commands hook and the config backend hook are sort of mutually exclusiveAddresses 8. proposal from #611.
> you might check whether the customer has both the subnet commands hook and the config backend hook. a lot of people don't seem to understand these are sort of mutually exclusiveAddresses 8. proposal from #611.
> you might check whether the customer has both the subnet commands hook and the config backend hook. a lot of people don't seem to understand these are sort of mutually exclusive1.10Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3806adb->hmctx does not have a name associated with it2023-02-03T14:47:33ZMichał Kępieńadb->hmctx does not have a name associated with itThis is a minor issue introduced by !7228 and its backport (!7248). See
#3739 for context.
The new memory context added in those MRs, `adb->hmctx`, does not have a
name associated with it.
## Before (e.g. BIND 9.18.10)
```sh
$ curl -...This is a minor issue introduced by !7228 and its backport (!7248). See
#3739 for context.
The new memory context added in those MRs, `adb->hmctx`, does not have a
name associated with it.
## Before (e.g. BIND 9.18.10)
```sh
$ curl -s http://localhost:8080/json | jq ".memory.contexts[].name"
"main"
"zonemgr-pool"
"zonemgr-pool"
"clientmgr"
"clientmgr"
"clientmgr"
"clientmgr"
"cache"
"cache_heap"
"ADB"
"cache"
"cache_heap"
"ADB"
```
## After (e.g. BIND 9.18.11)
```sh
$ curl -s http://localhost:8080/json | jq ".memory.contexts[].name"
"main"
"zonemgr-pool"
"zonemgr-pool"
"clientmgr"
"clientmgr"
"clientmgr"
"clientmgr"
"cache"
"cache_heap"
"ADB"
null
"cache"
"cache_heap"
"ADB"
null
```
Could we please add an `isc_mem_setname()` call for this new memory
context that would describe its purpose?February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3805Memory context reference leak intermittently triggered by the "stress" system...2023-11-03T07:35:41ZMichał KępieńMemory context reference leak intermittently triggered by the "stress" system testThe `stress` system test (**not** the performance test that is only run
in scheduled pipelines!) fails intermittently due to the reference count
for one of the memory contexts not being brought down to zero upon
shutdown.
Example: https...The `stress` system test (**not** the performance test that is only run
in scheduled pipelines!) fails intermittently due to the reference count
for one of the memory contexts not being brought down to zero upon
shutdown.
Example: https://gitlab.isc.org/isc-projects/bind9/-/jobs/3074540
`bin/tests/system/stress/ns3/named.run`:
```
...
17-Jan-2023 01:18:03.406 calling free_rbtdb(zone000004.example)
17-Jan-2023 01:18:03.406 done free_rbtdb(zone000001.example)
17-Jan-2023 01:18:03.410 adjust_quantum: old=200, new=275
17-Jan-2023 01:18:03.410 adjust_quantum: old=400, new=550
17-Jan-2023 01:18:03.410 done free_rbtdb(zone000000.example)
17-Jan-2023 01:18:03.410 done free_rbtdb(zone000004.example)
17-Jan-2023 01:18:03.422 Unregistering DLZ_dlopen driver
17-Jan-2023 01:18:03.422 Unregistering SDLZ driver.
17-Jan-2023 01:18:03.422 Unregistering DLZ driver.
17-Jan-2023 01:18:03.422 exiting
Dump of all outstanding memory allocations:
None.
mem.c:675: REQUIRE(isc_refcount_current(&ctx->references) == 0) failed
```
Backtrace:
```
(lldb) bt
* thread #1, name = 'named', stop reason = signal SIGABRT
* frame #0: 0x00007f4e4f2c7ce1 libc.so.6`__GI_raise(sig=<unavailable>) at raise.c:51:1
frame #1: 0x00007f4e4f2b1537 libc.so.6`__GI_abort at abort.c:79:7
frame #2: 0x0000560aa520ee31 named`assertion_failed(file=<unavailable>, line=<unavailable>, type=<unavailable>, cond=<unavailable>) at main.c:236:3
frame #3: 0x00007f4e5161983a libisc-9.18.12-dev.so`isc_assertion_failed(file=<unavailable>, line=675, type=isc_assertiontype_require, cond=<unavailable>) at assertions.c:48:2
frame #4: 0x00007f4e5168ae2d libisc-9.18.12-dev.so`isc__mem_destroy(ctxp=0x0000560aa5d3c200, file=<unavailable>, line=1614) at mem.c:675:2
frame #5: 0x0000560aa520df76 named`main(argc=<unavailable>, argv=0x00007ffc6f3a9ec8) at main.c:1614:2
frame #6: 0x00007f4e4f2b2d0a libc.so.6`__libc_start_main(main=(named`main at main.c:1480), argc=16, argv=0x00007ffc6f3a9ec8, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007ffc6f3a9eb8) at libc-start.c:308:16
frame #7: 0x0000560aa511ba5a named`_start + 42
```
The context in question is the `main` one. It has one outstanding
reference.
I can only confirm this with 100% certainty for ~"v9.18" right now, but
we should definitely keep our minds open wrt other branches being
affected ;-)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3804[tests] False-negative results of test `statschannel`2023-01-17T13:49:58ZStanislav Levin[tests] False-negative results of test `statschannel`System tests `statschannel` are conditional and depend on build
options, e.g. they may require `libxml2` or `libjson-c`. Those
conditions are checked with the help of `feature-test` tool which
exits with `0` code in case of enabled featu...System tests `statschannel` are conditional and depend on build
options, e.g. they may require `libxml2` or `libjson-c`. Those
conditions are checked with the help of `feature-test` tool which
exits with `0` code in case of enabled feature and `1` otherwise.
Pytest markers `have_libxml2` and `have_json_c` have wrong skip
condition, i.e. a test will be skipped if the build has feature.
Thereby,
- upstream unintentionally skip these tests
- xml/json test false-negatively fail against builds without
corresponging feature
Example of the fix:
```diff
--- a/bin/tests/system/pytest_custom_markers.py
+++ b/bin/tests/system/pytest_custom_markers.py
@@ -34,9 +34,9 @@ def feature_test(feature):
have_libxml2 = pytest.mark.skipif(
- feature_test("--have-libxml2"), reason="libxml2 support disabled in the build"
+ not feature_test("--have-libxml2"), reason="libxml2 support disabled in the build"
)
have_json_c = pytest.mark.skipif(
- feature_test("--have-json-c"), reason="json-c support disabled in the build"
+ not feature_test("--have-json-c"), reason="json-c support disabled in the build"
)
```February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3801dns_view is detached from deleted zone too late2023-10-30T15:00:55ZOndřej Surýdns_view is detached from deleted zone too lateWhen zone is removed from the configuration, it keeps a reference to `.view` (and possibly `.prev_view`) until the zone is deleted. The removal can take a long time, and if there's a constant stream of `rndc reconfig` adding and removin...When zone is removed from the configuration, it keeps a reference to `.view` (and possibly `.prev_view`) until the zone is deleted. The removal can take a long time, and if there's a constant stream of `rndc reconfig` adding and removing zones, the otherwise dead views can be kept in memory for really long time leading to a memory bloat.
This symptom might also be encountered on a server with a Catalog Zone with a high rate of change.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3800MacOS address in use not handled gracefully2023-02-01T13:43:03ZMark AndrewsMacOS address in use not handled gracefullyI happened to have an `asn.pl` active on one interface and that triggered an assertion due to mismatching result values.
```
(lldb) print sock->children[0].result
(isc_result_t) $11 = ISC_R_ADDRINUSE
(lldb) print sock->children[1].resul...I happened to have an `asn.pl` active on one interface and that triggered an assertion due to mismatching result values.
```
(lldb) print sock->children[0].result
(isc_result_t) $11 = ISC_R_ADDRINUSE
(lldb) print sock->children[1].result
(isc_result_t) $12 = ISC_R_SUCCESS
(lldb) print sock->children[2].result
(isc_result_t) $13 = ISC_R_SUCCESS
(lldb) print sock->children[3].result
(isc_result_t) $14 = ISC_R_SUCCESS
(lldb) print sock->children[4].result
(isc_result_t) $15 = ISC_R_SUCCESS
```
```
* thread #1, stop reason = signal SIGSTOP
frame #0: 0x00000001814b8e28 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x00000001814eb43c libsystem_pthread.dylib`pthread_kill + 292
frame #2: 0x0000000181433454 libsystem_c.dylib`abort + 124
frame #3: 0x0000000102f6a478 named`assertion_failed(file="netmgr/udp.c", line=181, type=isc_assertiontype_insist, cond="result == sock->children[i].result") at main.c:236:3
frame #4: 0x000000010351a14c libisc-9.19.10-dev.dylib`isc_assertion_failed(file="netmgr/udp.c", line=181, type=isc_assertiontype_insist, cond="result == sock->children[i].result") at assertions.c:49:2
* frame #5: 0x0000000103517050 libisc-9.19.10-dev.dylib`isc_nm_listenudp(mgr=0x0000000106a781e0, workers=8, iface=0x00000001088eedd8, cb=(libns-9.19.10-dev.dylib`ns__client_request at client.c:1689), cbarg=0x00000001088eed80, sockp=0x00000001088eee98) at udp.c:181:3
frame #6: 0x00000001033185a4 libns-9.19.10-dev.dylib`ns_interface_listenudp(ifp=0x00000001088eed80) at interfacemgr.c:494:11
frame #7: 0x000000010331763c libns-9.19.10-dev.dylib`interface_setup(mgr=0x0000000106a121a0, addr=0x000000016cea2670, name="lo0", ifpret=0x000000016cea2638, elt=0x00000001067f0bf0, addr_in_use=0x000000016cea25ff) at interfacemgr.c:696:11
frame #8: 0x0000000103315ed0 libns-9.19.10-dev.dylib`do_scan(mgr=0x0000000106a121a0, verbose=true, config=true) at interfacemgr.c:1266:13
frame #9: 0x00000001033157b0 libns-9.19.10-dev.dylib`ns_interfacemgr_scan(mgr=0x0000000106a121a0, verbose=true, config=true) at interfacemgr.c:1326:11
frame #10: 0x0000000102f80860 named`load_configuration(filename="/dev/null", server=0x0000000106b3c8c0, first_time=true) at server.c:8947:12
frame #11: 0x0000000102f7ed18 named`run_server(task=0x0000000106ac6640, event=0x0000000000000000) at server.c:9974:2
frame #12: 0x000000010354ffb4 libisc-9.19.10-dev.dylib`task_run(task=0x0000000106ac6640) at task.c:470:4
frame #13: 0x000000010354fb98 libisc-9.19.10-dev.dylib`task__run(arg=0x0000000106ac6640) at task.c:287:24
frame #14: 0x000000010352aa70 libisc-9.19.10-dev.dylib`isc__job_cb(idle=0x0000000106ac6a08) at job.c:75:2
frame #15: 0x00000001041dafe4 libuv.1.dylib`uv__run_idle + 152
frame #16: 0x00000001041d5cd0 libuv.1.dylib`uv_run + 204
frame #17: 0x0000000103535bb8 libisc-9.19.10-dev.dylib`loop_run(loop=0x0000000106c3c000) at loop.c:270:6
frame #18: 0x00000001035342bc libisc-9.19.10-dev.dylib`loop_thread(arg=0x0000000106c3c000) at loop.c:297:2
frame #19: 0x0000000103534174 libisc-9.19.10-dev.dylib`isc_loopmgr_run(loopmgr=0x00000001067ef750) at loop.c:481:2
frame #20: 0x0000000102f6a17c named`main(argc=6, argv=0x000000016cea36c0) at main.c:1513:2
frame #21: 0x0000000181509430 libdyld.dylib`start + 4
```
The assertion doesn't make sense on the Mac as `mgr->load_balance_sockets` is `false` and `fd` is the result of `dup` rather than using `socket` and `bind` resulting in different `result` values being stored.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)https://gitlab.isc.org/isc-projects/stork/-/issues/937Default form for standard DHCP options with known definitions2023-02-08T16:52:50ZMarcin SiodelskiDefault form for standard DHCP options with known definitionsWhen a user creates a new standard DHCP option in the host editing form, the controls for this option should be initialised using the option definitions. For example: if a given option comprises a single IPv4 address field, the input box...When a user creates a new standard DHCP option in the host editing form, the controls for this option should be initialised using the option definitions. For example: if a given option comprises a single IPv4 address field, the input box for the IPv4 address should be displayed. It eliminates the need for the user to know the option formats and minimises the risk of errors.1.9Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/3799TSAN race between dns_rbtnode_t bitfields2023-02-01T13:40:09ZMichał KępieńTSAN race between dns_rbtnode_t bitfieldsA certain TSAN issue has been repeatedly reported for different branches
by TSAN-enabled respdiff tests:
- `v9_18_sub`: https://gitlab.isc.org/isc-private/bind9/-/jobs/3069484
- `v9_16`: https://gitlab.isc.org/isc-private/bind9/-/jo...A certain TSAN issue has been repeatedly reported for different branches
by TSAN-enabled respdiff tests:
- `v9_18_sub`: https://gitlab.isc.org/isc-private/bind9/-/jobs/3069484
- `v9_16`: https://gitlab.isc.org/isc-private/bind9/-/jobs/3067159
- `v9_16_sub`: https://gitlab.isc.org/isc-private/bind9/-/jobs/3067260
```
WARNING: ThreadSanitizer: data race
Read of size 1 at 0x000000000001 by thread T1 (mutexes: read M1):
#0 decrement_reference lib/dns/rbtdb.c:2090
#1 detachnode lib/dns/rbtdb.c:5552
#2 rdataset_disassociate lib/dns/rbtdb.c:8874
#3 dns_rdataset_disassociate lib/dns/rdataset.c:113
#4 fctx_destroy lib/dns/resolver.c:4718
#5 fctx_doshutdown lib/dns/resolver.c:4945
#6 task_run lib/isc/task.c:853
#7 isc_task_run lib/isc/task.c:947
#8 isc__nm_async_task lib/isc/netmgr/netmgr.c:861
#9 process_netievent lib/isc/netmgr/netmgr.c:933
#10 process_queue lib/isc/netmgr/netmgr.c:999
#11 process_all_queues lib/isc/netmgr/netmgr.c:780
#12 async_cb lib/isc/netmgr/netmgr.c:809
#13 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163
#14 isc__trampoline_run lib/isc/trampoline.c:213
Previous write of size 1 at 0x000000000001 by thread T2 (mutexes: write M2, write M3):
#0 add_wildcard_magic lib/dns/rbtdb.c:2808
#1 findnodeintree lib/dns/rbtdb.c:2885
#2 findnode lib/dns/rbtdb.c:2923
#3 dns_db_findnode lib/dns/db.c:441
#4 validated lib/dns/resolver.c:6155
#5 task_run lib/isc/task.c:853
#6 isc_task_run lib/isc/task.c:947
#7 isc__nm_async_task lib/isc/netmgr/netmgr.c:861
#8 process_netievent lib/isc/netmgr/netmgr.c:933
#9 process_queue lib/isc/netmgr/netmgr.c:999
#10 process_all_queues lib/isc/netmgr/netmgr.c:780
#11 async_cb lib/isc/netmgr/netmgr.c:809
#12 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163
#13 isc__trampoline_run lib/isc/trampoline.c:213
Location is heap block of size 115 at 0x000000000022 allocated by thread T3:
#0 malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:651
#1 default_memalloc lib/isc/mem.c:715
#2 mem_get lib/isc/mem.c:624
#3 isc___mem_get lib/isc/mem.c:1066
#4 isc__mem_get lib/isc/mem.c:2384
#5 create_node lib/dns/rbt.c:2279
#6 dns_rbt_addnode lib/dns/rbt.c:1471
#7 findnodeintree lib/dns/rbtdb.c:2877
#8 findnode lib/dns/rbtdb.c:2923
#9 dns_db_findnode lib/dns/db.c:441
#10 cache_name lib/dns/resolver.c:6457
#11 cache_message lib/dns/resolver.c:6870
#12 resquery_response lib/dns/resolver.c:8274
#13 task_run lib/isc/task.c:853
#14 isc_task_run lib/isc/task.c:947
#15 isc__nm_async_task lib/isc/netmgr/netmgr.c:861
#16 process_netievent lib/isc/netmgr/netmgr.c:933
#17 process_queue lib/isc/netmgr/netmgr.c:999
#18 process_all_queues lib/isc/netmgr/netmgr.c:780
#19 async_cb lib/isc/netmgr/netmgr.c:809
#20 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163
#21 isc__trampoline_run lib/isc/trampoline.c:213
Mutex M1 is already destroyed.
Mutex M2 is already destroyed.
Mutex M3 is already destroyed.
Thread T1 (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:962
#1 isc_thread_create lib/isc/pthreads/thread.c:81
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:345
#3 isc_managers_create lib/isc/managers.c:28
#4 create_managers main.c:1064
#5 setup main.c:1389
#6 main main.c:1703
Thread T2 (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:962
#1 isc_thread_create lib/isc/pthreads/thread.c:81
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:345
#3 isc_managers_create lib/isc/managers.c:28
#4 create_managers main.c:1064
#5 setup main.c:1389
#6 main main.c:1703
Thread T3 (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:962
#1 isc_thread_create lib/isc/pthreads/thread.c:81
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:345
#3 isc_managers_create lib/isc/managers.c:28
#4 create_managers main.c:1064
#5 setup main.c:1389
#6 main main.c:1703
SUMMARY: ThreadSanitizer: data race lib/dns/rbtdb.c:2090 in decrement_reference
```
Looking at line numbers, this looks like a race between (line numbers
taken from `v9_16_37`):
```c
2089 /* Handle easy and typical case first. */
2090 >>> if (!node->dirty && KEEP_NODE(node, rbtdb, locked)) {
2091 if (isc_refcount_decrement(&node->references) == 1) {
2092 refs = isc_refcount_decrement(&nodelock->references);
2093 INSIST(refs > 0);
2094 return (true);
2095 } else {
2096 return (false);
2097 }
2098 }
```
and:
```c
2787 static isc_result_t
2788 add_wildcard_magic(dns_rbtdb_t *rbtdb, const dns_name_t *name) {
2789 isc_result_t result;
2790 dns_name_t foundname;
2791 dns_offsets_t offsets;
2792 unsigned int n;
2793 dns_rbtnode_t *node = NULL;
2794
2795 dns_name_init(&foundname, offsets);
2796 n = dns_name_countlabels(name);
2797 INSIST(n >= 2);
2798 n--;
2799 dns_name_getlabelsequence(name, 1, n, &foundname);
2800 result = dns_rbt_addnode(rbtdb->tree, &foundname, &node);
2801 if (result != ISC_R_SUCCESS && result != ISC_R_EXISTS) {
2802 return (result);
2803 }
2804 if (result == ISC_R_SUCCESS) {
2805 node->nsec = DNS_RBT_NSEC_NORMAL;
2806 }
2807 node->find_callback = 1;
2808 >>> node->wild = 1;
2809 return (ISC_R_SUCCESS);
2810 }
```
`dirty` and `wild` are bitfields:
```c
struct dns_rbtnode {
...
void *data;
uint8_t : 0; /* start of bitfields c/o node lock */
uint8_t dirty : 1;
uint8_t wild : 1;
uint8_t : 0; /* end of bitfields c/o node lock */
uint16_t locknum; /* note that this is not in the bitfield */
isc_refcount_t references;
/*@}*/
};
```
I cannot recall this issue being reported for the current `main`, but
perhaps it gets triggered there as well, just with a lower frequency.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3798named-checkconf errors when using a custom dnssec-policy statement2023-01-13T23:55:02ZDennis Radfordnamed-checkconf errors when using a custom dnssec-policy statement
### Summary
When configuring a "custom" dnssec-policy statement, named-checkconf produces two errors when attempting to start BIND
### BIND version used
BIND 9.18.10 (Stable Release)<br />
running on FreeBSD amd64 13.1-RELEASE-p3
##...
### Summary
When configuring a "custom" dnssec-policy statement, named-checkconf produces two errors when attempting to start BIND
### BIND version used
BIND 9.18.10 (Stable Release)<br />
running on FreeBSD amd64 13.1-RELEASE-p3
### Steps to reproduce
Insert a custom dnssec-policy statement
`dnssec-policy "custom" {`
versus using
`dnssec-policy "none";` or `dnssec-policy "default";`
### What is the current *bug* behavior?
named-checkconf produces the following errors and BIND does not start
<pre>/usr/local/etc/namedb/named.conf:153: missing ';' before '{'
/usr/local/etc/namedb/named.conf:153: '}' expected near '{'
/usr/local/etc/rc.d/named: ERROR: named-checkconf for /usr/local/etc/namedb/named.conf failed</pre>
The affected line number is the line that begins the statement: `dnssec-policy "custom" {`
### Relevant configuration files
Copy/pasted from [https://bind9.readthedocs.io/en/v9_18_10/chapter5.html#fully-automated-key-and-signing-policy](https://bind9.readthedocs.io/en/v9_18_10/chapter5.html#fully-automated-key-and-signing-policy)
<pre>
dnssec-policy "custom" {
dnskey-ttl 600;
keys {
ksk lifetime P1Y algorithm ecdsap384sha384;
zsk lifetime 60d algorithm ecdsap384sha384;
};
nsec3param iterations 0 optout no salt-length 0;
};</pre>https://gitlab.isc.org/isc-projects/bind9/-/issues/3797remove isc_task and related APIs2023-02-27T14:42:45ZEvan Huntremove isc_task and related APIsThe `isc_loop`, `isc_async` and `isc_job` APIs can now do everything `isc_task` and `isc_event` used to, and in fact the latter is just a shim around the former. Let's convert everything that still uses isc_task to use loop instead:
- [...The `isc_loop`, `isc_async` and `isc_job` APIs can now do everything `isc_task` and `isc_event` used to, and in fact the latter is just a shim around the former. Let's convert everything that still uses isc_task to use loop instead:
- [x] zone.c (`zonemgr_getio()` and the `dns_io` API, key refresh queries, synchronizing inline signing zones, nsec3param updates, xfrin quota, etc)
- [x] `isc_ratelimiter`
- [x] libdns modules: `dns_request`, `dns_validator`, `dns_adb`
- [x] `dnssec-signzone`
- [x] UPDATE processing
- [x] plugin, dyndb, and `dns_client` callbacks
- [x] TAT queries
- [x] `dns_resolver`
- [x] `dns_catz` and `rndc addzone`/`delzone`
- [x] final `isc_task` API cleanupMarch 2023 (9.16.39, 9.16.39-S1, 9.18.13, 9.18.13-S1, 9.19.11)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3796Building BIND on newer versions of DragonFly BSD (at least 6.4) fails (w/ and...2023-02-03T14:24:47ZArtem BoldarievBuilding BIND on newer versions of DragonFly BSD (at least 6.4) fails (w/ and w/o Jemalloc)While doing some investigations for #3774, it was found that building BIND 9 is not possible on that platform as our memory management code fails to build on this platform when configuring with both `--with-jemalloc=yes` and `--with-jema...While doing some investigations for #3774, it was found that building BIND 9 is not possible on that platform as our memory management code fails to build on this platform when configuring with both `--with-jemalloc=yes` and `--with-jemalloc=no`. I think that it would be fair to make it work at least in the case when jemalloc-specific APIs are not available (like in the case of OpenBSD). BIND builds fine at least for DragonFly 6.2, according to @mnowak report in #3774. Obviously, that happens due to the changes to OS-specific headers.
## When Jemalloc is detected or when building with `--with-jemalloc=yes`
By default, `./configure` tries to detect presence of `<malloc_np.h>` and assumes that when it is available, Jemalloc specific API is availalbe (`mallocx()`, `sdallocx()`, `rallocx()`, etc). The header usually corresponds to `<jemalloc/jemalloc.h>` in upstream versions of Jemalloc. In this case `HAVE_MALLOC_NP_H` is defined in `config.h`.
That used to be the case for DragonFly BSD, but is not tanymore. On this platform `./configure` script works fine, but building BIND will fail as follows:
```
mem.c: In function 'mem_get':
mem.c:343:8: error: implicit declaration of function 'mallocx'; did you mean 'malloc'? [-Werror=implicit-function-declaration]
ret = mallocx(size, flags);
^~~~~~~
malloc
mem.c:343:6: warning: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
ret = mallocx(size, flags);
^
mem.c: In function 'mem_put':
mem.c:365:2: error: implicit declaration of function 'sdallocx'; did you mean 'reallocf'? [-Werror=implicit-function-declaration]
sdallocx(mem, size, flags);
^~~~~~~~
reallocf
mem.c: In function 'mem_realloc':
mem.c:375:12: error: implicit declaration of function 'rallocx'; did you mean 'reallocf'? [-Werror=implicit-function-declaration]
new_ptr = rallocx(old_ptr, new_size, flags);
^~~~~~~
reallocf
mem.c:375:10: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
new_ptr = rallocx(old_ptr, new_size, flags);
^
In file included from ./include/isc/hash.h:22,
from mem.c:26:
mem.c: In function 'mem_initialize':
mem.c:441:32: error: 'MALLOCX_ZERO' undeclared (first use in this function)
RUNTIME_CHECK(ISC_MEM_ZERO == MALLOCX_ZERO);
...
```
Keep in mind that `HAVE_MALLOC_NP_H` is defined in the case above, as the header is present. The case is that it does not provide the required API.
## When building without Jemalloc (`--with-jemalloc=yes`)
In such a case, `jemalloc_shim.h` is broken (the file is intended to provide a simple implementation of Jemalloc specific APIs using the available OS-specific capabilities). It fails as follows:
```
jemalloc_shim.h:44:10: fatal error: malloc.h: No such file or directory
#include <malloc.h>
^~~~~~~~~~
```
As memory allocator on DragonFly BSD does have `malloc_usable_size()`, we end up building with `HAVE_MALLOC_USABLE_SIZE` defined (which is not a surprise, as it is still a custom version of Jemalloc). In such a case, we attempt to include non-standard `<malloc.h>` ... which is not available on DragonFly BSD anymore. As far as I understand the matter, on newer versions of DragonFly BSD we should use `<sys/malloc.h>`. Doing so fixes the build. We can solve this by introducing `HAVE_SYS_MALLOC_H`, I guess.
To lessen maintenance pressure, I would suggest to assume that Jemalloc is not available on Dragon Fly BSD and use the generic code (the one used on OpenBSD)February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3795performance degradation on NSEC3 zones when queried with DO=12023-02-01T13:31:57ZPetr Špačekpspacek@isc.orgperformance degradation on NSEC3 zones when queried with DO=1### Summary
Authoritative zone signed using RSASHA256 + NSEC3 with 15 iterations and no opt-out suffers from large performance degradation when queried with DO=1.
### BIND version used
* ~"Affects v9.19": v9_19_9
* ~"Affects v9.18": v...### Summary
Authoritative zone signed using RSASHA256 + NSEC3 with 15 iterations and no opt-out suffers from large performance degradation when queried with DO=1.
### BIND version used
* ~"Affects v9.19": v9_19_9
* ~"Affects v9.18": v9_18_11
* ~"Affects v9.16": v9_16_36
### Steps to reproduce
1. Start with an empty zone: [empty.db](/uploads/78f9e83a3ba44691462255a842ec70c6/empty.db)
2. Generate new keys, I used alg 8 KSK 2048 b, ZSK 1024 b: [Knet.+008+42541.private](/uploads/6ae5ccf49604074e33dcab6b60491ae4/Knet.+008+42541.private) [Knet.+008+42541.key](/uploads/5f3e28bd750148db6aa88636ec14cbbe/Knet.+008+42541.key) [Knet.+008+62311.private](/uploads/5c5ba007421f0fd65246feb30f621bfb/Knet.+008+62311.private) [Knet.+008+62311.key](/uploads/8bf39172d04789154af9aed67bb83449/Knet.+008+62311.key)
3. Resign the original zone using new keys and 15 NSEC3 iterations with non-empty salt
```
dnssec-signzone -S -o net -u -H 15 -3 0123456789ABCDEF empty.db
```
[empty.db.signed](/uploads/1066d5cebdc4eed9999551c1a3d6b411/empty.db.signed)
4. Load into auth:
```
options {
check-names primary ignore;
check-names secondary ignore;
recursion no;
allow-query {
"any";
};
check-dup-records warn;
check-integrity no;
check-mx ignore;
check-mx-cname ignore;
check-sibling no;
check-spf ignore;
check-srv-cname ignore;
check-wildcard no;
notify no;
};
zone "net." {
type primary;
file "/usr/etc/empty.db.signed";
masterfile-format text;
};
```
5. Query with DO=0 and DO=1.
Query list can contain a single line:
`aaa.net. A`
Repeating the query suffices to reproduce the problem.
Command:
```
dnsperf -d qlist -s 10.10.126.46 -p 53 -S1 -T8 -O suppress=timeout -c 64 -q 1000 -l 10 -D
```
6. Compare max QPS - use `dnsperf` without and with `-D` to set the bit
### What is the current *bug* behavior?
On a 16 thread machine, 8 cores, AWS type c5n.4xlarge, the performance degradation from DO=0 to DO=1 is roughly 10x.
### What is the expected *correct* behavior?
Well, smaller performance drop :-)
### CPU profiling
Beware: Done on a `net.` zone which exhibits ~ 3-4x degradation. Profile is from v9_18_8.
#### DO=0
![flame.do0.try1.svg](/uploads/b8423164a1416387b5b04cc291b39d4e/flame.do0.try1.svg)
#### DO=1
![flame.do1.try1.svg](/uploads/369400e1f2e02c9ee94590066416ac28/flame.do1.try1.svg)
#### diff between DO=0 and DO=1 run
![diff-do0-vs-do1.svg](/uploads/4c29e97de144a0bb7dd71185a179bbbc/diff-do0-vs-do1.svg)February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)https://gitlab.isc.org/isc-projects/kea/-/issues/2719IP Address Re-Offer Cooldown2023-07-17T13:58:22ZDarren AnkneyIP Address Re-Offer Cooldown---
name: IP Address Re-Offer Cooldown
about: A configuration option to cause Kea to not offer the same address to different clients for a configurable period of time.
---
Kea can, in certain situations, offer the same address to multip...---
name: IP Address Re-Offer Cooldown
about: A configuration option to cause Kea to not offer the same address to different clients for a configurable period of time.
---
Kea can, in certain situations, offer the same address to multiple clients in a short period of time. These situations include (but may not be limited to):
- High DHCP client traffic, high network latency
- Kea servers without HA, with overlapping pools, connected to a shared lease database. The more pool overlap, the more it happens.
- Nearly exhausted pools, and high client traffic.
This can cause clients to be offered an address only to receive a NAK when they request the offered address. This does not break RFC but does produce extra traffic (and logs) as the clients must then attempt another 4-way handshake.
A possible solution to this is a configuration option that allows a configurable period of time, during which an already offered address will not be offered to any other clients.
[RT #21635](https://support.isc.org/Ticket/Display.html?id=21635)kea2.3.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/stork/-/issues/936connection refused: stork machine registration2023-02-14T16:42:50ZAdam Chaitconnection refused: stork machine registrationWhen I run stork-agent register --server-url http://127.0.0.1 i get the following returned and I can't figure out how to resolve the "connection refused":
>>>> Server access token (optional):
>>>> IP address or FQDN of the host with Sto...When I run stork-agent register --server-url http://127.0.0.1 i get the following returned and I can't figure out how to resolve the "connection refused":
>>>> Server access token (optional):
>>>> IP address or FQDN of the host with Stork Agent (for the Stork Server connection) [kea]:
>>>> Port number that Stork Agent will listen on [8080]:
INFO[2023-01-12 16:58:44] register.go:160 Agent token stored in /var/lib/stork-agent/tokens/agent-token.txt
INFO[2023-01-12 16:58:44] register.go:161 Agent key, agent token, and CSR (re)generated
INFO[2023-01-12 16:58:44] register.go:449 =============================================================================
INFO[2023-01-12 16:58:44] register.go:450 AGENT TOKEN: 71DACCA3209973F663246FE581CBFCE9FC9F000B0EF19A6B50030CCE35B35F61
INFO[2023-01-12 16:58:44] register.go:451 =============================================================================
INFO[2023-01-12 16:58:44] register.go:454 Authorize the machine in the Stork web UI
INFO[2023-01-12 16:58:44] register.go:471 Try to register agent in Stork Server
ERRO[2023-01-12 16:58:44] register.go:474 problem registering machine: Post "http://127.0.0.1/api/machines": dial tcp 127.0.0.1:80: connect: connection refused
FATA[2023-01-12 16:58:44] main.go:134 Registration failed1.10Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3793dnssec-signzone doesn't parallelise signing2023-02-01T13:47:44ZOndřej Surýdnssec-signzone doesn't parallelise signing@fabled discovered that there's an error how `assignwork()` is called when `sign()` returns data to the writer - all the work is done by the main thread and all other workers are idle.@fabled discovered that there's an error how `assignwork()` is called when `sign()` returns data to the writer - all the work is done by the main thread and all other workers are idle.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3791Typo in Documentation (DNSSEC)2023-01-13T12:54:32ZWaleed MortajaTypo in Documentation (DNSSEC)Typo in DNSSEC Documentation.
[Line 253 in the documentation](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/dnssec-guide/introduction.rst?plain=1#L253) says:
``` the ``isc.org`` name server(s), or course she would send matc...Typo in DNSSEC Documentation.
[Line 253 in the documentation](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/dnssec-guide/introduction.rst?plain=1#L253) says:
``` the ``isc.org`` name server(s), or course she would send matching ```
It should be:
``` the ``isc.org`` name server(s), of course she would send matching ```
(replacing `or` with `of`)January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3790In 9.18, "*-source" is ignoring [port <integer>]2023-02-09T13:33:37ZGreg ChoulesIn 9.18, "*-source" is ignoring [port <integer>]With configurations like `notify-source a.b.c.d port 12345;` the "port 12345" declaration is ignored, and BIND uses random, different ports. This applies to all `*-source` options as the reserved dispatches are only created and destroye...With configurations like `notify-source a.b.c.d port 12345;` the "port 12345" declaration is ignored, and BIND uses random, different ports. This applies to all `*-source` options as the reserved dispatches are only created and destroyed in `bin/named/server.c` when parsing the configuration, but they are never used anywhere.
Support ticket [21617](https://support.isc.org/Ticket/Display.html?id=21617) refers.March 2023 (9.16.39, 9.16.39-S1, 9.18.13, 9.18.13-S1, 9.19.11)https://gitlab.isc.org/isc-projects/kea/-/issues/2713Extend BLQ to return delegated prefixes for remote-id and relay-id2023-07-17T13:58:23ZThomas MarkwalderExtend BLQ to return delegated prefixes for remote-id and relay-idBulk Lease Query by remote-id, link, and relay-id currently only return addresses, not prefixes. We need to extend it to also return prefixes.
EDIT: There are two cases here:
- return PD when query by remote-id or relay-id (`QUERY_BY_R...Bulk Lease Query by remote-id, link, and relay-id currently only return addresses, not prefixes. We need to extend it to also return prefixes.
EDIT: There are two cases here:
- return PD when query by remote-id or relay-id (`QUERY_BY_RELAY_ID` or `QUERY_BY_REMOTE_ID`).
- return PD that contains an address when querying for an address (`QUERY_BY_ADDRESS`).
The former is in scope, but the latter is not. The latter is not implemented even for basic LQ. It's a missing functionality, yes, but nobody complained about this shortcoming so far.
Decided to ignore the link address vs prefix possible issue i.e. do the same if the link address is :: or is not.kea2.3.4Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2711perfdhcp documentation mismatch regarding -Y/-y2023-02-27T17:56:41ZDarren Ankneyperfdhcp documentation mismatch regarding -Y/-yIn the man page for perfdhcp `man 8 perfdhcp` it gives the following documentation:
```
-y seconds
Time in seconds after which perfdhcp starts simulating the client waiting longer for server responses. This increase...In the man page for perfdhcp `man 8 perfdhcp` it gives the following documentation:
```
-y seconds
Time in seconds after which perfdhcp starts simulating the client waiting longer for server responses. This increases
the secs field in DHCPv4 and sends increased values in the Elapsed Time option in DHCPv6. Must be used with -Y.
-Y seconds
Time in seconds during which perfdhcp simulates the client waiting longer for server responses. This increases the
secs field in DHCPv4 and sends increased values in the Elapsed Time option in DHCPv6. Must be used with -y.
```
While `perfdhcp --help` outputs:
```
-Y<time>: time in seconds after which perfdhcp will start sending
messages with increased elapsed time option.
-y<time>: period of time in seconds in which perfdhcp will be sending
messages with increased elapsed time option.
```
Notice how the case of the Y/y is reversed. The content from `perfdhcp --help` is the correct content. I found this issue while doing some testing that required the `SECS` field to increase and I was having trouble getting it to do so. This issue is present in 2.2.0 and 2.3.3. I did not investigate any other versions.kea2.3.6Darren AnkneyDarren Ankneyhttps://gitlab.isc.org/isc-projects/kea/-/issues/2710Kea ARM database tweaks and recomendations2023-07-17T13:58:23ZMarcin GodzinaKea ARM database tweaks and recomendationsKea requires changes in documentation about recomended database and tweaks to improve performance.
Related issue: isc-projects/kea#2706Kea requires changes in documentation about recomended database and tweaks to improve performance.
Related issue: isc-projects/kea#2706kea2.3.5Marcin GodzinaMarcin Godzina