ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-10-06T10:58:58Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2200Format GSS-TSIG code2022-10-06T10:58:58ZAndrei Pavelandrei@isc.orgFormat GSS-TSIG codeNow that GSS-TSIG development has reached maturity, this is a good opportunity to:
* [x] apply code formatting to its code
* [ ] improve .clang-formatNow that GSS-TSIG development has reached maturity, this is a good opportunity to:
* [x] apply code formatting to its code
* [ ] improve .clang-formatoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2201DHCPv6 request dropped with rfc7217 link-local addresses and too long flex-id2022-01-11T10:04:52ZJohan MulderDHCPv6 request dropped with rfc7217 link-local addresses and too long flex-id---
name: dhcpv6 request dropped with rfc7217 link-local address
about: DHCPv6 message dropped with rfc7217 link-local addresses and too long flex-id
---
**Describe the bug**
When flex-id is used for static host reservation in combin...---
name: dhcpv6 request dropped with rfc7217 link-local address
about: DHCPv6 message dropped with rfc7217 link-local addresses and too long flex-id
---
**Describe the bug**
When flex-id is used for static host reservation in combination with replace-client-id set to true **and** the client has a link-local address that doesn't match the hardware address (actually the mac address), kea wil drop the message with the following message:
```
ERROR DHCP6_PACKET_PROCESS_STD_EXCEPTION exception occurred during packet processing: hwaddr length exceeds MAX_HWADDR_LEN
```
This only happens when the evaluated flex-id value exceeds MAX_HWADDR_LEN (which appears to be set to 20 in kea 2.0.0).
**To Reproduce**
Steps to reproduce the behavior:
1. Run kea-dhcp6 with the following flex-id configuration:
```jsonc
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_flex_id.so",
"parameters": {
// Obviously this can be anything, as long as the result exceeds the max of 20 chars
"identifier-expression": "substring(relay6[0].option[37].hex, 4, all)",
"replace-client-id": true
}
}
```
2. Generate and send a DHCPv6 request which causes the flex-id to exceed MAX_HWADDR_LEN, with a client identifier option containing a duid which contains the proper hardware address (DUID-LLT or DUID-LL will do) from a link-local address based on rfc7217.
3. The server receives the request, evaluates flex-id and replaces the duid with the evaluated flex-id value.
4. It then breaks with the forementioned error message and the request is then dropped.
**Expected behavior**
The server is not supposed to break in this kind of a situation.
**Environment:**
- Kea version (from the ISC provided packages):
```
2.0.0
tarball
linked with:
log4cplus 1.1.2
OpenSSL 1.1.1d 10 Sep 2019
database:
MySQL backend 12.0, library 10.3.29
PostgreSQL backend 6.2, library 110012
Memfile backend 2.1
```
- OS: Debian 10.10 on x86_64.
- Features: See ISC provided packages.
- hooks: legal log, flex-id, host_cmds
**Additional Information**
Complete debug log message:
```
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG DHCP6_BUFFER_RECEIVED received buffer from 2001:db8:1:8::23:547 to 2001:db8:3:117::117:1:0 over interface eth0
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG DHCP6_BUFFER_UNPACK parsing buffer received from 2001:db8:1:8::23 to 2001:db8:3:117::117:1 over interface eth0
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG DHCP6_PACKET_RECEIVED duid=[00:01:00:01:29:2e:5d:11:dc:a6:32:dd:8c:c3], tid=0x6df500: SOLICIT (type 1) received from 2001:db8:1:8::23 to 2001:db8:3:117::117:1 on interface eth0
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG DHCP6_QUERY_DATA duid=[00:01:00:01:29:2e:5d:11:dc:a6:32:dd:8c:c3], tid=0x6df500, packet details: localAddr=[2001:db8:3:117::117:1]:0 remoteAddr=[2001:db8:1:8::23]:547
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: msgtype=1(SOLICIT), transid=0x6df500
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: type=00001, len=00014: 00:01:00:01:29:2e:5d:11:dc:a6:32:dd:8c:c3
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: type=00003(IA_NA), len=00012: iaid=1, t1=0, t2=0
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: type=00006, len=00010: 23(uint16) 24(uint16) 39(uint16) 82(uint16) 83(uint16)
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: type=00008, len=00002: 49244 (uint16)
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: type=00014, len=00000:
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: type=16, len=4, enterprise id=0x9f08
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: type=00020, len=00000:
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: type=00025(IA_PD), len=00012: iaid=2, t1=0, t2=0
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: type=00037, len=00026: 941806 (uint32) 616C722D6F66662D61737730323B323033343B302F36 (binary)
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: type=39(CLIENT_FQDN), flags: (N=0, O=0, S=1), domain-name='pi-port-6' (partial)
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: 1 relay(s):
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: relay[0]: msg-type=12(RELAY_FORWARD), hop-count=0,
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: link-address=2001:db8:1:8::23, peer-address=fe80::57a1:95ad:1fc4:13d1, 2 option(s)
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: type=00018, len=00008: 76:6c:61:6e:32:30:33:34
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: type=00037, len=00026: 941806 (uint32) 616C722D6F66662D61737730323B323033343B302F36 (binary)
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG HOOKS_CALLOUTS_BEGIN begin all callouts for hook pkt6_receive
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook pkt6_receive that has address 0x7f0a5a0bc9a0 (callout duration: 0.048 ms)
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG EVAL_DEBUG_OPTION Pushing option 37 with value 0x000E5EEE616C722D6F66662D61737730323B323033343B302F36
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG EVAL_DEBUG_STRING Pushing text string '4'
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG EVAL_DEBUG_STRING Pushing text string 'all'
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG EVAL_DEBUG_SUBSTRING Popping length all, start 4, string 0x000E5EEE616C722D6F66662D61737730323B323033343B302F36 pushing result 0x616C722D6F66662D61737730323B323033343B302F36
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG FLEX_ID_EXPRESSION_EVALUATED Expression evaluated for packet to "alr-off-asw02;2034;0/6" (size: 22)
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG FLEX_ID_EXPRESSION_HEX evaluated expression in hexadecimal form "61:6c:72:2d:6f:66:66:2d:61:73:77:30:32:3b:32:30:33:34:3b:30:2f:36"
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG FLEX_ID_USED_AS_DUID using flexible identifier "00:00:61:6c:72:2d:6f:66:66:2d:61:73:77:30:32:3b:32:30:33:34:3b:30:2f:36" as DUID
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG HOOKS_CALLOUT_CALLED hooks library with index 2 has called a callout on hook pkt6_receive that has address 0x7f0a5a074700 (callout duration: 0.389 ms)
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG HOOKS_CALLOUTS_COMPLETE completed callouts for hook pkt6_receive (total callouts duration: 0.437 ms)
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG DHCPSRV_CFGMGR_SUBNET6_RELAY selected subnet 2001:db8:1:b::/64, because of matching relay addr 2001:db8:1:8::23
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG DHCP6_SUBNET_SELECTED duid=[00:00:61:6c:72:2d:6f:66:66:2d:61:73:77:30:32:3b:32:30:33:34:3b:30:2f:36], tid=0x6df500: the subnet with ID 1 was selected for client assignments
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: DEBUG DHCP6_SUBNET_DATA duid [00:00:61:6c:72:2d:6f:66:66:2d:61:73:77:30:32:3b:32:30:33:34:3b:30:2f:36], tid=0x6df500: the selected subnet details: 2001:db8:1:b::/64
Nov 22 16:00:20 dhcpradius kea-dhcp6[18922]: ERROR DHCP6_PACKET_PROCESS_STD_EXCEPTION exception occurred during packet processing: hwaddr length exceeds MAX_HWADDR_LEN
```
The request in this case was relayed and received via unicast by kea. The mac address of the client can be derived from the duid and the link-local address can be found in the log above.
**Contacting you**
Sending a message on github or replying in this ticket is ok.kea2.1.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2202Continue review/update of ARM hooks sections2021-12-03T18:01:43ZSuzanne GoldlustContinue review/update of ARM hooks sectionsOngoing review of the Kea ARM, focusing on the hooks-related sections (followup from #2139)Ongoing review of the Kea ARM, focusing on the hooks-related sections (followup from #2139)kea2.1.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/stork/-/issues/618build_kea_premium_container and run_kea_premium_container don't work because ...2021-12-03T07:27:36ZAndrei Pavelandrei@isc.orgbuild_kea_premium_container and run_kea_premium_container don't work because of renamed containers9e024d6e7448b7e1795038d0ac5d6697ea6cb1b1 renamed `agent-kea-hosts` to `agent-kea-premium` in some parts, but left it in others. As a result, `rake build_kea_hosts_container` and `rake run_kea_hosts_container` don't work anymore. This is ...9e024d6e7448b7e1795038d0ac5d6697ea6cb1b1 renamed `agent-kea-hosts` to `agent-kea-premium` in some parts, but left it in others. As a result, `rake build_kea_hosts_container` and `rake run_kea_hosts_container` don't work anymore. This is meant to finish the job.1.0Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3020netmgr/netmgr.c:1737: (...) failed2022-04-26T13:28:04ZNelson A. de Oliveiranetmgr/netmgr.c:1737: (...) failedHi!
I am seeing this for some internal DNS queries:
```
$ host www.unesp.br 200.145.86.1
Using domain server:
Name: 200.145.86.1
Address: 200.145.86.1#53
Aliases:
www.unesp.br has address 200.145.6.98
netmgr/netmgr.c:1737: REQUIRE(((...Hi!
I am seeing this for some internal DNS queries:
```
$ host www.unesp.br 200.145.86.1
Using domain server:
Name: 200.145.86.1
Address: 200.145.86.1#53
Aliases:
www.unesp.br has address 200.145.6.98
netmgr/netmgr.c:1737: REQUIRE((((handle) != ((void *)0) && ((const isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H') << 8 | ('D')))) && __extension__ ({ __auto_type __atomic_load_ptr = (&(handle)->references); __typeof__ ((void)0, *__atomic_load_ptr) __atomic_load_tmp; __atomic_load (__atomic_load_ptr, &__atomic_load_tmp, (5)); __atomic_load_tmp; }) > 0)) failed, back trace
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(+0x3552f)[0x7fae10e0f52f]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc_assertion_failed+0xa)[0x7fae10e0f48a]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc__nmhandle_attach+0x63)[0x7fae10df9aa3]
host(+0xe3aa)[0x55c5f12963aa]
host(+0xf2c7)[0x55c5f12972c7]
host(+0x1177b)[0x55c5f129977b]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc__nm_async_readcb+0xad)[0x7fae10dfce6d]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc__nm_readcb+0x97)[0x7fae10dfcf97]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(+0x30cd0)[0x7fae10e0acd0]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc__nm_udp_read_cb+0x46)[0x7fae10e0c4c6]
/usr/lib/x86_64-linux-gnu/libuv.so.1(+0x1ee8d)[0x7fae10956e8d]
/usr/lib/x86_64-linux-gnu/libuv.so.1(+0x22c75)[0x7fae1095ac75]
/usr/lib/x86_64-linux-gnu/libuv.so.1(uv_run+0x114)[0x7fae10947854]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(+0x247da)[0x7fae10dfe7da]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc__trampoline_run+0x16)[0x7fae10e36bd6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8eae)[0x7fae10b36eae]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fae10a66a5f]
zsh: IOT instruction (core dumped) host www.unesp.br 200.145.86.1
```
I hope that some of these files are helpful :-)
[core dump](/uploads/325a587af3cbf8c8862b554c57597f93/core-isc-net-0000.55659.neon.1637667477)
[gdb's "thread apply all bt full"](/uploads/56e9ac73d79041b0ed8606e102813b88/gdb.txt)
[tcpdump output](/uploads/60932dfe55240b848a0ef2902bae3289/tcpdump.txt)
This is also https://bugs.debian.org/1000447
If you need anything else, just let me know, please.
Thank you!April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3021dns_sdlz_putrr does not auto increase buffer2021-11-25T20:48:33ZRainer W.dns_sdlz_putrr does not auto increase buffer### Summary
dns_sdlz_putrr does not auto increase buffer
### BIND version used
9.16, but the in the current master the bug exists.
### Steps to reproduce
add dlz ldap support and create long dlzDomain
### What is the current *bug*...### Summary
dns_sdlz_putrr does not auto increase buffer
### BIND version used
9.16, but the in the current master the bug exists.
### Steps to reproduce
add dlz ldap support and create long dlzDomain
### What is the current *bug* behavior?
when "dns_rdata_fromtext: buffer-0x7f17cc6ea940:1: near '604800': ran out of space" is "detected" and buffer < 64k, dns_sdlz_putrr imediatly exits with DNS_R_SERVFAIL.
### What is the expected *correct* behavior?
loop in dns_sdlz_putrr to increase the buffer so parsing can happen.
### Relevant configuration files
-
### Relevant logs and/or screenshots
-
### Possible fixes
commenting out `result = DNS_R_SERVFAIL;` in https://gitlab.isc.org/isc-projects/bind9/-/blob/main/lib/dns/sdlz.c#L1855 fixes the issue.
As far as i understand the code in dns_sdlz_putrr it does run a while loop until the buffer had been increased enough so the input could be sucessfully parsed ( or 64k buffer size is reached).
But the line mentioned above does overwrite the result hard to DNS_R_SERVFAIL. Yes, only when `result != ISC_R_SUCCESS` but for my understanding a result ISC_R_NOSPACE will always be != ISC_R_SUCCESS, so the loop will never happen / is basically dead code.
Which in my case does break lookup, but removing the 1855 line enables the original buffer increment logic and a patched instance does loop a second time with an increased buffer and therefor can parse the dlz ldap input correctly and resolve sucessfully.
I'm not sure if just removing line 1855 is the correct solution. I would say 1866 does already handle the jump to failure: in case the result is != success.December 2021 (9.16.24, 9.16.24-S1, 9.17.21)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/kea/-/issues/2203Update doc about ways to get the config/build report2023-03-08T09:40:04ZFrancis DupontUpdate doc about ways to get the config/build reportThere are 2 or 3 ways to get the config/build report when the config.report file itself is not available:
- the -W command line argument
- a grep for ';;;;' on the extracted strings from the main binary
- when there is a control chann...There are 2 or 3 ways to get the config/build report when the config.report file itself is not available:
- the -W command line argument
- a grep for ';;;;' on the extracted strings from the main binary
- when there is a control channel the build-report command
All have different constraints: the first requires to run the binary, the second is more hairy but requires only access to the main binary, and the last requires a running binary but can be done remotely.
Unfortunately it seems this is not explained in the ARM for all Kea commands compiled from C++ so:
- the ARM must be updated
- each way should be checked (some failures were reported and fixed so do not assume they work)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2204Sanity checks for Kea 2.1.1 rc12021-11-24T20:28:34ZjenkinsSanity checks for Kea 2.1.1 rc1```
We are now at step SANITY CHECKS of Kea 2.1.1 rc1.
Please verify the packages and files according to "4. Sanity Checks" chapter on:
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks
and your imagination.
Be...```
We are now at step SANITY CHECKS of Kea 2.1.1 rc1.
Please verify the packages and files according to "4. Sanity Checks" chapter on:
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks
and your imagination.
Before starting any checks, please state what check you are doing in a
thread/discussion (not as comment) in Sanity Checks issue in GitLab:
None
When you finish given check state in the same thread/discussion what is the result.
This way we know what is covered upfront and we can avoid repeating ourselves.
Release content is located on:
1) [tarballs] repo.isc.org in the following folders:
/data/shared/sweng/kea/releases/2.1.1-rc1
/data/shared/sweng/kea/releases/premium-2.1.1-rc1
/data/shared/sweng/kea/releases/subscription-2.1.1-rc1
SHA256 (kea-2.1.1.tar.gz) = d787a629cd28b020b731dbbd599f5d5e40423decad89ea7e8526d00fb3289757
SHA256 (kea-premium-2.1.1.tar.gz) = e53a64dbd91c89972e4fd59311d2d0420606a5c53c07a0f6bb6845277889f037
SHA256 (kea-subscription-2.1.1.tar.gz) = 0da9e61dec3cb77b82c9ac5be61e7620d4c53dfd5bbdd2ec62e7e3cdcf0a2c47
2) APK, deb, RPM packages on packages.aws.isc.org, exact packages versions are stored here:
https://jenkins.aws.isc.org/job/kea-dev/job/pkg/632/
Release versions are:
APK: 2.1.1-r20211123204920: https://packages.aws.isc.org/#browse/search/raw=format%3Draw%20AND%20name.raw%3D*r20211123204920.apk
deb: 2.1.1-isc20211123204920: https://packages.aws.isc.org/#browse/search/apt=format%3Dapt%20AND%20version%3D2.1.1-isc20211123204920
RPM: 2.1.1-isc20211123204920.[os]: https://packages.aws.isc.org/#browse/search/yum=format%3Dyum%20AND%20version%3D2.1.1-isc20211123204920*
Installation instructions are here: https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks, chapter 4. Sanity Checks, point 9.
```https://gitlab.isc.org/isc-projects/bind9/-/issues/3022DoH: dig eventually aborts on ALPN negotiation failure when issuing a DoH que...2021-12-01T08:58:44ZArtem BoldarievDoH: dig eventually aborts on ALPN negotiation failure when issuing a DoH query (because of dangling handles)It was found by accident that `dig` crashes when issuing a query against a server which does not support HTTP/2, or to be more precise, when 'h2' ALPN token negotiation fails.
```
;; Connection to 127.0.0.1#44344(127.0.0.1) for example ...It was found by accident that `dig` crashes when issuing a query against a server which does not support HTTP/2, or to be more precise, when 'h2' ALPN token negotiation fails.
```
;; Connection to 127.0.0.1#44344(127.0.0.1) for example failed: ALPN for HTTP/2 failed.
;; Connection to 127.0.0.1#44344(127.0.0.1) for example failed: ALPN for HTTP/2 failed.
;; Connection to 127.0.0.1#44344(127.0.0.1) for example failed: ALPN for HTTP/2 failed.
Outstanding sockets
=================
Active server socket 0x7f172da91a00, type isc_nm_tlssocket, refs 1
Parent (nil), listener (nil), server (nil), statichandle = (nil)
Flags: closing
Created by:
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc___nmsocket_init+0x276)[0x7f1732594301]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc_nm_tlsconnect+0xb9)[0x7f17325fbfdb]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc_nm_httpconnect+0x89f)[0x7f17325f1ce2]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x18fb5)[0x560157b26fb5]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x1e20d)[0x560157b2c20d]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x14874)[0x560157b22874]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x1e2a6)[0x560157b2c2a6]
=================
Active server socket 0x7f172da93800, type isc_nm_tlssocket, refs 1
Parent (nil), listener (nil), server (nil), statichandle = (nil)
Flags: closing
Created by:
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc___nmsocket_init+0x276)[0x7f1732594301]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc_nm_tlsconnect+0xb9)[0x7f17325fbfdb]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc_nm_httpconnect+0x89f)[0x7f17325f1ce2]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x18fb5)[0x560157b26fb5]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x1e20d)[0x560157b2c20d]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x14874)[0x560157b22874]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x13dfd)[0x560157b21dfd]
=================
Active server socket 0x7f172da91000, type isc_nm_tlssocket, refs 1
Parent (nil), listener (nil), server (nil), statichandle = (nil)
Flags: closing
Created by:
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc___nmsocket_init+0x276)[0x7f1732594301]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc_nm_tlsconnect+0xb9)[0x7f17325fbfdb]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc_nm_httpconnect+0x89f)[0x7f17325f1ce2]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x18fb5)[0x560157b26fb5]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x1e20d)[0x560157b2c20d]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x14874)[0x560157b22874]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x13dfd)[0x560157b21dfd]
netmgr/netmgr.c:578: INSIST(0) failed, back trace
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(+0x42894)[0x7f17325b2894]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc_assertion_failed+0x31)[0x7f17325b27a7]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc__netmgr_destroy+0x10d)[0x7f173258f0d8]
/home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.17.20.so(isc_managers_destroy+0xf5)[0x7f17325ca823]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x1e815)[0x560157b2c815]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0xef35)[0x560157b1cf35]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0xef96)[0x560157b1cf96]
/usr/lib/libc.so.6(__libc_start_main+0xd5)[0x7f1731645b25]
/home/artem/projects/isc/open/bind9/bin/dig/.libs/lt-dig(+0x5e9e)[0x560157b13e9e]
Aborted (core dumped)
```December 2021 (9.16.24, 9.16.24-S1, 9.17.21)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3023auto-dnssec documented under options, only accepted under zone2022-01-05T11:26:18ZJohn W. O'Brienauto-dnssec documented under options, only accepted under zone<!--
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
`auto-dnssec` is documented under the grammar for the `options` statement, but can only be specified inside a `zone` statement.
### BIND version used
```
BIND 9.16.22 (Extended Support Version) <id:59bfaba>
running on FreeBSD amd64 12.2-RELEASE-p7 FreeBSD 12.2-RELEASE-p7 GENERIC
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr/local' '--with-readline=-L/usr/local/lib -ledit' '--with-dlz-filesystem=yes' '--enable-dnstap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--with-gssapi=/usr/local' 'CFLAGS=-I/usr/local/include -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS=-L/usr/local/lib -Wl,-rpath,/usr/local/lib:/usr/local/lib -L/usr/local/lib -ljson-c -fstack-protector-strong ' 'LIBS=-lkrb5 -lgssapi_krb5 -L/usr/local/lib' 'KRB5CONFIG=/usr/local/bin/krb5-config' '--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python' '--disable-querytrace' '--enable-tcp-fastopen' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.2' 'build_alias=amd64-portbld-freebsd12.2' 'CC=cc' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
compiled by CLANG FreeBSD Clang 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)
compiled with OpenSSL version: OpenSSL 1.1.1l 24 Aug 2021
linked to OpenSSL version: OpenSSL 1.1.1l 24 Aug 2021
compiled with libuv version: 1.42.0
linked to libuv version: 1.42.0
compiled with libxml2 version: 2.9.12
linked to libxml2 version: 20912
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.4.0
linked to protobuf-c version: 1.4.0
threads support is enabled
default paths:
named configuration: /usr/local/etc/namedb/named.conf
rndc configuration: /usr/local/etc/namedb/rndc.conf
DNSSEC root key: /usr/local/etc/namedb/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Set `auto-dnssec` under `options` and start or reload `named`.
### What is the current *bug* behavior?
The configuration is rejected as invalid.
### What is the expected *correct* behavior?
If the documentation is correct, this option should define the default setting for all subsequent zone definitions, just like `allow-transfer` and friends.
If the documentation is incorrect, specification of `auto-dnssec` should appear under "`zone` Statement Definition and Usage".
### Relevant configuration files
`named.conf`:
```
options {
auto-dnssec maintain; # or "allow"
};
```
### Relevant logs and/or screenshots
```
% sudo service named start
/usr/local/etc/namedb/named.conf:2: auto-dnssec may only be activated at the zone level
/usr/local/etc/rc.d/named: ERROR: named-checkconf for /usr/local/etc/namedb/named.conf failed
```
### Possible fixes
* [Config validation check](https://gitlab.isc.org/isc-projects/bind9/-/blob/v9_16_22/lib/bind9/check.c#L1304-1319)
* [`auto-dnssec` in ARM](https://gitlab.isc.org/isc-projects/bind9/-/blob/v9_16_22/doc/arm/reference.rst#L2023-2044)January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2205CI job to detect that dhcpdb_create scripts and upgrade scripts are in sync2022-01-21T12:30:22ZAndrei Pavelandrei@isc.orgCI job to detect that dhcpdb_create scripts and upgrade scripts are in syncInconsistencies between dhcpdb_create scripts and upgrade scripts have been slipping MRs lately. The proposition is to prevent these in CI.Inconsistencies between dhcpdb_create scripts and upgrade scripts have been slipping MRs lately. The proposition is to prevent these in CI.kea2.1.2Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3024doh_connect_makeuri fails on illumos2021-11-25T19:56:15ZMichal Nowakdoh_connect_makeuri fails on illumosCompiling `doh_test` (5069b58dc9dfa570fc306d9ed7d89a1e1d1c46fc) with GCC 10.3.0 on OpenIndiana 2021.10 (`illumos-ee57561bf1`) produces warning and the `doh_connect_makeuri` test fails:
```
/usr/gcc/10/bin/gcc -DHAVE_CONFIG_H -I. -I../../...Compiling `doh_test` (5069b58dc9dfa570fc306d9ed7d89a1e1d1c46fc) with GCC 10.3.0 on OpenIndiana 2021.10 (`illumos-ee57561bf1`) produces warning and the `doh_connect_makeuri` test fails:
```
/usr/gcc/10/bin/gcc -DHAVE_CONFIG_H -I. -I../../.. -D_FORTIFY_SOURCE=2 -include ../../../config.h -I./include -I../../../include -I../../../lib/isc/include -I../../../lib/isc/include -DNAMED_PLUGINDIR=\"/usr/lib/dns/amd64/named\" -DSKIPPED_TEST_EXIT_CODE=77 -DTESTS_DIR=\"/export/home/newman/bind9/lib/isc/tests\" -I/usr/openssl/1.0/include -Wall -Wextra -Wwrite-strings -Wpointer-arith -Wno-missing-field-initializers -Wformat -Wshadow -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=format-security -Werror=parentheses -Werror=implicit -Werror=strict-prototypes -fno-strict-aliasing -fno-delete-null-pointer-checks -fdiagnostics-show-option -fsanitize=undefined -m64 -D_XOPEN_SOURCE=600 -D__EXTENSIONS__=1 -D_XPG6 -fno-omit-frame-pointer -fno-optimize-sibling-calls -O1 -g -Wall -Wextra -D_POSIX_PTHREAD_SEMANTICS -pthread -MT doh_test-doh_test.o -MD -MP -MF .deps/doh_test-doh_test.Tpo -c -o doh_test-doh_test.o `test -f 'doh_test.c' || echo './'`doh_test.c
doh_test.c: In function 'doh_connect_makeuri':
doh_test.c:2069:31: warning: missing braces around initializer [-Wmissing-braces]
2069 | struct in_addr localhostv4 = { ntohl(INADDR_LOOPBACK) };
| ^
| {{ }}
```
```
[ RUN ] doh_connect_makeuri
[ ERROR ] --- strcmp("https://127.0.0.1:443/dns-query", uri) == 0
[ LINE ] --- doh_test.c:2079: error: Failure!
[ FAILED ] doh_connect_makeuri
```December 2021 (9.16.24, 9.16.24-S1, 9.17.21)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/kea/-/issues/2206bump version to 2.1.2-git2022-01-25T11:28:18ZAndrei Pavelandrei@isc.orgbump version to 2.1.2-gitkea2.1.2Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2207Correct Kea ARM auth option code is 11, not 10.2022-01-10T11:11:16ZTomek MrugalskiCorrect Kea ARM auth option code is 11, not 10.As pointed out during a recent discussion, the option code in Kea ARM for auth option is incorrect. Says 10, should be 11.As pointed out during a recent discussion, the option code in Kea ARM for auth option is incorrect. Says 10, should be 11.kea2.1.2Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2208Make forensic log timestamp configurable2022-01-21T16:55:00ZPeter DaviesMake forensic log timestamp configurableThis is a tracking ticket to ensure we don't forget merge requests originating from the 19485-kea-premium tracking branch.
[RT 19485](https://support.isc.org/Ticket/Display.html?id=19485)This is a tracking ticket to ensure we don't forget merge requests originating from the 19485-kea-premium tracking branch.
[RT 19485](https://support.isc.org/Ticket/Display.html?id=19485)kea2.1.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3025Document how rate limiting uses DNS cookies.2022-01-12T10:13:31ZBjörn PerssonDocument how rate limiting uses DNS cookies.The reference manual gives the impression that rate limiting ignores DNS cookies. My experiments show that clients that support DNS cookies are sent server cookies instead of truncated responses, and clients that present a valid server c...The reference manual gives the impression that rate limiting ignores DNS cookies. My experiments show that clients that support DNS cookies are sent server cookies instead of truncated responses, and clients that present a valid server cookie are exempted from rate limiting. This is great, but it should be documented.
Here's a patch to document the behaviour as I understand it from my observations. It might be good if someone who knows the code would fact-check this.
[0001-Document-how-rate-limiting-uses-DNS-cookies.patch](/uploads/23a25512fa614d38bde831378f9bbc02/0001-Document-how-rate-limiting-uses-DNS-cookies.patch)January 2022 (9.16.25, 9.16.25-S1, 9.17.22)https://gitlab.isc.org/isc-projects/stork/-/issues/619Connect to agent over IPv6 link-local address2021-11-30T14:28:16ZSlawek FigielConnect to agent over IPv6 link-local addressThe connection between Stork Agent and Stork Server doesn't work when the Agent uses a link-local IPv6 address.
The Stork Server rejects this address during validation. But even if the validation will change there is one more problem.
...The connection between Stork Agent and Stork Server doesn't work when the Agent uses a link-local IPv6 address.
The Stork Server rejects this address during validation. But even if the validation will change there is one more problem.
The apps in the Stork Server use schema `APPNAME@AGENTADDRESS%NUM`. The NUM is sequential and optional.
The zone ID in the link-local address (e.g. `fe80::%eth0`) is recognized as an app number. Additionally, the validator denies multiple app numbers in the name.
The validation is implemented partially as the database triggers.backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3026premature TCP connection closure leaks fetch contexts (hang on shutdown)2021-12-06T09:52:36ZPetr Špačekpspacek@isc.orgpremature TCP connection closure leaks fetch contexts (hang on shutdown)### Summary
An error in error handling code causes resource leaks when an authoritative server closes TCP connection without responding. This ultimately leads to hang on shutdown.
### BIND version used
* ~v9.17: 6bd1e6de94dd096618e842...### Summary
An error in error handling code causes resource leaks when an authoritative server closes TCP connection without responding. This ultimately leads to hang on shutdown.
### BIND version used
* ~v9.17: 6bd1e6de94dd096618e8428234044143273e3c23 is affected
* ~v9.11 and ~v9.16 are not affected.
### Steps to reproduce
1. Force resolver to contact an authoritative server which closes TCP connection without responding.
2. Shutdown the resolver and observe hang.
3. Repeat if it did not reproduce on first try.
#### Commands & files
* [localhost.test.zone](/uploads/6d8f7be4f65bcef92fa6903b1794245f/localhost.test.zone) - a zone with delegation to localhost
* [named.conf](/uploads/39e480d6917016ed0145b218f3fc3e14/named.conf) - config for resolver to load the delegation
* [udpresp.py](/uploads/95c4634a93727b39c148e725ed99888d/udpresp.py) - UDP responder which always responds with TC=1
* [tcpresp.py](/uploads/54eed74b8a872fefa47235eb2e5ce5b8/tcpresp.py) - TCP responder which keeps the connection open for couple seconds after accept() and then closes the connection without replying
1. Run `named -g -c named.conf -d 99`
2. Run `python3 udpresp.py &`
3. Run `python3 tcpresp.py &`
4. Run `dig @::1 -p 5300 sub.localhost.test.`
5. Attempt to shutdown the named process
### What is the current *bug* behavior?
Fetch context leaks and resolver hangs on shutdown. [Investigation by @michal](https://mattermost.isc.org/isc/pl/oisjr5r7bjnatnya9igekec7ky):
AFAICT, the bug lies in the ISC_R_CONNECTIONRESET case for a TCP dispatch. in short, when tcp_recv() is called with ISC_R_CONNECTIONRESET, execution jumps here:
```c
743 if (resp != NULL) {
744 /* We got a matching response, or timed out */
745 resp->response(eresult, region, resp->arg);
746 dispentry_detach(&resp);
747 } else {
748 /* We're being shut down; cancel all outstanding resps */
749 for (resp = ISC_LIST_HEAD(resps); resp != NULL; resp = next) {
750 next = ISC_LIST_NEXT(resp, rlink);
751 ISC_LIST_UNLINK(resps, resp, rlink);
752 resp->response(ISC_R_SHUTTINGDOWN, region, resp->arg);
753 dispentry_detach(&resp);
754 }
755 }
```
however, in this case, resp is NULL and resps is an empty list, which means resp->response (the resolver callback, resquery_response()) is not called, preventing the last reference on the query from being detached and therefore preventing the whole fetch context from shutting down.
if I am right, it should be easy to reproduce with a toy auth server which forces a named resolver to retry a UDP query over TCP and then resets the TCP connection after it gets established. this should result in the fetch context hanging around.
### What is the expected *correct* behavior?
Well, it does not leak resources and does not hang on shutdown.
### Relevant configuration files
It's not configuration specific, configuration in the reproducer is just for convenience.December 2021 (9.16.24, 9.16.24-S1, 9.17.21)https://gitlab.isc.org/isc-projects/kea/-/issues/2209reservation-get-by-hostname: subnet-id not in response if it is in request2022-06-30T09:53:14ZAndrei Pavelandrei@isc.orgreservation-get-by-hostname: subnet-id not in response if it is in requestExpected `subnet-id` to be contained in response regardless of arguments.
This is useful when users switch between API calls and they expect the response to be the same when, for example, they parse the response or they chain API calls.Expected `subnet-id` to be contained in response regardless of arguments.
This is useful when users switch between API calls and they expect the response to be the same when, for example, they parse the response or they chain API calls.kea2.1.7Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2210document why DUID can be used in DHCPv42021-12-16T10:52:22ZAndrei Pavelandrei@isc.orgdocument why DUID can be used in DHCPv4Discovered specifically in the reservation-get-by-id command. It was confusing for me at first when I first met this situation. I thought DUID was DHCPv6-specific.Discovered specifically in the reservation-get-by-id command. It was confusing for me at first when I first met this situation. I thought DUID was DHCPv6-specific.kea2.1.2Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.org