ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-02-03T14:57:00Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2277HA design document update2022-02-03T14:57:00ZPeter DaviesHA design document updatehigh availability design document update
Regarding the design document at https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/High-Availability-Design
It contains an example of a HA "url" containing a fully qualified domain name. T...high availability design document update
Regarding the design document at https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/High-Availability-Design
It contains an example of a HA "url" containing a fully qualified domain name. This should be an IP address.
Also the HA timer values are described as being in seconds where they should be milliseconds in the comments to example configurations.
[RT #20025](https://support.isc.org/Ticket/Display.html?id=20025)Vicky Riskvicky@isc.orgVicky Riskvicky@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/31039.17.21 will not compile on centos 7.42022-01-18T10:54:53Zchampiondot9.17.21 will not compile on centos 7.4```
gcc -std=gnu99 -include /root/xiejieling/bind-9.16.18/config.h -I/root/xiejieling/bind-9.16.18 -I../.. -I/root/xiejieling/bind-9.16.18/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/...```
gcc -std=gnu99 -include /root/xiejieling/bind-9.16.18/config.h -I/root/xiejieling/bind-9.16.18 -I../.. -I/root/xiejieling/bind-9.16.18/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -g -O2 -pthread -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers -fno-strict-aliasing -c pkcs11-keygen.c
pkcs11-keygen.c:79:1: 错误:用非常量的数组表达式初始化数组
static CK_BYTE pk11_ecc_prime256v1[] = PK11_ECC_PRIME256V1;
^
pkcs11-keygen.c:80:1: 错误:用非常量的数组表达式初始化数组
static CK_BYTE pk11_ecc_secp384r1[] = PK11_ECC_SECP384R1;
^
pkcs11-keygen.c:81:1: 错误:用非常量的数组表达式初始化数组
static CK_BYTE pk11_ecx_ed25519[] = PK11_ECX_ED25519;
^
pkcs11-keygen.c:82:1: 错误:用非常量的数组表达式初始化数组
static CK_BYTE pk11_ecx_ed448[] = PK11_ECX_ED448;
^
make[2]: *** [pkcs11-keygen.o] 错误 1
make[2]: 离开目录“/root/xiejieling/bind-9.16.18/bin/pkcs11”
make[1]: *** [subdirs] 错误 1
make[1]: 离开目录“/root/xiejieling/bind-9.16.18/bin”
make: *** [subdirs] 错误 1
``https://gitlab.isc.org/isc-projects/bind9/-/issues/3102ASAN error in fctx_cancelquery()2023-11-03T07:32:07ZMichał KępieńASAN error in fctx_cancelquery()Apparently #3018/!5584 was not the only scenario to fix.
https://gitlab.isc.org/isc-projects/bind9/-/jobs/2233451
<details>
<summary>Click to expand/collapse backtrace</summary>
<pre>D:forward:Core was generated by `/builds/isc-project...Apparently #3018/!5584 was not the only scenario to fix.
https://gitlab.isc.org/isc-projects/bind9/-/jobs/2233451
<details>
<summary>Click to expand/collapse backtrace</summary>
<pre>D:forward:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D forward-ns3 -X named.lock -'.
D:forward:Program terminated with signal SIGABRT, Aborted.
D:forward:#0 0x00007f82ca52984c in __pthread_kill_implementation () from /lib64/libc.so.6
D:forward:[Current thread is 1 (Thread 0x7f82c26e8640 (LWP 6446))]
D:forward:#0 0x00007f82ca52984c in __pthread_kill_implementation () from /lib64/libc.so.6
D:forward:#1 0x00007f82ca4dc6a6 in raise () from /lib64/libc.so.6
D:forward:#2 0x00007f82ca4c67d3 in abort () from /lib64/libc.so.6
D:forward:#3 0x00007f82ce2a05df in __sanitizer::Abort() () from /lib64/libasan.so.6
D:forward:#4 0x00007f82ce2ab94c in __sanitizer::Die() () from /lib64/libasan.so.6
D:forward:#5 0x00007f82ce28cd9c in __asan::ScopedInErrorReport::~ScopedInErrorReport() () from /lib64/libasan.so.6
D:forward:#6 0x00007f82ce28c666 in __asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) () from /lib64/libasan.so.6
D:forward:#7 0x00007f82ce28d22c in __asan_report_load4 () from /lib64/libasan.so.6
D:forward:#8 0x00007f82cc974fa5 in fctx_cancelquery (queryp=queryp@entry=0x7f82c26e1fb0, finish=0x7f82c26e29a8, no_response=no_response@entry=false, age_untried=age_untried@entry=false) at resolver.c:1297
D:forward:#9 0x00007f82cc99e8df in rctx_done (rctx=rctx@entry=0x7f82c26e2930, result=result@entry=ISC_R_SUCCESS) at resolver.c:9658
D:forward:#10 0x00007f82cc9af918 in resquery_response (eresult=eresult@entry=ISC_R_SUCCESS, region=region@entry=0x7f82c26e4570, arg=<optimized out>) at resolver.c:7805
D:forward:#11 0x00007f82cc5b49a5 in udp_recv (handle=<optimized out>, eresult=ISC_R_SUCCESS, region=<optimized out>, arg=<optimized out>) at dispatch.c:593
D:forward:#12 0x00007f82cd8f6f00 in isc__nm_async_readcb (worker=worker@entry=0x0, ev0=ev0@entry=0x7f82c26e4610) at netmgr/netmgr.c:2798
D:forward:#13 0x00007f82cd8f755f in isc__nm_readcb (sock=sock@entry=0x61d0000a3280, uvreq=uvreq@entry=0x61d0000a4680, eresult=eresult@entry=ISC_R_SUCCESS) at netmgr/netmgr.c:2771
D:forward:#14 0x00007f82cd934490 in udp_recv_cb (handle=handle@entry=0x61d0000a3830, nrecv=nrecv@entry=339, buf=buf@entry=0x7f82c26e4860, addr=addr@entry=0x7f82c26e48b0, flags=flags@entry=0) at netmgr/udp.c:641
D:forward:#15 0x00007f82cd93854f in isc__nm_udp_read_cb (handle=0x61d0000a3830, nrecv=339, buf=0x7f82c26e4860, addr=0x7f82c26e48b0, flags=0) at netmgr/udp.c:1047
D:forward:#16 0x00007f82cb21acc4 in uv__udp_recvmsg (handle=0x61d0000a3830) at /usr/src/libuv-v1.43.0/src/unix/udp.c:302
D:forward:#17 0x00007f82cb21a5e8 in uv__udp_io (loop=0x6280000021e0, w=0x61d0000a38b0, revents=1) at /usr/src/libuv-v1.43.0/src/unix/udp.c:178
D:forward:#18 0x00007f82cb22162b in uv__io_poll (loop=0x6280000021e0, timeout=800) at /usr/src/libuv-v1.43.0/src/unix/epoll.c:374
D:forward:#19 0x00007f82cb205c01 in uv_run (loop=0x6280000021e0, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.43.0/src/unix/core.c:389
D:forward:#20 0x00007f82cd8fad6d in nm_thread (worker0=0x6280000021d0) at netmgr/netmgr.c:691
D:forward:#21 0x00007f82cd9f87f6 in isc__trampoline_run (arg=0x60300002c6b0) at trampoline.c:187
D:forward:#22 0x00007f82ca527a87 in start_thread () from /lib64/libc.so.6
D:forward:#23 0x00007f82ca5ab8d4 in clone () from /lib64/libc.so.6
D:forward:--------------------------------------------------------------------------------</pre>
</details>
Unfortunately, the job ran over the weekend and the artifacts were no
longer available when I tried to examine them today, so I am unable to
paste the full ASAN report. However, judging from line numbers, the
problem lies here:
```c
1286 REQUIRE(queryp != NULL);
1287
1288 query = *queryp;
1289 fctx = query->fctx;
1290
1291 if (RESQUERY_CANCELED(query)) {
1292 return;
1293 }
1294
1295 FCTXTRACE("cancelquery");
1296
1297 >>> query->attributes |= RESQUERY_ATTR_CANCELED;
```
Looking at the test output, I sense this is happening on shutdown.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3101doth: enable max-age checking in system test on OpenBSD2022-01-21T07:37:17ZMichal Nowakdoth: enable max-age checking in system test on OpenBSDOpenBSD's `curl` has HTTP/2 support but because of differences in `grep` implementation, a check in `doth` test [disables](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2233880) max-age checking tests which need HTTP/2 aware `curl` an...OpenBSD's `curl` has HTTP/2 support but because of differences in `grep` implementation, a check in `doth` test [disables](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2233880) max-age checking tests which need HTTP/2 aware `curl` and are skipped with `The available version of CURL does not have HTTP/2 support` message.
`curl -V`:
```
curl 7.79.0 (x86_64-unknown-openbsd7.0) libcurl/7.79.0 LibreSSL/3.4.1 zlib/1.2.11 nghttp2/1.44.0
Release-Date: 2021-09-15
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL UnixSockets
```
But the current check won't detect it:
```
$ /usr/local/bin/curl --version | grep '^Features:.* HTTP2\( \|$\)'
$
```
This should do (also tested on Fedora 35 & FreeBSD 12.3):
```
$ /usr/local/bin/curl --version | grep -E '^Features:.* HTTP2( |$)'
Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL UnixSockets
```
The check originated here: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5585#note_250222.January 2022 (9.18.0)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3100bind-9.17.21 configure error: "EVP_DigestSignInit/EVP_DigestVerifyInit suppor...2022-01-17T10:14:58ZbboyHanbind-9.17.21 configure error: "EVP_DigestSignInit/EVP_DigestVerifyInit support in OpenSSL is mandator"my openssl version is 1.1.1,(I try to change my openssl version - 1.0.x also can't)
use command:
./configure --prefix=/usr/local/bind --with-dlz-mysql=/usr/local/mariadb/ --enable-threads --disable-chroot --enable-largefile --enable-epo...my openssl version is 1.1.1,(I try to change my openssl version - 1.0.x also can't)
use command:
./configure --prefix=/usr/local/bind --with-dlz-mysql=/usr/local/mariadb/ --enable-threads --disable-chroot --enable-largefile --enable-epoll --without-python
ERROR
config: EVP_DigestSignInit/EVP_DigestVerifyInit support in OpenSSL is mandator
see 'config.log' ...
I change my bind9 version to 9.11.36. Nothing goes wrong.https://gitlab.isc.org/isc-projects/bind9/-/issues/3099doth system test fails because it uses 'timeout'2022-01-18T10:03:12ZMark Andrewsdoth system test fails because it uses 'timeout'```
I:doth:checking max-age for positive answer (146)
I:doth:checking max-age for negative answer (147)
I:doth:checking sending a DoT query using gnutls-cli (148)
tests.sh: line 603: timeout: command not found
I:doth:failed
I:doth:exit s...```
I:doth:checking max-age for positive answer (146)
I:doth:checking max-age for negative answer (147)
I:doth:checking sending a DoT query using gnutls-cli (148)
tests.sh: line 603: timeout: command not found
I:doth:failed
I:doth:exit status: 1
I:doth:stopping servers
R:doth:FAIL
E:doth:2022-01-17T14:29:17+1100
FAIL: doth
```
`timeout` is GNU specific. `&& sleep 10 && cat /dev/null` should work if `sleep` is closing `stdout` at startup. Additionally `timeout 10 cat` reads from `stdin` which no part of the system tests should do.January 2022 (9.18.0)https://gitlab.isc.org/isc-projects/kea/-/issues/2273HA Peers can't send Heartbeat (HA+TLS)2022-08-31T10:23:31ZGJEHA Peers can't send Heartbeat (HA+TLS)I have installed and configured KEA Server version 2.0.0 in 2 Debian 10 Buster virtual machines in Virtual Box and I was able to install these machines in Stork. Also I have successfully configured logging and ha hooks on both machines. ...I have installed and configured KEA Server version 2.0.0 in 2 Debian 10 Buster virtual machines in Virtual Box and I was able to install these machines in Stork. Also I have successfully configured logging and ha hooks on both machines. Unfortunately when I try to set up HA (either with load -balancing and hot-standby) they have both unavailable HA status. For communication between KEA Servers I have followed the instruction in kea 2.0.0 admin reference manual(/kea-2.0.0/src/lib/asiolink/testutils/ca/doc).
Regarding dhcpv4 logs both machines can't send ha-heartbeat message. Regarding control agents logs tls-handshake failed but I can't find more detailed info about that.
I have configured HA as followed (in kea-dhcp4.conf file)
"hooks-libraries": [
{
"library": "/usr/local/lib/kea/hooks/libdhcp_stat_cmds.so",
"parameters": { }
},
{
"library": "/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so",
"parameters": { }
},
{ "library": "/usr/local/lib/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [{
"this-server-name": "server2",
"mode": "load-balancing",
"heartbeat-delay": 10000,
"max-response-delay": 60000,
"max-ack-delay": 5000,
"max-unacked-clients": 5,
"delayed-updates-limit": 100,
"peers": [{
"name": "server2",
"url": "http://192.168.0.20:8090/",
"role": "secondary",
"auto-failover": true
}, {
"name": "enea",
"url": "http://192.168.0.10:8088/",
"role": "primary",
"auto-failover": true
}]
}]
}
}
],
Example of my control agent configuration in kea-ctrl-agent.conf:
"http-host": "192.168.0.20",
"http-port": 8090,
"trust-anchor": "/KEA/StorkCA.pem",
"cert-file": "/KEA/keacrt2.pem",
"key-file": "KEA/keakey2.pem",
![HA_Error_End_of_File](/uploads/98a27148a62d164bf90aee111b9e1baf/HA_Error_End_of_File.jpg)
![TLS_Handshake_Error](/uploads/b7a8494f9d02e13fc89e60c70c540621/TLS_Handshake_Error.jpg)
![HA_Status](/uploads/a6d159ba8bcca8c9fc6c42fb1ee36445/HA_Status.jpg)kea2.3.0https://gitlab.isc.org/isc-projects/kea/-/issues/2272ddns-override-domain-name2022-04-19T09:37:10ZPeter Daviesddns-override-domain-nameddns-override-domain-name:
When a client sends a FQDN ( option 81) in a DHCPREQUEST it could be useful to extract the hostname portion from this and use it in combination with a "ddns-qualifying-suffix", if present, to change the FQDN u...ddns-override-domain-name:
When a client sends a FQDN ( option 81) in a DHCPREQUEST it could be useful to extract the hostname portion from this and use it in combination with a "ddns-qualifying-suffix", if present, to change the FQDN used in the dns update.
[RT 20029]( https://support.isc.org/Ticket/Display.html?id=20029)kea2.1.5Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3091Assertion failure in the "shutdown" system test (dns_resolver_attach() error)2023-06-19T10:33:40ZArаm SаrgsyаnAssertion failure in the "shutdown" system test (dns_resolver_attach() error)https://gitlab.isc.org/isc-projects/bind9/-/jobs/2221481
```c
10330 void
10331 dns_resolver_attach(dns_resolver_t *source, dns_resolver_t **targetp) {
10332 REQUIRE(VALID_RESOLVER(source));
10333 REQUIRE(targetp != NULL && *targetp ==...https://gitlab.isc.org/isc-projects/bind9/-/jobs/2221481
```c
10330 void
10331 dns_resolver_attach(dns_resolver_t *source, dns_resolver_t **targetp) {
10332 REQUIRE(VALID_RESOLVER(source));
10333 REQUIRE(targetp != NULL && *targetp == NULL);
10334
10335 RRTRACE(source, "attach");
10336
10337 >>>> REQUIRE(!atomic_load_acquire(&source->exiting));
10338 isc_refcount_increment(&source->references);
10339
10340 *targetp = source;
10341 }
```
<details><summary>Click to expand</summary>
<pre>
D:shutdown:tests-shutdown.py::test_named_shutdown FAILED [100%]
D:shutdown:
D:shutdown:=================================== FAILURES ===================================
D:shutdown:_____________________________ test_named_shutdown ______________________________
D:shutdown:
D:shutdown:named_port = 29944, control_port = 29956
D:shutdown:
D:shutdown:@pytest.mark.dnspython
D:shutdown:def test_named_shutdown(named_port, control_port):
D:shutdown:# pylint: disable-msg=too-many-locals
D:shutdown:cfg_dir = os.path.join(os.getcwd(), "resolver")
D:shutdown:assert os.path.isdir(cfg_dir)
D:shutdown:
D:shutdown:cfg_file = os.path.join(cfg_dir, "named.conf")
D:shutdown:assert os.path.isfile(cfg_file)
D:shutdown:
D:shutdown:named = os.getenv("NAMED")
D:shutdown:assert named is not None
D:shutdown:
D:shutdown:rndc = os.getenv("RNDC")
D:shutdown:assert rndc is not None
D:shutdown:
D:shutdown:# rndc configuration resides in ../common/rndc.conf
D:shutdown:rndc_cfg = os.path.join("..", "common", "rndc.conf")
D:shutdown:assert os.path.isfile(rndc_cfg)
D:shutdown:
D:shutdown:# rndc command with default arguments.
D:shutdown:rndc_cmd = [rndc, "-c", rndc_cfg, "-p", str(control_port),
D:shutdown:"-s", "10.53.0.3"]
D:shutdown:
D:shutdown:# We create a resolver instance that will be used to send queries.
D:shutdown:resolver = dns.resolver.Resolver()
D:shutdown:resolver.nameservers = ['10.53.0.3']
D:shutdown:resolver.port = named_port
D:shutdown:
D:shutdown:# We test named shutting down using two methods:
D:shutdown:# Method 1: using rndc ctop
D:shutdown:# Method 2: killing with SIGTERM
D:shutdown:# In both methods named should exit gracefully.
D:shutdown:for kill_method in ("rndc", "sigterm"):
D:shutdown:named_cmdline = [named, "-c", cfg_file, "-f"]
D:shutdown:with subprocess.Popen(named_cmdline, cwd=cfg_dir) as named_proc:
D:shutdown:# Ensure named is running
D:shutdown:assert named_proc.poll() is None
D:shutdown:# wait for named to finish loading
D:shutdown:for _ in range(10):
D:shutdown:try:
D:shutdown:resolver.query('version.bind', 'TXT', 'CH')
D:shutdown:break
D:shutdown:except (dns.resolver.NoNameservers, dns.exception.Timeout):
D:shutdown:time.sleep(1)
D:shutdown:
D:shutdown:do_work(named_proc, resolver, rndc_cmd,
D:shutdown:kill_method, n_workers=12, n_queries=16)
D:shutdown:
D:shutdown:# Wait named to exit for a maximum of MAX_TIMEOUT seconds.
D:shutdown:MAX_TIMEOUT = 10
D:shutdown:is_dead = False
D:shutdown:for _ in range(MAX_TIMEOUT):
D:shutdown:if named_proc.poll() is not None:
D:shutdown:is_dead = True
D:shutdown:break
D:shutdown:time.sleep(1)
D:shutdown:
D:shutdown:if not is_dead:
D:shutdown:named_proc.send_signal(signal.SIGABRT)
D:shutdown:for _ in range(MAX_TIMEOUT):
D:shutdown:if named_proc.poll() is not None:
D:shutdown:is_dead = True
D:shutdown:break
D:shutdown:time.sleep(1)
D:shutdown:if not is_dead:
D:shutdown:named_proc.kill()
D:shutdown:
D:shutdown:assert is_dead
D:shutdown:# Ensures that named exited gracefully.
D:shutdown:# If it crashed (abort()) exitcode will be non zero.
D:shutdown:> assert named_proc.returncode == 0
D:shutdown:E assert -6 == 0
D:shutdown:E + where -6 = <subprocess.Popen object at 0x7fd9a7bd2208>.returncode
D:shutdown:
D:shutdown:tests-shutdown.py:199: AssertionError
D:shutdown:----------------------------- Captured stderr call -----------------------------
D:shutdown:rndc: rndc: recv failed: connection resetrecv failed: connection reset
D:shutdown:
D:shutdown:rndc: connect failed: 10.53.0.3#29956: connection refused
D:shutdown:rndc: connect failed: 10.53.0.3#29956: connection refused
D:shutdown:rndc: connect failed: 10.53.0.3#29956: connection refused
D:shutdown:rndc: connect failed: 10.53.0.3#29956: connection refused
D:shutdown:rndc: connect failed: 10.53.0.3#29956: connection refused
D:shutdown:rndc: rndc: rndc: rndc: rndc: rndc: recv failed: connection resetrecv failed: connection resetrecv failed: connection resetrecv failed: connection resetrecv failed: connection resetrecv failed: connection reset
D:shutdown:
D:shutdown:
D:shutdown:
D:shutdown:
D:shutdown:
D:shutdown:rndc: connect failed: 10.53.0.3#29956: connection refused
D:shutdown:========================== 1 failed in 64.25 seconds ===========================
I:system:FAILED
I:shutdown:stopping servers
I:shutdown:Core dump(s) found: shutdown/resolver/core.30561
D:shutdown:backtrace from shutdown/resolver/core.30561:
D:shutdown:--------------------------------------------------------------------------------
D:shutdown:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -c /builds/isc-projects/bind9/'.
D:shutdown:Program terminated with signal SIGABRT, Aborted.
D:shutdown:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
D:shutdown:[Current thread is 1 (Thread 0x7f2077bff700 (LWP 30575))]
D:shutdown:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
D:shutdown:#1 0x00007f207cac9921 in __GI_abort () at abort.c:79
D:shutdown:#2 0x0000561eb31883a2 in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=0x7f207f028778 "!__extension__ ({ __auto_type __atomic_load_ptr = ((&source->exiting)); __typeof__ (*__atomic_load_ptr) __atomic_load_tmp; __atomic_load (__atomic_load_ptr, &__atomic_load_tmp, (memory_order_acquire))"...) at main.c:238
D:shutdown:#3 0x00007f207f29ed3a in isc_assertion_failed (file=file@entry=0x7f207f029159 "resolver.c", line=line@entry=10337, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7f207f028778 "!__extension__ ({ __auto_type __atomic_load_ptr = ((&source->exiting)); __typeof__ (*__atomic_load_ptr) __atomic_load_tmp; __atomic_load (__atomic_load_ptr, &__atomic_load_tmp, (memory_order_acquire))"...) at assertions.c:49
D:shutdown:#4 0x00007f207ef778eb in dns_resolver_attach (source=source@entry=0x7f206ecc7200, targetp=targetp@entry=0x7f206e7498d0) at resolver.c:10337
D:shutdown:#5 0x00007f207ef7d82d in dns_resolver_createfetch (res=0x7f206ecc7200, name=name@entry=0x7f206cc2f148, type=type@entry=28, domain=domain@entry=0x7f2077bf9020, nameservers=nameservers@entry=0x7f2077bf8fb0, forwarders=forwarders@entry=0x0, client=0x0, id=0, options=34, depth=2, qc=0x7f206d02a0d0, task=0x7f206e65dc80, action=0x7f207ee8cf30 <fetch_callback>, arg=0x7f206cc2f140, rdataset=0x7f2077ff82b0, sigrdataset=0x0, fetchp=0x7f2077ff82a8) at resolver.c:10610
D:shutdown:#6 0x00007f207ee8a4b1 in fetch_name (adbname=adbname@entry=0x7f206cc2f140, start_at_zone=start_at_zone@entry=true, depth=depth@entry=2, qc=qc@entry=0x7f206d02a0d0, type=type@entry=28) at adb.c:4041
D:shutdown:#7 0x00007f207ee96d71 in dns_adb_createfind (adb=0x7f206e61c980, task=0x7f206e65b700, action=action@entry=0x7f207ef840f0 <fctx_finddone>, arg=0x7f206cc5c000, name=name@entry=0x7f2077bf9d50, qname=0x7f206cc5c010, qtype=28, options=239, now=<optimized out>, target=0x0, port=29944, depth=2, qc=0x7f206d02a0d0, findp=0x7f2077bf9800) at adb.c:3123
D:shutdown:#8 0x00007f207ef7d159 in findname (fctx=<optimized out>, fctx@entry=0x7f206cc5c000, name=name@entry=0x7f2077bf9d50, port=port@entry=0, options=<optimized out>, options@entry=15, flags=flags@entry=0, now=1641906898, overquota=0x7f2077bf9cf8, need_alternate=0x7f2077bf9cd7, no_addresses=0x7f2077bf9cdc) at resolver.c:3308
D:shutdown:#9 0x00007f207ef813e9 in fctx_getaddresses (badcache=false, fctx=0x7f206cc5c000) at resolver.c:3643
D:shutdown:#10 fctx_try (fctx=fctx@entry=0x7f206cc5c000, retrying=<optimized out>, badcache=badcache@entry=false) at resolver.c:4033
D:shutdown:#11 0x00007f207ef85c37 in rctx_nextserver (rctx=rctx@entry=0x7f2077bfaa50, message=<optimized out>, addrinfo=addrinfo@entry=0x7f206ed3bb00, result=<optimized out>, result@entry=ISC_R_SUCCESS) at resolver.c:9528
D:shutdown:#12 0x00007f207ef86d63 in rctx_done (rctx=rctx@entry=0x7f2077bfaa50, result=result@entry=ISC_R_SUCCESS) at resolver.c:9670
D:shutdown:#13 0x00007f207ef879b7 in resquery_response (eresult=eresult@entry=ISC_R_SHUTTINGDOWN, region=region@entry=0x7f2077bfb730, arg=<optimized out>) at resolver.c:7644
D:shutdown:#14 0x00007f207eeacaf7 in udp_recv (handle=<optimized out>, eresult=<optimized out>, region=0x7f2077bfb730, arg=<optimized out>) at dispatch.c:593
D:shutdown:#15 0x00007f207f28d1ed in isc__nm_async_readcb (worker=worker@entry=0x7f2077c27000, ev0=ev0@entry=0x7f203fc10c00) at netmgr/netmgr.c:2809
D:shutdown:#16 0x00007f207f28d933 in process_netievent (worker=worker@entry=0x7f2077c27000, ievent=0x7f203fc10c00) at netmgr/netmgr.c:971
D:shutdown:#17 0x00007f207f28e095 in process_queue (worker=worker@entry=0x7f2077c27000, type=type@entry=NETIEVENT_NORMAL) at netmgr/netmgr.c:1010
D:shutdown:#18 0x00007f207f28e844 in process_all_queues (worker=0x7f2077c27000) at netmgr/netmgr.c:756
D:shutdown:#19 async_cb (handle=0x7f2077c27360) at netmgr/netmgr.c:785
D:shutdown:#20 0x00007f207dab23b4 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:shutdown:#21 0x00007f207dac2340 in uv.io_poll () from /usr/lib/x86_6
4-linux-gnu/libuv.so.1
nux-gnu/libuv.so.1
D:shutdown:#23 0x00007f207f28e12e in nm_thread (worker0=0x7f2077c27000) at netmgr/netmgr.c:691
D:shutdown:#24 0x00007f207f2ca166 in isc__trampoline_run (arg=0x561eb3f00710) at trampoline.c:187
D:shutdown:#25 0x00007f207ce816db in start_thread (arg=0x7f2077bff700) at pthread_create.c:463
D:shutdown:#26 0x00007f207cbaa71f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
D:shutdown:--------------------------------------------------------------------------------
D:shutdown:full backtrace from shutdown/resolver/core.30561 saved in shutdown/resolver/core.30561-backtrace.txt
D:shutdown:core dump shutdown/resolver/core.30561 archived as shutdown/resolver/core.30561.gz
R:shutdown:FAIL
E:shutdown:2022-01-11T13:15:31+0000
FAIL: shutdown
</pre>
</details>BIND 9.19.xhttps://gitlab.isc.org/isc-projects/kea/-/issues/2269Add support for hostnames in configuration files2022-01-27T15:03:34ZDamyan YordanovAdd support for hostnames in configuration filesCurrently, as stated in https://lists.isc.org/pipermail/kea-users/2021-December/003287.html, Kea does not support hostnames in configuration files. With kubernetes in mind, where IP addresses are highly short-lived, supporting hostnames ...Currently, as stated in https://lists.isc.org/pipermail/kea-users/2021-December/003287.html, Kea does not support hostnames in configuration files. With kubernetes in mind, where IP addresses are highly short-lived, supporting hostnames can be a major improvement.
Note that ISC DHCP server does support hostname in configs (https://kb.isc.org/v1/docs/isc-dhcp-44-manual-pages-dhcpdconf#configuring-failover), so some implementation concepts could be borrowed from there.https://gitlab.isc.org/isc-projects/bind9/-/issues/30909.14.12 will not compile on centos 5.112022-01-11T07:41:00Zchampiondot9.14.12 will not compile on centos 5.11
rwlock.c:51:24: error: immintrin.h: No such file or directory
rwlock.c: In function ‘isc__rwlock_lock’:
rwlock.c:310: warning: assignment makes integer from pointer without a cast
rwlock.c: In function ‘isc_rwlock_lock’:
rwlock.c:348: w...
rwlock.c:51:24: error: immintrin.h: No such file or directory
rwlock.c: In function ‘isc__rwlock_lock’:
rwlock.c:310: warning: assignment makes integer from pointer without a cast
rwlock.c: In function ‘isc_rwlock_lock’:
rwlock.c:348: warning: implicit declaration of function ‘_mm_pause’
rwlock.c:351: warning: value computed is not used
rwlock.c: In function ‘isc_rwlock_trylock’:
rwlock.c:400: warning: assignment makes integer from pointer without a cast``
rwlock.c:410: warning: value computed is not used
rwlock.c: In function ‘isc_rwlock_tryupgrade’:
rwlock.c:429: warning: assignment makes integer from pointer without a cast
rwlock.c:443: warning: value computed is not used
rwlock.c: In function ‘isc_rwlock_downgrade’:
rwlock.c:465: warning: value computed is not used
rwlock.c:466: warning: value computed is not used
rwlock.c: In function ‘isc_rwlock_unlock’:
rwlock.c:508: warning: value computed is not used
rwlock.c:509: warning: value computed is not used
make[2]: *** [rwlock.o] Error 1
make[2]: Leaving directory `/home/ops/bind-9.14.12/lib/isc'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/ops/bind-9.14.12/lib'
make: *** [subdirs] Error 1https://gitlab.isc.org/isc-projects/bind9/-/issues/3084Assertion failure on shutdown caused by refresh_callback()2022-01-13T16:58:45ZOndřej SurýAssertion failure on shutdown caused by refresh_callback()See https://gitlab.isc.org/isc-projects/bind9/-/jobs/2212377:
```
D:catz:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D catz-ns2 -X named.lock -m r'.
8477D:catz:Program terminated with signal SIGABRT, Aborted....See https://gitlab.isc.org/isc-projects/bind9/-/jobs/2212377:
```
D:catz:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D catz-ns2 -X named.lock -m r'.
8477D:catz:Program terminated with signal SIGABRT, Aborted.
8478D:catz:#0 0x00007f267f9a684c in __pthread_kill_implementation () from /lib64/libc.so.6
8479D:catz:[Current thread is 1 (Thread 0x7f2679c73640 (LWP 31354))]
8480D:catz:#0 0x00007f267f9a684c in __pthread_kill_implementation () from /lib64/libc.so.6
8481D:catz:#1 0x00007f267f9596a6 in raise () from /lib64/libc.so.6
8482D:catz:#2 0x00007f267f9437d3 in abort () from /lib64/libc.so.6
8483D:catz:#3 0x00007f2680ac2581 in abort () from /lib64/libtsan.so.0
8484D:catz:#4 0x000000000042269e in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at main.c:236
8485D:catz:#5 0x00007f26804edbf0 in isc_assertion_failed (file=file@entry=0x7f2680465225 "request.c", line=line@entry=1028, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7f26804654e0 "((request) != ((void *)0) && ((const isc__magic_t *)(request))->magic == ((('R') << 24 | ('q') << 16 | ('u') << 8 | ('!'))))") at assertions.c:47
8486D:catz:#6 0x00007f26803630ae in req_senddone (eresult=eresult@entry=ISC_R_CANCELED, region=region@entry=0x0, arg=0x7b440006a540) at request.c:1028
8487D:catz:#7 0x00007f2680244db9 in send_done (handle=0x7b4800038880, result=result@entry=ISC_R_CANCELED, cbarg=cbarg@entry=0x7b5000041600) at dispatch.c:1862
8488D:catz:#8 0x00007f26804d5df6 in isc__nm_async_sendcb (worker=worker@entry=0x7ba000009770, ev0=ev0@entry=0x7b480007da00) at netmgr/netmgr.c:2847
8489D:catz:#9 0x00007f26804d66e7 in process_netievent (worker=worker@entry=0x7ba000009770, ievent=ievent@entry=0x7b480007da00) at netmgr/netmgr.c:970
8490D:catz:#10 0x00007f26804d6abb in process_queue (worker=worker@entry=0x7ba000009770, type=type@entry=NETIEVENT_NORMAL) at netmgr/netmgr.c:1008
8491D:catz:#11 0x00007f26804d73e4 in process_all_queues (worker=0x7ba000009770) at netmgr/netmgr.c:754
8492D:catz:#12 async_cb (handle=0x7ba000009ad0) at netmgr/netmgr.c:783
8493D:catz:#13 0x00007f267fd12100 in uv__async_io (loop=0x7ba000009780, w=0x7ba000009948, events=1) at /usr/src/libuv-v1.42.0/src/unix/async.c:163
8494D:catz:#14 0x00007f267fd2e3d1 in uv__io_poll (loop=0x7ba000009780, timeout=0) at /usr/src/libuv-v1.42.0/src/unix/epoll.c:374
8495D:catz:#15 0x00007f267fd12b6c in uv_run (loop=0x7ba000009780, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.42.0/src/unix/core.c:389
8496D:catz:#16 0x00007f26804d6c07 in nm_thread (worker0=0x7ba000009770) at netmgr/netmgr.c:689
8497D:catz:#17 0x00007f2680529b8b in isc__trampoline_run (arg=0x7b0800019be0) at trampoline.c:185
8498D:catz:#18 0x00007f2680a92550 in __tsan_thread_start_func () from /lib64/libtsan.so.0
8499D:catz:#19 0x00007f267f9a4a87 in start_thread () from /lib64/libc.so.6
8500D:catz:#20 0x00007f267fa288d4 in clone () from /lib64/libc.so.6
```February 2022 (9.16.26, 9.16.26-S1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3078Release Checklist for BIND 9.16.25, 9.16.25-S1, 9.17.222022-01-20T12:24:02ZPetr Špačekpspacek@isc.orgRelease Checklist for BIND 9.16.25, 9.16.25-S1, 9.17.22## Release Schedule
**Preliminary!**
**Code Freeze:**
Friday, 07 January 2022
**Tagging Deadline:**
Monday, 10 January 2022
**Public Release:**
Wednesday, 19 January 2022
## Documentation Review Links
**Closed issues assigned to the...## Release Schedule
**Preliminary!**
**Code Freeze:**
Friday, 07 January 2022
**Tagging Deadline:**
Monday, 10 January 2022
**Public Release:**
Wednesday, 19 January 2022
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.17.22](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&state=closed&milestone_title=January+2022+%289.16.25%2C+9.16.25-S1%2C+9.17.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.17)
- [9.16.25-S1](https://gitlab.isc.org/isc-private/bind9/-/issues?scope=all&state=closed&milestone_title=January+2022+%289.16.25%2C+9.16.25-S1%2C+9.17.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16-S)
- [9.16.25](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&state=closed&milestone_title=January+2022+%289.16.25%2C+9.16.25-S1%2C+9.17.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16)
**Merge requests merged into the milestone without a release note:**
- [9.17.22](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=January+2022+%289.16.25%2C+9.16.25-S1%2C+9.17.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=main)
- [9.16.25-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&state=merged&milestone_title=January+2022+%289.16.25%2C+9.16.25-S1%2C+9.17.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=v9_16_sub)
- [9.16.25](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=January+2022+%289.16.25%2C+9.16.25-S1%2C+9.17.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=v9_16)
**Merge requests merged into the milestone without a CHANGES entry:**
- [9.17.22](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=January+2022+%289.16.25%2C+9.16.25-S1%2C+9.17.22%29&label_name%5B%5D=No+CHANGES&target_branch=main)
- [9.16.25-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&state=merged&milestone_title=January+2022+%289.16.25%2C+9.16.25-S1%2C+9.17.22%29&label_name%5B%5D=No+CHANGES&target_branch=v9_16_sub)
- [9.16.25](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=January+2022+%289.16.25%2C+9.16.25-S1%2C+9.17.22%29&label_name%5B%5D=No+CHANGES&target_branch=v9_16)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** [Inform](https://mattermost.isc.org/isc/pl/9kp8757b3ig6xexm1eg7sc6gzo) Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are [no permanent test failures](https://gitlab.isc.org/isc-projects/bind9/-/issues/3078#note_258248) on any platform.
- [x] ***(QA)*** [Check Perflab](https://gitlab.isc.org/isc-projects/bind9/-/issues/3078#note_258243) to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
- [x] ***(QA)*** Announce ([on Mattermost](https://mattermost.isc.org/isc/pl/gtmfaxb9ij8ijgzyar47mejkzr)) that the code freeze is in effect.
### Before the Tagging Deadline
- [x] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Update API files for libraries with new version information.
- [x] ***(QA)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(QA)*** Update `CHANGES`.
- [x] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update `README.md`.
- [x] ***(QA)*** Update `version`.
- [x] ***(QA)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is over.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription Edition (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public RPMs.
- [x] ***(SwEng) *** Build Debian/Ubuntu packages.
- [x] ***(SwEng) *** Update Docker images.
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Merge the automatically prepared `prep 9.x.y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_x`).
- [x] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Michał KępieńMichał Kępień2022-01-19https://gitlab.isc.org/isc-projects/bind9/-/issues/3077`check that SERVFAIL is returned for an empty question section via TCP` fails2022-03-01T12:31:38ZMark Andrews`check that SERVFAIL is returned for an empty question section via TCP` failsJob [#2208322](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2208322) failed for 96d63ac075a66d231784eb2933b393c23521f619:
I've seen this multiple times.
```
I:resolver:check that SERVFAIL is returned for an empty question section v...Job [#2208322](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2208322) failed for 96d63ac075a66d231784eb2933b393c23521f619:
I've seen this multiple times.
```
I:resolver:check that SERVFAIL is returned for an empty question section via TCP (70)
I:resolver:failed
I:resolver:checking SERVFAIL is returned when all authoritative servers return FORMERR (71)
```February 2022 (9.16.26, 9.16.26-S1)https://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/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/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/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/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/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 Boldariev