ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2019-07-30T13:34:10Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1142RNDC test hangs on Windows2019-07-30T13:34:10ZStephen MorrisRNDC test hangs on WindowsTests with the putative V9.15.2 release appear to show the RNDC test hanging on Windows, immediately after issuing the message:
```
I:rndc:testing rndc with hmac-md5 (21)
```Tests with the putative V9.15.2 release appear to show the RNDC test hanging on Windows, immediately after issuing the message:
```
I:rndc:testing rndc with hmac-md5 (21)
```BIND 9.15.3https://gitlab.isc.org/isc-projects/dhcp/-/issues/33Fix dhcpd/dhcrelay in v6 mode operation on OpenBSD2019-11-18T16:18:43ZBrad SmithFix dhcpd/dhcrelay in v6 mode operation on OpenBSDThe linked diff has been in our tree for quite awhile. It fixes v6 mode operation of dhcpd/dhcrelay on OpenBSD.
sin6_scope_id needs to be set not just for dhclient but also for dhcpd/dhcrelay.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~c...The linked diff has been in our tree for quite awhile. It fixes v6 mode operation of dhcpd/dhcrelay on OpenBSD.
sin6_scope_id needs to be set not just for dhclient but also for dhcpd/dhcrelay.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/net/isc-dhcp/patches/patch-common_socket_c?rev=1.7&content-type=text/plain&hideattic=14.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1140dig sends \0 to itself on every run via udp/v62020-03-18T13:54:57ZGhost Userdig sends \0 to itself on every run via udp/v6<!--
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
Dig sends a UDP v6 packet with the payload \0 to itself (as it seems) every time it is being executed. The packets are being dropped and are flooding our logs. Dig works anyway so I suspect this is a bug.
Truss output:
getsockname(6,{ AF_INET6 [2a02:c00:8000::ac11:9438]:53121 },0x7fff7fffd9e8) = 0 (0x0)
sendmsg(6,{{ AF_INET6 [2a02:c00:8000::ac11:9438]:53121 },28,[{"\0",1}],1, \
{{level=IPPROTO_IPV6,type=IPV6_TCLASS,data={0xb8,0x00,0x00,0x00}}},24,0},0) = 1 (0x1)
Source and destination ports are always the same but random:
11:20:13.119122 IP6 2a02:c00:8000::ac11:9438.14634 > 2a02:c00:8000::ac11:9438.14634: UDP, length 1
### BIND version used
```
named -V
BIND 9.11.7 (Extended Support Version) <id:084ef47>
running on FreeBSD amd64 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 #0: Thu Sep 27 08:16:24 UTC 2018 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
built by make with '--localstatedir=/var' '--disable-linux-caps' '--with-randomdev=/dev/random' '--with-libxml2=/usr/local' '--with-readline=-L/usr/local/lib -ledit' '--with-dlopen=yes' '--with-gost=no' '--without-python' '--sysconfdir=/usr/local/etc/namedb' '--with-dlz-filesystem=yes' '--disable-dnstap' '--disable-filter-aaaa' '--disable-fixed-rrset' '--without-gssapi' '--with-libidn2=/usr/local' '--enable-ipv6' '--without-libjson' '--disable-largefile' '--without-lmdb' '--disable-native-pkcs11' '--disable-querytrace' '--enable-rpz-nsdname' '--enable-rpz-nsip' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--with-openssl=/usr/local' '--enable-threads' '--with-tuning=default' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd11.2' 'build_alias=amd64-portbld-freebsd11.2' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -Wl,-rpath,/usr/local/lib -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp'
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 6.0.0 (tags/RELEASE_600/final 326565)
compiled with OpenSSL version: OpenSSL 1.0.2r 26 Feb 2019
linked to OpenSSL version: OpenSSL 1.0.2r 26 Feb 2019
compiled with libxml2 version: 2.9.8
linked to libxml2 version: 20908
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
```
### Steps to reproduce
Execute some random dns query with dig.
### What is the current *bug* behavior?
Dig issues suspicious packets.
### What is the expected *correct* behavior?
It should only send dns queries.https://gitlab.isc.org/isc-projects/bind9/-/issues/1139!1952 Breaks Windows Build2019-07-10T13:18:25ZThomas Jach!1952 Breaks Windows Build@wpk, The Windows build fails after !1952. The patch below (based on commit 3cf11418b57abcb4c9c37c2fa09b5365779804bf) resolves the issue. Maybe you can have a look?
```
diff --git a/lib/isc/win32/socket.c b/lib/isc/win32/socket.c
index ...@wpk, The Windows build fails after !1952. The patch below (based on commit 3cf11418b57abcb4c9c37c2fa09b5365779804bf) resolves the issue. Maybe you can have a look?
```
diff --git a/lib/isc/win32/socket.c b/lib/isc/win32/socket.c
index 995261ede0..c612fdffa3 100644
--- a/lib/isc/win32/socket.c
+++ b/lib/isc/win32/socket.c
@@ -55,6 +55,7 @@
#include <isc/os.h>
#include <isc/platform.h>
#include <isc/print.h>
+#include <isc/refcount.h>
#include <isc/region.h>
#include <isc/socket.h>
#include <isc/stats.h>
@@ -393,7 +394,7 @@ sock_dump(isc_socket_t *sock) {
printf("\n\t\tSock Dump\n");
printf("\t\tfd: %Iu\n", sock->fd);
printf("\t\treferences: %" PRIuFAST32 "\n",
- isc_refcount_current(sock->references));
+ isc_refcount_current(&sock->references));
printf("\t\tpending_accept: %u\n", sock->pending_accept);
printf("\t\tconnecting: %u\n", sock->pending_connect);
printf("\t\tconnected: %u\n", sock->connected);
@@ -1450,7 +1451,7 @@ maybe_free_socket(isc_socket_t **socketp, int lineno) {
|| sock->pending_recv > 0
|| sock->pending_send > 0
|| sock->pending_accept > 0
- || isc_refcount_current(sock->references) > 0
+ || isc_refcount_current(&sock->references) > 0
|| sock->pending_connect == 1
|| !ISC_LIST_EMPTY(sock->recv_list)
|| !ISC_LIST_EMPTY(sock->send_list)
@@ -1543,7 +1544,7 @@ socket_create(isc_socketmgr_t *manager, int pf, isc_sockettype_t type,
"con_reset_fix_failed",
sock->pending_recv,
sock->pending_send,
- isc_refcount_current(sock->references));
+ isc_refcount_current(&sock->references));
closesocket(sock->fd);
_set_state(sock, SOCK_CLOSED);
sock->fd = INVALID_SOCKET;
@@ -1595,7 +1596,7 @@ socket_create(isc_socketmgr_t *manager, int pf, isc_sockettype_t type,
socket_log(__LINE__, sock, NULL, EVENT,
"closed %d %d %" PRIuFAST32 " make_nonblock_failed",
sock->pending_recv, sock->pending_send,
- isc_refcount_current(sock->references));
+ isc_refcount_current(&sock->references));
closesocket(sock->fd);
sock->fd = INVALID_SOCKET;
free_socket(&sock, __LINE__);
@@ -1739,7 +1740,7 @@ isc_socket_attach(isc_socket_t *sock, isc_socket_t **socketp) {
void
isc_socket_detach(isc_socket_t **socketp) {
isc_socket_t *sock;
- uint32_t refs;
+ uint32_t references;
REQUIRE(socketp != NULL);
sock = *socketp;
@@ -1748,12 +1749,12 @@ isc_socket_detach(isc_socket_t **socketp) {
LOCK(&sock->lock);
CONSISTENT(sock);
- references = isc_refcount_decrement(&socket->references);
+ references = isc_refcount_decrement(&sock->references);
socket_log(__LINE__, sock, NULL, EVENT,
"detach_socket %d %d %" PRIuFAST32,
sock->pending_recv, sock->pending_send,
- isc_refcount_current(sock->references));
+ isc_refcount_current(&sock->references));
if (references == 1 && sock->fd != INVALID_SOCKET) {
closesocket(sock->fd);
@@ -2488,7 +2489,6 @@ isc_socketmgr_create2(isc_mem_t *mctx, isc_socketmgr_t **managerp,
unsigned int maxsocks, int nthreads)
{
isc_socketmgr_t *manager;
- isc_result_t result;
REQUIRE(managerp != NULL && *managerp == NULL);
@@ -3675,7 +3675,7 @@ isc_socketmgr_renderxml(isc_socketmgr_t *mgr, void *writer0)
TRY0(xmlTextWriterStartElement(writer,
ISC_XMLCHAR "references"));
TRY0(xmlTextWriterWriteFormatString(writer, "%" PRIuFAST32,
- isc_refcount_current(sock->references)));
+ isc_refcount_current(&sock->references)));
TRY0(xmlTextWriterEndElement(writer));
TRY0(xmlTextWriterWriteElement(writer, ISC_XMLCHAR "type",
```https://gitlab.isc.org/isc-projects/kea/-/issues/729commitRuntimeOptionDefs is called in ctrl_dhcp6_srv.cc and not in ctrl_dhcp4_...2019-09-06T09:03:42ZRazvan BecheriucommitRuntimeOptionDefs is called in ctrl_dhcp6_srv.cc and not in ctrl_dhcp4_srv.ccthe v4 implementation does not call commitRuntimeOptionDefs after loading config as v6 does.the v4 implementation does not call commitRuntimeOptionDefs after loading config as v6 does.kea1.7.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/728createAnswer uses hard coded value instead of define2023-03-24T10:12:54ZRazvan BecheriucreateAnswer uses hard coded value instead of definethere are a lot of places in the code where createAnswer uses hard coded values instead of defines:
CONTROL_RESULT_SUCCESS
CONTROL_RESULT_ERROR
CONTROL_RESULT_COMMAND_UNSUPPORTEDthere are a lot of places in the code where createAnswer uses hard coded values instead of defines:
CONTROL_RESULT_SUCCESS
CONTROL_RESULT_ERROR
CONTROL_RESULT_COMMAND_UNSUPPORTEDbacklogRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1138From Bugs (#43718) : extend nsip-wait-recurse or add nsdname-wait-recurse2022-01-17T13:24:02ZCathy AlmondFrom Bugs (#43718) : extend nsip-wait-recurse or add nsdname-wait-recurseFrom [BUGS feature request #43718](https://bugs.isc.org/Ticket/Display.html?id=43718)
tl;dr - we should expect there to be similar need with NSDNAME triggers
as there was with NSIP triggers, even if no one has asked for it yet.
On 2016...From [BUGS feature request #43718](https://bugs.isc.org/Ticket/Display.html?id=43718)
tl;dr - we should expect there to be similar need with NSDNAME triggers
as there was with NSIP triggers, even if no one has asked for it yet.
On 2016-11-23 08:41, vjs wrote:
>>>> On the other hand, NSDNAME wasn't requested and I don't think I've ever
>>>> seen an NSDNAME rule outside of an example..
>>>
>>> What about many of the wildcards in rpz.spamhaus.org?
>>
>> The only rpz.spamhaus.org zone I've seen in detail is dbl, and it didn't
>> have any at the time.
>
> The Spamhaus RPZ zone published as the rpz.spamhaus.org contains about
> 3.8 million pairs of domains and wildcards. While none of those records
> are NSDNAME RPZ triggers, they all seem to me prime candidates for
> being additionally written as NSDNAME triggers.
>
> It would be unconfortable to double the current 192 MByte text size
> of that zone by adding all of those NSDNAME RPZ rules. However, Fastrpz
> supports two directives that help. "ip-as-ns yes_or_no" and especially
> "qname-as-ns yes_or_no" do what I hope their names suggest.
> As might be guessed, I think those two directives should be added
> to BIND RPZ.
>
> I should also mention that I did not invent NSDNAME, but added it
> at the explicit request of RPZ users. Maybe over the years those who
> asked have stopped using NSDNAME, but I doubt it.
DO we need this?
( Interest expressed in Support ticket [#14957](https://support.isc.org/Ticket/Display.html?id=14957) )April 2020 (9.11.18, 9.16.2, 9.17.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/1137Inconsistent XFR behavior with builtin empty zones2021-10-04T19:41:35ZGhost UserInconsistent XFR behavior with builtin empty zones### Summary
Using `database "_builtin empty ...;` results in inconstant behavior between AXFR and IXFR. Additionally, the IXFR results with dig are inconsistent with standard transfers. (These are very minor issues, and perhaps more inte...### Summary
Using `database "_builtin empty ...;` results in inconstant behavior between AXFR and IXFR. Additionally, the IXFR results with dig are inconsistent with standard transfers. (These are very minor issues, and perhaps more interesting than anything else.)
Related issue: `_builtin empty` is not documented in the ARM.
### BIND version used
9.14.3. The issue was also seen in a 9.12.X version.
### Steps to reproduce
#### Entire named.conf:
>options { directory "/etc/namedb"; };
>
>zone "cnn.com" { type master; database "_builtin empty x.invalid. TedTurner"; };
#### Checking the SOA and NS RRs gets non-problematic results.
> dig +noall +answer @127.1 soa cnn.com
>
> cnn.com. 86400 IN SOA x.invalid. TedTurner.cnn.com. 0 28800 7200 604800 86400
>
> dig +noall +answer @127.1 ns cnn.com
>
> cnn.com. 0 IN NS x.invalid.
#### AXFR is denied, which is just fine.
> dig +noall +answer @127.1 axfr cnn.com
>
> ; Transfer failed.
>
#### IXFR is not denied, an inconsistency. Furthermore, the response contains the SOA, but not the NS record. Finally, the SOA comes only once, not both before and after all the other RRs as is standard.
> dig @127.1 ixfr=1 cnn.com
>
>; <<>> DiG 9.14.3 <<>> @127.1 ixfr=1 cnn.com
>
>; (1 server found)
>
>;; global options: +cmd
>
>cnn.com. 86400 IN SOA x.invalid. TedTurner.cnn.com. 0 28800 7200 604800 86400
>
>;; Query time: 0 msec
>
>;; SERVER: 127.0.0.1#53(127.0.0.1)
>
>;; WHEN: Tue Jul 09 16:48:27 CEST 2019
>
>;; XFR size: 1 records (messages 1, bytes 119)
### What is the current *bug* behavior?
Shown above.
### What is the expected *correct* behavior?
The easiest solution would be for IXFR to result in a failed transfer like AXFR.
A short blurb in the ARM about the using the _builtin empty would be a good idea.
### Relevant configuration files
Shown above.https://gitlab.isc.org/isc-projects/bind9/-/issues/1136named-checkconf should report missing dnstap-output option when dnstap option...2019-09-12T09:19:14ZGhost Usernamed-checkconf should report missing dnstap-output option when dnstap option is set### Description
named-checkconf reports no errors, but named will not start.
The option "dnstap" requires "dnstap-output" to also be present, but named-checkconf does not discover/report the unloadable configuration.
>
> **named-check...### Description
named-checkconf reports no errors, but named will not start.
The option "dnstap" requires "dnstap-output" to also be present, but named-checkconf does not discover/report the unloadable configuration.
>
> **named-checkconf; echo $?**
>
> 0
>
> **named -g 2>&1 | tail -4**
>
> 09-Jul-2019 16:05:14.735 automatic empty zone: HOME.ARPA
>
> 09-Jul-2019 16:05:14.735 'dnstap-output' must be set if 'dnstap' is set: not found
>
> 09-Jul-2019 16:05:14.735 loading configuration: not found
>
> 09-Jul-2019 16:05:14.735 exiting (due to fatal error)
>
> #
>
### Request
An rndc-checkconf error message.
### Links / references
BIND 9.14.3
Config:
> named-checkconf -p
>
> options {
>
> directory "/etc/namedb";
>
> dnstap { client; auth; };
>
> recursion yes;
>
> };https://gitlab.isc.org/isc-projects/bind9/-/issues/1135named can be started multiple times2021-10-04T19:41:02ZGhost Usernamed can be started multiple times### Summary
named will start multiple times. Several years ago based on a feature request from Carsten Strotmann, code was added that only allowed it to start once, and a second attempt at starting would fail with exit status=1.
The ne...### Summary
named will start multiple times. Several years ago based on a feature request from Carsten Strotmann, code was added that only allowed it to start once, and a second attempt at starting would fail with exit status=1.
The new situation is more problematic than the one Carsten reported. Then, if named was started and then a new named process was begun, the second would fail to listen on all ports, and could not be communicated with using rndc. Now, the second named can be reached with rndc after the first process is stopped, and it may listed ports and respond to queries. (May means I saw that behavior, but haven't documented it.)
### BIND version used
Problem version: 9.14.3 (demoed below) Also seen in 9.14.2
Problem does not appear in: BIND 9.12.3
```
# named -V
BIND 9.14.3 (Stable Release) <id:896acdc>
running on Linux x86_64 4.11.12-100.fc24.x86_64 #1 SMP Fri Jul 21 17:35:20 UTC 2017
built by make with '--sysconfdir=/etc/namedb' '--enable-dnstap'
compiled by GCC 8.3.0
compiled with OpenSSL version: OpenSSL 1.1.1c 28 May 2019
linked to OpenSSL version: OpenSSL 1.1.1c 28 May 2019
threads support is enabled
default paths:
named configuration: /etc/namedb/named.conf
rndc configuration: /etc/namedb/rndc.conf
DNSSEC root key: /etc/namedb/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
# named is initially not running
```
# ps -ef | grep named | grep -v grep
# named
# named is process 15662
#ps -ef | grep named | grep -v grep
root 15662 1 1 15:13 ? 00:00:00 named
```
# note the time named was last configured: 13:13:23
```
# rndc status | grep last
last configured: Tue, 09 Jul 2019 13:13:23 GMT
```
# ss reports that named (proc 15662) has 11 sockets open
```
# ss -ltunp | grep named | sed 's/ *$//'
udp UNCONN 0 0 192.168.53.111:53 0.0.0.0:* users:(("named",pid=15662,fd=517))
udp UNCONN 0 0 192.168.53.111:53 0.0.0.0:* users:(("named",pid=15662,fd=516))
udp UNCONN 0 0 127.0.0.1:53 0.0.0.0:* users:(("named",pid=15662,fd=515))
udp UNCONN 0 0 127.0.0.1:53 0.0.0.0:* users:(("named",pid=15662,fd=514))
udp UNCONN 0 0 [::]:53 [::]:* users:(("named",pid=15662,fd=512))
udp UNCONN 0 0 [::]:53 [::]:* users:(("named",pid=15662,fd=513))
tcp LISTEN 0 10 192.168.53.111:53 0.0.0.0:* users:(("named",pid=15662,fd=23))
tcp LISTEN 0 10 127.0.0.1:53 0.0.0.0:* users:(("named",pid=15662,fd=22))
tcp LISTEN 0 128 127.0.0.1:953 0.0.0.0:* users:(("named",pid=15662,fd=24))
tcp LISTEN 0 10 [::]:53 [::]:* users:(("named",pid=15662,fd=21))
tcp LISTEN 0 128 [::1]:953 [::]:* users:(("named",pid=15662,fd=25))
```
# Starting named a second time succeeds.
```
# named
# echo $?
0
# ps -ef | grep named | grep -v grep
root 15662 1 0 15:13 ? 00:00:00 named
root 15803 1 0 15:26 ? 00:00:00 named
```
# Now the weird part. The second process succeeded in listening on the same ports as the first process.
```
# ss -ltunp | grep named | sed 's/ *$//'
udp UNCONN 0 0 192.168.53.111:53 0.0.0.0:* users:(("named",pid=15803,fd=517))
udp UNCONN 0 0 192.168.53.111:53 0.0.0.0:* users:(("named",pid=15803,fd=516))
udp UNCONN 0 0 127.0.0.1:53 0.0.0.0:* users:(("named",pid=15803,fd=515))
udp UNCONN 0 0 127.0.0.1:53 0.0.0.0:* users:(("named",pid=15803,fd=514))
udp UNCONN 0 0 192.168.53.111:53 0.0.0.0:* users:(("named",pid=15662,fd=517))
udp UNCONN 0 0 192.168.53.111:53 0.0.0.0:* users:(("named",pid=15662,fd=516))
udp UNCONN 0 0 127.0.0.1:53 0.0.0.0:* users:(("named",pid=15662,fd=515))
udp UNCONN 0 0 127.0.0.1:53 0.0.0.0:* users:(("named",pid=15662,fd=514))
udp UNCONN 0 0 [::]:53 [::]:* users:(("named",pid=15662,fd=512))
udp UNCONN 0 0 [::]:53 [::]:* users:(("named",pid=15662,fd=513))
udp UNCONN 0 0 [::]:53 [::]:* users:(("named",pid=15803,fd=512))
udp UNCONN 0 0 [::]:53 [::]:* users:(("named",pid=15803,fd=513))
tcp LISTEN 0 10 192.168.53.111:53 0.0.0.0:* users:(("named",pid=15803,fd=23))
tcp LISTEN 0 10 127.0.0.1:53 0.0.0.0:* users:(("named",pid=15803,fd=22))
tcp LISTEN 0 10 192.168.53.111:53 0.0.0.0:* users:(("named",pid=15662,fd=23))
tcp LISTEN 0 10 127.0.0.1:53 0.0.0.0:* users:(("named",pid=15662,fd=22))
tcp LISTEN 0 128 127.0.0.1:953 0.0.0.0:* users:(("named",pid=15803,fd=24))
tcp LISTEN 0 128 127.0.0.1:953 0.0.0.0:* users:(("named",pid=15662,fd=24))
tcp LISTEN 0 10 [::]:53 [::]:* users:(("named",pid=15662,fd=21))
tcp LISTEN 0 10 [::]:53 [::]:* users:(("named",pid=15803,fd=21))
tcp LISTEN 0 128 [::1]:953 [::]:* users:(("named",pid=15662,fd=25))
tcp LISTEN 0 128 [::1]:953 [::]:* users:(("named",pid=15803,fd=25))
```
# NOTE: I would have thought this was an operating environment failure, except that with the same environment, BIND 9.12.3 does not start a second time.
# **AND NOW THE PROBLEM.** Run rndc status over and over again, and sometimes it will connect with one process, sometime with the other. We notice this with different "last configured" timestamps. Keep repeating the command until it shows connecting with both processes:
```
# rndc status | grep last
last configured: Tue, 09 Jul 2019 13:13:23 GMT
# rndc status | grep last
last configured: Tue, 09 Jul 2019 13:13:23 GMT
# rndc status | grep last
last configured: Tue, 09 Jul 2019 13:26:04 GMT
# rndc status | grep last
last configured: Tue, 09 Jul 2019 13:26:04 GMT
# rndc status | grep last
last configured: Tue, 09 Jul 2019 13:13:23 GMT
#
```
# Not shown, but when this problem will effect queries as well. Some go to one process, some to the other. That was to debug.
### What is the current *bug* behavior?
Because some queries and some rndc commands go to one process, and some to another, this is inconsistent results from the same server (where server is defined as a machine, not a process).
### What is the expected *correct* behavior?
named should not start twice.
As an extra request, I recommend it should put out an error to STDERR. A second invocation of named will almost always be manual from the CLI. Therefore, output to STDERR is very useful. This contrasts to error and warning messages when named is started automatically. Possible message:
named: Another instance is already running. Not starting.
### Relevant configuration files
N/Ahttps://gitlab.isc.org/isc-projects/kea/-/issues/727Reservation client-classes too late/later as documented for depending classes2019-08-15T15:09:28ZChrisReservation client-classes too late/later as documented for depending classes**Describe the bug**
Client classes that are applied from a reservation are added too late to `test` against except for `only-if-required` classes, even when also depending on `KNOWN` (despite of what the NOTE in [Kea Guide 8.3.6](https...**Describe the bug**
Client classes that are applied from a reservation are added too late to `test` against except for `only-if-required` classes, even when also depending on `KNOWN` (despite of what the NOTE in [Kea Guide 8.3.6](https://ftp.isc.org/isc/kea/1.5.0/doc/kea-guide.html#reservation4-client-classes) says).
**To Reproduce**
Steps to reproduce the behavior:
1. Run Kea dhcpv4 with config:
```json[kea-reservation.log](/uploads/282012d6ad4a49c58157219f47d511c7/kea-reservation.log)[kea-reservation.log](/uploads/8b88984ba62689b6768b146dd13dbb7f/kea-reservation.log)
"client-classes": [
{
"name": "pxe"
},
{
"name": "ipxe",
"test": "member('KNOWN') and (option[77].hex == 'iPXE') and member('pxe')",
"boot-file-name": "http://ipxe.example.com/menu.php"
},
{
"name": "not_ipxe",
"next-server": "192.168.100.6",
"boot-file-name": "undionly.kpxe"
}
]
```
MySQL hosts reservation:
```
+--------------+----------+----------------------+
| ipv4_address | hostname | dhcp4_client_classes |
+--------------+----------+----------------------+
| 167837702 | pxetest | pxe,testing |
+--------------+----------+----------------------+
```
2. Logging set kea-dhcp4 to DEBUG, debuglevel 55
3. Client "pxetest" is booted with iPXE
4. Client "pxetest" does not get boot-file-name/added to class `pxe` in time to eval true on `ipxe`
5. See kea-reservation.log for details
(6. See extremely little logging for reservation classes - only reason I know they were applied at all (not even the final list mentions `pxe`!) was the warning about `testing` after lease assignment)
**Expected behavior**
The server is supposed to add client-classes at reservation lookup together with `KNOWN`, so classes that depend on `KNOWN` and a reserved class are evaluated as true, as described in mentioned documentation.
**Environment:**
- Kea version: 1.5.0 from Ubuntu 19.04 repositories (manually downloaded)
- OS: Ubuntu 18.04 x64
- Which features were compiled in:
- MySQL 7.0, library 5.7.26
- PostgreSQL backend 5.0, library 100009 (not used)
- Memfile backend 2.1 (not used)
- If/which hooks where loaded in:
- lease commands
- HA
**Additional Information**
Current workaround is to load classes depending on reserved classes only-if-required, which means adding a `require-client-classes` to all subnets/shared networks as appropriate (in my case 97% of subnets) adding a lot of configuration overhead with the possibility of very long lists in complicating setups, which kinda defeats the purpose of client classes in my mind.
**Log Debuglevel 55**
```
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.dhcpsrv/7390] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 192.168.100.0/24 for packet received by matching address 192.168.100.1
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.packets/7390] DHCP4_SUBNET_SELECTED [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: the subnet with ID 16 was selected for client assignments
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.packets/7390] DHCP4_SUBNET_DATA [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: the selected subnet details: 192.168.100.0/24
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.hosts/7390] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=52C625F534AC
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.hosts/7390] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=52C625F534AC, found 0 host(s)
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.dhcp4/7390] DHCP4_CLASS_ASSIGNED [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: client packet has been assigned to the following class(es): KNOWN
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_MEMBER Checking membership of 'KNOWN', pushing result 'true'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_OPTION Pushing option 77 with value 0x69505845
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_STRING Pushing text string 'iPXE'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_EQUAL Popping 0x69505845 and 0x69505845 pushing result 'true'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_AND Popping 'true' and 'true' pushing 'true'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_MEMBER Checking membership of 'pxe', pushing result 'false'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_AND Popping 'false' and 'true' pushing 'false'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.options/7390] EVAL_RESULT Expression ipxe evaluated to 0
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_OPTION Pushing option 77 with value 0x69505845
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_STRING Pushing text string 'iPXE'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_EQUAL Popping 0x69505845 and 0x69505845 pushing result 'true'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_NOT Popping 'true' pushing 'false'
2019-07-08 12:15:54.796 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_MEMBER Checking membership of 'pxe', pushing result 'false'
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_AND Popping 'false' and 'false' pushing 'false'
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_MEMBER Checking membership of 'KNOWN', pushing result 'true'
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.eval/7390] EVAL_DEBUG_AND Popping 'true' and 'false' pushing 'false'
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.options/7390] EVAL_RESULT Expression not_ipxe evaluated to 0
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.dhcp4/7390] DHCP4_CLASS_ASSIGNED [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: client packet has been assigned to the following class(es): HA_ns1-kea, ALL, VENDOR_CLASS_PXEClient:Arch:00000:UNDI:002001, deny_snom_dap_pap2t, KNOWN
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.ddns/7390] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: processing client's Hostname option
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.dhcpsrv/7390] DHCPSRV_MYSQL_GET_CLIENTID obtaining IPv4 leases for client ID 01:52:c6:25:f5:34:ac
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.hosts/7390] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 162 and IPv4 address 10.1.0.6
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.hosts/7390] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.1.0.6
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.hosts/7390] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.1.0.6, found 0 host(s)
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.hosts/7390] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 162 and address 10.1.0.6
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.hosts/7390] HOSTS_MGR_ALTERNATE_GET4_SUBNET_ID_ADDRESS4 trying alternate sources for host using subnet id 162 and address 10.1.0.6
2019-07-08 12:15:54.797 DEBUG [kea-dhcp4.dhcpsrv/7390] DHCPSRV_MYSQL_GET_ADDR4 obtaining IPv4 lease for address 10.1.0.6
2019-07-08 12:15:54.798 DEBUG [kea-dhcp4.alloc-engine/7390] ALLOC_ENGINE_V4_REQUEST_EXTEND_LEASE [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: extending lifetime of the lease for address 10.1.0.6
2019-07-08 12:15:54.798 DEBUG [kea-dhcp4.dhcpsrv/7390] DHCPSRV_MYSQL_UPDATE_ADDR4 updating IPv4 lease for address 10.1.0.6
2019-07-08 12:15:54.861 DEBUG [kea-dhcp4.packets/7390] DHCP4_SUBNET_DYNAMICALLY_CHANGED [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: changed selected subnet 192.168.100.0/24 to subnet 10.1.0.0/20 from shared network servers for client assignments
2019-07-08 12:15:54.861 INFO [kea-dhcp4.leases/7390] DHCP4_LEASE_ALLOC [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: lease 10.1.0.6 has been allocated
2019-07-08 12:15:54.861 DEBUG [kea-dhcp4.dhcp4/7390] DHCP4_CLASS_UNCONFIGURED [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: client packet belongs to an unconfigured class: testing
2019-07-08 12:15:54.861 DEBUG [kea-dhcp4.callouts/7390] HOOKS_CALLOUTS_BEGIN begin all callouts for hook leases4_committed
2019-07-08 12:15:54.861 DEBUG [kea-dhcp4.callouts/7390] HOOKS_CALLOUT_CALLED hooks library with index 2 has called a callout on hook leases4_committed that has address 0x7efe0edcb150 (callout duration: 0.123 ms)
2019-07-08 12:15:54.861 DEBUG [kea-dhcp4.callouts/7390] HOOKS_CALLOUTS_COMPLETE completed callouts for hook leases4_committed (total callouts duration: 0.123 ms)
2019-07-08 12:15:54.861 DEBUG [kea-dhcp4.hooks/7390] DHCP4_HOOK_LEASES4_COMMITTED_PARK [hwtype=1 52:c6:25:f5:34:ac], cid=[01:52:c6:25:f5:34:ac], tid=0xdc575936: packet is parked, because a callout set the next step to PARK
```
**Contacting you**
Gitlab/hubKea1.6-finalFrancis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1134Implement dnssec-policy logic2020-01-23T08:16:02ZMatthijs Mekkingmatthijs@isc.orgImplement dnssec-policy logicDNSSEC Made Easyhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1133Your problem or Cygwin's ?????2019-07-31T00:58:38ZGhost UserYour problem or Cygwin's ?????Below is a cut/paste of the results of two different *nslookup*s executed as admin under Command Prompt (cmd). Almost identical results when executed on Cygwin. Cygwin's *nslookup* is distributed with its **bind9** package. My question...Below is a cut/paste of the results of two different *nslookup*s executed as admin under Command Prompt (cmd). Almost identical results when executed on Cygwin. Cygwin's *nslookup* is distributed with its **bind9** package. My question is whether this is a **bind9** problem or did the Cygwin folks mismanipulate their package software?
```
> where nslookup
C:\Windows\System32\nslookup.exe
C:\cygwin64\bin\nslookup.exe
> C:\Windows\System32\nslookup.exe -query=any andromeda.cs.purdue.edu ns3.purdue.edu
Server: ns3.purdue.edu
Address: 128.210.224.226
andromeda.cs.purdue.edu internet address = 128.10.19.24
cs.purdue.edu nameserver = ns1.rice.edu
cs.purdue.edu nameserver = ns3.purdue.edu
cs.purdue.edu nameserver = harbor.ecn.purdue.edu
cs.purdue.edu nameserver = ns4.purdue.edu
cs.purdue.edu nameserver = pendragon.cs.purdue.edu
cs.purdue.edu nameserver = ns2.rice.edu
ns1.rice.edu internet address = 128.42.209.32
ns2.rice.edu internet address = 128.42.178.32
ns3.purdue.edu internet address = 128.210.224.226
ns4.purdue.edu internet address = 128.210.224.234
harbor.ecn.purdue.edu internet address = 128.46.154.76
pendragon.cs.purdue.edu internet address = 128.10.2.5
ns3.purdue.edu AAAA IPv6 address = 2001:18e8:800:200::a
ns4.purdue.edu AAAA IPv6 address = 2001:18e8:800:201::a
> C:\cygwin64\bin\nslookup.exe -query=any andromeda.cs.purdue.edu ns3.purdue.edu
socket.c:5916: connect(128.210.224.226#53) 116/Connection timed out
/usr/bin/nslookup: isc_socket_connect: unexpected error
'''
-- Thanks,
-- aabatpurduehttps://gitlab.isc.org/isc-projects/kea/-/issues/724subnet and shared network default and inheritance are not consistent2020-01-27T14:19:32ZFrancis Dupontsubnet and shared network default and inheritance are not consistent#682 describes a more generic (than limited to interface-id) issue introduced by the optional/inheriting get methods. In particular the behaviors of configuration file and configuration backend should be the same.#682 describes a more generic (than limited to interface-id) issue introduced by the optional/inheriting get methods. In particular the behaviors of configuration file and configuration backend should be the same.kea1.7.4Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1132HTTPS and SVCB records2024-03-14T12:58:04ZMark AndrewsHTTPS and SVCB recordsSubject to change. Defined in draft-ietf-dnsop-svcb-https (now published as RFC 9460). Experimental type codes of HTTPS/65482 and SVBC/65481Subject to change. Defined in draft-ietf-dnsop-svcb-https (now published as RFC 9460). Experimental type codes of HTTPS/65482 and SVBC/65481September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1131backport geoip2 windows support2019-07-04T21:43:14ZEvan Huntbackport geoip2 windows supportEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/dhcp/-/issues/30Coverity: memory leaks in conf file parsing2019-11-18T16:01:03ZMark AndrewsCoverity: memory leaks in conf file parsingCIDs 1448191, 1448193, 1448194, 1448195CIDs 1448191, 1448193, 1448194, 14481954.4.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/721kea-shell is not working when installed from a debian package2019-08-15T15:07:07ZMichal Nowikowskikea-shell is not working when installed from a debian packageThe problem is with hardcoded path for importing of kea_conn.
In kea-shell, this should be removed:
```python
sys.path.append('@PKGPYTHONDIR@')
```
and this:
```python
from kea_conn import CARequest # CAResponse
```
should be change...The problem is with hardcoded path for importing of kea_conn.
In kea-shell, this should be removed:
```python
sys.path.append('@PKGPYTHONDIR@')
```
and this:
```python
from kea_conn import CARequest # CAResponse
```
should be changed to:
```python
from kea.kea_conn import CARequest # CAResponse
```Kea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1129HSM support2024-03-08T05:35:57ZMatthijs Mekkingmatthijs@isc.orgHSM supportMarch 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1126Implement check if the DS record has been published2021-07-08T08:59:38ZMatthijs Mekkingmatthijs@isc.orgImplement check if the DS record has been publishedImplement a way to configure one or more name servers to query to ensure the DS for a given key is published. This is needed to perform automatic key rollover (for keys with the KSK role).
Will need a `check-ds-interval` too, to configu...Implement a way to configure one or more name servers to query to ensure the DS for a given key is published. This is needed to perform automatic key rollover (for keys with the KSK role).
Will need a `check-ds-interval` too, to configure how often such a check needs to be performed.July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.org