ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-07-14T09:20:07Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2025Warning of unexpectedly missing active key never stops2020-07-14T09:20:07ZJP MensWarning of unexpectedly missing active key never stopsI'm experimenting with KSK rollovers and have a validating BIND `9.16.4` running on FreeBSD.
```
BIND 9.16.4 (Stable Release) <id:0849b42>
running on FreeBSD amd64 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC
built by make with '--...I'm experimenting with KSK rollovers and have a validating BIND `9.16.4` running on FreeBSD.
```
BIND 9.16.4 (Stable Release) <id:0849b42>
running on FreeBSD amd64 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr' '--with-readline=-L/usr/local/lib -ledit' '--with-dlz-filesystem=yes' '--disable-dnstap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python' '--disable-querytrace' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-tcp-fastopen' '--with-tuning=default' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.1' 'build_alias=amd64-portbld-freebsd12.1' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 8.0.1 (tags/RELEASE_801/final 366581)
compiled with OpenSSL version: OpenSSL 1.1.1d-freebsd 10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d-freebsd 10 Sep 2019
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.14
linked to json-c version: 0.14
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
```
The server is configured with a private root. Here's it's full configuration:
```
options {
directory "/usr/local/etc/namedb/working";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
listen-on { 127.0.0.1; 192.168.1.157; };
allow-query { any; };
};
zone "." { type hint; file "/usr/local/etc/namedb/named.root"; };
```
and the hint file
```
. 3600000 NS ksigner.aa.
ksigner.aa. 3600000 A 192.168.1.150
```
I configured `bind.keys` with the initial trust anchor (key tag `41155`)
```
trust-anchors {
"." initial-key 257 3 8 "AwEAAdVfg0pf59Z7QyOVnPcm41C6H5ohxIQv4PVjYR4e
w9+FzVKrG+T894UgqTjOmiwPjskdJCU1Cbm16/a1opd6
WJ+3sJwyY2+/yQ2iTMpQOgHnW9jBYH5ffvNBzaHLZfCC
prkHyOPbdaxHzHhjKBi+PoJr67uJH4/6AS8Le9ncayag
TK0UM/fi9Emu2k5o/XOav2MXiW+WjjFAHTUTwggWN5nY
g6NrEDAtVb62yNqgGIG3NyZoKGyVQSyBI3JX6o0LCeyh
UENV6yvlnN9uvOdwzS4EOfoEkE8lt3NwBTBfaCp3pO9L
egaG2VALhWMIjz35tWiAF3AFqd293dq9VTeVljM="; // 41155
};
```
I'm running the server as follows:
```
named -g -T mkeytimers=2/5/300
```
The server validated fine.
I then began a KSK rollover several hours ago and observed that the new KSK (`30377`) appeared in `managed-keys.bind`:
```
$ORIGIN .
$TTL 0 ; 0 seconds
@ IN SOA . . (
3567 ; serial
0 ; refresh (0 seconds)
0 ; retry (0 seconds)
0 ; expire (0 seconds)
0 ; minimum (0 seconds)
)
KEYDATA 20200714075405 20200713205807 19700101000000 257 3 8 (
AwEAAdVfg0pf59Z7QyOVnPcm41C6H5ohxIQv4PVjYR4e
w9+FzVKrG+T894UgqTjOmiwPjskdJCU1Cbm16/a1opd6
WJ+3sJwyY2+/yQ2iTMpQOgHnW9jBYH5ffvNBzaHLZfCC
prkHyOPbdaxHzHhjKBi+PoJr67uJH4/6AS8Le9ncayag
TK0UM/fi9Emu2k5o/XOav2MXiW+WjjFAHTUTwggWN5nY
g6NrEDAtVb62yNqgGIG3NyZoKGyVQSyBI3JX6o0LCeyh
UENV6yvlnN9uvOdwzS4EOfoEkE8lt3NwBTBfaCp3pO9L
egaG2VALhWMIjz35tWiAF3AFqd293dq9VTeVljM=
) ; KSK; alg = RSASHA256; key id = 41155
; next refresh: Tue, 14 Jul 2020 07:54:05 GMT
; trusted since: Mon, 13 Jul 2020 20:58:07 GMT
KEYDATA 20200714075433 20200713220851 19700101000000 257 3 8 (
AwEAAcq2mOD4nCqlDOzXmaHJF5MrcxMiPOvclSnb8F0K
dKnFWaTGwucwtf2r0GYP2wRvybfyhUXhraHXAkzVSI4I
h435qW3b9TMPmi9VAxWnU4Gex5DT0VSPF3pDrR46A67v
DBy6i1fsQB7coIB3SyWtq19KRCS4GBGp86tTTishSVCd
) ; KSK; alg = RSASHA256; key id = 30377
; next refresh: Tue, 14 Jul 2020 07:54:33 GMT
; trusted since: Mon, 13 Jul 2020 22:08:51 GMT
```
The authoriative server is Knot and I don't seem to be able to actually revoke a KSK so I "retired" and then removed the KSK `41155` from the zone.
BIND then started logging the following:
```
14-Jul-2020 07:54:01.121 managed-keys-zone: Key 30377 for zone . is now trusted (acceptance timer complete)
14-Jul-2020 07:54:03.143 managed-keys-zone: Active key 41155 for zone . unexpectedly missing
14-Jul-2020 07:54:03.143 managed-keys-zone: Key 30377 for zone . is now trusted (acceptance timer complete)
14-Jul-2020 07:54:05.195 managed-keys-zone: Active key 41155 for zone . unexpectedly missing
14-Jul-2020 07:54:05.195 managed-keys-zone: Key 30377 for zone . is now trusted (acceptance timer complete)
14-Jul-2020 07:54:07.241 managed-keys-zone: Active key 41155 for zone . unexpectedly missing
14-Jul-2020 07:54:07.241 managed-keys-zone: Key 30377 for zone . is now trusted (acceptance timer complete)
...
```
and has been doing so for over an hour; it doesn't seem to stop.
Will it ever stop, or is this unexpected behaviour?https://gitlab.isc.org/isc-projects/bind9/-/issues/2024A single hung outgoing TCP connection causes resolution to time out with defa...2020-08-04T13:23:19ZMichał KępieńA single hung outgoing TCP connection causes resolution to time out with default settingsWhen named acting as a resolver connects to an authoritative server over
TCP, it [sets][1] the idle timeout for that connection to 20 seconds.
This fixed timeout was [picked][2] back when the default processing
timeout for each client qu...When named acting as a resolver connects to an authoritative server over
TCP, it [sets][1] the idle timeout for that connection to 20 seconds.
This fixed timeout was [picked][2] back when the default processing
timeout for each client query was [hardcoded][3] to 30 seconds. Commit
000a8970f840a0c27c5cc404826853c4674362ac made this processing timeout
configurable through `resolver-query-timeout` and decreased its default
value to 10 seconds, but the idle TCP timeout was not adjusted to
reflect that change. As a result, with the current defaults in effect,
a single hung TCP connection will consistently cause the resolution
process for a given query to time out.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/c53bfb30e84498559dd004cb674fafb47235a05b/lib/dns/resolver.c#L3020
[2]: 09b45f7b5800c4dbb86846dea35e8aba0a25b0d0
[3]: https://gitlab.isc.org/isc-projects/bind9/-/blob/7f950d7cb71c8816168654f5a28edbb67ee27553/lib/dns/resolver.c#L3320August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2023use netmgr for dig/host/nslookup2020-11-13T11:13:20ZEvan Huntuse netmgr for dig/host/nslookupUpdate dig and friends to use the network manager API instead of `isc_socket`.
(mdig and delv have to wait because they use `dns_dispatch`, so that will have to be converted first.)Update dig and friends to use the network manager API instead of `isc_socket`.
(mdig and delv have to wait because they use `dns_dispatch`, so that will have to be converted first.)November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2022use netmgr for statschannel2022-08-31T11:01:40ZEvan Huntuse netmgr for statschannelUpdate the statistics channel to use the network manager.Update the statistics channel to use the network manager.August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2021Double unlock in bin/named/server.c2020-07-16T07:55:39ZMichal NowakDouble unlock in bin/named/server.cCoverity reports [double unlock](https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=34348205&defectInstanceId=10861501&mergedDefectId=304960) in `bin/named/server.c` in July 12 run.
This likely came with the [recent LMD...Coverity reports [double unlock](https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=34348205&defectInstanceId=10861501&mergedDefectId=304960) in `bin/named/server.c` in July 12 run.
This likely came with the [recent LMDB fixes](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3758), the only locking change to `bin/named/server.c` from July 5 (the time of the previous Coverity run) to July 12 (the time of the identification in Coverity).August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/2020configure call needs to be cleaned up main: gcc:centos6:amd642020-07-31T06:26:12ZMark Andrewsconfigure call needs to be cleaned up main: gcc:centos6:amd64Job [#1019080](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1019080) failed for c91dc92410f15d1c93c70d2c596350eee7748958:
Unrecognized options:
--with-libtool, --without-make-clean, --with-python, --without-pythonJob [#1019080](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1019080) failed for c91dc92410f15d1c93c70d2c596350eee7748958:
Unrecognized options:
--with-libtool, --without-make-clean, --with-python, --without-pythonAugust 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/kea/-/issues/1322kea-dhcp4 do not exit when DHCPSRV_NO_SOCKETS_OPEN2020-07-13T10:10:32ZGururajsrkkea-dhcp4 do not exit when DHCPSRV_NO_SOCKETS_OPENIn a failure case, if the ethernet interface is down the kea-dhcp4 fail to exit on DHCPSRV_NO_SOCKETS_OPEN.
It just hangs till restart/reload.
```
"Dhcp4": {
"interfaces-config": {
"interfaces":[ "eth0" ],
"dhcp-socke...In a failure case, if the ethernet interface is down the kea-dhcp4 fail to exit on DHCPSRV_NO_SOCKETS_OPEN.
It just hangs till restart/reload.
```
"Dhcp4": {
"interfaces-config": {
"interfaces":[ "eth0" ],
"dhcp-socket-type" : "raw"
},
........
}
```
> 2020-06-30 00:55:09.582 WARN [kea-dhcp4.dhcpsrv/56] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface fastcmVlan is not running
>
> 2020-06-30 00:55:09.583 WARN [kea-dhcp4.dhcpsrv/56] DHCPSRV_NO_SOCKETS_OPEN no interface configured to listen to DHCP traffic
can you help with your comments
Thanks in Advance.https://gitlab.isc.org/isc-projects/kea/-/issues/1321Change the answer type from ConstElementPtr to ElementPtr2020-07-20T13:20:14ZFrancis DupontChange the answer type from ConstElementPtr to ElementPtrThe idea is to ease an answer update, for instance adding service, transaction-id, extra message, etc.The idea is to ease an answer update, for instance adding service, transaction-id, extra message, etc.kea1.7.10Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/stork/-/issues/344Tailing log files on Stork Agent2020-07-23T09:50:33ZMarcin SiodelskiTailing log files on Stork AgentThe Stork agent must be extended to tail a selected log file on the server's request. The log file contents should be available for the user to view in the UI. We need new calls on the Stork Agent side to return the log file on demand.The Stork agent must be extended to tail a selected log file on the server's request. The log file contents should be available for the user to view in the UI. We need new calls on the Stork Agent side to return the log file on demand.0.10Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2018could not get query source dispatcher error after reconfig2021-03-03T10:06:19ZLaurent Frigaultcould not get query source dispatcher error after reconfig### Summary
We are running an hidden master only bind server with about many zones , most signed with auto-dnssec maintain; inline-signing yes;
Every few days (7-8 days) we get the following error in the log :
```
Jul 9 11:32:37 nsmas...### Summary
We are running an hidden master only bind server with about many zones , most signed with auto-dnssec maintain; inline-signing yes;
Every few days (7-8 days) we get the following error in the log :
```
Jul 9 11:32:37 nsmaster named[68180]: general: info: received control channel command 'reconfig'
Jul 9 11:32:48 nsmaster named[68180]: general: error: could not get query source dispatcher (213.36.252.194#0)
Jul 9 11:32:48 nsmaster named[68180]: general: error: reloading configuration failed: out of memory
```
and the server must be restarted.
### BIND version used
```
# /usr/local/sbin/named -V
BIND 9.16.4 (Stable Release) <id:0849b42>
running on FreeBSD amd64 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr' '--with-readline=-L/usr/local/lib -ledit' '--with-dlz-filesystem=yes' '--disable-dnstap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python' '--disable-querytrace' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-tcp-fastopen' '--with-tuning=large' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.1' 'build_alias=amd64-portbld-freebsd12.1' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 8.0.1 (tags/RELEASE_801/final 366581)
compiled with OpenSSL version: OpenSSL 1.1.1d-freebsd 10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d-freebsd 10 Sep 2019
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /usr/local/etc/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
```
It is the FreeBSD port compiled with --with-tuning=large
We had the same issue before with --with-tuning=default
We also had the same issue before with bind 9.11.20.
I try starting named with -U 20 but this does not change anything.
We have been running the same configuration WITHOUT DNSSEC signed zones for years on smaller servers without this issue.
### Steps to reproduce
We periodically regenerate our configuration to add/update/remove zones.
when needed, we use "rndc reconfig"
### What is the current *bug* behavior?
After some rndc reconfig the named server stop working with the errors:
```
Jul 9 11:32:48 nsmaster named[68180]: general: error: could not get query source dispatcher (213.36.252.194#0)
Jul 9 11:32:48 nsmaster named[68180]: general: error: reloading configuration failed: out of memory
```
and top reports:
```
last pid: 62441; load averages: 0.29, 0.57, 0.70 up 169+19:01:18 11:47:47
15 processes: 1 running, 14 sleeping
CPU: 1.4% user, 0.0% nice, 4.8% system, 0.0% interrupt, 93.8% idle
Mem: 7100M Active, 5153M Inact, 18G Laundry, 14G Wired, 582M Buf, 18G Free
ARC: 7506M Total, 4261M MFU, 1187M MRU, 30M Anon, 287M Header, 1742M Other
3994M Compressed, 17G Uncompressed, 4.45:1 Ratio
Swap: 64G Total, 422M Used, 64G Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
68180 bind 170 52 0 30G 26G sigwai 3 42.3H 0.00% named
```
When named is started, top reports :
```
last pid: 64008; load averages: 0.49, 0.68, 1.00 up 169+21:04:34 13:51:03
21 processes: 1 running, 20 sleeping
CPU: 1.4% user, 0.0% nice, 4.8% system, 0.0% interrupt, 93.8% idle
Mem: 8509M Active, 2467M Inact, 22M Laundry, 16G Wired, 582M Buf, 36G Free
ARC: 7491M Total, 4043M MFU, 1410M MRU, 11M Anon, 286M Header, 1740M Other
3990M Compressed, 18G Uncompressed, 4.52:1 Ratio
Swap: 64G Total, 98M Used, 64G Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
63924 bind 170 52 0 9180M 7033M sigwai 25 13:36 0.00% named
```
There must be some memory / resource leak issue.
The server has 64G RAM / 56 cores .
This should not be a memory issue.
When it happens, we need to stop and start the named server.
### What is the expected *correct* behavior?
There should not be any errors after the reconfig and the server should not stop working.
Its memory usage should not grow that much .
### Relevant configuration files
Too many zones (about 73000) to paste them all here
```
logging {
channel stdlog {
syslog local1;
print-category yes;
print-severity yes;
print-time no;
};
category default { stdlog; };
category queries { "null"; };
category query-errors { "null"; };
category update { "null"; };
category update-security { "null"; };
category security { "null"; };
};
options {
// All file and path names are relative to the chroot directory,
// if any, and should be fully qualified.
directory "/usr/local/etc/namedb/working";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
listen-on { 127.0.1.4; 213.36.252.194; };
listen-on-v6 { 2a01:e0d:1:2:58bf:f9c2:0:1; };
disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
query-source address 213.36.252.194 port *;
query-source-v6 address 2a01:e0d:1:2:58bf:f9c2:0:1 port *;
allow-transfer {
127.0.1.4;
213.36.252.128/25;
2a01:e0b:1:e:0:0:0:0/64;
213.36.252.32/27;
62.210.98.15;
213.36.253.14;
};
startup-notify-rate 100;
notify-source 213.36.252.194;
recursion no;
notify no;
check-integrity no;
minimal-responses yes;
max-transfer-idle-out 5;
max-transfer-time-out 10;
tcp-clients 1000;
tcp-listen-queue 100;
transfers-out 1000;
dnssec-enable yes;
sig-validity-interval 60 30;
masterfile-format text;
request-ixfr no;
provide-ixfr no;
};
zone "." { type hint; file "/usr/local/etc/namedb/named.root"; };
key "rndc-key" {
algorithm hmac-sha256;
secret "xxx";
};
controls {
inet 127.0.1.4
port 953
allow { any; } keys { "rndc-key"; };
};
// les zones
include "/usr/local/etc/namedb/named.conf.custom.inc";
include "/usr/local/etc/namedb/named.conf.custom-old.inc";
```
Most zones are signed like:
```
zone "bookmyname.be" {
type master;
file "custom/b/o/bookmyname.be/bookmyname.be";
notify explicit;
also-notify { 213.36.252.135; 62.210.98.15; 213.36.253.14; };
auto-dnssec maintain;
inline-signing yes;
key-directory "custom/b/o/bookmyname.be";
};
```
a few are not signed and have the following config:
```
zone "bookmyname.lu" {
type master;
file "custom/b/o/bookmyname.lu/bookmyname.lu";
notify explicit;
also-notify { 213.36.252.135; 62.210.98.15; 213.36.253.14; };
};
```
### Relevant logs and/or screenshots
```
# rndc status
version: BIND 9.16.4 (Stable Release) <id:0849b42>
running on nsmaster.free.org: FreeBSD amd64 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC
boot time: Thu, 09 Jul 2020 09:52:25 GMT
last configured: Thu, 09 Jul 2020 10:42:49 GMT
configuration file: /usr/local/etc/namedb/named-custom.conf
CPUs found: 56
worker threads: 56
UDP listeners per interface: 56
number of zones: 144025 (0 automatic)
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
recursive clients: 0/900/1000
tcp clients: 0/1000
TCP high-water: 17
server is up and running
```
### Possible fixes
No ideaMarch 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2017auto-dnssec zones loose NSEC3 params when the zone journal is removed2023-02-18T03:56:51ZKlaus Darilionauto-dnssec zones loose NSEC3 params when the zone journal is removed### Summary
When Bind removed the journal "journal file is out of date: removing journal file", then the zone also forgets is NSEC3 settings.
### BIND version used
```
BIND 9.12.2-P2 <id:b2bf278>
running on Linux x86_64 4.15.0-74-gene...### Summary
When Bind removed the journal "journal file is out of date: removing journal file", then the zone also forgets is NSEC3 settings.
### BIND version used
```
BIND 9.12.2-P2 <id:b2bf278>
running on Linux x86_64 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019
built by make with '--prefix=/dns/bind/9.12.2-P2' '--enable-threads' '--enable-static' '--enable-ipv6=yes' '--with-openssl=yes' '--with-gssapi=no' '--enable-rrl' 'CFLAGS=-g'
compiled by GCC 4.8.4
compiled with OpenSSL version: OpenSSL 1.0.1f 6 Jan 2014
linked to OpenSSL version: OpenSSL 1.0.2n 7 Dec 2017
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20904
compiled with zlib version: 1.2.8
linked to zlib version: 1.2.11
threads support is enabled
```
I noticed this problem also with older versions, but have not tested newer versions.
### Steps to reproduce
I use Bind as bump-in-the-wire signer, ie:
```
zone "nxdomain.at" {
type slave;
file "/tmp/nxdomain.at";
masters { 176.9.98.135; };
auto-dnssec maintain;
dnssec-dnskey-kskonly no;
inline-signing yes;
key-directory "/tmp/";
};
```
I do not know why, but the journal is lost quite often. I can trigger it often by retransfering the zone with "rndc retransfer":
```
received control channel command 'retransfer nxdomain.at'
transfer of 'nxdomain.at/IN (unsigned)' from 176.9.98.135#53: connected using 83.136.34.11#52809
zone nxdomain.at/IN (unsigned): transferred serial 2020070901
transfer of 'nxdomain.at/IN (unsigned)' from 176.9.98.135#53: Transfer status: success
transfer of 'nxdomain.at/IN (unsigned)' from 176.9.98.135#53: Transfer completed: 1 messages, 13 records, 16168 bytes, 0.025 secs (646720 bytes/sec)
zone nxdomain.at/IN (signed): journal file is out of date: removing journal file
zone nxdomain.at/IN (signed): loaded serial 2020073557
zone nxdomain.at/IN (signed): receive_secure_serial: unchanged
zone nxdomain.at/IN (signed): receive_secure_serial: unchanged
zone nxdomain.at/IN (signed): sending notifies (serial 2020073557)
```
### What is the current *bug* behavior?
The problem is, that when this happens, a zone which uses NSEC3 for zone walking protections, is suddenly vulnerable to zone walking.
### What is the expected *correct* behavior?
The nsec3 params should be recovered when the journal is broken, or should be stored in a separate file, i.e. in the keys directory.
### Relevant configuration files
```
options {
directory "/var/cache/bind";
// Disable recursion
allow-recursion {"none";};
allow-update { none; };
recursion no;
// Allow new zones to be added via rdnc tool
allow-new-zones yes;
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
// lifetime of DNSSEC signatures (RRSIGs) in days
sig-validity-interval 30;
max-journal-size 1m;
version none;
};
```BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2016use netmgr for xfrin2022-01-26T11:33:41ZEvan Huntuse netmgr for xfrin- add support for establishing outgoing TCPDNS connections
- use it for zone transfers- add support for establishing outgoing TCPDNS connections
- use it for zone transfersNovember 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2015Shutdown crash on Windows: lib\isc\netmgr\netmgr.c:275: INSIST(r == 0) failed2020-09-30T15:57:30ZMichał KępieńShutdown crash on Windows: lib\isc\netmgr\netmgr.c:275: INSIST(r == 0) failedFirst observed in a scheduled pipeline run for
1dd265df8f5540c3c89d92ff9b364994bf96138d:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1014592
I am only making the issue confidential out of abundance of caution as
the crash seems to...First observed in a scheduled pipeline run for
1dd265df8f5540c3c89d92ff9b364994bf96138d:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1014592
I am only making the issue confidential out of abundance of caution as
the crash seems to be caused by a [call][1] to `uv_loop_close()`
returning a non-zero value.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/1dd265df8f5540c3c89d92ff9b364994bf96138d/lib/isc/netmgr/netmgr.c#L274October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/stork/-/issues/343Req 3.4.1: Aggregated logs viewer2022-01-18T19:02:58ZTomek MrugalskiReq 3.4.1: Aggregated logs viewer#52 introduced simple log viewing capabilities, which lets browsing a single log file. However, both BIND 9 and Kea have the capability to log different messages to different log files. As a user I want to be able to view aggregated log ...#52 introduced simple log viewing capabilities, which lets browsing a single log file. However, both BIND 9 and Kea have the capability to log different messages to different log files. As a user I want to be able to view aggregated log messages from all files, sorted by timestamps.
On the 2020-07-07 call it was pointed out that this is sort of like reimplementing elastic search. One way to address this requirement would be to implement aggregation. Another would be to integrate elasticsearch or logstash (or similar) and use its capabilities.1.0-backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2014Statschannel system test failed at setup stage.2020-07-16T07:22:03ZMark AndrewsStatschannel system test failed at setup stage.Job [#1013834](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1013834) failed for 032133d8cedd202f30f8e32b38386158cc647649:
Looking at the contents of ns2 and sign.sh it appears that the dnssec-signzone failed. This is almost certain...Job [#1013834](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1013834) failed for 032133d8cedd202f30f8e32b38386158cc647649:
Looking at the contents of ns2 and sign.sh it appears that the dnssec-signzone failed. This is almost certainly due to verification failing as it set expiration to `"now"+1s`.
```
S:statschannel:2020-07-08T02:16:29+0000
T:statschannel:1:A
A:statschannel:System test statschannel
I:statschannel:PORTRANGE:12500 - 12599
I:statschannel:setup.sh script failed
R:statschannel:FAIL
E:statschannel:2020-07-08T02:16:31+0000
```
```
[beetle:system/statschannel/ns2] marka% ls
Kdnssec.+013+42972.key Kdnssec.+013+47508.private
Kdnssec.+013+42972.private dsset-dnssec.
Kdnssec.+013+47508.key named.conf
[beetle:system/statschannel/ns2] marka%
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/stork/-/issues/342Detect log files used by Kea app2020-07-16T17:32:16ZMarcin SiodelskiDetect log files used by Kea appIn order to be able to view the logs generated by Kea apps we need to identify the log files it creates. We do this by parsing the log file when the app is initially added to Stork. The log files used will have to be stored in the databa...In order to be able to view the logs generated by Kea apps we need to identify the log files it creates. We do this by parsing the log file when the app is initially added to Stork. The log files used will have to be stored in the database so as they can be later referenced by id in the REST API calls.0.10Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2013Unchecked returns of inet_pton in geoip_test.c2020-07-13T01:45:30ZMark AndrewsUnchecked returns of inet_pton in geoip_test.c```
305 dns_geoip_elem_t elt;
306 struct in_addr in4;
307 isc_netaddr_t na;
308
CID 281437 (#1 of 1): Unchecked return value (CHECKED_RETURN)
1. check_return: Calling inet_pton without checking return value (as ...```
305 dns_geoip_elem_t elt;
306 struct in_addr in4;
307 isc_netaddr_t na;
308
CID 281437 (#1 of 1): Unchecked return value (CHECKED_RETURN)
1. check_return: Calling inet_pton without checking return value (as is done elsewhere 89 out of 91 times).
309 inet_pton(AF_INET, addr, &in4);
310 isc_netaddr_fromin(&na, &in4);
...
322 dns_geoip_elem_t elt;
323 struct in6_addr in6;
324 isc_netaddr_t na;
325
CID 281472 (#1 of 1): Unchecked return value (CHECKED_RETURN)
1. check_return: Calling inet_pton without checking return value (as is done elsewhere 89 out of 91 times).
326 inet_pton(AF_INET6, addr, &in6);
327 isc_netaddr_fromin6(&na, &in6);
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2012Add assertion check to silence dereference before NULL check in tsig_test.c2020-07-13T03:21:36ZMark AndrewsAdd assertion check to silence dereference before NULL check in tsig_test.c```
363 /*
364 * Start digesting.
365 */
deref_ptr_in_call: Dereferencing pointer tsigout. [show details]
366 result = add_mac(outctx, tsigout);
367 assert_int_equal(result, ISC_R_SUCCESS);
...
47...```
363 /*
364 * Start digesting.
365 */
deref_ptr_in_call: Dereferencing pointer tsigout. [show details]
366 result = add_mac(outctx, tsigout);
367 assert_int_equal(result, ISC_R_SUCCESS);
...
474 if (tsigin != NULL) {
475 isc_buffer_free(&tsigin);
476 }
CID 281475 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking tsigout suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
477 if (tsigout != NULL) {
478 isc_buffer_free(&tsigout);
479 }
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/2011Off-by-one error in dns_rdatatype_attributes?2020-07-08T03:45:35ZMichael McNallyOff-by-one error in dns_rdatatype_attributes?On [Support #16775](https://support.isc.org/Ticket/Display.html?id=16775), Jinmei writes to let us know:
> I happened to notice one very minor "off-by-one" glitch in lib/dns/rdata.c:dns_rdatatype_attributes, which would be fixed by the ...On [Support #16775](https://support.isc.org/Ticket/Display.html?id=16775), Jinmei writes to let us know:
> I happened to notice one very minor "off-by-one" glitch in lib/dns/rdata.c:dns_rdatatype_attributes, which would be fixed by the following patch. That is, I believe including 255 is more logical according to the meta type range specified by IANA: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
>
> This doesn't affect the behavior anyway (hence "very minor"), since RDATATYPE_ATTRIBUTE_SW covers the case of type == 255. But the "fixed" code would be less confusing for code readers.
>
> (BTW: If 255 was intentionally excluded because the type is not "UNKNOWN", I'd say 249-254 should also be excluded).
```
diff --git a/lib/dns/rdata.c b/lib/dns/rdata.c
index c8453aae5c..7a281c2ef7 100644
--- a/lib/dns/rdata.c
+++ b/lib/dns/rdata.c
@@ -1286,7 +1286,7 @@ dns_rdata_checknames(dns_rdata_t *rdata, const dns_name_t *owner,
unsigned int
dns_rdatatype_attributes(dns_rdatatype_t type) {
RDATATYPE_ATTRIBUTE_SW
- if (type >= (dns_rdatatype_t)128 && type < (dns_rdatatype_t)255) {
+ if (type >= (dns_rdatatype_t)128 && type <= (dns_rdatatype_t)255) {
return (DNS_RDATATYPEATTR_UNKNOWN | DNS_RDATATYPEATTR_META);
}
return (DNS_RDATATYPEATTR_UNKNOWN);
```
Has he discovered an error on our part or was this done intentionally (in which case, can we explain why?)August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/2010Potential NULL pointer dereference (9.11) in dnstap.c2020-07-13T04:31:50ZMark AndrewsPotential NULL pointer dereference (9.11) in dnstap.c```
REQUIRE(handlep != NULL && *handlep == NULL);
858
859 handle = isc_mem_get(mctx, sizeof(*handle));
4. Condition handle == NULL, taking true branch.
5. var_compare_op: Comparing handle to null implies that ha...```
REQUIRE(handlep != NULL && *handlep == NULL);
858
859 handle = isc_mem_get(mctx, sizeof(*handle));
4. Condition handle == NULL, taking true branch.
5. var_compare_op: Comparing handle to null implies that handle might be null.
860 if (handle == NULL)
6. Condition result != 0, taking true branch.
7. Jumping to label cleanup.
861 CHECK(ISC_R_NOMEMORY);
...
897 cleanup:
8. Condition result != 0, taking true branch.
CID 286432 (#1 of 1): Dereference after null check (FORWARD_NULL)
9. var_deref_op: Dereferencing null pointer handle.
898 if (result != ISC_R_SUCCESS && handle->reader != NULL) {
899 fstrm_reader_destroy(&handle->reader);
900 handle->reader = NULL;
901 }
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Mark AndrewsMark Andrews