ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-07-07T07:11:25Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2249early global reservation lookup for classes2022-07-07T07:11:25ZFrancis Dupontearly global reservation lookup for classesThe idea is to introduce a new global boolean parameter (*) which:
- makes global reservations to be search as soon as possible
- add reserved classes to the query
- perform classification
- check the drop class (if the query is in t...The idea is to introduce a new global boolean parameter (*) which:
- makes global reservations to be search as soon as possible
- add reserved classes to the query
- perform classification
- check the drop class (if the query is in the class drop it)
- use classes as guards for subnets and pools
This implements with other goodies the drop using reservations (more convenient in some cases than long classification expressions) asked by some customers.
This change should address #1973, #1543.kea2.1.4Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/stork/-/issues/678Upgrade go-pg to version 102022-02-04T08:46:22ZMarcin SiodelskiUpgrade go-pg to version 10The currently used go-pg version is already pretty old. It would be good to migrate to the new version v10: https://github.com/go-pg/pg/blob/v10/CHANGELOG.md. One of the useful features is "Added pg.DBI which is a DB interface implemente...The currently used go-pg version is already pretty old. It would be good to migrate to the new version v10: https://github.com/go-pg/pg/blob/v10/CHANGELOG.md. One of the useful features is "Added pg.DBI which is a DB interface implemented by pg.DB and pg.Tx".1.1Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/3064Disable the interface-interval timer on systems where route/netlink messages ...2022-05-30T10:44:26ZArtem BoldarievDisable the interface-interval timer on systems where route/netlink messages workThis issue is essentially a follow-up from #3059 and !5638.
The idea is that there is no point in having `interface-interval` on the systems where a kernel reliably informs us about the state of network interfaces. On such systems, havi...This issue is essentially a follow-up from #3059 and !5638.
The idea is that there is no point in having `interface-interval` on the systems where a kernel reliably informs us about the state of network interfaces. On such systems, having `interface-interval` is redundant. At the very least the list of such systems includes all Linux distributions, where NetLink messages are available for that.
We may wish to disable the timer with a `WARNING` message in the log earlier during 9.19 release series to see how well it will work on practice (it should work just fine, IMO).June 2022 (9.16.30, 9.16.30-S1, 9.18.4, 9.19.2)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/kea/-/issues/2250TLS unit tests fail with OpenSSL 1.1.1m2022-02-09T09:07:25ZAndrei Pavelandrei@isc.orgTLS unit tests fail with OpenSSL 1.1.1m```
$ grep OPENSSL_VERSION_TEXT /usr/include/openssl/opensslv.h
# define OPENSSL_VERSION_TEXT "OpenSSL 1.1.1m 14 Dec 2021"
```
<details open>
<summary>The full list of failing tests:</summary>
<pre>
[ RUN ] TLSTest.loadNoCAFile...```
$ grep OPENSSL_VERSION_TEXT /usr/include/openssl/opensslv.h
# define OPENSSL_VERSION_TEXT "OpenSSL 1.1.1m 14 Dec 2021"
```
<details open>
<summary>The full list of failing tests:</summary>
<pre>
[ RUN ] TLSTest.loadNoCAFile
tls_unittest.cc:359: Failure
Failed
exception with unknown 'No such file or directory (system library, fopen)'
[ FAILED ] TLSTest.loadNoCAFile (0 ms)
[ RUN ] TLSTest.loadCAPath
[ OK ] TLSTest.loadCAPath (0 ms)
[ RUN ] TLSTest.loadKeyCA
tls_unittest.cc:359: Failure
Failed
exception with unknown 'no certificate or crl found (x509 certificate routines, X509_load_cert_crl_file)'
[ FAILED ] TLSTest.loadKeyCA (0 ms)
[ RUN ] TLSTest.loadCertFile
[ OK ] TLSTest.loadCertFile (0 ms)
[ RUN ] TLSTest.loadNoCertFile
tls_unittest.cc:359: Failure
Failed
exception with unknown 'No such file or directory (system library, fopen)'
[ FAILED ] TLSTest.loadNoCertFile (0 ms)
[ RUN ] TLSTest.loadCsrCertFile
tls_unittest.cc:359: Failure
Failed
exception with unknown 'no start line (PEM routines, get_name)'
[ FAILED ] TLSTest.loadCsrCertFile (0 ms)
[ RUN ] TLSTest.loadKeyFile
[ OK ] TLSTest.loadKeyFile (0 ms)
[ RUN ] TLSTest.loadNoKeyFile
tls_unittest.cc:359: Failure
Failed
exception with unknown 'No such file or directory (system library, fopen)'
[ FAILED ] TLSTest.loadNoKeyFile (0 ms)
[ RUN ] TLSTest.loadCertKeyFile
tls_unittest.cc:359: Failure
Failed
exception with unknown 'no start line (PEM routines, get_name)'
[ FAILED ] TLSTest.loadCertKeyFile (0 ms)
[ RUN ] TLSTest.loadMismatch
[ OK ] TLSTest.loadMismatch (0 ms)
[ RUN ] TLSTest.configure
[ OK ] TLSTest.configure (0 ms)
[ RUN ] TLSTest.configureError
tls_unittest.cc:359: Failure
Failed
exception with unknown 'load of cert file '/no-such-file' failed: No such file or directory (system library, fopen)'
[ FAILED ] TLSTest.configureError (0 ms)
[ RUN ] TLSTest.stream
[ OK ] TLSTest.stream (0 ms)
[ RUN ] TLSTest.noHandshake
tls_unittest.cc:406: Failure
Failed
send got unexpected error 'uninitialized (SSL routines, ssl_write_internal)'
tls_unittest.cc:406: Failure
Failed
receive got unexpected error 'uninitialized (SSL routines, ssl_read_internal)'
[ FAILED ] TLSTest.noHandshake (2 ms)
[ RUN ] TLSTest.serverNotConfigured
tls_unittest.cc:406: Failure
Failed
server got unexpected error 'no shared cipher (SSL routines, tls_post_process_client_hello)'
tls_unittest.cc:406: Failure
Failed
client got unexpected error 'sslv3 alert handshake failure (SSL routines, ssl3_read_bytes)'
[ FAILED ] TLSTest.serverNotConfigured (2 ms)
[ RUN ] TLSTest.clientNotConfigured
tls_unittest.cc:406: Failure
Failed
server got unexpected error 'tlsv1 alert unknown ca (SSL routines, ssl3_read_bytes)'
tls_unittest.cc:406: Failure
Failed
client got unexpected error 'certificate verify failed (SSL routines, tls_process_server_certificate)'
[ FAILED ] TLSTest.clientNotConfigured (14 ms)
[ RUN ] TLSTest.clientHTTPnoS
tls_unittest.cc:406: Failure
Failed
server got unexpected error 'http request (SSL routines, ssl3_get_record)'
[ FAILED ] TLSTest.clientHTTPnoS (1 ms)
[ RUN ] TLSTest.unknownClient
tls_unittest.cc:406: Failure
Failed
server got unexpected error 'wrong version number (SSL routines, ssl3_get_record)'
[ FAILED ] TLSTest.unknownClient (1 ms)
[ RUN ] TLSTest.anotherClient
tls_unittest.cc:406: Failure
Failed
server got unexpected error 'certificate verify failed (SSL routines, tls_process_client_certificate)'
[ FAILED ] TLSTest.anotherClient (18 ms)
[ RUN ] TLSTest.selfSigned
tls_unittest.cc:406: Failure
Failed
server got unexpected error 'certificate verify failed (SSL routines, tls_process_client_certificate)'
[ FAILED ] TLSTest.selfSigned (19 ms)
[ RUN ] TLSTest.noHandshakeCloseOnError
tls_unittest.cc:406: Failure
Failed
send got unexpected error 'uninitialized (SSL routines, ssl_write_internal)'
tls_unittest.cc:406: Failure
Failed
receive got unexpected error 'uninitialized (SSL routines, ssl_read_internal)'
[ FAILED ] TLSTest.noHandshakeCloseOnError (2 ms)
[ RUN ] TLSTest.serverNotConfiguredCloseonError
tls_unittest.cc:406: Failure
Failed
server got unexpected error 'no shared cipher (SSL routines, tls_post_process_client_hello)'
tls_unittest.cc:406: Failure
Failed
client got unexpected error 'sslv3 alert handshake failure (SSL routines, ssl3_read_bytes)'
[ FAILED ] TLSTest.serverNotConfiguredCloseonError (2 ms)
[ RUN ] TLSTest.clientNotConfiguredCloseonError
tls_unittest.cc:406: Failure
Failed
server got unexpected error 'tlsv1 alert unknown ca (SSL routines, ssl3_read_bytes)'
tls_unittest.cc:406: Failure
Failed
client got unexpected error 'certificate verify failed (SSL routines, tls_process_server_certificate)'
[ FAILED ] TLSTest.clientNotConfiguredCloseonError (7 ms)
[ RUN ] TLSTest.clientHTTPnoSCloseonError
tls_unittest.cc:406: Failure
Failed
server got unexpected error 'http request (SSL routines, ssl3_get_record)'
[ FAILED ] TLSTest.clientHTTPnoSCloseonError (1 ms)
[ RUN ] TLSTest.anotherClientCloseonError
tls_unittest.cc:406: Failure
Failed
server got unexpected error 'certificate verify failed (SSL routines, tls_process_client_certificate)'
[ FAILED ] TLSTest.anotherClientCloseonError (19 ms)
[ RUN ] TLSTest.selfSignedCloseonError
tls_unittest.cc:406: Failure
Failed
server got unexpected error 'certificate verify failed (SSL routines, tls_process_client_certificate)'
[ FAILED ] TLSTest.selfSignedCloseonError (18 ms)
</pre>
</details>kea2.1.3Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/680Add new event initiating config review2022-01-10T15:03:58ZMarcin SiodelskiAdd new event initiating config reviewCurrently, config review is started when Kea configuration change has been detected, on demand or when new configuration checkers have been added. We need another optional trigger, when new hosts have been fetched via host_cmds. There ar...Currently, config review is started when Kea configuration change has been detected, on demand or when new configuration checkers have been added. We need another optional trigger, when new hosts have been fetched via host_cmds. There are new checkers using the host information stored in the Stork database. This information changes independently from Kea config updates.1.1Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2251[ISC-support #19987] Race condition on the initialization of flex_id_expr[4|6]2022-02-23T06:32:13ZEverett Fulton[ISC-support #19987] Race condition on the initialization of flex_id_expr[4|6]https://support.isc.org/Ticket/Display.html?id=19987
Customer reports seeing exceptions in the logs:
```
Dec 15 13:26:31 dhcp1 kea-dhcp-safe-start.sh: 2021-12-15 13:26:31.358 ERROR [kea-dhcp4.callouts/11189.139755113694976] HOOKS_CALL...https://support.isc.org/Ticket/Display.html?id=19987
Customer reports seeing exceptions in the logs:
```
Dec 15 13:26:31 dhcp1 kea-dhcp-safe-start.sh: 2021-12-15 13:26:31.358 ERROR [kea-dhcp4.callouts/11189.139755113694976] HOOKS_CALLOUT_EXCEPTION exception thrown by callout on hook pkt4_receive registered by library with index 4 (callout address 0x7f1b46695e60): expression: [relay4[2].hex] error: <string>:1.1-7: syntax error, unexpected [ (callout duration: 0.310 ms)
Dec 15 13:26:31 dhcp1 kea-dhcp-safe-start.sh: 2021-12-15 13:26:31.358 ERROR [kea-dhcp4.callouts/11189.139755122087680] HOOKS_CALLOUT_EXCEPTION exception thrown by callout on hook pkt4_receive registered by library with index 4 (callout address 0x7f1b46695e60): expression: [relay4[2].hex] error: <string>:1.1-6: syntax error, unexpected relay4, expecting top-level bool or top-level string (callout duration: 0.315 ms)
Dec 15 14:27:36 dhcp1 kea-dhcp-safe-start.sh: 2021-12-15 14:27:36.383 ERROR [kea-dhcp4.callouts/16176.140013766174464] HOOKS_CALLOUT_EXCEPTION exception thrown by callout on hook pkt4_receive registered by library with index 4 (callout address 0x7f577f4ce340): expression: [relay4[2].hex] error: <string>:1.8-19: syntax error, unexpected relay4, expecting top-level bool or top-level string (callout duration: 0.352 ms)
```
Razvan stated he had found a race: https://mattermost.isc.org/isc/pl/d1aye5oqgp8xbehpks41r6zkyokea2.1.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3065memory leak on duplicately named dnssec-policy2022-01-11T14:54:59ZMark Andrewsmemory leak on duplicately named dnssec-policy```
[ant-3044:~/git/bind9] marka% named-checkconf lll
mem.c:667: REQUIRE(isc_refcount_current(&ctx->references) == 0) failed, back trace
0 libisc-9.17.20.dylib 0x00000001006ab618 default_callback + 72
1 libisc-9.17.20....```
[ant-3044:~/git/bind9] marka% named-checkconf lll
mem.c:667: REQUIRE(isc_refcount_current(&ctx->references) == 0) failed, back trace
0 libisc-9.17.20.dylib 0x00000001006ab618 default_callback + 72
1 libisc-9.17.20.dylib 0x00000001006ab594 isc_assertion_failed + 56
2 libisc-9.17.20.dylib 0x00000001006c4340 isc__mem_destroy + 372
3 named-checkconf 0x0000000100400548 main + 1460
4 libdyld.dylib 0x000000018afc9430 start + 4
Abort
[ant-3044:~/git/bind9] marka% cat lll
dnssec-policy x {
};
dnssec-policy x {
};
[ant-3044:~/git/bind9] marka%
```January 2022 (9.16.25, 9.16.25-S1, 9.17.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/3066crash happens in rdataset_disassociate2021-12-23T12:48:03Zhen siconcrash happens in rdataset_disassociateBellow is the backtrace when crash happened. It happened when the recordset in zone is updated frequently. From backtrace, it seems the rbt node is invalid so the isc_assertion_failed failed.
The locknum in rbt node is 951, this is wrong...Bellow is the backtrace when crash happened. It happened when the recordset in zone is updated frequently. From backtrace, it seems the rbt node is invalid so the isc_assertion_failed failed.
The locknum in rbt node is 951, this is wrong so it get a wrong lock from rbtdb->node_locks array.
When crash happens, even thread 4 is destroy another rbt_tree but it is not match the memory with thread 11.
(gdb) info threads
Id Target Id Frame
11 Thread 0x7f3a7945f880 (LWP 968) 0x00007f3a76296792 in sigsuspend () from /lib64/libc.so.6
10 Thread 0x7f3a74d4f700 (LWP 969) 0x00007f3a773be965 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
9 Thread 0x7f3a7454e700 (LWP 970) 0x00007f3a773bcd57 in pthread_mutex_lock () from /lib64/libpthread.so.0
8 Thread 0x7f3a7354c700 (LWP 972) 0x00007f3a773be965 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
7 Thread 0x7f3a70d47700 (LWP 977) 0x00007f3a773bed12 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
6 Thread 0x7f3a70546700 (LWP 978) 0x00007f3a7635a0b3 in epoll_wait () from /lib64/libc.so.6
5 Thread 0x7f3a73d4d700 (LWP 971) 0x00007f3a773be965 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
4 Thread 0x7f3a71548700 (LWP 976) 0x00007f3a773be965 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
3 Thread 0x7f3a71d49700 (LWP 975) 0x00007f3a773be965 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
2 Thread 0x7f3a7254a700 (LWP 974) 0x00007f3a773be965 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
* 1 Thread 0x7f3a72d4b700 (LWP 973) 0x00007f3a76296417 in raise () from /lib64/libc.so.6
(gdb) f 11
#11 0x000000000042761a in ns_client_endrequest (client=0x7f3a68198660) at client.c:881
881 client.c: No such file or directory.
(gdb) bt
#0 0x00007f3a76296417 in raise () from /lib64/libc.so.6
#1 0x00007f3a76297b08 in abort () from /lib64/libc.so.6
#2 0x000000000043a046 in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at ./main.c:250
#3 0x00007f3a77a47d9a in isc_assertion_failed (file=file@entry=0x7f3a77a8c81c "rwlock.c", line=line@entry=245, type=type@entry=isc_assertiontype_require,
cond=cond@entry=0x7f3a77a8c8f0 "(__builtin_expect(!!((rwl) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(rwl))->magic == ((('R') << 24 | ('W') << 16 | ('L') << 8 | ('k')))), 1))") at assertions.c:58
#4 0x00007f3a77a633e3 in isc_rwlock_lock (rwl=rwl@entry=0x7f3704188978, type=type@entry=isc_rwlocktype_read) at rwlock.c:245
#5 0x00007f3a78cf0a08 in detachnode (db=0x7f371bab95a0, targetp=targetp@entry=0x7f3a72d492e8) at rbtdb.c:5425
#6 0x00007f3a78cf0c2e in rdataset_disassociate (rdataset=<optimized out>) at rbtdb.c:8466
#7 0x00007f3a78d47ce8 in dns_rdataset_disassociate (rdataset=rdataset@entry=0x7f3a6f8feef0) at rdataset.c:123
#8 0x00007f3a78cc4c81 in msgresetnames (first_section=0, msg=0x7f3a6f8f5010, msg@entry=0x7f3a6f8fb060) at message.c:451
#9 msgreset (msg=msg@entry=0x7f3a6f8f5010, everything=everything@entry=isc_boolean_false) at message.c:535
#10 0x00007f3a78cc5a7a in dns_message_reset (msg=0x7f3a6f8f5010, intent=intent@entry=1) at message.c:792
#11 0x000000000042761a in ns_client_endrequest (client=0x7f3a68198660) at client.c:881
#12 exit_check (client=0x7f3a68198660) at client.c:534
#13 0x00000000004292d0 in ns_client_detach (clientp=clientp@entry=0x7f3a72d494e8) at client.c:3386
#14 0x0000000000446ef8 in query_find (client=0x0, event=event@entry=0x0, qtype=qtype@entry=1) at query.c:8417
#15 0x0000000000450ea5 in ns_query_start (client=client@entry=0x7f3a68198660) at query.c:8708
#16 0x000000000042c2d2 in client_request (task=<optimized out>, event=<optimized out>) at client.c:2827
#17 0x00007f3a77a6b4f3 in dispatch (manager=0x7f3a79422010) at task.c:1128
#18 run (uap=0x7f3a79422010) at task.c:1300
#19 0x00007f3a773bae45 in start_thread () from /lib64/libpthread.so.0
#20 0x00007f3a76359add in clone () from /lib64/libc.so.6
(gdb) f 4
#4 0x00007f3a77a633e3 in isc_rwlock_lock (rwl=rwl@entry=0x7f3704188978, type=type@entry=isc_rwlocktype_read) at rwlock.c:245
245 rwlock.c: No such file or directory.
(gdb) info local
No locals.
(gdb) p entry
No symbol "entry" in current context.
(gdb) p rwl
$6 = (isc_rwlock_t *) 0x7f3704188978
(gdb) p *rwl
$7 = {magic = 3200171710, lock = {__data = {__lock = -1094795586, __count = 3200171710, __owner = -1094795586, __nusers = 3200171710, __kind = -1094795586,
__spins = -16706, __elision = -16706, __list = {__prev = 0xbebebebebebebebe, __next = 0xbebebebebebebebe}}, __size = '\276' <repeats 40 times>,
__align = -4702111234474983746}, write_requests = -1094795586, write_completions = -1094795586, cnt_and_flag = -1094795586, readable = {__data = {
__lock = -1094795586, __futex = 3200171710, __total_seq = 13744632839234567870, __wakeup_seq = 13744632839234567870, __woken_seq = 13744632839234567870,
__mutex = 0xbebebebebebebebe, __nwaiters = 3200171710, __broadcast_seq = 3200171710}, __size = '\276' <repeats 48 times>,
__align = -4702111234474983746}, writeable = {__data = {__lock = -1094795586, __futex = 3200171710, __total_seq = 13744632839234567870,
__wakeup_seq = 13744632839234567870, __woken_seq = 13744632839234567870, __mutex = 0xbebebebebebebebe, __nwaiters = 3200171710,
__broadcast_seq = 3200171710}, __size = '\276' <repeats 48 times>, __align = -4702111234474983746}, readers_waiting = 3200171710,
write_granted = 3200171710, write_quota = 3200171710}
(gdb) p rwl->magic
$8 = 3200171710
gdb) f 5
#5 0x00007f3a78cf0a08 in detachnode (db=0x7f371bab95a0, targetp=targetp@entry=0x7f3a72d492e8) at rbtdb.c:5425
5425 rbtdb.c: No such file or directory.
(gdb) info local
rbtdb = 0x7f371bab95a0
node = 0x7f3719c3f5b0
want_free = isc_boolean_false
inactive = isc_boolean_false
nodelock = 0x7f3704188978
(gdb) p node->locknum
$11 = 951
(gdb) p *node
$25 = {magic = 740377912, is_root = 1, color = 1, find_callback = 1, attributes = 6, nsec = 0, namelen = 127, offsetlen = 0, oldnamelen = 0, is_mmapped = 0,
parent_is_relative = 1, left_is_relative = 1, right_is_relative = 1, down_is_relative = 1, data_is_relative = 0, rpz = 1, hashval = 3739147998,
uppernode = 0xdededededededede, hashnext = 0xdededededededede, parent = 0xdededededededede, left = 0xdededededededede, right = 0xdededededededede,
down = 0xdededededededede, deadlink = {prev = 0xdededededededede, next = 0xdededededededede}, data = 0xdededededededede, dirty = 0, wild = 1, locknum = 951,
references = {refs = -555819298}}
(gdb) t 9
[Switching to thread 9 (Thread 0x7f3a7454e700 (LWP 970))]
#0 0x00007f3a773bcd57 in pthread_mutex_lock () from /lib64/libpthread.so.0
(gdb) info local
No symbol table info available.
(gdb) bt
#0 0x00007f3a773bcd57 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1 0x00007f3a77a63864 in isc_rwlock_unlock (rwl=0x7f370415e018, type=type@entry=isc_rwlocktype_write) at rwlock.c:510
#2 0x00007f3a78ce819d in delete_callback (data=<optimized out>, arg=0x7f371bab95a0) at rbtdb.c:7717
#3 0x00007f3a78cda981 in deletetreeflat (rbt=rbt@entry=0x7f35972fe0f8, quantum=213, unhash=unhash@entry=isc_boolean_false, nodep=nodep@entry=0x7f35972fe108)
at rbt.c:2841
#4 0x00007f3a78cdb9f8 in dns_rbt_destroy2 (rbtp=rbtp@entry=0x7f371bab9830, quantum=<optimized out>) at rbt.c:1022
#5 0x00007f3a78ce34c2 in free_rbtdb (rbtdb=0x7f371bab95a0, log=isc_boolean_true, event=0x7f3895445dd0) at rbtdb.c:1185
#6 0x00007f3a77a6b4f3 in dispatch (manager=0x7f3a79422010) at task.c:1128
#7 run (uap=0x7f3a79422010) at task.c:1300
#8 0x00007f3a773bae45 in start_thread () from /lib64/libpthread.so.0
#9 0x00007f3a76359add in clone () from /lib64/libc.so.6https://gitlab.isc.org/isc-projects/bind9/-/issues/3067Implement TLS context cache2022-01-04T16:05:39ZArtem BoldarievImplement TLS context cacheThe intention of having a TLS context cache object is manyfold:
- In the case of client-side contexts: allow reusing the previously
created contexts to employ the context-specific TLS session resumption
cache. That will enable XoT conne...The intention of having a TLS context cache object is manyfold:
- In the case of client-side contexts: allow reusing the previously
created contexts to employ the context-specific TLS session resumption
cache. That will enable XoT connection to be reestablished faster and
with fewer resources by not going through the full TLS handshake
procedure.
- In the case of server-side contexts: reduce the number of contexts
created on startup. That could reduce startup time in a case when
there are many `listen-on` statements referring to a smaller amount of
`tls` statements, especially when `ephemeral` certificates are
involved.
- The long-term goal is to provide in-memory storage for additional
data associated with the certificates, like runtime
representation (`X509_STORE`) of intermediate CA-certificates bundle for
Strict TLS/Mutual TLS (`ca-file`).
*See !5672, #1784*January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3068"shutdown" system test sometimes triggers shutdown hangs2021-12-28T12:42:48ZMichał Kępień"shutdown" system test sometimes triggers shutdown hangsInfrequently, the `shutdown` system test triggers shutdown hangs when
run on the `main` branch:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2177353
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2190765
- https://gitlab...Infrequently, the `shutdown` system test triggers shutdown hangs when
run on the `main` branch:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2177353
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2190765
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2190770January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3069"resolver" test fails intermittently2022-04-01T13:07:44ZMichał Kępień"resolver" test fails intermittentlyThe recently-added (only on `main`) check for a SERVFAIL response to a
TCP query with an empty question section fails pretty frequently. The
check was added in commit 2f3ded7652e31be2a278c49b6e8e6219a11411b1 (part
of !5616). Despite a ...The recently-added (only on `main`) check for a SERVFAIL response to a
TCP query with an empty question section fails pretty frequently. The
check was added in commit 2f3ded7652e31be2a278c49b6e8e6219a11411b1 (part
of !5616). Despite a [code comment][1] suggesting otherwise, the test
fails due to `dig` hitting a timeout instead of receiving a SERVFAIL
response:
```
$ cat dig.ns5.out.70
; <<>> DiG 9.17.21 <<>> -p 29349 @10.53.0.5 -b 10.53.0.5 +tcp tcpalso.no-questions. a +tries=3 +time=4
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
```
Example occurrences:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2197750
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2197749
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2197279
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2196581
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2185707
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2185704
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2185288
Most of these happened on FreeBSD, but two happened on Linux (under
TSAN), so the common denominator seems to be "machine under load" rather
than "only happens on FreeBSD".
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/cb22ed049207c165c0f986a032e96c16986ffd48/bin/tests/system/resolver/tests.sh#L829-831January 2022 (9.18.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/3070DoH example config2021-12-30T06:58:33ZawoldeDoH example configI have this config trying out DoH on Bind 9.17
```
acl goodclients {
192.168.1.0/24;
localhost;
localnets;
};
tls local-tls {
key-file "/etc/bind/server.key";
cert-file "/etc/bind/server.crt";
};...I have this config trying out DoH on Bind 9.17
```
acl goodclients {
192.168.1.0/24;
localhost;
localnets;
};
tls local-tls {
key-file "/etc/bind/server.key";
cert-file "/etc/bind/server.crt";
};
# HTTP endpoint description
http local-http-server {
# multiple paths can be specified
endpoints { "/dns-query"; };
};
options {
directory "/var/cache/bind";
listen-on port 53 {any;};
listen-on-v6 port 53 {any;};
recursion yes;
allow-query { goodclients; };
allow-recursion { goodclients; };
forwarders {
1.1.1.1;
1.0.0.1;
#8.8.8.8;
#8.8.4.4;
};
forward only;
#dnssec-enable yes;
#dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
http-port 80;
https-port 443;
max-cache-size 5%;
listen-on port 443 tls local-tls http default {any;};
listen-on-v6 port 443 tls local-tls http default {any;};
};
```
Cant seem to get https to work. Port 53 works fine. Here's the error message I get from kdig
```
kdig -d @192.168.1.1 +tls-ca +tls-host=ns.example.com www.google.co.uk -p 443
;; DEBUG: Querying for owner(www.google.co.uk.), class(1), type(1), server(192.168.1.1), port(443), protocol(TCP)
;; DEBUG: TLS, imported 129 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG: #1, C=AU,ST=Some-State,O=Internet Widgits Pty Ltd,CN=ns.example.com
;; DEBUG: SHA-256 PIN: /BaoYTTAMxnRXqqmEHIWvlG+wUO+FQhcliV4a4Xvgm8=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted.
;; WARNING: failed to query server 192.168.1.1@443(TCP)
```
I'm using a self signed cert which I imported to the systems trusted ca list. Any complete example would be highly appreciated.https://gitlab.isc.org/isc-projects/kea/-/issues/2254Prepare subnet selection speedup: simplified collections2022-01-18T16:35:34ZFrancis DupontPrepare subnet selection speedup: simplified collectionsThe global collection is the only case where all indexes of SubnetXCollection are useful. In other cases, for instance members of a shared network, it is enough to have the by-id and by-prefix indexes.
The code comes from #554The global collection is the only case where all indexes of SubnetXCollection are useful. In other cases, for instance members of a shared network, it is enough to have the by-id and by-prefix indexes.
The code comes from #554kea2.1.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3071Signed version of an inline-signed zone may be dumped without unsigned serial...2022-01-06T11:27:25ZMichał KępieńSigned version of an inline-signed zone may be dumped without unsigned serial number informationWhen the signed version of an inline-signed zone is dumped to disk, the
serial number of the unsigned version of the zone is written in the
raw-format header so that the contents of the signed zone can be
resynchronized after `named` res...When the signed version of an inline-signed zone is dumped to disk, the
serial number of the unsigned version of the zone is written in the
raw-format header so that the contents of the signed zone can be
resynchronized after `named` restart if the unsigned zone file is
modified while `named` is not running (see [RT #26676][1]).
In order for the serial number of the unsigned zone to be determined
during the dump, `zone->raw` must be set to a non-`NULL` value. This
should always be the case as long as the signed version of the zone is
used for anything by `named`.
However, a scenario exists in which the signed version of the zone has
`zone->raw` set to `NULL` while it is being dumped:
1. Zone dump is requested; `zone_dump()` is invoked.
2. Another zone dump is already in progress, so the dump gets deferred
until I/O is available (see `zonemgr_getio()`).
3. The last external reference to the zone is released.
`zone_shutdown()` gets queued to the zone's task.
4. I/O becomes available for zone dumping. `zone_gotwritehandle()`
gets queued to the zone's task.
5. The zone's task runs `zone_shutdown()`. `zone->raw` gets set to
`NULL`.
6. The zone's task runs `zone_gotwritehandle()`. `zone->raw` is
determined to be `NULL`, causing the serial number of the unsigned
version of the zone to be omitted from the raw-format dump of the
signed zone file.
I believe this issue became easier to trigger in BIND 9.12.0. That was
the first BIND 9 release containing change 4613 (see [RT #38324][2]),
specifically this hunk:
```diff
@@ -9773,7 +9822,7 @@ dns_zone_flush(dns_zone_t *zone) {
dumping = ISC_TRUE;
UNLOCK_ZONE(zone);
if (!dumping)
- result = zone_dump(zone, ISC_FALSE); /* Unknown task. */
+ result = zone_dump(zone, ISC_TRUE); /* Unknown task. */
return (result);
}
```
`zone_dump()` can either perform the `zone->raw` check itself or defer
it until zone dump I/O becomes available. Before the above change,
deferring the check was only possible if `zone_dump()` was called from
`zone_maintenance()` (which itself is timer-based). The above change
enables the `zone->raw` check to also be deferred when `zone_dump()` is
called from `dns_zone_flush()`, i.e. essentially from anywhere,
particularly from zone table cleanup callbacks which are run when the
zone's reference count is likely to drop to zero, triggering
`zone_shutdown()` and ultimately causing the bug above.
The above change was originally introduced in commit
[980611a3fe3ececeb0049b9e7c2e380b577f5e68][3] without any detailed
explanation. I am not entirely sure why, but the change seems to be
necessary in order for some tests related to `max-journal-size` to pass.
I ran out of time to determine why that is. Note, however, that
`zone_dump()` [warns][4] against setting `compact` to `true` for
non-task-locked call sites (see also the code comments next to
`zone_dump()` invocations).
At any rate, I believe that the bug could be triggered even without the
above change - when the zone's reference count drops to zero while
`zone_maintenance()` is running. I have not confirmed that it is
practically possible and I can certainly be missing some implicit
protection against such a triggering scenario happening. It does not
matter much anyway with BIND 9.11 reaching EoL soon and this not being a
critical problem.
The only quick way to fix this issue that I see is to defer detaching
from `zone->raw` in `zone_shutdown()` if the zone is in the process of
being dumped to disk.
The problem is easily reproducible, though I need to find a clean way of
turning it into a system test.
This problem was [discovered][5] in the process of attempting to fix an
unrelated issue.
[1]: https://bugs.isc.org/Ticket/Display.html?id=26676
[2]: https://bugs.isc.org/Ticket/Display.html?id=38324
[3]: https://gitlab.isc.org/isc-archive/bind9/-/commit/980611a3fe3ececeb0049b9e7c2e380b577f5e68
[4]: https://gitlab.isc.org/isc-projects/bind9/-/blob/ae7ba926d4dca3f3d3eedc63d946b4f99f438029/lib/dns/zone.c#L11967-11969
[5]: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5676#note_257235January 2022 (9.16.25, 9.16.25-S1, 9.17.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/3072Investigate/fix how CATZ update post-processing can block servicing of inboun...2023-01-19T09:31:38ZCathy AlmondInvestigate/fix how CATZ update post-processing can block servicing of inbound queries in BIND 9.16Related to Support Ticket [RT #19629](https://support.isc.org/Ticket/Display.html?id=19629)
After upgrading a busy authoritative server from BIND 9.11 to BIND 9.16, the behaviour of the RTTs on the primary zone monitoring test queries (...Related to Support Ticket [RT #19629](https://support.isc.org/Ticket/Display.html?id=19629)
After upgrading a busy authoritative server from BIND 9.11 to BIND 9.16, the behaviour of the RTTs on the primary zone monitoring test queries (sampled at a rate of 2 QPS) changed significantly to become much more 'spiky'. Overall, the RTTs are lower (9.16 is faster at servicing queries than 9.11), but there are some significant 'spikes' where the RTT of the test queries are much larger than average.
Investigation of the causes (carried out by eliminating potential candidates during the running and monitoring of a 'test' server highlighted that the 'spikes' corresponded to the period immediately after an update had been received for a catalog zone.
(Also noted was that the spikes didn't occur after every catalog zone update, but this would tally with the way that inbound client queries are hashed to a netmgr thread which may or may not be the one to get temporarily blocked by CATZ post-processing)
---
My understanding is that catalog zone post-processing is a task that runs to completion, so does not iterate/pause for the duration of its operation to sort out adds/deletes/changes to catalog zones on the receiving secondary server - so this is a plausible cause for these test RTT spikes.
Also a potential candidate might be inbound AXFR/IXFR processing as a follow-on outcome of CATZ updates.
---
Please can this be investigated/tested/confirmed and solutions considered. It may be that CATZ post-processing should be considered as another candidate to migrate to threadpools, although it might also need to be something that iterates also, if it ends up locking resources that could block inbound client queries too (as in, it's not just about it sitting on the netmgr thread doing its thing, but it also by what it is doing, blocks other threads - ref !5151https://gitlab.isc.org/isc-projects/kea/-/issues/2257lease not loaded from memfile if user context has multiple key-value pairs2022-01-12T12:26:19ZAndrei Pavelandrei@isc.orglease not loaded from memfile if user context has multiple key-value pairsmemfile CSV:
```
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context
10.0.0.1,ff:01:02:03:04:08,01:ff:01:02:03:04:08,7200,1641205200,1,0,0,,0,{"comment": "hello", "comment2": "do not rel...memfile CSV:
```
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context
10.0.0.1,ff:01:02:03:04:08,01:ff:01:02:03:04:08,7200,1641205200,1,0,0,,0,{"comment": "hello", "comment2": "do not release"}
```
error:
```
ERROR DHCPSRV_MEMFILE_LEASE_LOAD_ROW_ERROR discarding row x, error: EOF read, one of ",}" expected in <string>:y:z
```
See `MemfileLeaseMgrTest.v4UserContext` and `MemfileLeaseMgrTest.v6UserContext` unit tests. They will require adjustments.https://gitlab.isc.org/isc-projects/bind9/-/issues/3073NSUPDATE crypto failure2022-01-03T11:47:35ZJan SorensenNSUPDATE crypto failure<!--
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
NSUPDATE returns dns_request_createvia: crypto failure
### BIND version used
BIND 9.17.21 (Development Release) <id:ffdb856>
running on Linux x86_64 4.18.0-348.7.1.el8_5.x86_64 #1 SMP Tue Dec 21 19:02:23 UTC 2021
built by make with '--disable-linux-caps' '--with-gssapi=no' '--with-tuning=small' '--with-libnghttp2=no' '--disable-doh' 'LDFLAGS=-L/usr/local/lib64/' 'CPPFLAGS=-I/usr/local/include/openssl'
compiled by GCC 8.5.0 20210514 (Red Hat 8.5.0-4)
compiled with OpenSSL version: OpenSSL 3.0.1 14 Dec 2021
linked to OpenSSL version: OpenSSL 3.0.1 14 Dec 2021
compiled with libuv version: 1.41.1
linked to libuv version: 1.41.1
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
DNSSEC root key: /usr/local/etc/bind.keys
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
named lock file: /usr/local/var/run/named/named.lock
### Steps to reproduce
/usr/local/bin/nsupdate -DD -k bistruphave.key file
### What is the current *bug* behavior?
setup_system()
Creating key...
Creating key...
namefromtext
keycreate
reset_system()
user_interaction()
do_next_command()
do_next_command()
evaluate_update()
update_addordelete()
do_next_command()
evaluate_update()
update_addordelete()
do_next_command()
evaluate_update()
update_addordelete()
do_next_command()
start_update()
dns_request_createvia: crypto failure
### What is the expected *correct* behavior?
No crypto failure
### Additional information
When NSUPDATE is compiled with OpenSSL version 1.1.1 it works correctly.
With version 3.0.1 it fails, and no traffic is observed with tcpdump on the
primary DNS server, which should receive the update.https://gitlab.isc.org/isc-projects/stork/-/issues/681Optimize host reservation puller2022-02-01T12:53:59ZMarcin SiodelskiOptimize host reservation pullerKea provides no way to signal whether or not host reservations have changed in the database. Thus, Stork always fetches all host reservations for a daemon and updates them in its database. In a typical environment, the host reservations ...Kea provides no way to signal whether or not host reservations have changed in the database. Thus, Stork always fetches all host reservations for a daemon and updates them in its database. In a typical environment, the host reservations do not change very often and there is no need to update them in the Stork database all the time. In addition, the ticket #680 introduces config reviews for host reservations. Right now, the config reviews are scheduled every time the puller fetched all reservations. We should optimize the hosts puller to check whether there are any changes to the pulled host reservations and update the reservations in the Stork database only when there were some changes. The config reviews should be scheduled only when at least one host reservation has changed.1.1Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2258Cloudsmith repos not working with RockyLinux 8.5 (RHEL8)2022-02-10T14:53:41ZOlavi KuldveeCloudsmith repos not working with RockyLinux 8.5 (RHEL8)---
name: Cloudsmith repos not working with RockyLinux 8.5 (RHEL8)
about: RHEL8 and derivates come default with ISC-KEA 1.8.0 from EPEL-release repo, if you want to update to newer binary version, you have to add repos from ISC Cloudsmit...---
name: Cloudsmith repos not working with RockyLinux 8.5 (RHEL8)
about: RHEL8 and derivates come default with ISC-KEA 1.8.0 from EPEL-release repo, if you want to update to newer binary version, you have to add repos from ISC Cloudsmith and get newer versions of ISC-KEA from there.
---
All ISC Cloudsmith .repo setup links come with faulty urls to download RPMs for ISC-KEA.
**To Reproduce**
1. Install RockyLinux 8.4/8.5
2. Add ISC-KEA repo from https://cloudsmith.io/~isc/repos/ (Set Me Up -> RedHat)
3. After adding ISC-KEA repo, try "dnf search kea"
4. Result is, only KEA 1.8.0 is listed from EPEL repo, no ISC-KEA is listed.
**Expected behavior**
You should get both versions of KEA(KEA from EPEL and ISC-KEA from Cloudsmith) listed from both repos, if you have added EPEL and Cloudsmith repos installed.
**Environment:**
- Kea version: Tried all "Set Me Up -> RedHat" repos from 1.9-2.0-2.1
- OS: RockyLinux 8.5 4.18.0-348.7.1.el8_5.x86_64
**Solution**
1. cd /etc/yum.repos.d
2. Fix urls in isc-kea-2-1.repo (or isc-kea-1-9.repo, isc-kea-2-0.repo)
3. Find three lines with each section
baseurl=https://dl.cloudsmith.io/public/isc/kea-2-1/rpm/rocky/8.5/$basearch
And replace "rocky" with "el" and "8.5" with "8"
baseurl=https://dl.cloudsmith.io/public/isc/kea-2-1/rpm/el/8/$basearch
4. After these replacements, ISC-KEA is listed in DNF packages and can be installed without problems.Vicky Riskvicky@isc.orgVicky Riskvicky@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2259gss-tsig-rekey and gss-tsig-rekey-all are missing from the ARM2022-04-07T20:12:36ZAndrei Pavelandrei@isc.orggss-tsig-rekey and gss-tsig-rekey-all are missing from the ARM* [X] add `src/share/api/gss-tsig-rekey.json`
* [X] add `src/share/api/gss-tsig-rekey-all.json`* [X] add `src/share/api/gss-tsig-rekey.json`
* [X] add `src/share/api/gss-tsig-rekey-all.json`kea2.1.5Razvan BecheriuRazvan Becheriu