ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-09-22T17:23:20Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2085HTTP client request queue can grow unbounded in passive-backup mode2021-09-22T17:23:20ZThomas MarkwalderHTTP client request queue can grow unbounded in passive-backup modeIf the primary is able to process DHCP work faster than the passive-backup can respond to lease updates it is possible for them to accrue within the primary in the http::ConnectionPool::Destination::queue_. DHCP packet queue size and p...If the primary is able to process DHCP work faster than the passive-backup can respond to lease updates it is possible for them to accrue within the primary in the http::ConnectionPool::Destination::queue_. DHCP packet queue size and parking lot limits likely do not mitigate this for obvious reasons. It may be possible to mitigate it by reducing the number of DHCP threads versus the number of HA+MT threads but that's speculation on my part.
This can be readily demonstrated by running the passive-backup under valgrind, which slows the process down enough to make the accrual very predictable.
Tomek suggested possibly a warning log for now. We could monitor queue size and report periodically when it is growing. Note that when the traffic rate slows or stops, the backlog does get cleared and all updates are applied.kea2.0.0 (formerly 1.9.12)Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/205ipv6 dhcp replies do not arrive at dhclient2022-03-09T19:14:32Zudovdhipv6 dhcp replies do not arrive at dhclient**Describe the bug**
We run isc dhclient to do ipv6 prefix delegation:
`dhclient -P -6 ppp0 -d -v`
We see packets bing transmitted (in the cli and in tcpdump if we are monitoring).
We see replies arrive at the box but do NOT see these b...**Describe the bug**
We run isc dhclient to do ipv6 prefix delegation:
`dhclient -P -6 ppp0 -d -v`
We see packets bing transmitted (in the cli and in tcpdump if we are monitoring).
We see replies arrive at the box but do NOT see these being processed by dhclient.
These replies and up in the FORWARD iptables rule.
Issue also happens when NO firewall is active.
**To Reproduce**
Steps to reproduce the behavior:
1. see the description.
**Expected behavior**
I'd expect the packet to be recived, dhclient doing some processing and running scripts etc.
**Environment:**
dhcp-client-4.4.2-11.b1.fc34.x86_64
Fedora 34
kernel.org
```
# ip -6 a s dev ppp0
20: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc cbq state UNKNOWN group default qlen 3
inet6 fe80::c5d5:e942:39c7:7eb7 peer fe80::9ecc:83ff:fec6:e7e5/128 scope link
valid_lft forever preferred_lft forever
```
```
# lsof -p 4066992 -n
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
dhclient 4066992 root cwd DIR 254,0 4096 40961 /root
dhclient 4066992 root rtd DIR 254,0 4096 2 /
dhclient 4066992 root txt REG 254,2 2018144 141553 /usr/sbin/dhclient
dhclient 4066992 root mem REG 254,2 53728 22104 /usr/lib64/libnss_files-2.33.so
dhclient 4066992 root mem REG 254,2 1913544 21939 /usr/lib64/libc-2.33.so
dhclient 4066992 root mem REG 254,2 32696 30196 /usr/lib64/libcap-ng.so.0.0.0
dhclient 4066992 root mem REG 254,2 842360 30776 /usr/lib64/ld-2.33.so
dhclient 4066992 root 0u CHR 136,4 0t0 7 /dev/pts/4 (deleted)
dhclient 4066992 root 1u CHR 136,4 0t0 7 /dev/pts/4 (deleted)
dhclient 4066992 root 2u CHR 136,4 0t0 7 /dev/pts/4 (deleted)
dhclient 4066992 root 3u unix 0x000000001f2593f7 0t0 16525445 type=DGRAM (UNCONNECTED)
dhclient 4066992 root 4w REG 254,4 64 251 /var/lib/dhclient/dhclient6.leases
dhclient 4066992 root 5w FIFO 0,8 0t0 16525446 pipe
dhclient 4066992 root 6u IPv6 16524541 0t0 UDP [fe80::c5d5:e942:39c7:7eb7]:dhcpv6-client
```
```
# tcpdump -i ppp0 -vn port 546
dropped privs to tcpdump
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
06:53:09.236781 IP6 (flowlabel 0x7f0d8, hlim 1, next-header UDP (17) payload length: 60) fe80::c5d5:e942:39c7:7eb7.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=b68ba1 (client-ID hwaddr/time type 1 time 394565497 004063f60200) (option-request DNS-server DNS-search-list) (elapsed-time 65535) (IA_PD IAID:0 T1:3600 T2:5400))
06:53:09.469530 IP6 (class 0xc0, hlim 64, next-header UDP (17) payload length: 141) fe80::9ecc:83ff:fec6:e7e5.dhcpv6-server > fe80::c5d5:e942:39c7:7eb7.dhcpv6-client: [udp sum ok] dhcp6 advertise (xid=b68ba1 (client-ID hwaddr/time type 1 time 394565497 004063f60200) (server-ID vid 0000058339633a63) (IA_PD IAID:0 T1:3600 T2:5760 (IA_PD-prefix 2001:981:a812::/48 pltime:7200 vltime:7200)) (DNS-server 2001:888:0:6::66 2001:888:0:9::99))
06:53:09.469756 IP6 (class 0xc0, hlim 63, next-header UDP (17) payload length: 141) fe80::9ecc:83ff:fec6:e7e5.dhcpv6-server > fe80::c5d5:e942:39c7:7eb7.dhcpv6-client: [udp sum ok] dhcp6 advertise (xid=b68ba1 (client-ID hwaddr/time type 1 time 394565497 004063f60200) (server-ID vid 0000058339633a63) (IA_PD IAID:0 T1:3600 T2:5760 (IA_PD-prefix 2001:981:a812::/48 pltime:7200 vltime:7200)) (DNS-server 2001:888:0:6::66 2001:888:0:9::99))
^C
```
**Describe the solution you'd like**
It appears that the issue is local but what is prohibiting the replies being received?
**Describe alternatives you've considered**
We need ipv6 PD as it is the sole mechanism the ISP gives us ipv6.https://gitlab.isc.org/isc-projects/bind9/-/issues/2900listenlist_test, notify_test, and query_test failing.2021-10-05T06:47:26ZMark Andrewslistenlist_test, notify_test, and query_test failing.```
FAIL: listenlist_test
FAIL: notify_test
PASS: plugin_test
FAIL: query_test
============================================================================
Testsuite summary for BIND 9.17.17
==============================================...```
FAIL: listenlist_test
FAIL: notify_test
PASS: plugin_test
FAIL: query_test
============================================================================
Testsuite summary for BIND 9.17.17
============================================================================
# TOTAL: 4
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 3
# XPASS: 0
# ERROR: 0
============================================================================
See lib/ns/tests/test-suite.log
Please report to info@isc.org
============================================================================
make[5]: *** [test-suite.log] Error 1
make[4]: *** [check-TESTS] Error 2
make[3]: *** [check-am] Error 2
make[2]: *** [unit-recursive] Error 1
make[1]: *** [unit-recursive] Error 1
make: *** [unit-recursive] Error 1
[ant-1443:~/git/bind9] marka% cd bin/tests/system/
[ant-1443:bin/tests/system] marka% cd lib/d
lib/ not found
[ant-1443:bin/tests/system] marka% cd ../../..
[ant-1443:~/git/bind9] marka% cd lib/dns/tests/
[ant-1443:lib/dns/tests] marka% cd ../ns
../ns: No such file or directory.
[ant-1443:lib/dns/tests] marka% cd ../../ns/tests/
[ant-1443:lib/ns/tests] marka% ls
Makefile listenlist_test notify_test nstest.c plugin_test.c.dump query_test.c.dump
Makefile.am listenlist_test.c notify_test.c nstest.c.dump plugin_test.log query_test.log
Makefile.in listenlist_test.c.dump notify_test.c.dump nstest.h plugin_test.o query_test.o
kyua.log listenlist_test.log notify_test.log nstest.lo plugin_test.trs query_test.trs
libnstest.la listenlist_test.o notify_test.o plugin_test query_test test-suite.log
libwrap.so listenlist_test.trs notify_test.trs plugin_test.c query_test.c testdata
[ant-1443:lib/ns/tests] marka% ./listenlist_test
[==========] Running 1 test(s).
[ RUN ] ns_listenlist_default_test
netmgr/udp.c:104: REQUIRE(csock->fd >= 0) failed, back trace
0 libisc-9.17.17.dylib 0x00000001046fc838 default_callback + 72
1 libisc-9.17.17.dylib 0x00000001046fc7ac isc_assertion_failed + 56
2 libisc-9.17.17.dylib 0x00000001046f6c34 start_udp_child + 264
3 libisc-9.17.17.dylib 0x00000001046f681c isc_nm_listenudp + 540
4 libns-9.17.17.dylib 0x00000001047cb374 ns_interface_listenudp + 64
5 libns-9.17.17.dylib 0x00000001047ca4e8 ns_interface_setup + 436
6 libns-9.17.17.dylib 0x00000001047ca00c do_scan + 2444
7 libns-9.17.17.dylib 0x00000001047c8aa4 ns_interfacemgr_scan0 + 224
8 libns-9.17.17.dylib 0x00000001047c8998 ns_interfacemgr_scan + 88
9 listenlist_test 0x00000001046bb034 scan_interfaces + 52
10 libisc-9.17.17.dylib 0x000000010473f5e4 task_run + 884
11 libisc-9.17.17.dylib 0x000000010473f264 isc_task_run + 24
12 libisc-9.17.17.dylib 0x00000001046e5714 isc__nm_async_task + 40
13 libisc-9.17.17.dylib 0x00000001046dde8c process_netievent + 236
14 libisc-9.17.17.dylib 0x00000001046e563c process_queue + 192
15 libisc-9.17.17.dylib 0x00000001046e54dc process_all_queues + 56
16 libisc-9.17.17.dylib 0x00000001046d9ac8 async_cb + 40
17 libuv.1.dylib 0x000000010538a260 uv__async_io + 320
18 libuv.1.dylib 0x0000000105399ac4 uv__io_poll + 1592
19 libuv.1.dylib 0x000000010538a680 uv_run + 320
20 libisc-9.17.17.dylib 0x00000001046d9b44 nm_thread + 96
21 libisc-9.17.17.dylib 0x0000000104748aa0 isc__trampoline_run + 52
22 libsystem_pthread.dylib 0x000000018f02f878 _pthread_start + 320
23 libsystem_pthread.dylib 0x000000018f02a5e0 thread_start + 8
Abort
[ant-1443:lib/ns/tests] marka% ./notify_test
[==========] Running 1 test(s).
[ RUN ] notify_start
netmgr/udp.c:104: REQUIRE(csock->fd >= 0) failed, back trace
0 libisc-9.17.17.dylib 0x00000001009e8838 default_callback + 72
1 libisc-9.17.17.dylib 0x00000001009e87ac isc_assertion_failed + 56
2 libisc-9.17.17.dylib 0x00000001009e2c34 start_udp_child + 264
3 libisc-9.17.17.dylib 0x00000001009e281c isc_nm_listenudp + 540
4 libns-9.17.17.dylib 0x0000000100df3374 ns_interface_listenudp + 64
5 libns-9.17.17.dylib 0x0000000100df24e8 ns_interface_setup + 436
6 libns-9.17.17.dylib 0x0000000100df200c do_scan + 2444
7 libns-9.17.17.dylib 0x0000000100df0aa4 ns_interfacemgr_scan0 + 224
8 libns-9.17.17.dylib 0x0000000100df0998 ns_interfacemgr_scan + 88
9 notify_test 0x0000000100877140 scan_interfaces + 52
10 libisc-9.17.17.dylib 0x0000000100a2b5e4 task_run + 884
11 libisc-9.17.17.dylib 0x0000000100a2b264 isc_task_run + 24
12 libisc-9.17.17.dylib 0x00000001009d1714 isc__nm_async_task + 40
13 libisc-9.17.17.dylib 0x00000001009c9e8c process_netievent + 236
14 libisc-9.17.17.dylib 0x00000001009d163c process_queue + 192
15 libisc-9.17.17.dylib 0x00000001009d14dc process_all_queues + 56
16 libisc-9.17.17.dylib 0x00000001009c5ac8 async_cb + 40
17 libuv.1.dylib 0x0000000101542260 uv__async_io + 320
18 libuv.1.dylib 0x0000000101551ac4 uv__io_poll + 1592
19 libuv.1.dylib 0x0000000101542680 uv_run + 320
20 libisc-9.17.17.dylib 0x00000001009c5b44 nm_thread + 96
21 libisc-9.17.17.dylib 0x0000000100a34aa0 isc__trampoline_run + 52
22 libsystem_pthread.dylib 0x000000018f02f878 _pthread_start + 320
23 libsystem_pthread.dylib 0x000000018f02a5e0 thread_start + 8
Abort
[ant-1443:lib/ns/tests] marka% ./query_test
[==========] Running 4 test(s).
[ RUN ] ns__query_sfcache_test
netmgr/udp.c:104: REQUIRE(csock->fd >= 0) failed, back trace
0 libisc-9.17.17.dylib 0x00000001008b8838 default_callback + 72
1 libisc-9.17.17.dylib 0x00000001008b87ac isc_assertion_failed + 56
2 libisc-9.17.17.dylib 0x00000001008b2c34 start_udp_child + 264
3 libisc-9.17.17.dylib 0x00000001008b281c isc_nm_listenudp + 540
4 libns-9.17.17.dylib 0x0000000100de7374 ns_interface_listenudp + 64
5 libns-9.17.17.dylib 0x0000000100de64e8 ns_interface_setup + 436
6 libns-9.17.17.dylib 0x0000000100de600c do_scan + 2444
7 libns-9.17.17.dylib 0x0000000100de4aa4 ns_interfacemgr_scan0 + 224
8 libns-9.17.17.dylib 0x0000000100de4998 ns_interfacemgr_scan + 88
9 query_test 0x0000000100876394 scan_interfaces + 52
10 libisc-9.17.17.dylib 0x00000001008fb5e4 task_run + 884
11 libisc-9.17.17.dylib 0x00000001008fb264 isc_task_run + 24
12 libisc-9.17.17.dylib 0x00000001008a1714 isc__nm_async_task + 40
13 libisc-9.17.17.dylib 0x0000000100899e8c process_netievent + 236
14 libisc-9.17.17.dylib 0x00000001008a163c process_queue + 192
15 libisc-9.17.17.dylib 0x00000001008a14dc process_all_queues + 56
16 libisc-9.17.17.dylib 0x0000000100895ac8 async_cb + 40
17 libuv.1.dylib 0x0000000101546260 uv__async_io + 320
18 libuv.1.dylib 0x0000000101555ac4 uv__io_poll + 1592
19 libuv.1.dylib 0x0000000101546680 uv_run + 320
20 libisc-9.17.17.dylib 0x0000000100895b44 nm_thread + 96
21 libisc-9.17.17.dylib 0x0000000100904aa0 isc__trampoline_run + 52
22 libsystem_pthread.dylib 0x000000018f02f878 _pthread_start + 320
23 libsystem_pthread.dylib 0x000000018f02a5e0 thread_start + 8
Abort
[ant-1443:lib/ns/tests] marka%
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/2899[CVE-2021-25219] Lame cache can be abused to severely degrade resolver perfor...2021-12-01T20:46:29ZMark Andrews[CVE-2021-25219] Lame cache can be abused to severely degrade resolver performance### CVE-specific actions
- [x] [Assign a CVE identifier](#note_237851)
- [x] [Determine CVSS score](#note_237854)
- [x] [Determine the range of BIND versions affected (including the Subscription Edition)](#note_237917)
- [x] [De...### CVE-specific actions
- [x] [Assign a CVE identifier](#note_237851)
- [x] [Determine CVSS score](#note_237854)
- [x] [Determine the range of BIND versions affected (including the Subscription Edition)](#note_237917)
- [x] [Determine whether workarounds for the problem exists](#note_238377)
- [x] [Create a draft of the security advisory and put the information above in there](#note_238387)
- [x] Prepare a detailed description of the problem which should include the following by default:
- [instructions for reproducing the problem (a system test is good enough)](#note_238412)
- [explanation of code flow which triggers the problem (a system test is *not* good enough)](#note_238416)
- [x] [Prepare a private merge request containing the following items in separate commits:](isc-private/bind9!322)
- a test for the issue (may be moved to a separate merge request for deferred merging)
- a fix for the issue
- documentation updates (`CHANGES`, release notes, anything else applicable)
- [x] Ensure the merge request from the previous step is reviewed by SWENG staff and has no outstanding discussions
- [x] Ensure the documentation changes introduced by the merge request addressing the problem are reviewed by Support and Marketing staff
- [x] Prepare backports of the merge request addressing the problem for all affected (and still maintained) BIND branches (backporting might affect the issue's scope and/or description)
- [x] Prepare a standalone patch for the last stable release of each affected (and still maintained) BIND branch
### Release-specific actions
- [x] [Create/update the private issue containing links to fixes & reproducers for all CVEs fixed in a given release cycle](isc-private/bind9#48)
- [x] [Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined](!5479)
- [x] Ensure the merge requests containing CVE fixes are merged into `security-*` branches in CVE identifier order
### Post-disclosure actions
- [x] ~~[Merge a regression test reproducing the bug into all affected (and still maintained) BIND branches](#note_238412)~~
---
The ADB lame cache lists can grow long under a random subdomain attack involving a lame server resulting in degraded server performance.
https://support.isc.org/Ticket/Display.html?id=19171
We received a customer support issue where attacker is exploiting handling of lame responses in BIND's resolver to degrade its performance. This is done by performing a Random Subdomain Attack on a domain for which the supposed to-be authoritative name-server sends a lame response.
Attack Pattern:
In an ideal case, if an upstream authoritative name server sends a lame response for a (qname, qtype) then the DNS resolver marks the upstream server as lame for the (qname, qtype) by adding an entry to dns_adblameinfo_t list (which is a linked list and safe-guarded with a mutex lock) under that server in the address database. This entry will be maintained in the address database until lame_ttl expiry (default = 600s). This is done to ensure that if any other client sends a query with the same (qname, qtype), then a SERVFAIL is sent to that client without sending any queries to the upstream name server.
Suppose an attacker identifies a domain (say example.com) for which the upstream name server is sending lame responses, then the attacker can send more and more queries to the DNS resolver with random & unique subdomains. Since all the upstream responses will be lame, the dns_adblameinfo_t list can grow very long for the server over time. If example.com is hosted on multiple nameservers and all respond with lame answers for subdomains of example.com then a similar list is maintained for each server.
In this case, any queries to more random subdomains in this domain (example.com), can severely impact address lookup in ADB database as the resolver has to walkthrough the dns_adblameinfo_t list to see if the incoming (qname, qtype) matches any entry in the list. Also, when processing lame responses from an upstream nameserver, the dns_adblameinfo_t list is traversed completely once again to ensure there is no entry with the same (qname, qtype) before adding a new entry to the list.
Because of the long length of the dns_adblameinfo_t linked list and list being safeguarded with mutex locks, we see a huge performance impact on the DNS resolver. Some threads are busy traversing the list when an incoming query is received, some threads are busy marking a server as lame for (qname, qtype) and some threads are busy waiting on the mutex lock. We have observed that UDP socket buffers are filled and incoming query requests are dropped. This behavior is impacting query responses.
<details>
<summary>Click here to expand/collapse further details</summary>
Lab reproduction steps follow. If you are unable to reproduce this and absolutely need a system test, please ask us.
- Create 4 upstream name servers to give lame responses to all the subdomains of example.com and valid responses to any other domains.
- Create a fake root name server which will give aforementioned name servers as delegations for any domain
- Set up a DNS resolver with recursion enabled and lame_ttl set to 600s
- Set up a client to send a "good" load of 10K QPS
- Set up another client to send 0.5K qps "bad" load which contains random & unique subdomains of example.com which results in lame responses from upstream servers
- Once the dns_adblameinfo_t list grows huge, we will see both good and bad queries getting dropped as socket buffers gets filled up.
Sample ADB dump snippet below:
```
; ns0.lamezone.com [v4 TTL 9] [v4 success] [v6 unexpected]
; x.x.x.x [srtt 14886] [flags 00000008] [edns 0/0/0/0/0] [plain 243/0] [udpsize 512] [ttl 1381]
; lame7b666f80772a3ca0.lamezone.com A [lame TTL 600]
; lame2a66477284602834.lamezone.com A [lame TTL 600]
; lame13d22bfabedd01ec.lamezone.com A [lame TTL 600]
; lameb80ed1378a08573c.lamezone.com A [lame TTL 600]
; lame00e62ac39a71892d.lamezone.com A [lame TTL 600]
; lame89b523316ebed0c5.lamezone.com A [lame TTL 600]
; lame8cd0d0dbef312217.lamezone.com A [lame TTL 600]
; lame9706e9b7d1efbc99.lamezone.com A [lame TTL 600]
; lame9032e2c6e17d6641.lamezone.com A [lame TTL 599]
; lame7ad64e7c0ab85626.lamezone.com A [lame TTL 599]
; lamed06b237517ce8645.lamezone.com A [lame TTL 599]
; lamee2060685a923fda7.lamezone.com A [lame TTL 599]
; lame343ee8665dcea995.lamezone.com A [lame TTL 599]
; lameb977875001a8b8fb.lamezone.com A [lame TTL 599]
; lame2310dcd40d94a0f2.lamezone.com A [lame TTL 599]
; lame483fe23ba5a988cb.lamezone.com A [lame TTL 599]
; lameda3f75bdb0c831ed.lamezone.com A [lame TTL 599]
; lameced50ee825424244.lamezone.com A [lame TTL 599]
; lame3bb661710d73d83b.lamezone.com A [lame TTL 599]
; lame6c55f727a1a6ddeb.lamezone.com A [lame TTL 599]
; lame0caa15b502515d55.lamezone.com A [lame TTL 599]
; lame5fc20a3d0a323793.lamezone.com A [lame TTL 599]
; lame5fa76a80eb12d174.lamezone.com A [lame TTL 599]
; lame54056775b52b26c6.lamezone.com A [lame TTL 599]
; lamea44305ab4775bc9d.lamezone.com A [lame TTL 599]
; lame5378076402e48972.lamezone.com A [lame TTL 599]
; lamedcee9bf7bc559c51.lamezone.com A [lame TTL 599]
; lame393f530f9243b217.lamezone.com A [lame TTL 599]
; lamea6eed84f4c259e21.lamezone.com A [lame TTL 599]
; lamea60557f44db138dc.lamezone.com A [lame TTL 599]
; lame021df6990bfc90b5.lamezone.com A [lame TTL 599]
; lame7bc389882ce41950.lamezone.com A [lame TTL 599]
; lame3648acfec5264795.lamezone.com A [lame TTL 599]
; lamee2874e4794550f45.lamezone.com A [lame TTL 599]
; lame57c91be78ddec9e8.lamezone.com A [lame TTL 599]
; lame9abfe14a3d21195d.lamezone.com A [lame TTL 599]
; lame5cc66b7c9fc9a50b.lamezone.com A [lame TTL 599]
```
Sample lame response: AA bit is unset, NO ERROR, NO DATA, AUTHORITY RRS > 0
```
Domain Name System (response)
Transaction ID: 0x9754
Flags: 0x8000 Standard query response, No error
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... 0... .... = Recursion available: Server can't do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... ...0 .... = Non-authenticated data: Unacceptable
.... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 0
Authority RRs: 4
Additional RRs: 4
Queries
Authoritative nameservers
lamezone.com: type NS, class IN, ns ns0.lamezone.com
lamezone.com: type NS, class IN, ns ns1.lamezone.com
lamezone.com: type NS, class IN, ns ns2.lamezone.com
lamezone.com: type NS, class IN, ns ns3.lamezone.com
Additional records
ns0.lamezone.com: type A, class IN, addr 1.0.70.93
ns1.lamezone.com: type A, class IN, addr 1.0.157.163
ns2.lamezone.com: type A, class IN, addr 1.0.184.154
ns3.lamezone.com: type A, class IN, addr 1.0.66.115
[Request In: 23]
[Time: 0.000326587 seconds]
```
Below are couple of major functions which traverses the entire dns_adblameinfo_t list:
- entry_is_lame() method which is invoked when an incoming query is received and recursion is to be performed. In this function, complete list is traversed to check if lame_ttl is expired for any (qname, qtype) entry and also checks for incoming (qname, qtype) matches with any entry in the list.
```
/*
* Entry bucket MUST be locked!
*/
static isc_boolean_t
entry_is_lame(dns_adb_t *adb, dns_adbentry_t *entry, dns_name_t *qname,
dns_rdatatype_t qtype, isc_stdtime_t now)
{
dns_adblameinfo_t *li, *next_li;
isc_boolean_t is_bad;
is_bad = ISC_FALSE;
li = ISC_LIST_HEAD(entry->lameinfo);
if (li == NULL)
return (ISC_FALSE);
while (li != NULL) {
next_li = ISC_LIST_NEXT(li, plink);
/*
* Has the entry expired?
*/
if (li->lame_timer < now) {
ISC_LIST_UNLINK(entry->lameinfo, li, plink);
free_adblameinfo(adb, &li);
}
/*
* Order tests from least to most expensive.
*
* We do not break out of the main loop here as
* we use the loop for house keeping.
*/
if (li != NULL && !is_bad && li->qtype == qtype &&
dns_name_equal(qname, &li->qname))
is_bad = ISC_TRUE;
li = next_li;
}
return (is_bad);
}
```
- dns_adb_marklame() method is invoked when a upstream response is found lame and (qname, qtype) entry added for the server. Before adding an entry entire list is traversed.
```
isc_result_t
dns_adb_marklame(dns_adb_t *adb, dns_adbaddrinfo_t *addr, dns_name_t *qname,
dns_rdatatype_t qtype, isc_stdtime_t expire_time)
{
dns_adblameinfo_t *li;
int bucket;
isc_result_t result = ISC_R_SUCCESS;
REQUIRE(DNS_ADB_VALID(adb));
REQUIRE(DNS_ADBADDRINFO_VALID(addr));
REQUIRE(qname != NULL);
bucket = addr->entry->lock_bucket;
LOCK(&adb->entrylocks[bucket]);
li = ISC_LIST_HEAD(addr->entry->lameinfo);
while (li != NULL &&
(li->qtype != qtype || !dns_name_equal(qname, &li->qname)))
li = ISC_LIST_NEXT(li, plink);
if (li != NULL) {
if (expire_time > li->lame_timer)
li->lame_timer = expire_time;
goto unlock;
}
li = new_adblameinfo(adb, qname, qtype);
if (li == NULL) {
result = ISC_R_NOMEMORY;
goto unlock;
}
li->lame_timer = expire_time;
ISC_LIST_PREPEND(addr->entry->lameinfo, li, plink);
unlock:
UNLOCK(&adb->entrylocks[bucket]);
return (result);
}
```
Pstack traces:
```
Thread 15 (Thread 0x7fccbbbc3710 (LWP 30236)):
#0 entry_is_lame (adb=0x7fccaf4d4010, entry=0x0, qname=0x7fc911524052, qtype=23682, now=1623806085) at adb.c:2183
#1 0x00000000004b7c90 in copy_namehook_lists (adb=0x7fccaf4d4010, find=0x7fccb2226a40, qname=<optimized out>, qtype=<optimized out>, name=<optimized out>, now=<optimized out>) at adb.c:2264
#2 0x00000000004c150a in dns_adb_createfind2 (adb=0x7fccaf4d4010, task=<optimized out>, action=<optimized out>, arg=<optimized out>, name=<optimized out>, qname=<optimized out>, qtype=23682, options=207, now=1623806085, target=0x0, port=53, depth=1, qc=0x7fcc80612050, findp=0x7fccbbbc1998) at adb.c:3291
#3 0x00000000005b05b7 in findname (fctx=0x7fcc09264280, name=0x7fccbbbc1cc0, port=<optimized out>, options=<optimized out>, flags=0, now=<optimized out>, overquota=0x7fccbbbc1c90, need_alternate=0x7fccbbbc1c9c, no_addresses=0x7fccbbbc1c98) at resolver.c:3703
#4 0x00000000005b8826 in fctx_getaddresses (fctx=0x7fcc09264280, badcache=<optimized out>) at resolver.c:4017
#5 0x00000000005bb4bc in fctx_try (fctx=0x7fcc09264280, retrying=<optimized out>, badcache=isc_boolean_false) at resolver.c:4401
#6 0x00000000005c27e8 in resquery_response (task=<optimized out>, event=<optimized out>) at resolver.c:10182
#7 0x0000000000750133 in dispatch (manager=<optimized out>) at task.c:1180
#8 run (uap=<optimized out>) at task.c:1352
#9 0x00007fcf28758fc9 in start_thread (arg=<optimized out>) at pthread_create.c:297
#10 0x00007fcf216c855d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#11 0x0000000000000000 in ?? ()
Thread 14 (Thread 0x7fccbb3c2710 (LWP 30237)):
#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
#1 0x00007fcf2875a93e in _L_lock_949 () from /lib64/libpthread.so.0
#2 0x00007fcf2875a877 in __pthread_mutex_lock (mutex=0x7fc931917ff8) at pthread_mutex_lock.c:101
#3 0x00000000004b28e0 in dns_adb_beginudpfetch (adb=0x7fccaf4d4010, addr=0x80) at adb.c:5000
#4 0x00000000005b950d in fctx_query (fctx=0x7fcc48213d60, addrinfo=0x7fcc8a02f3f8, options=<optimized out>) at resolver.c:2160
#5 0x00000000005bba5f in fctx_try (fctx=0x7fcc48213d60, retrying=<optimized out>, badcache=isc_boolean_false) at resolver.c:4470
#6 0x00000000005c27e8 in resquery_response (task=<optimized out>, event=<optimized out>) at resolver.c:10182
#7 0x0000000000750133 in dispatch (manager=<optimized out>) at task.c:1180
#8 run (uap=<optimized out>) at task.c:1352
#9 0x00007fcf28758fc9 in start_thread (arg=<optimized out>) at pthread_create.c:297
#10 0x00007fcf216c855d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#11 0x0000000000000000 in ?? ()
Thread 13 (Thread 0x7fccbabc1710 (LWP 30238)):
#0 entry_is_lame (adb=0x7fccaf4d4010, entry=0x0, qname=0x7fc91152bd50, qtype=28336, now=1623806085) at adb.c:2183
#1 0x00000000004b7c90 in copy_namehook_lists (adb=0x7fccaf4d4010, find=0x7fcc8c69ee70, qname=<optimized out>, qtype=<optimized out>, name=<optimized out>, now=<optimized out>) at adb.c:2264
#2 0x00000000004c150a in dns_adb_createfind2 (adb=0x7fccaf4d4010, task=<optimized out>, action=<optimized out>, arg=<optimized out>, name=<optimized out>, qname=<optimized out>, qtype=28336, options=207, now=1623806085, target=0x0, port=53, depth=1, qc=0x7fcc8c756fc0, findp=0x7fccbabbf998) at adb.c:3291
#3 0x00000000005b05b7 in findname (fctx=0x7fcc33205be0, name=0x7fccbabbfcc0, port=<optimized out>, options=<optimized out>, flags=0, now=<optimized out>, overquota=0x7fccbabbfc90, need_alternate=0x7fccbabbfc9c, no_addresses=0x7fccbabbfc98) at resolver.c:3703
#4 0x00000000005b8826 in fctx_getaddresses (fctx=0x7fcc33205be0, badcache=<optimized out>) at resolver.c:4017
#5 0x00000000005bb4bc in fctx_try (fctx=0x7fcc33205be0, retrying=<optimized out>, badcache=isc_boolean_false) at resolver.c:4401
#6 0x00000000005c27e8 in resquery_response (task=<optimized out>, event=<optimized out>) at resolver.c:10182
#7 0x0000000000750133 in dispatch (manager=<optimized out>) at task.c:1180
#8 run (uap=<optimized out>) at task.c:1352
#9 0x00007fcf28758fc9 in start_thread (arg=<optimized out>) at pthread_create.c:297
#10 0x00007fcf216c855d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#11 0x0000000000000000 in ?? ()
Thread 12 (Thread 0x7fccba3c0710 (LWP 30239)):
#0 0x00000000004b542b in dns_adb_marklame (adb=0x7fccaf4d4010, addr=0x7fcc94d62030, qname=0x7fcc4cab6f50, qtype=1, expire_time=<optimized out>) at adb.c:4182
#1 0x00000000005c2d6c in resquery_response (task=<optimized out>, event=<optimized out>) at resolver.c:9768
#2 0x0000000000750133 in dispatch (manager=<optimized out>) at task.c:1180
#3 run (uap=<optimized out>) at task.c:1352
#4 0x00007fcf28758fc9 in start_thread (arg=<optimized out>) at pthread_create.c:297
#5 0x00007fcf216c855d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#6 0x0000000000000000 in ?? ()
Thread 11 (Thread 0x7fccb9bbf710 (LWP 30240)):
#0 strchrnul () at ../sysdeps/x86_64/strchrnul.S:49
#1 0x00007fcf216477cc in __find_specmb (format=<optimized out>) at printf-parse.h:99
#2 _IO_vfprintf_internal (s=0x7fccb9bbca10, format=<optimized out>, ap=0x7fccb9bbcb90) at vfprintf.c:1619
#3 0x00007fcf2166c041 in _IO_vsnprintf (string=0x7fccb9bbcbb0 "Name voovlive.com (SOA", maxlen=2048, format=0x7ab020 "Name %s (%s) not subdomain of zone %s -- invalid response", args=0x7fccb9bbcb90) at vsnprintf.c:120
#4 0x00000000005b2583 in log_formerr (fctx=0x7fcca5501a70, format=0x220 <error: Cannot access memory at address 0x220>) at resolver.c:5483
#5 0x00000000005ba024 in noanswer_response (fctx=0x7fcca5501a70, oqname=<optimized out>, look_in_options=<optimized out>) at resolver.c:8051
#6 0x00000000005c083e in resquery_response (task=<optimized out>, event=<optimized out>) at resolver.c:9915
#7 0x0000000000750133 in dispatch (manager=<optimized out>) at task.c:1180
#8 run (uap=<optimized out>) at task.c:1352
#9 0x00007fcf28758fc9 in start_thread (arg=<optimized out>) at pthread_create.c:297
#10 0x00007fcf216c855d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#11 0x0000000000000000 in ?? ()
Thread 10 (Thread 0x7fccb93be710 (LWP 30241)):
#0 0x00000000004b542b in dns_adb_marklame (adb=0x7fccaf4d4010, addr=0x7fcc95313ac0, qname=0x7fcbeb7203f0, qtype=1, expire_time=<optimized out>) at adb.c:4182
#1 0x00000000005c2d6c in resquery_response (task=<optimized out>, event=<optimized out>) at resolver.c:9768
#2 0x0000000000750133 in dispatch (manager=<optimized out>) at task.c:1180
#3 run (uap=<optimized out>) at task.c:1352
#4 0x00007fcf28758fc9 in start_thread (arg=<optimized out>) at pthread_create.c:297
#5 0x00007fcf216c855d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#6 0x0000000000000000 in ?? ()
Thread 9 (Thread 0x7fccb8bbd710 (LWP 30242)):
#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
#1 0x00007fcf2875a93e in _L_lock_949 () from /lib64/libpthread.so.0
#2 0x00007fcf2875a877 in __pthread_mutex_lock (mutex=0x7fc931917ff8) at pthread_mutex_lock.c:101
#3 0x00000000004b28e0 in dns_adb_beginudpfetch (adb=0x7fccaf4d4010, addr=0x80) at adb.c:5000
#4 0x00000000005b950d in fctx_query (fctx=0x7fcaecad1470, addrinfo=0x7fccb22152a0, options=<optimized out>) at resolver.c:2160
#5 0x00000000005bba5f in fctx_try (fctx=0x7fcaecad1470, retrying=<optimized out>, badcache=isc_boolean_false) at resolver.c:4470
#6 0x00000000005c27e8 in resquery_response (task=<optimized out>, event=<optimized out>) at resolver.c:10182
#7 0x0000000000750133 in dispatch (manager=<optimized out>) at task.c:1180
#8 run (uap=<optimized out>) at task.c:1352
#9 0x00007fcf28758fc9 in start_thread (arg=<optimized out>) at pthread_create.c:297
#10 0x00007fcf216c855d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#11 0x0000000000000000 in ?? ()
Thread 8 (Thread 0x7fccb83bc710 (LWP 30243)):
#0 entry_is_lame (adb=0x7fccaf4d4010, entry=0x0, qname=0x7fc91152680d, qtype=16189, now=1623806085) at adb.c:2183
#1 0x00000000004b7c90 in copy_namehook_lists (adb=0x7fccaf4d4010, find=0x7fccb221d640, qname=<optimized out>, qtype=<optimized out>, name=<optimized out>, now=<optimized out>) at adb.c:2264
#2 0x00000000004c150a in dns_adb_createfind2 (adb=0x7fccaf4d4010, task=<optimized out>, action=<optimized out>, arg=<optimized out>, name=<optimized out>, qname=<optimized out>, qtype=16189, options=223, now=1623806085, target=0x0, port=53, depth=1, qc=0x7fcc9a960910, findp=0x7fccb83bb738) at adb.c:3291
#3 0x00000000005b05b7 in findname (fctx=0x7fcc41fa4010, name=0x7fccb83bba60, port=<optimized out>, options=<optimized out>, flags=0, now=<optimized out>, overquota=0x7fccb83bba30, need_alternate=0x7fccb83bba3c, no_addresses=0x7fccb83bba38) at resolver.c:3703
#4 0x00000000005b8826 in fctx_getaddresses (fctx=0x7fcc41fa4010, badcache=<optimized out>) at resolver.c:4017
#5 0x00000000005bb4bc in fctx_try (fctx=0x7fcc41fa4010, retrying=<optimized out>, badcache=isc_boolean_false) at resolver.c:4401
#6 0x00000000005bc0f0 in fctx_start (task=<optimized out>, event=<optimized out>) at resolver.c:4981
#7 0x0000000000750133 in dispatch (manager=<optimized out>) at task.c:1180
#8 run (uap=<optimized out>) at task.c:1352
#9 0x00007fcf28758fc9 in start_thread (arg=<optimized out>) at pthread_create.c:297
#10 0x00007fcf216c855d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#11 0x0000000000000000 in ?? ()
</details>
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Petr Špačekpspacek@isc.orgPetr Špačekpspacek@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2898Improve functions parameter validation in lib/dns/message.c to prevent access...2022-04-26T11:03:18ZArаm SаrgsyаnImprove functions parameter validation in lib/dns/message.c to prevent accessing the -1 index of an arrayThe `REQUIRE(VALID_SECTION(section))` checks in the `dns_message_findname()` and `dns_message_sectiontotext()` functions allow the section variable to be -1, which is not a valid array index.
The checks should be replaced by `REQUIRE(VA...The `REQUIRE(VALID_SECTION(section))` checks in the `dns_message_findname()` and `dns_message_sectiontotext()` functions allow the section variable to be -1, which is not a valid array index.
The checks should be replaced by `REQUIRE(VALID_NAMED_SECTION(section))`.May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)https://gitlab.isc.org/isc-projects/kea/-/issues/2084Make Parser slightly more noob-friendly2021-12-17T15:35:26ZVicky Riskvicky@isc.orgMake Parser slightly more noob-friendlyA comment Carsten made in the Kea training class, is that when people cut and paste config snippets, they frequently forget that the last item in a list of options cannot be followed with a comma. This results in a hard failure by the pa...A comment Carsten made in the Kea training class, is that when people cut and paste config snippets, they frequently forget that the last item in a list of options cannot be followed with a comma. This results in a hard failure by the parser.
The suggestion is, could the parser instead emit a warning along the lines of "we see you have a trailing comma <here>. Did you forget something?" and basically ignore that last comma.kea2.1.2Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2083max-response-delay in ARM examples is often equal to heartbeat-delay which w...2022-07-11T16:14:10ZThomas Markwaldermax-response-delay in ARM examples is often equal to heartbeat-delay which we consider as wrongWe recommend the max-response-delay be a multiple of heartbeat-delay, yet in our HA example config snippets in the ARM they are frequently the same, customers are following the examples not the text.
```
max-response-delay - specifies a...We recommend the max-response-delay be a multiple of heartbeat-delay, yet in our HA example config snippets in the ARM they are frequently the same, customers are following the examples not the text.
```
max-response-delay - specifies a duration in milliseconds since the last successful communication with the partner, after which the server assumes that communication with the partner is interrupted. This duration should be greater than the heartbeat-delay. Usually it is greater than the duration of multiple heartbeat-delay values. When the server detects that communication is interrupted, it may transition to the partner-down state (when max-unacked-clients is 0) or trigger the failure-detection procedure using the values of the two parameters below. The default value of this parameter is 60000 ms.
```kea2.2.0 - a new stable branchRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2897rndc thaw does not process manually made changes to a dynamic zone2021-09-09T19:36:12ZJakob Dhondtrndc thaw does not process manually made changes to a dynamic zone### Summary
When freezing a dynamic zone with `rndc freeze <zone>`, manually editing the zone file and then unfreezing the zone with `rndc thaw <zone>` the manual changes do not seem to be processed. E.g. when manually adding an entry i...### Summary
When freezing a dynamic zone with `rndc freeze <zone>`, manually editing the zone file and then unfreezing the zone with `rndc thaw <zone>` the manual changes do not seem to be processed. E.g. when manually adding an entry it won't be returned after unfreezing the zone, when querying it with dig. If I am not misunderstanding the [documentation](https://bind9.readthedocs.io/en/latest/advanced.html#the-journal-file) the following paragraph seems to suggest that manual changes to a dynamic zone should be immediately processed as described.
> To make changes to a dynamic zone manually, follow these steps: first, disable dynamic updates to the zone using rndc freeze zone. This updates the zone file with the changes stored in its .jnl file. Then, edit the zone file. Finally, run rndc thaw zone to reload the changed zone and re-enable dynamic updates.
This seems to be related to issue #2186.
### BIND version used
```
BIND 9.16.20 (Extended Support Version) <id:26db37f>
running on Linux x86_64 3.10.0-1160.25.1.el7.x86_64 #1 SMP Tue Apr 13 18:55:45 EDT 2021
built by make with '--build=x86_64-koji-linux-gnu' '--host=x86_64-koji-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/named' '--bindir=/opt/named/bin' '--sbindir=/opt/named/sbin' '--sysconfdir=/etc' '--datadir=/opt/named/share' '--includedir=/opt/named/include' '--libdir=/opt/named/lib64' '--libexecdir=/opt/named/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/opt/named/share/man' '--infodir=/opt/named/share/info' '--exec-prefix=/opt/named' '--disable-static' '--enable-dnstap' '--disable-openssl-version-check' '--with-randomdev=/dev/urandom' '--with-pic' '--with-json-c' '--with-libtool' '--with-libxml2' '--without-lmdb' '--with-tuning=large' '--with-python' '--with-python-install-dir=/opt/named/usr/lib/python2.7/site-packages' '--with-docbook-xsl=/opt/named/share/sgml/docbook/xsl-stylesheets' '--includedir=/opt/named/include/bind9' 'build_alias=x86_64-koji-linux-gnu' 'host_alias=x86_64-koji-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'PKG_CONFIG_PATH=:/opt/named/lib64/pkgconfig:/opt/named/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
compiled with protobuf-c version: 1.0.2
linked to protobuf-c version: 1.0.2
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
1. Have a dynamic zone with the following config and content.
```
zone "zone.dyn-test.rpz.switch.ch" {
type master;
file "dynamic/zone.dyn-test.rpz.switch.ch";
update-policy {
grant "zone.dyn-test.rpz.switch.ch.tsig" subdomain "zone.dyn-test.rpz.switch.ch" "ANY";
};
dnssec-policy "none";
};
```
```
$ORIGIN .
$TTL 300 ; 5 minutes
zone.dyn-test.rpz.switch.ch IN SOA bona.switch.ch. dns-operation.switch.ch. (
2021073347 ; serial
600 ; refresh (10 minutes)
300 ; retry (5 minutes)
604800 ; expire (1 week)
300 ; minimum (5 minutes)
)
NS bona.switch.ch.
```
2. Check that dynamic updates work
* on a different machine that is allowed to do dynamic updates:
```
nsupdate -k <tsig-key>
> server pepsi.switch.ch
> zone zone.dyn-test.rpz.switch.ch
> update add test.zone.dyn-test.rpz.switch.ch 300 a 127.0.0.1
> send
```
* check for the record on the nameserver:
```
$ dig test.zone.dyn-test.rpz.switch.ch @localhost +norec
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 <<>> test.zone.dyn-test.rpz.switch.ch @localhost +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23411
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;test.zone.dyn-test.rpz.switch.ch. IN A
;; ANSWER SECTION:
test.zone.dyn-test.rpz.switch.ch. 300 IN A 127.0.0.1
;; AUTHORITY SECTION:
zone.dyn-test.rpz.switch.ch. 300 IN NS bona.switch.ch.
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Sep 09 11:44:51 CEST 2021
;; MSG SIZE rcvd: 105
```
3. Freeze the zone, manually add a record and unfreeze the zone.
* `$ rndc freeze zone.dyn-test.rpz.switch.ch`
* Zone file correctly shows the dynamically added record.
```
$ cat zone.dyn-test.rpz.switch.ch
$ORIGIN .
$TTL 300 ; 5 minutes
zone.dyn-test.rpz.switch.ch IN SOA bona.switch.ch. dns-operation.switch.ch. (
2021073348 ; serial
600 ; refresh (10 minutes)
300 ; retry (5 minutes)
604800 ; expire (1 week)
300 ; minimum (5 minutes)
)
NS bona.switch.ch.
$ORIGIN zone.dyn-test.rpz.switch.ch.
test A 127.0.0.1
```
* Add another record e.g.
```
$ cat zone.dyn-test.rpz.switch.ch
$ORIGIN .
$TTL 300 ; 5 minutes
zone.dyn-test.rpz.switch.ch IN SOA bona.switch.ch. dns-operation.switch.ch. (
2021073348 ; serial
600 ; refresh (10 minutes)
300 ; retry (5 minutes)
604800 ; expire (1 week)
300 ; minimum (5 minutes)
)
NS bona.switch.ch.
$ORIGIN zone.dyn-test.rpz.switch.ch.
test A 127.0.0.1
A 127.0.0.2
```
* `$ rndc thaw zone.dyn-test.rpz.switch.ch`
* Logs:
```
09-Sep-2021 11:49:50.536 general: info: received control channel command 'freeze zone.dyn-test.rpz.switch.ch'
09-Sep-2021 11:49:52.203 general: info: freezing zone 'zone.dyn-test.rpz.switch.ch/IN': success
09-Sep-2021 11:53:06.670 general: info: received control channel command 'thaw zone.dyn-test.rpz.switch.ch'
09-Sep-2021 11:53:06.671 general: info: thawing zone 'zone.dyn-test.rpz.switch.ch/IN': success
```
4. Query the record again.
```
$ dig test.zone.dyn-test.rpz.switch.ch @localhost +norec
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 <<>> test.zone.dyn-test.rpz.switch.ch @localhost +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19316
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;test.zone.dyn-test.rpz.switch.ch. IN A
;; ANSWER SECTION:
test.zone.dyn-test.rpz.switch.ch. 300 IN A 127.0.0.1
;; AUTHORITY SECTION:
zone.dyn-test.rpz.switch.ch. 300 IN NS bona.switch.ch.
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Sep 09 11:54:39 CEST 2021
;; MSG SIZE rcvd: 105
```
### What is the current *bug* behavior?
After executing the 4 steps above only one A record is returned.
### What is the expected *correct* behavior?
After executing the 4 steps above I'd expect there to be two A records.
### Relevant configuration files
named.conf
```
...
some acls
...
controls {
inet 127.0.0.1 allow {
127.0.0.1/32;
} keys {
"rndc-key";
};
inet ::1 allow {
::1/128;
} keys {
"rndc-key";
};
};
dnssec-policy "test" {
dnskey-ttl 3600;
keys {
csk key-directory lifetime unlimited algorithm 13;
};
max-zone-ttl 3600;
parent-ds-ttl 3600;
parent-propagation-delay 3600;
publish-safety 3600;
retire-safety 3600;
signatures-refresh P1D;
zone-propagation-delay 300;
};
logging {
channel "switch_local" {
file "/var/log/named/named" versions 10 size 6291456;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel "switch_other" {
file "/var/log/named/other" versions 10 size 6291456;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
category "general" {
"switch_local";
};
category "notify" {
"switch_local";
};
category "xfer-in" {
"switch_local";
};
category "xfer-out" {
"switch_local";
};
category "network" {
"switch_local";
};
category "dnssec" {
"switch_local";
};
category "default" {
"switch_other";
};
};
options {
directory "/etc/bind/zones";
listen-on port 53 {
"any";
};
listen-on-v6 port 53 {
"any";
};
pid-file "/var/run/named/named.pid";
server-id hostname;
transfers-in 100;
transfers-out 100;
transfers-per-ns 10;
version "contact dns-operation@switch.ch";
allow-query-cache {
"none";
};
check-names master warn;
dnssec-validation no;
ixfr-from-differences yes;
query-source address 130.59.117.36 port 0;
query-source-v6 address 2001:620:0:1005:21a:4aff:fede:5a port 0;
recursion no;
allow-transfer {
"XFR-SWITCH";
};
check-integrity no;
check-sibling no;
notify explicit;
notify-source 130.59.117.36;
notify-source-v6 2001:620:0:1005:21a:4aff:fede:5a;
transfer-source 130.59.117.36;
transfer-source-v6 2001:620:0:1005:21a:4aff:fede:5a;
use-alt-transfer-source no;
};
statistics-channels {
inet 127.0.0.1 port 8053 allow {
127.0.0.1/32;
};
inet ::1 port 8053 allow {
::1/128;
};
};
key "rndc-key" {
algorithm "hmac-md5";
secret "????????????????????????";
};
...
more keys
...
key "zone.dyn-test.rpz.switch.ch.tsig" {
algorithm "HMAC-SHA512";
secret "????????????????????????????????????????????????????????????????????????????????????????";
};
...
more zones
...
zone "zone.dyn-test.rpz.switch.ch" {
type master;
file "dynamic/zone.dyn-test.rpz.switch.ch";
update-policy {
grant "zone.dyn-test.rpz.switch.ch.tsig" subdomain "zone.dyn-test.rpz.switch.ch" "ANY";
};
dnssec-policy "none";
};
```
I removed some parts of the config. I hope they're not relevant.
### Relevant logs and/or screenshots
See above.
### Possible fixeshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2896TXT record parsing interop issue in named-compilezone2021-09-08T11:23:35ZGavin BrownTXT record parsing interop issue in named-compilezone<!--
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
I have an interoperability issue where `named-compilezone` and `ldns-read-zone` handle the following TXT record differently:
```
example.com. 3600 IN TXT "foo""bar"
```
Note the lack of space between `"foo"` and `"bar"`. From reading RFC 1035 it's not clear whether the space between the two text segments is required or optional:
> ```
> 3.3.14. TXT RDATA format
>
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> / TXT-DATA /
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>
> where:
>
> TXT-DATA One or more <character-string>s.
> ```
A `<character-string>` is defined in Section 5 as follows:
> ```
> <character-string> is expressed in one or two ways: as a contiguous set
> of characters without interior spaces, or as a string beginning with a "
> and ending with a ". Inside a " delimited string any character can
> occur, except for a " itself, which must be quoted using \ (back slash).
> ```
RFC 1035 says nothing about how consecutive `<character-string>`s are delimited from each other.
`named-compilezone` parses the above TXT record without issue, and in its output, re-emits the TXT record with a space between each segment:
```
example.com. 3600 IN TXT "foo" "bar"
```
My question is whether or `named-compilezone` should reject the input above because it's malformed.
`ldns-read-zone` parses the record incorrectly and produces a mangled record, which I've already reported [here](https://github.com/NLnetLabs/ldns/issues/139).
### BIND version used
```
$ named-compilezone -v
9.16.7
```
Installed using Homebrew on macOS Big Sur, but this behaviour has also been reported on other versions/OSes.
### Steps to reproduce
`named-compilezone -i none -o /dev/stdout example.com example.com.txt`
[example.com.txt](/uploads/6f3e9f50560dbc932d1336da202a322c/example.com.txt)
### What is the current *bug* behavior?
```
$ named-compilezone -i none -o /dev/stdout example.com example.com.txt
zone example.com/IN: loaded serial 2021090201
example.com. 900 IN SOA ns.icann.org. noc.dns.icann.org. 2021090201 7200 3600 1209600 3600
example.com. 900 IN NS a.iana-servers.net.
example.com. 900 IN NS b.iana-servers.net.
example.com. 900 IN TXT "foo" "bar"
OK
```
### What is the expected *correct* behavior?
The existing behaviour *or* `named-compilezone` should reject the RR as malformed.
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
N/A
### Possible fixes
N/Ahttps://gitlab.isc.org/isc-projects/stork/-/issues/578sanity checks 0.202022-02-03T11:47:41ZWlodzimierz Wencelsanity checks 0.20Please do sanity checks according to steps below:
1. Get the tarball and check it, run tests. tarball: https://gitlab.isc.org/isc-projects/stork/-/jobs/1967428/artifacts/browse
1. Start demo locally with `rake docker_up` and follow the ...Please do sanity checks according to steps below:
1. Get the tarball and check it, run tests. tarball: https://gitlab.isc.org/isc-projects/stork/-/jobs/1967428/artifacts/browse
1. Start demo locally with `rake docker_up` and follow the steps from the demo wiki: https://gitlab.isc.org/isc-projects/stork/-/wikis/Demo
1. Install server and agent locally e.g. in VMs from binary debs & rpms packages: https://gitlab.isc.org/isc-projects/stork/-/jobs/1967429/artifacts/browse0.20https://gitlab.isc.org/isc-projects/stork/-/issues/5770.20 release2021-09-08T08:55:31ZWlodzimierz Wencel0.20 release0.20Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2895named can create unrecoverable managed-keys.jnl file2022-11-01T11:20:24ZOndřej Surýnamed can create unrecoverable managed-keys.jnl file1. Run `named` in a way it can't reach the internet (f.e. set the query-source port to the listening port).
```
options {
query-source address 10.10.10.20 port 53054;
port 53;
listen-on port 53053 { 10.10.10.20; };
};
```
2. Stop it a...1. Run `named` in a way it can't reach the internet (f.e. set the query-source port to the listening port).
```
options {
query-source address 10.10.10.20 port 53054;
port 53;
listen-on port 53053 { 10.10.10.20; };
};
```
2. Stop it after you see `running` in the log immediately, but before `resolver priming query complete` is printed
3. Verify that managed-keys.jnl is bogus with `$ bin/tools/named-journalprint managed-keys.bind.jnl`
```
del . 0 IN SOA . . 0 0 0 0 0
add . 0 IN SOA . . 1 0 0 0 0
add . 0 IN TYPE65533 \# 16 00000000000000000000000000000000
```
4. Now fix your config:
```
options {
query-source address 10.10.10.20 port 0;
port 53;
listen-on port 53053 { 10.10.10.20; };
};
```
5. Run `named` again and it will not recover from the broken `managed-keys.bind.jnl` file:
```
08-Sep-2021 09:50:48.172 running
08-Sep-2021 09:50:49.784 managed-keys-zone: DNSKEY set for zone '.' could not be verified with current keys
08-Sep-2021 09:50:49.788 validating ./NS: no valid signature found
08-Sep-2021 09:50:49.788 no valid RRSIG resolving './NS/IN': 198.97.190.53#53
08-Sep-2021 09:50:49.796 validating ./NS: no valid signature found
08-Sep-2021 09:50:49.796 no valid RRSIG resolving './NS/IN': 199.7.83.42#53
08-Sep-2021 09:50:49.804 validating ./NS: no valid signature found
08-Sep-2021 09:50:49.804 no valid RRSIG resolving './NS/IN': 193.0.14.129#53
08-Sep-2021 09:50:53.028 validating ./NS: no valid signature found
08-Sep-2021 09:50:53.028 no valid RRSIG resolving './NS/IN': 198.41.0.4#53
08-Sep-2021 09:50:53.040 validating ./NS: no valid signature found
08-Sep-2021 09:50:53.040 no valid RRSIG resolving './NS/IN': 192.33.4.12#53
08-Sep-2021 09:50:58.168 resolver priming query complete
08-Sep-2021 09:51:13.172 managed-keys-zone: DNSKEY set for zone '.' could not be verified with current keys
```
This is low-priority issue, but it should be recorded somewhere.November 2022 (9.16.35, 9.16.35-S1, 9.18.9, 9.19.7)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/kea/-/issues/2082time-sensitive unit test failure GssTsigContextTest.unsigned2021-12-09T15:46:05ZAndrei Pavelandrei@isc.orgtime-sensitive unit test failure GssTsigContextTest.unsignedhttps://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/446/
```
12:07:28 [ RUN ] GssTsigContextTest.unsigned
12:07:28 gss_tsig_context_unittests.cc:165: Failure
12:07:28 Expected: (after) >= (rdata.getTimeSigned()), actual: 163...https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/446/
```
12:07:28 [ RUN ] GssTsigContextTest.unsigned
12:07:28 gss_tsig_context_unittests.cc:165: Failure
12:07:28 Expected: (after) >= (rdata.getTimeSigned()), actual: 1631005647 vs 1631005648
12:07:28 gss_tsig_context_unittests.cc:196: Failure
12:07:28 Expected: (after) >= (rdata2.getTimeSigned()), actual: 1631005647 vs 1631005648
12:07:28 [ FAILED ] GssTsigContextTest.unsigned (0 ms)
```kea2.1.0Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2894Windows Service Error 1067 for v. 9.16.202021-09-06T15:28:42ZmikeksWindows Service Error 1067 for v. 9.16.20### Summary
Unable to start ISC Bind v. 9.16.20 as Windows Service. It works with ISC Bind v. 9.11.35.
### BIND version used
The problem only occurs with ISC Bind 9.16.20, but not in 9.11.35
### Steps to reproduce
1. Download Windo...### Summary
Unable to start ISC Bind v. 9.16.20 as Windows Service. It works with ISC Bind v. 9.11.35.
### BIND version used
The problem only occurs with ISC Bind 9.16.20, but not in 9.11.35
### Steps to reproduce
1. Download Windows x64 binaries for ISC Bind 9.16.20
2. Run BINDInstall.exe as administrator, install the Bind.
3. Put your configs into ./etc folder
4. Allow full access to bind service account
5. Successfully run the Bind from command line: named -f
6. Attempt to run as service causes Windows error 1067
### What is the current *bug* behavior?
Attempt to run Windows service causes error 1067.
### What is the expected *correct* behavior?
Service should be able to start. The same configuration works with Bind 9.11.35.
### Relevant logs and/or screenshots
The Windows Application Events log doesn't reveal any error(s).https://gitlab.isc.org/isc-projects/kea/-/issues/2080Documentation update for "include" statement2021-09-24T13:55:17ZPeter DaviesDocumentation update for "include" statementIt may be of use to users if there were an example of the usage of the "include" statement in the Kea configuration file.
[RT #19145]( https://support.isc.org/Ticket/Display.html?id=19145 )It may be of use to users if there were an example of the usage of the "include" statement in the Kea configuration file.
[RT #19145]( https://support.isc.org/Ticket/Display.html?id=19145 )kea2.0.0 (formerly 1.9.12)Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/576alerting: server should report statistics to Prometheus2021-11-04T10:18:55ZTomek Mrugalskialerting: server should report statistics to PrometheusImplement the ability in Stork server to export statistics to Prometheus. For the time being I think the following stats should be made available:
1. number of authorized machines
2. number of unauthorized machines
3. number of unreacha...Implement the ability in Stork server to export statistics to Prometheus. For the time being I think the following stats should be made available:
1. number of authorized machines
2. number of unauthorized machines
3. number of unreachable machines
The third statistic should report 0 under normal circumstances, so not exactly exciting. The idea is that an admin could set up an alarm for non-zero value reported. For the first two, a careful admin may set up an alert if there's a new machine in the system, e.g. when someone tries to set up a fake machine or when the system is scaled up by adding new VM with Kea.
In the future we may also report the number of error events or something similar. The general idea here is to offload the alterting to prometheus. We were supposed to provide some alterting mechanisms, but instead of implementing them ourselves in Stork, it's much more robust to use existing mechanisms from Prometheus.0.22Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/580Error while reading host reservations2021-11-03T10:14:38ZFabian KretschmerError while reading host reservationsHi,
we are facing a problem reading the host reservations in Stork 0.19.0 with the kea premium hook host_cmds library (tested with compiled kea 1.8.2 and 1.9.11).
Using the API, multiple hosts reservations were successfully added to a M...Hi,
we are facing a problem reading the host reservations in Stork 0.19.0 with the kea premium hook host_cmds library (tested with compiled kea 1.8.2 and 1.9.11).
Using the API, multiple hosts reservations were successfully added to a MySQL database backend. The Library is successfully loaded, the kea server is registered in stork and the agent is running, so everything looks fine until here.
At the DHCP host reservation page in stork no reservations are displayed. At this time, an Error is logged in stork and kea, please have a look at the logs below. In both Kea versions they are looking the same and the error is reproducible.
Please let me know, if you need any additional informations, any help would be appreciated.
Kind regards,
Fabian
**Environment:**
- Kea version: 1.8.2 / 1.9.11 with Stork 0.19.0
- OS: Ubuntu 18.04 Docker Container
- Which hooks where loaded in: libdhcp_host_cmds.so, libdhcp_stat_cmds.so, libdhcp_lease_cmds.so
**Logs:**
The reservation-add command logs looks like:
```
INFO COMMAND_RECEIVED Received command 'reservation-add'
INFO HOST_CMDS_RESERV_ADD reservation-add command successful (parameters: { "reservation": { "boot-file-name": "bootfile.efi", "hostname": "HOST1", "hw-address": "00:11:22:33:44:55", "ip-address": "192.168.10.100", "subnet-id": 10, "user-context": "{key': 'value'}" } })
INFO CTRL_AGENT_COMMAND_FORWARDED command reservation-add successfully forwarded to the service dhcp4
```
Kea Server:
`ERROR HOOKS_CALLOUT_ERROR error returned by callout on hook $reservation_get_page registered by library with index 3 (callout address 0x7ff88302e410) (callout duration 18.124 ms)`
Stork Server:
```
INFO[2021-09-03 07:38:44] eventcenter.go:117 event 'communication with <daemon id="12" name="dhcp4" appId="3" appType="kea"> of <app id="3" name="kea@172.17.0.3" type="kea" version="1.9.11"> failed'
ERRO[2021-09-03 07:38:44] host.go:87 error occurred while fetching hosts from app 3: error returned by Kea in response to reservation-get-page command
isc.org/stork/server/apps/kea.(*HostDetectionIterator).sendReservationGetPage
/tmp/build/backend/server/apps/kea/host.go:254
isc.org/stork/server/apps/kea.(*HostDetectionIterator).DetectHostsPageFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:356
isc.org/stork/server/apps/kea.updateHostsFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:536
isc.org/stork/server/apps/kea.(*HostsPuller).pullData
/tmp/build/backend/server/apps/kea/host.go:84
isc.org/stork/server/agentcomm.(*PeriodicPuller).pullerLoop
/tmp/build/backend/server/agentcomm/puller.go:169
runtime.goexit
/tmp/build/tools/1.15.5/go/src/runtime/asm_amd64.s:1374
problem with sending reservation-get-page command upon attempt to detect host reservations over the host_cmds hooks library
INFO[2021-09-03 07:38:44] host.go:100 completed pulling hosts from Kea apps: 0/1 succeeded
ERRO[2021-09-03 07:38:44] puller.go:172 errors were encountered while pulling data from apps: error returned by Kea in response to reservation-get-page command
isc.org/stork/server/apps/kea.(*HostDetectionIterator).sendReservationGetPage
/tmp/build/backend/server/apps/kea/host.go:254
isc.org/stork/server/apps/kea.(*HostDetectionIterator).DetectHostsPageFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:356
isc.org/stork/server/apps/kea.updateHostsFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:536
isc.org/stork/server/apps/kea.(*HostsPuller).pullData
/tmp/build/backend/server/apps/kea/host.go:84
isc.org/stork/server/agentcomm.(*PeriodicPuller).pullerLoop
/tmp/build/backend/server/agentcomm/puller.go:169
runtime.goexit
/tmp/build/tools/1.15.5/go/src/runtime/asm_amd64.s:1374
problem with sending reservation-get-page command upon attempt to detect host reservations over the host_cmds hooks library
INFO[2021-09-03 06:37:47] eventcenter.go:117 event 'communication with <daemon id="3" name="dhcp4" appId="1" appType="kea"> of <app id="1" name="kea@172.17.0.3" type="kea" version="1.8.2"> failed'
ERRO[2021-09-03 06:37:47] host.go:87 error occurred while fetching hosts from app 1: error returned by Kea in response to reservation-get-page command
isc.org/stork/server/apps/kea.(*HostDetectionIterator).sendReservationGetPage
/tmp/build/backend/server/apps/kea/host.go:254
isc.org/stork/server/apps/kea.(*HostDetectionIterator).DetectHostsPageFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:356
isc.org/stork/server/apps/kea.updateHostsFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:536
isc.org/stork/server/apps/kea.(*HostsPuller).pullData
/tmp/build/backend/server/apps/kea/host.go:84
isc.org/stork/server/agentcomm.(*PeriodicPuller).pullerLoop
/tmp/build/backend/server/agentcomm/puller.go:169
runtime.goexit
/tmp/build/tools/1.15.5/go/src/runtime/asm_amd64.s:1374
problem with sending reservation-get-page command upon attempt to detect host reservations over the host_cmds hooks library
INFO[2021-09-03 06:37:47] host.go:100 completed pulling hosts from Kea apps: 0/1 succeeded
ERRO[2021-09-03 06:37:47] puller.go:172 errors were encountered while pulling data from apps: error returned by Kea in response to reservation-get-page command
isc.org/stork/server/apps/kea.(*HostDetectionIterator).sendReservationGetPage
/tmp/build/backend/server/apps/kea/host.go:254
isc.org/stork/server/apps/kea.(*HostDetectionIterator).DetectHostsPageFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:356
isc.org/stork/server/apps/kea.updateHostsFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:536
isc.org/stork/server/apps/kea.(*HostsPuller).pullData
/tmp/build/backend/server/apps/kea/host.go:84
isc.org/stork/server/agentcomm.(*PeriodicPuller).pullerLoop
/tmp/build/backend/server/agentcomm/puller.go:169
runtime.goexit
/tmp/build/tools/1.15.5/go/src/runtime/asm_amd64.s:1374
problem with sending reservation-get-page command upon attempt to detect host reservations over the host_cmds hooks library
```
Edit: Here's a more verbose (debuglevel 99) output from the kea server:
```
WARN[2021-09-07 13:32:42] promkeaexporter.go:368 problem with connecting to dhcp daemon: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
DEBUG DHCPSRV_MYSQL_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.581 ms
DEBUG ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: flush-reclaimed-leases
DEBUG ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE begin deletion of reclaimed leases expired more than 3600 seconds ago
DEBUG DHCPSRV_MYSQL_DELETE_EXPIRED_RECLAIMED4 deleting reclaimed IPv4 leases that expired more than 3600 seconds ago
DEBUG DHCPSRV_MYSQL_DELETED_EXPIRED_RECLAIMED deleted 0 reclaimed leases from the database
DEBUG ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_COMPLETE successfully deleted 0 expired-reclaimed leases
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: flush-reclaimed-leases
INFO COMMAND_RECEIVED Received command 'reservation-get-page'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 128 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'reservation-get-page'
DEBUG HOOKS_CALLOUTS_BEGIN begin all callouts for hook $reservation_get_page
DEBUG HOOKS_CALLOUT_CALLED hooks library with index 3 has called a callout on hook $reservation_get_page that has address 0x7f176473c4a0 (callout duration: 4.296 ms)
DEBUG HOOKS_CALLOUTS_COMPLETE completed callouts for hook $reservation_get_page (total callouts duration: 4.296 ms)
DEBUG COMMAND_SOCKET_WRITE Sent response of 92 bytes (0 bytes left to send) over command socket 23
INFO CTRL_AGENT_COMMAND_FORWARDED command reservation-get-page successfully forwarded to the service dhcp4
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO[2021-09-07 13:32:50] agent.go:375 Compressing response from 96 B to 108 B, ratio 112%
INFO COMMAND_RECEIVED Received command 'stat-lease4-get'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 56 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'stat-lease4-get'
DEBUG HOOKS_CALLOUTS_BEGIN begin all callouts for hook $stat_lease4_get
INFO STAT_CMDS_LEASE4_GET stat-lease4-get command successful, parameters: [all subnets] rows found: 1
DEBUG HOOKS_CALLOUT_CALLED hooks library with index 2 has called a callout on hook $stat_lease4_get that has address 0x7f17649600c0 (callout duration: 0.431 ms)
DEBUG HOOKS_CALLOUTS_COMPLETE completed callouts for hook $stat_lease4_get (total callouts duration: 0.431 ms)
INFO CTRL_AGENT_COMMAND_FORWARDED command stat-lease4-get successfully forwarded to the service dhcp4
DEBUG COMMAND_SOCKET_WRITE Sent response of 303 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO[2021-09-07 13:32:50] agent.go:375 Compressing response from 307 B to 212 B, ratio 69%
INFO COMMAND_RECEIVED Received command 'statistic-get'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 96 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'statistic-get'
DEBUG COMMAND_SOCKET_WRITE Sent response of 90 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command statistic-get successfully forwarded to the service dhcp4
INFO[2021-09-07 13:32:50] agent.go:375 Compressing response from 94 B to 110 B, ratio 117%
INFO COMMAND_RECEIVED Received command 'reservation-get-page'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 129 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'reservation-get-page'
DEBUG HOOKS_CALLOUTS_BEGIN begin all callouts for hook $reservation_get_page
ERROR HOOKS_CALLOUT_ERROR error returned by callout on hook 3 registered by library with index $reservation_get_page (callout address 0x7f176473c4a0) (callout duration 15.274 ms)
DEBUG HOOKS_CALLOUTS_COMPLETE completed callouts for hook $reservation_get_page (total callouts duration: 15.274 ms)
INFO CTRL_AGENT_COMMAND_FORWARDED command reservation-get-page successfully forwarded to the service dhcp4
DEBUG COMMAND_SOCKET_WRITE Sent response of 657 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO[2021-09-07 13:32:50] agent.go:375 Compressing response from 661 B to 365 B, ratio 55%
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 86 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_WRITE Sent response of 1759 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command statistic-get-all successfully forwarded to the service dhcp4
WARN[2021-09-07 13:32:52] promkeaexporter.go:368 problem with connecting to dhcp daemon: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
DEBUG DHCPSRV_MYSQL_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 1.478 ms
DEBUG ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
INFO COMMAND_RECEIVED Received command 'version-get'
INFO[2021-09-07 13:32:59] agent.go:375 Compressing response from 116 B to 125 B, ratio 107%
INFO COMMAND_RECEIVED Received command 'config-get'
INFO[2021-09-07 13:32:59] agent.go:375 Compressing response from 683 B to 314 B, ratio 45%
INFO COMMAND_RECEIVED Received command 'version-get'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 67 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'version-get'
DEBUG COMMAND_SOCKET_WRITE Sent response of 205 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command version-get successfully forwarded to the service dhcp4
INFO[2021-09-07 13:32:59] agent.go:375 Compressing response from 482 B to 273 B, ratio 56%
INFO COMMAND_RECEIVED Received command 'status-get'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 60 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'status-get'
DEBUG COMMAND_SOCKET_WRITE Sent response of 107 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command status-get successfully forwarded to the service dhcp4
INFO[2021-09-07 13:32:59] agent.go:375 Compressing response from 249 B to 196 B, ratio 78%
INFO COMMAND_RECEIVED Received command 'config-get'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 66 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'config-get'
DEBUG COMMAND_SOCKET_WRITE Sent response of 3167 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command config-get successfully forwarded to the service dhcp4
WARN[2021-09-07 13:32:59] kea.go:69 skipped refreshing viewable log files because config-get returned non success result
WARN[2021-09-07 13:32:59] kea.go:69 skipped refreshing viewable log files because config-get returned non success result
INFO[2021-09-07 13:32:59] agent.go:375 Compressing response from 3444 B to 1296 B, ratio 37%
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 86 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_WRITE Sent response of 1759 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command statistic-get-all successfully forwarded to the service dhcp4
WARN[2021-09-07 13:33:02] promkeaexporter.go:368 problem with connecting to dhcp daemon: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
DEBUG DHCPSRV_MYSQL_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.633 ms
DEBUG ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 86 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_WRITE Sent response of 1759 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command statistic-get-all successfully forwarded to the service dhcp4
WARN[2021-09-07 13:33:12] promkeaexporter.go:368 problem with connecting to dhcp daemon: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: flush-reclaimed-leases
DEBUG ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE begin deletion of reclaimed leases expired more than 3600 seconds ago
DEBUG DHCPSRV_MYSQL_DELETE_EXPIRED_RECLAIMED4 deleting reclaimed IPv4 leases that expired more than 3600 seconds ago
DEBUG DHCPSRV_MYSQL_DELETED_EXPIRED_RECLAIMED deleted 0 reclaimed leases from the database
DEBUG ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_COMPLETE successfully deleted 0 expired-reclaimed leases
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: flush-reclaimed-leases
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
DEBUG DHCPSRV_MYSQL_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.626 ms
DEBUG ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 86 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_WRITE Sent response of 1759 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command statistic-get-all successfully forwarded to the service dhcp4
WARN[2021-09-07 13:33:22] promkeaexporter.go:368 problem with connecting to dhcp daemon: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
```0.22https://gitlab.isc.org/isc-projects/kea/-/issues/2079Error while reading host reservations2021-09-13T14:32:40ZFabian KretschmerError while reading host reservationsHi,
we are facing a problem reading the host reservations in Stork 0.19.0 with the kea premium hook host_cmds library (tested with compiled kea 1.8.2 and 1.9.11).
Using the API, multiple hosts reservations were successfully added to a M...Hi,
we are facing a problem reading the host reservations in Stork 0.19.0 with the kea premium hook host_cmds library (tested with compiled kea 1.8.2 and 1.9.11).
Using the API, multiple hosts reservations were successfully added to a MySQL database backend. The Library is successfully loaded, the kea server is registered in stork and the agent is running, so everything looks fine until here.
At the DHCP host reservation page in stork no reservations are displayed. At this time, an Error is logged in stork and kea, please have a look at the logs below. In both Kea versions they are looking the same and the error is reproducible.
Please let me know, if you need any additional informations, any help would be appreciated.
Kind regards,
Fabian
**Environment:**
- Kea version: 1.8.2 / 1.9.11 with Stork 0.19.0
- OS: Ubuntu 18.04 Docker Container
- Which hooks where loaded in: libdhcp_host_cmds.so, libdhcp_stat_cmds.so, libdhcp_lease_cmds.so
**Logs:**
The reservation-add command logs looks like:
```
INFO COMMAND_RECEIVED Received command 'reservation-add'
INFO HOST_CMDS_RESERV_ADD reservation-add command successful (parameters: { "reservation": { "boot-file-name": "bootfile.efi", "hostname": "HOST1", "hw-address": "00:11:22:33:44:55", "ip-address": "192.168.10.100", "subnet-id": 10, "user-context": "{key': 'value'}" } })
INFO CTRL_AGENT_COMMAND_FORWARDED command reservation-add successfully forwarded to the service dhcp4
```
Kea Server:
`ERROR HOOKS_CALLOUT_ERROR error returned by callout on hook $reservation_get_page registered by library with index 3 (callout address 0x7ff88302e410) (callout duration 18.124 ms)`
Stork Server:
```
INFO[2021-09-03 07:38:44] eventcenter.go:117 event 'communication with <daemon id="12" name="dhcp4" appId="3" appType="kea"> of <app id="3" name="kea@172.17.0.3" type="kea" version="1.9.11"> failed'
ERRO[2021-09-03 07:38:44] host.go:87 error occurred while fetching hosts from app 3: error returned by Kea in response to reservation-get-page command
isc.org/stork/server/apps/kea.(*HostDetectionIterator).sendReservationGetPage
/tmp/build/backend/server/apps/kea/host.go:254
isc.org/stork/server/apps/kea.(*HostDetectionIterator).DetectHostsPageFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:356
isc.org/stork/server/apps/kea.updateHostsFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:536
isc.org/stork/server/apps/kea.(*HostsPuller).pullData
/tmp/build/backend/server/apps/kea/host.go:84
isc.org/stork/server/agentcomm.(*PeriodicPuller).pullerLoop
/tmp/build/backend/server/agentcomm/puller.go:169
runtime.goexit
/tmp/build/tools/1.15.5/go/src/runtime/asm_amd64.s:1374
problem with sending reservation-get-page command upon attempt to detect host reservations over the host_cmds hooks library
INFO[2021-09-03 07:38:44] host.go:100 completed pulling hosts from Kea apps: 0/1 succeeded
ERRO[2021-09-03 07:38:44] puller.go:172 errors were encountered while pulling data from apps: error returned by Kea in response to reservation-get-page command
isc.org/stork/server/apps/kea.(*HostDetectionIterator).sendReservationGetPage
/tmp/build/backend/server/apps/kea/host.go:254
isc.org/stork/server/apps/kea.(*HostDetectionIterator).DetectHostsPageFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:356
isc.org/stork/server/apps/kea.updateHostsFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:536
isc.org/stork/server/apps/kea.(*HostsPuller).pullData
/tmp/build/backend/server/apps/kea/host.go:84
isc.org/stork/server/agentcomm.(*PeriodicPuller).pullerLoop
/tmp/build/backend/server/agentcomm/puller.go:169
runtime.goexit
/tmp/build/tools/1.15.5/go/src/runtime/asm_amd64.s:1374
problem with sending reservation-get-page command upon attempt to detect host reservations over the host_cmds hooks library
INFO[2021-09-03 06:37:47] eventcenter.go:117 event 'communication with <daemon id="3" name="dhcp4" appId="1" appType="kea"> of <app id="1" name="kea@172.17.0.3" type="kea" version="1.8.2"> failed'
ERRO[2021-09-03 06:37:47] host.go:87 error occurred while fetching hosts from app 1: error returned by Kea in response to reservation-get-page command
isc.org/stork/server/apps/kea.(*HostDetectionIterator).sendReservationGetPage
/tmp/build/backend/server/apps/kea/host.go:254
isc.org/stork/server/apps/kea.(*HostDetectionIterator).DetectHostsPageFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:356
isc.org/stork/server/apps/kea.updateHostsFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:536
isc.org/stork/server/apps/kea.(*HostsPuller).pullData
/tmp/build/backend/server/apps/kea/host.go:84
isc.org/stork/server/agentcomm.(*PeriodicPuller).pullerLoop
/tmp/build/backend/server/agentcomm/puller.go:169
runtime.goexit
/tmp/build/tools/1.15.5/go/src/runtime/asm_amd64.s:1374
problem with sending reservation-get-page command upon attempt to detect host reservations over the host_cmds hooks library
INFO[2021-09-03 06:37:47] host.go:100 completed pulling hosts from Kea apps: 0/1 succeeded
ERRO[2021-09-03 06:37:47] puller.go:172 errors were encountered while pulling data from apps: error returned by Kea in response to reservation-get-page command
isc.org/stork/server/apps/kea.(*HostDetectionIterator).sendReservationGetPage
/tmp/build/backend/server/apps/kea/host.go:254
isc.org/stork/server/apps/kea.(*HostDetectionIterator).DetectHostsPageFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:356
isc.org/stork/server/apps/kea.updateHostsFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:536
isc.org/stork/server/apps/kea.(*HostsPuller).pullData
/tmp/build/backend/server/apps/kea/host.go:84
isc.org/stork/server/agentcomm.(*PeriodicPuller).pullerLoop
/tmp/build/backend/server/agentcomm/puller.go:169
runtime.goexit
/tmp/build/tools/1.15.5/go/src/runtime/asm_amd64.s:1374
problem with sending reservation-get-page command upon attempt to detect host reservations over the host_cmds hooks library
```
Edit: Here's a more verbose (debuglevel 99) output from the kea server:
```
WARN[2021-09-07 13:32:42] promkeaexporter.go:368 problem with connecting to dhcp daemon: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
DEBUG DHCPSRV_MYSQL_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.581 ms
DEBUG ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: flush-reclaimed-leases
DEBUG ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE begin deletion of reclaimed leases expired more than 3600 seconds ago
DEBUG DHCPSRV_MYSQL_DELETE_EXPIRED_RECLAIMED4 deleting reclaimed IPv4 leases that expired more than 3600 seconds ago
DEBUG DHCPSRV_MYSQL_DELETED_EXPIRED_RECLAIMED deleted 0 reclaimed leases from the database
DEBUG ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_COMPLETE successfully deleted 0 expired-reclaimed leases
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: flush-reclaimed-leases
INFO COMMAND_RECEIVED Received command 'reservation-get-page'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 128 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'reservation-get-page'
DEBUG HOOKS_CALLOUTS_BEGIN begin all callouts for hook $reservation_get_page
DEBUG HOOKS_CALLOUT_CALLED hooks library with index 3 has called a callout on hook $reservation_get_page that has address 0x7f176473c4a0 (callout duration: 4.296 ms)
DEBUG HOOKS_CALLOUTS_COMPLETE completed callouts for hook $reservation_get_page (total callouts duration: 4.296 ms)
DEBUG COMMAND_SOCKET_WRITE Sent response of 92 bytes (0 bytes left to send) over command socket 23
INFO CTRL_AGENT_COMMAND_FORWARDED command reservation-get-page successfully forwarded to the service dhcp4
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO[2021-09-07 13:32:50] agent.go:375 Compressing response from 96 B to 108 B, ratio 112%
INFO COMMAND_RECEIVED Received command 'stat-lease4-get'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 56 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'stat-lease4-get'
DEBUG HOOKS_CALLOUTS_BEGIN begin all callouts for hook $stat_lease4_get
INFO STAT_CMDS_LEASE4_GET stat-lease4-get command successful, parameters: [all subnets] rows found: 1
DEBUG HOOKS_CALLOUT_CALLED hooks library with index 2 has called a callout on hook $stat_lease4_get that has address 0x7f17649600c0 (callout duration: 0.431 ms)
DEBUG HOOKS_CALLOUTS_COMPLETE completed callouts for hook $stat_lease4_get (total callouts duration: 0.431 ms)
INFO CTRL_AGENT_COMMAND_FORWARDED command stat-lease4-get successfully forwarded to the service dhcp4
DEBUG COMMAND_SOCKET_WRITE Sent response of 303 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO[2021-09-07 13:32:50] agent.go:375 Compressing response from 307 B to 212 B, ratio 69%
INFO COMMAND_RECEIVED Received command 'statistic-get'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 96 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'statistic-get'
DEBUG COMMAND_SOCKET_WRITE Sent response of 90 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command statistic-get successfully forwarded to the service dhcp4
INFO[2021-09-07 13:32:50] agent.go:375 Compressing response from 94 B to 110 B, ratio 117%
INFO COMMAND_RECEIVED Received command 'reservation-get-page'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 129 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'reservation-get-page'
DEBUG HOOKS_CALLOUTS_BEGIN begin all callouts for hook $reservation_get_page
ERROR HOOKS_CALLOUT_ERROR error returned by callout on hook 3 registered by library with index $reservation_get_page (callout address 0x7f176473c4a0) (callout duration 15.274 ms)
DEBUG HOOKS_CALLOUTS_COMPLETE completed callouts for hook $reservation_get_page (total callouts duration: 15.274 ms)
INFO CTRL_AGENT_COMMAND_FORWARDED command reservation-get-page successfully forwarded to the service dhcp4
DEBUG COMMAND_SOCKET_WRITE Sent response of 657 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO[2021-09-07 13:32:50] agent.go:375 Compressing response from 661 B to 365 B, ratio 55%
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 86 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_WRITE Sent response of 1759 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command statistic-get-all successfully forwarded to the service dhcp4
WARN[2021-09-07 13:32:52] promkeaexporter.go:368 problem with connecting to dhcp daemon: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
DEBUG DHCPSRV_MYSQL_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 1.478 ms
DEBUG ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
INFO COMMAND_RECEIVED Received command 'version-get'
INFO[2021-09-07 13:32:59] agent.go:375 Compressing response from 116 B to 125 B, ratio 107%
INFO COMMAND_RECEIVED Received command 'config-get'
INFO[2021-09-07 13:32:59] agent.go:375 Compressing response from 683 B to 314 B, ratio 45%
INFO COMMAND_RECEIVED Received command 'version-get'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 67 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'version-get'
DEBUG COMMAND_SOCKET_WRITE Sent response of 205 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command version-get successfully forwarded to the service dhcp4
INFO[2021-09-07 13:32:59] agent.go:375 Compressing response from 482 B to 273 B, ratio 56%
INFO COMMAND_RECEIVED Received command 'status-get'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 60 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'status-get'
DEBUG COMMAND_SOCKET_WRITE Sent response of 107 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command status-get successfully forwarded to the service dhcp4
INFO[2021-09-07 13:32:59] agent.go:375 Compressing response from 249 B to 196 B, ratio 78%
INFO COMMAND_RECEIVED Received command 'config-get'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 66 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'config-get'
DEBUG COMMAND_SOCKET_WRITE Sent response of 3167 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command config-get successfully forwarded to the service dhcp4
WARN[2021-09-07 13:32:59] kea.go:69 skipped refreshing viewable log files because config-get returned non success result
WARN[2021-09-07 13:32:59] kea.go:69 skipped refreshing viewable log files because config-get returned non success result
INFO[2021-09-07 13:32:59] agent.go:375 Compressing response from 3444 B to 1296 B, ratio 37%
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 86 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_WRITE Sent response of 1759 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command statistic-get-all successfully forwarded to the service dhcp4
WARN[2021-09-07 13:33:02] promkeaexporter.go:368 problem with connecting to dhcp daemon: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
DEBUG DHCPSRV_MYSQL_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.633 ms
DEBUG ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 86 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_WRITE Sent response of 1759 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command statistic-get-all successfully forwarded to the service dhcp4
WARN[2021-09-07 13:33:12] promkeaexporter.go:368 problem with connecting to dhcp daemon: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: flush-reclaimed-leases
DEBUG ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE begin deletion of reclaimed leases expired more than 3600 seconds ago
DEBUG DHCPSRV_MYSQL_DELETE_EXPIRED_RECLAIMED4 deleting reclaimed IPv4 leases that expired more than 3600 seconds ago
DEBUG DHCPSRV_MYSQL_DELETED_EXPIRED_RECLAIMED deleted 0 reclaimed leases from the database
DEBUG ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_COMPLETE successfully deleted 0 expired-reclaimed leases
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: flush-reclaimed-leases
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
DEBUG DHCPSRV_MYSQL_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.626 ms
DEBUG ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 86 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_WRITE Sent response of 1759 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command statistic-get-all successfully forwarded to the service dhcp4
WARN[2021-09-07 13:33:22] promkeaexporter.go:368 problem with connecting to dhcp daemon: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
```https://gitlab.isc.org/isc-projects/kea/-/issues/2078Finish the GSS-TSIG key manager2021-09-16T14:52:15ZFrancis DupontFinish the GSS-TSIG key managerFollow up of #2019 (note this ticket should get a not empty core MR in addition of the premium one).Follow up of #2019 (note this ticket should get a not empty core MR in addition of the premium one).kea2.0.0 (formerly 1.9.12)Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2893Release Checklist for BIND 9.16.21, BIND 9.16.21-S1, 9.17.182021-09-20T16:11:26ZMichał KępieńRelease Checklist for BIND 9.16.21, BIND 9.16.21-S1, 9.17.18## Notes
- BIND releases 9.11.36 & 9.11.36-S1, which were originally planned for September, are currently not expected to happen due to lack of code changes since 9.11.35(-S1).
## Release Schedule
**Code Freeze:** Wednesday, Septemb...## Notes
- BIND releases 9.11.36 & 9.11.36-S1, which were originally planned for September, are currently not expected to happen due to lack of code changes since 9.11.35(-S1).
## Release Schedule
**Code Freeze:** Wednesday, September 1st, 2021
**Tagging Deadline:** Monday, September 6th, 2021
**Public Release:** Wednesday, September 15th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.17.18](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
- [9.16.21](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
**Merge requests merged into the milestone without a release note:**
- [9.17.18](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)¬[label_name][]=Release%20Notes&target_branch=main)
- [9.16.21](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)¬[label_name][]=Release%20Notes&target_branch=v9_16)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.17.18](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)&label_name[]=No%20CHANGES&target_branch=main)
- [9.16.21](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)&label_name[]=No%20CHANGES&target_branch=v9_16)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab 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) 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 packages (`*.deb`, RPMs).
- [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.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Michał KępieńMichał Kępień2021-09-15