ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-04-06T16:27:07Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2585filter-a plugin2021-04-06T16:27:07ZMatthijs Mekkingmatthijs@isc.orgfilter-a pluginReverse the functionality of the 'filter-aaaa' plugin to omit A records instead of AAAA records.
This is useful especially in some IPv6-only environments. Sometimes, client software ignores system preferences and choses A over AAAA (e.g...Reverse the functionality of the 'filter-aaaa' plugin to omit A records instead of AAAA records.
This is useful especially in some IPv6-only environments. Sometimes, client software ignores system preferences and choses A over AAAA (e.g. 'NodeJS' does or used to do this). On an IPv6-only system, this will result in a failed connection attempt. If no 'happy eyeballs' is used, this will at least defer connection till after timeout, or worse it will make the connection impossible.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2586Follow-up from "WIP: Fix timers and TCPDNS send"2021-09-02T12:35:28ZOndřej SurýFollow-up from "WIP: Fix timers and TCPDNS send"The following discussion from !4807 should be addressed:
- [ ] @artem started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4807#note_200169): (+3 comments)
> I find it confusing that `isc__nm_inactive(...The following discussion from !4807 should be addressed:
- [ ] @artem started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4807#note_200169): (+3 comments)
> I find it confusing that `isc__nm_inactive()` is not orthogonal to `isc__nmsocket_active()`. That is, ideally `isc__nm_inactive()` should be implemented as `!isc__nmsocket_active()` (or vice versa).October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/kea/-/issues/1762update ChangeLog in premium repo2021-05-05T16:36:36ZRazvan Becheriuupdate ChangeLog in premium repothe ChangeLog has not been updated since...several release versions back. we could filter out important tickets and add entries before 2.0 goes out.the ChangeLog has not been updated since...several release versions back. we could filter out important tickets and add entries before 2.0 goes out.kea1.9.8Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2588Fixup the copyright texts2023-11-01T07:38:48ZOndřej SurýFixup the copyright textsThe following discussion from !4807 should be addressed:
- [ ] @sgoldlust started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4807#note_200295): (+2 comments)
> I know this is not what you asked for m...The following discussion from !4807 should be addressed:
- [ ] @sgoldlust started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4807#note_200295): (+2 comments)
> I know this is not what you asked for my review on, but there's no reason for the word "you" to be capitalized in these messages.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2589Follow-up from "Resolve "memory leak when named attempts to listen on FreeBSD...2021-03-19T08:15:16ZOndřej SurýFollow-up from "Resolve "memory leak when named attempts to listen on FreeBSD virtual interface""The following discussion from !4823 should be addressed:
- [ ] @sgoldlust started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4823#note_200533):
> ```
> - If an outgoing packet exceeded max-udp-si...The following discussion from !4823 should be addressed:
- [ ] @sgoldlust started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4823#note_200533):
> ```
> - If an outgoing packet exceeded max-udp-size, it was dropped instead
> of sending a proper response. To address this issue, the IP_DONTFRAG settings on
> UDP sockets, which were enabled during DNS Flag Day 2020, were rolled back.
> ```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/stork/-/issues/514System tests for lease search2021-05-17T13:22:52ZMarcin SiodelskiSystem tests for lease searchAs indicated in https://gitlab.isc.org/isc-projects/stork/-/merge_requests/281#note_200073, we need system tests for lease search introduced in #509. I pushed this to a separate ticket having issues with setting up system tests on my sys...As indicated in https://gitlab.isc.org/isc-projects/stork/-/merge_requests/281#note_200073, we need system tests for lease search introduced in #509. I pushed this to a separate ticket having issues with setting up system tests on my system.0.17Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2590Add CI_ENABLE_ALL_TESTS to schedule runs2021-03-19T18:18:19ZOndřej SurýAdd CI_ENABLE_ALL_TESTS to schedule runsThe following discussion from !4628 should be addressed:
- [ ] @artem started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4628#note_200028): (+4 comments)
> I think that we should not forget to make s...The following discussion from !4628 should be addressed:
- [ ] @artem started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4628#note_200028): (+4 comments)
> I think that we should not forget to make sure that these "complicated" tests are being run periodically on CI anyway at least before a release. We could miss important problems if these are not run on CI on periodical basis.
>
> Just thinking out aloud.BIND 9.17 BackburnerMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2591BIND 9.11.28 server hangs under load with 'dnssec-validation auto' configured2021-05-19T16:49:09ZGreg RabilBIND 9.11.28 server hangs under load with 'dnssec-validation auto' configured```
$ uname -a
Linux agr-centos7-ipc-test1 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ named -V
BIND 9.11.28 (Extended Support Version) <id:60f9417>
running on Linux x86_64 3.10.0-1127.el...```
$ uname -a
Linux agr-centos7-ipc-test1 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ named -V
BIND 9.11.28 (Extended Support Version) <id:60f9417>
running on Linux x86_64 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020
built by make with '--enable-ipv6' '--enable-filter-aaaa' '--enable-largefile' '--enable-fixed-rrset' '--enable-threads' '--enable-dnstap' '--disable-shared' '--with-dlopen=no' '--with-openssl=/opt/incontrol/dns/openssl' '--with-geoip2=/opt/incontrol/dns/maxminddb' '--with-protobuf-c=/opt/incontrol/dns/protobuf-c' '--with-libfstrm=/opt/incontrol/dns/fstrm' '--without-gssapi' '--without-pkcs11' '--with-libxml2=yes' '--with-libjson=yes' '--with-tuning=large' '--prefix=/opt/incontrol/dns' 'LDFLAGS=-ldl' 'PKG_CONFIG_PATH=/opt/incontrol/dns/openssl/lib/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
compiled with OpenSSL version: OpenSSL 1.1.1i 8 Dec 2020
linked to OpenSSL version: OpenSSL 1.1.1i 8 Dec 2020
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with libjson-c version: 0.11
linked to libjson-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
linked to maxminddb version: 1.4.3
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
default paths:
named configuration: /opt/incontrol/dns/etc/named.conf
rndc configuration: /opt/incontrol/dns/etc/rndc.conf
DNSSEC root key: /opt/incontrol/dns/etc/bind.keys
nsupdate session key: /opt/incontrol/dns/var/run/named/session.key
named PID file: /opt/incontrol/dns/var/run/named/named.pid
named lock file: /opt/incontrol/dns/var/run/named/named.lock
geoip-directory: opt/incontrol/dns/maxminddb/share/GeoIP
```
How to reproduce
================
named.conf
----------
```
options {
directory "/opt/incontrol/dns/db";
pid-file "/opt/incagent-12.0.24/etc/named.pid";
allow-transfer { none; };
allow-query { any; };
dnssec-validation auto ;
};
zone "." IN {
type hint;
file "db.cache";
};
zone "localhost" IN {
type master;
file "db.localhost";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "db.127.0.0";
allow-update { none; };
};
```
* Get the latest bind.keys from https://downloads.isc.org/isc/bind9/keys/9.11/ (This step is not necessary to reproduce the problem)
* rm -f db/managed-keys*
* start named
* Run resperf
` $ resperf -s <server_ip> -d queryfile-example-current`
queryfile-example-current has 10,000,000 records
* In another window run 'rndc status' in a loop
```
#!/bin/bash
while true
do
rndc status
done
```
* Sometimes 'rndc status' will hang and when that happens named
does not respond to any queries.
Last 'rndc status' before hung:
```
version: BIND 9.11.28 (Extended Support Version) <id:60f9417> (not available)
running on latest: Linux x86_64 4.15.12 #1 SMP Wed Mar 21 12:30:16 EDT 2018
boot time: Fri, 19 Mar 2021 17:05:02 GMT
last configured: Fri, 19 Mar 2021 17:05:02 GMT
configuration file: /opt/incontrol/dns/etc/named.conf
CPUs found: 4
worker threads: 4
UDP listeners per interface: 3
number of zones: 102 (99 automatic)
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 422/900/1000
tcp clients: 4/150
TCP high-water: 4
server is up and running
```
Sometimes 'recursive clients:' was 2/900/1000 but never 0/900/1000 when it hangs.
At that time strace looks like below:
```
# strace -f -p <pid>
[pid 6826] epoll_wait(8, <unfinished ...>
[pid 6825] restart_syscall(<... resuming interrupted futex ...> <unfinished ...>
[pid 6824] select(10, [9], [], NULL, NULL <unfinished ...>
[pid 6822] rt_sigsuspend([], 8 <unfinished ...>
[pid 6823] futex(0x7f8e8449e0d4, FUTEX_WAIT_PRIVATE, 5, NULL <unfinished ...>
[pid 6824] <... select resumed>) = 1 (in [9])
[pid 6824] read(9, ";\275\10vt\376", 36) = 6
[pid 6824] read(9, 0x7f8e82007d30, 30) = -1 EAGAIN (Resource temporarily unavailable)
[pid 6824] select(10, [9], [], NULL, NULL
```
The problem does not happen in 9.11.22 with same configuration.Brian ConryBrian Conryhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2592dig -u is extremely inaccurate, especially on machines with the kernel timer ...2022-04-26T13:18:31ZPatrick McLeandig -u is extremely inaccurate, especially on machines with the kernel timer tick set at 100HzThe current isc_time_now uses `CLOCK_REALTIME_COARSE` which only updates on a timer tick. This clock is generally fine for millisecond accuracy, but on servers with 100hz clocks, this clock is nowhere near accurate enough for microsecond...The current isc_time_now uses `CLOCK_REALTIME_COARSE` which only updates on a timer tick. This clock is generally fine for millisecond accuracy, but on servers with 100hz clocks, this clock is nowhere near accurate enough for microsecond accuracy.
This makes the `dig -u` command report very inaccurate timings. On a fast network with sub-ms responses, the reported time will oscillate between 0us and 10000us. I have created a patch to make this use `CLOCK_REALTIME` if the `-u` option is passed to dig.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2593Strategy of Selecting DNS Root2021-03-21T13:37:57Z♪(^∇^*)Strategy of Selecting DNS RootDear developers:
I am a researcher who keeps eye on the efficiency of DNS roots. I spent days finding the strategy of selecting DNS root in BIND source code, but I still know little about it. I will appreciate it if you tell me the posi...Dear developers:
I am a researcher who keeps eye on the efficiency of DNS roots. I spent days finding the strategy of selecting DNS root in BIND source code, but I still know little about it. I will appreciate it if you tell me the position about these codes and it will save me lots of time.https://gitlab.isc.org/isc-projects/bind9/-/issues/2594query.c:8367: INSIST(qctx->rdataset == ((void *)0) || (((&qctx->client->query...2022-09-21T11:18:47ZCathy Almondquery.c:8367: INSIST(qctx->rdataset == ((void *)0) || (((&qctx->client->query)->attributes & 0x40000) != 0)) failedAs reported in BIND 9.16.13-S1
```
18-Mar-2021 13:19:40.211 query.c:8367: INSIST(qctx->rdataset == ((void *)0) || (((&qctx->client->query)->attributes & 0x40000) != 0)) failed, back trace
18-Mar-2021 13:19:40.211 #0 0x55e22a736cf4 in ??...As reported in BIND 9.16.13-S1
```
18-Mar-2021 13:19:40.211 query.c:8367: INSIST(qctx->rdataset == ((void *)0) || (((&qctx->client->query)->attributes & 0x40000) != 0)) failed, back trace
18-Mar-2021 13:19:40.211 #0 0x55e22a736cf4 in ??
18-Mar-2021 13:19:40.211 #1 0x7f3df81838a0 in ??
18-Mar-2021 13:19:40.211 #2 0x7f3df9818af9 in ??
18-Mar-2021 13:19:40.211 #3 0x7f3df9818ca4 in ??
18-Mar-2021 13:19:40.211 #4 0x7f3df98131ec in ??
18-Mar-2021 13:19:40.211 #5 0x7f3df9819511 in ??
18-Mar-2021 13:19:40.211 #6 0x7f3df98199aa in ??
18-Mar-2021 13:19:40.211 #7 0x7f3df81ba11b in ??
18-Mar-2021 13:19:40.211 #8 0x7f3df81c0636 in ??
18-Mar-2021 13:19:40.211 #9 0x7f3df65f315a in ??
18-Mar-2021 13:19:40.211 #10 0x7f3df6324f73 in ??
18-Mar-2021 13:19:40.211 exiting (due to assertion failure)
```
ISC packaged RPM for RHEL/Centos 8 etc..
Originally occurred with these serve-stale settings:
```
stale-answer-enable yes;
// stale-answer-client-timeout 0;
max-stale-ttl 1w;
```
Uncommenting `stale-answer-client-timeout 0;` appears to prevent the crashes, otherwise they're occurring very frequently.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2595dig crash: l = query->lookup;2021-06-16T10:10:08ZMichal Nowakdig crash: l = query->lookup;`dig` [crashed](https://gitlab.isc.org/isc-private/bind9/-/jobs/1589225) in the `serve-stale` system test on `v9_11_sub` ([25bd30914f5d8ce2b78717599757105ea0d11035](https://gitlab.isc.org/isc-private/bind9/-/commit/25bd30914f5d8ce2b78717...`dig` [crashed](https://gitlab.isc.org/isc-private/bind9/-/jobs/1589225) in the `serve-stale` system test on `v9_11_sub` ([25bd30914f5d8ce2b78717599757105ea0d11035](https://gitlab.isc.org/isc-private/bind9/-/commit/25bd30914f5d8ce2b78717599757105ea0d11035)) with recent serve stale backports in place:
```
I:serve-stale:flush cache, re-enable serve-stale and query again (38)
tests.sh: line 439: 27066 Segmentation fault (core dumped) $DIG -p ${PORT} @10.53.0.1 data.example TXT > dig.out.test$n
I:serve-stale:failed
```
```
I:serve-stale:Core dump(s) found: serve-stale/core.27066
R:serve-stale:FAIL
D:serve-stale:backtrace from serve-stale/core.27066:
D:serve-stale:--------------------------------------------------------------------------------
D:serve-stale:Core was generated by `/builds/isc-private/bind9/bin/dig/.libs/dig -p 5200 @10.53.0.1 data.example TXT'.
D:serve-stale:Program terminated with signal SIGSEGV, Segmentation fault.
D:serve-stale:#0 0x000055f3182e09f5 in send_udp (query=0xffffffffffffffff) at dighost.c:3164
D:serve-stale:3164 l = query->lookup;
D:serve-stale:[Current thread is 1 (Thread 0x7f0951828700 (LWP 27080))]
D:serve-stale:#0 0x000055f3182e09f5 in send_udp (query=0xffffffffffffffff) at dighost.c:3164
D:serve-stale:#1 0x000055f3182df69a in send_done (_task=0x7f095182f010, event=0x7f095182e170) at dighost.c:2937
D:serve-stale:#2 0x00007f09542a0fd2 in dispatch (manager=0x7f095182e010) at task.c:1157
D:serve-stale:#3 0x00007f09542a16e8 in run (uap=0x7f095182e010) at task.c:1331
D:serve-stale:#4 0x00007f0953f7ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
D:serve-stale:#5 0x00007f0953d054cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
D:serve-stale:--------------------------------------------------------------------------------
D:serve-stale:full backtrace from serve-stale/core.27066 saved in serve-stale/core.27066-backtrace.txt
D:serve-stale:core dump serve-stale/core.27066 archived as serve-stale/core.27066.gz
```
```
[New LWP 27080]
[New LWP 27066]
[New LWP 27082]
[New LWP 27081]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/builds/isc-private/bind9/bin/dig/.libs/dig -p 5200 @10.53.0.1 data.example TXT'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055f3182e09f5 in send_udp (query=0xffffffffffffffff) at dighost.c:3164
3164 l = query->lookup;
[Current thread is 1 (Thread 0x7f0951828700 (LWP 27080))]
Thread 4 (Thread 0x7f0951027700 (LWP 27081)):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x7f09518300a0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
__ret = -512
oldtype = 0
err = <optimized out>
oldtype = <optimized out>
err = <optimized out>
__ret = <optimized out>
resultvar = <optimized out>
__arg4 = <optimized out>
__arg3 = <optimized out>
__arg2 = <optimized out>
__arg1 = <optimized out>
_a4 = <optimized out>
_a3 = <optimized out>
_a2 = <optimized out>
_a1 = <optimized out>
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x7f0951830028, cond=0x7f0951830078) at pthread_cond_wait.c:502
spin = 0
buffer = {__routine = 0x7f0953f85d80 <__condvar_cleanup_waiting>, __arg = 0x7f0951026e10, __canceltype = 1359113760, __prev = 0x0}
cbuffer = {wseq = 12, cond = 0x7f0951830078, mutex = 0x7f0951830028, private = 0}
rt = <optimized out>
err = <optimized out>
g = 0
flags = <optimized out>
g1_start = <optimized out>
signals = <optimized out>
result = 0
wseq = 12
seq = 6
private = 0
maxspin = <optimized out>
err = <optimized out>
result = <optimized out>
wseq = <optimized out>
g = <optimized out>
seq = <optimized out>
flags = <optimized out>
private = <optimized out>
signals = <optimized out>
g1_start = <optimized out>
spin = <optimized out>
buffer = <optimized out>
cbuffer = <optimized out>
rt = <optimized out>
s = <optimized out>
#2 __pthread_cond_wait (cond=0x7f0951830078, mutex=0x7f0951830028) at pthread_cond_wait.c:655
No locals.
#3 0x00007f09542abe22 in run (uap=0x7f0951830010) at timer.c:817
manager = 0x7f0951830010
now = {seconds = 1616408150, nanoseconds = 831112000}
result = 0
#4 0x00007f0953f7ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139677990549248, -8078676509628610609, 140720729018446, 140720729018447, 139677990549248, 0, 8210172624732112847, 8210169235483740111}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#5 0x00007f0953d054cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 3 (Thread 0x7f0950826700 (LWP 27082)):
#0 0x00007f0953d057ef in epoll_wait (epfd=5, events=0x7f0951832010, maxevents=64, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
resultvar = 18446744073709551612
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x00007f09542cdcb6 in watcher (uap=0x7f095182ef30) at socket.c:4318
manager = 0x7f095182ef30
done = false
cc = 1
fnname = 0x7f09542f0a65 "epoll_wait()"
strbuf = '\000' <repeats 127 times>
#2 0x00007f0953f7ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139677982156544, -8078676509628610609, 140720729018270, 140720729018271, 139677982156544, 0, 8210175923803867087, 8210169235483740111}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#3 0x00007f0953d054cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 2 (Thread 0x7f095186a780 (LWP 27066)):
#0 0x00007f0953c43b36 in __GI___sigsuspend (set=0x7ffc1910d0f0) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26
resultvar = 18446744073709551102
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x00007f09542aeff5 in isc__app_ctxrun (ctx0=0x7f0954328ba0 <isc_g_appctx>) at app.c:723
result = 0
ctx = 0x7f0954328ba0 <isc_g_appctx>
event = 0x0
next_event = 0x0
task = 0x0
sset = {__val = {0 <repeats 16 times>}}
strbuf = "\000\000\000\000\000\000\000\000\250\214\062T\t\177\000\000P\321\020\031\374\177\000\000p\321\020\031\374\177\000\000\360\322\020\031\374\177\000\000\246\327-T\t\177\000\000\200\321\020\031+\000\000\000\340\031.T#\000\000\000\255\322.T\t\177\000\000\300\214\062T\t\177\000\000\020\321\020\031\374\177\000\000\263\201%T\t\177\000\000h", '\000' <repeats 15 times>, "\341\214.\030\363U\000\000\020\360\202Q\001\000\005"
#2 0x00007f09542af3b7 in isc__app_run () at app.c:760
No locals.
#3 0x00007f09542b1969 in isc_app_run () at ../app_api.c:207
result = 32521
#4 0x000055f3182d23bb in dig_startup () at dig.c:2346
result = 0
#5 0x000055f3182d256a in main (argc=6, argv=0x7ffc1910d2f8) at dig.c:2378
No locals.
Thread 1 (Thread 0x7f0951828700 (LWP 27080)):
#0 0x000055f3182e09f5 in send_udp (query=0xffffffffffffffff) at dighost.c:3164
l = 0x0
result = 22003
sendbuf = 0x7f0951829058
next = 0x7f0951827df0
#1 0x000055f3182df69a in send_done (_task=0x7f095182f010, event=0x7f095182e170) at dighost.c:2937
sevent = 0x7f095182e170
b = 0x0
query = 0x7f095183c018
next = 0xffffffffffffffff
l = 0x55f319f08488
#2 0x00007f09542a0fd2 in dispatch (manager=0x7f095182e010) at task.c:1157
dispatch_count = 3
done = false
finished = false
requeue = false
event = 0x7f095182e170
task = 0x7f095182f010
#3 0x00007f09542a16e8 in run (uap=0x7f095182e010) at task.c:1331
manager = 0x7f095182e010
#4 0x00007f0953f7ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139677998941952, -8078676509628610609, 140720729018382, 140720729018383, 139677998941952, 0, 8210173723706869711, 8210169235483740111}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#5 0x00007f0953d054cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
```
Core dump: [core.27066.gz](/uploads/c3ed11381f3835fecd431c028468e4b8/core.27066.gz)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2596dnssec-policy unexpectedly breaks a DNSSEC-signed zone by creating new keys i...2021-05-11T07:35:16ZCathy Almonddnssec-policy unexpectedly breaks a DNSSEC-signed zone by creating new keys if it can't access the current keysetAs noted in [Support ticket #18133](https://support.isc.org/Ticket/Display.html?id=18133) it's possible to quite thoroughly 'break' a DNSSEC-signed zone if you're using dnssec-policy and the private keys are inaccessible when named start...As noted in [Support ticket #18133](https://support.isc.org/Ticket/Display.html?id=18133) it's possible to quite thoroughly 'break' a DNSSEC-signed zone if you're using dnssec-policy and the private keys are inaccessible when named starts up (and I would not be surprised if this also happens when doing a reconfig or a reload zone).
This could be quite serious if the same thing happens because of a temporary glitch with access to keys stored in an HSM. Although the keys were inaccessible, this could have been remedied.
The creation and addition to the zone of new keys, complete with the failure to be able to refresh the DNSSEY RRset RRSIGs from the old KSK (which was the only key with a DS RR in the parent zone) was catastrophic for DNSSEC-validation of this zone.
Here's what happened.
1. The zone was signed originally using dnssec-policy which generated the initial keys:
```
01-Feb-2021 16:53:35.845 zoneload: info: managed-keys-zone: loaded serial 0
01-Feb-2021 16:53:35.845 zoneload: info: zone example.com/IN: loaded serial 1000
01-Feb-2021 16:53:35.845 general: notice: all zones loaded
01-Feb-2021 16:53:35.845 general: notice: running
01-Feb-2021 16:53:35.845 notify: info: zone example.com/IN: sending notifies (serial 1000)
01-Feb-2021 16:53:35.846 dnssec: info: zone example.com/IN: reconfiguring zone keys
01-Feb-2021 16:53:35.846 dnssec: info: keymgr: DNSKEY example.com/ECDSAP256SHA256/57955 (KSK) created for policy example_DNSSEC_DEFAULT
01-Feb-2021 16:53:35.846 dnssec: info: keymgr: DNSKEY example.com/ECDSAP256SHA256/32569 (ZSK) created for policy example_DNSSEC_DEFAULT
01-Feb-2021 16:53:35.847 dnssec: info: Fetching example.com/ECDSAP256SHA256/57955 (KSK) from key repository.
01-Feb-2021 16:53:35.847 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/57955 (KSK) is now published
01-Feb-2021 16:53:35.847 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/57955 (KSK) is now active
01-Feb-2021 16:53:35.847 dnssec: info: Fetching example.com/ECDSAP256SHA256/32569 (ZSK) from key repository.
01-Feb-2021 16:53:35.847 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/32569 (ZSK) is now published
01-Feb-2021 16:53:35.847 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/32569 (ZSK) is now active
01-Feb-2021 16:53:35.851 dnssec: info: zone example.com/IN: next key event: 03-Feb-2021 17:53:35.846
```
2. All was good, with the DS in the parent zone and the signatures being refreshed automatically, until there was a restart of named with the keys unaccessible (some directory changes, the ramifications of which were not fully understood, nor the bad outcome anticipated). This is what was logged:
The zone is loaded and initiates the notifies:
`18-Mar-2021 18:26:06.346 notify: info: zone example.com/IN: sending notifies (serial 1616023774)`
But then runs into trouble because it can't access the DNSSEC keys (which is interesting, because I don't think this is how named used to behave when loading a zone with RRSIGs from keys it doesn't have):
```
18-Mar-2021 18:26:06.346 dnssec: info: zone example.com/IN: reconfiguring zone keys
18-Mar-2021 18:26:06.347 general: warning: dns_dnssec_keylistfromrdataset: error reading Kexample.com.+013+32569.private: file not found
```
^^^^ Oh dear
`18-Mar-2021 18:26:06.347 general: warning: dns_dnssec_keylistfromrdataset: error reading Kexample.com.+013+57955.private: file not found`
^^^^ Also oh dear...
And this is what dnssec-policy decided to do about it. This made a small oops (RRSIG maintenance broken) into something far far worse. We end up with:
- an updated DNSKEY RRset whose signature from the old KSK can't be refreshed (so fails validation).
- a covering signature for the new RRset from the new KSK (which also fails validation because it's not in the parent zone as a signed DS record).
- named starts replacing zone RR RRSIGs with ones created from the new ZSK as the old ones expire (which is also bad, because the ZSK wasn't pre-published for long enough for the operators to be sure that it has reached all caches).
- and even if the zone operators were able to fix the missing DS in the parent as well as refresh the RRSIG covering the DNSKEY set with the old KSK too - there are still issues with the new ZSK-signed RRSIGs because the key hasn't been 'known' for long enough.
-->
```
18-Mar-2021 18:26:06.347 dnssec: info: keymgr: DNSKEY example.com/ECDSAP256SHA256/39037 (KSK) created for policy example_DNSSEC_DEFAULT
18-Mar-2021 18:26:06.348 dnssec: info: keymgr: DNSKEY example.com/ECDSAP256SHA256/27753 (ZSK) created for policy example_DNSSEC_DEFAULT
18-Mar-2021 18:26:06.354 dnssec: info: Fetching example.com/ECDSAP256SHA256/39037 (KSK) from key repository.
18-Mar-2021 18:26:06.354 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/39037 (KSK) is now published
18-Mar-2021 18:26:06.354 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/39037 (KSK) is now active
18-Mar-2021 18:26:06.354 dnssec: info: Fetching example.com/ECDSAP256SHA256/27753 (ZSK) from key repository.
18-Mar-2021 18:26:06.354 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/27753 (ZSK) is now published
18-Mar-2021 18:26:06.354 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/27753 (ZSK) is now active
18-Mar-2021 18:26:06.355 general: warning: dns_dnssec_findzonekeys2: error reading Kexample.com.+013+32569.private: file not found
```
And the DNSKEY RRset now has 4 keys instead of two:
- Original KSK ID 57955
- New KSK ID 39037
- Original ZSK ID 32569
- New ZSK ID 27753
This is a bad thing that dnssec-policy has done to the zone, in response to an 'oops' - one that is hard to get back from gracefully, as resolvers start to query and cache the zone content. Better would have been (IMHO) to have not rolled the keys and to have done something like:
- Log a lot of errors
- Maybe just not start named or not load this zone when starting?
- If doing a reconfig or reload, not load the zone (and also log a lot of errors)
- If this scenario is encountered (I'm imagining e.g. an HSM that has gone unavailable unexpectedly, or a file system that contained the private key files unmounting) dynamically, then also log a lot of errors.
I'm not sure if unloading the zone would be a good response or not (discuss?)
I think that removing the old RRSIGs and NSEC(3) chains from the zone would also be bad (I'm thinking about what used to happen before dnssec-policy when adopting a zone that has RRSIGs from the previous zone host, where we don't have the private key). But we should maybe also think about some of these other zone migration cases too, not just about accidental issues.May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/515Ability to export certificates from Stork2021-05-31T07:04:11ZTomek MrugalskiAbility to export certificates from StorkStork stores its certificates in a database. @tomek feels (and @fdupont agrees) that there needs to be an ability to import and export certificates. Here are couple usecases:
1. there is a problem with TLS and it needs to be investigate...Stork stores its certificates in a database. @tomek feels (and @fdupont agrees) that there needs to be an ability to import and export certificates. Here are couple usecases:
1. there is a problem with TLS and it needs to be investigated. The standard practice is to inspect the certificates using openssl.
2. admin wants to inspect the traffic and decode the traffic, e.g. wireshark allows such ability, but it of course requires providing the necessary secrets.
3. an audit wants to inspect certificates and perform some form of automated checks
A more advanced case would be this:
4. a deployment with high security requirements would want to generate its own certs and keys and provision them to Stork. This by definition would be a manual process
Since the last item requires import capabilities, it is currently out of scope for this ticket. But it would very useful and also the next logical step after we get the export capability.0.18Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2597Make calling generic rdata methods consistent2021-03-29T14:02:33ZMark AndrewsMake calling generic rdata methods consistentApril 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/kea/-/issues/1766Document how to set up secure connections between HA peers in versions before...2022-01-27T13:55:57ZAndrei Pavelandrei@isc.orgDocument how to set up secure connections between HA peers in versions before 1.9.5https://kea.readthedocs.io/en/latest/arm/agent.html?highlight=Secure%20connections#secure-connections-version-before-1-9-5 documents how to secure the connection to a single CA and only works if you have an HTTPS-knowledgeable client. Fo...https://kea.readthedocs.io/en/latest/arm/agent.html?highlight=Secure%20connections#secure-connections-version-before-1-9-5 documents how to secure the connection to a single CA and only works if you have an HTTPS-knowledgeable client. For HA, where all involved entities i.e. CAs don't speak HTTPS, it's a bit more complex and involves changes to both ngins and Kea configuration too. Let's document that.
RT#18110kea2.1.1https://gitlab.isc.org/isc-projects/bind9/-/issues/2599Run "less stable" unit tests in CI2022-02-25T13:49:37ZMichal NowakRun "less stable" unit tests in CIThere are net manager unit tests which are at the moment "less stable" _in the CI_ than the rest of unit tests. Running them by default means CI pipelines results are overall less stable but those "less stable" unit test need to be run s...There are net manager unit tests which are at the moment "less stable" _in the CI_ than the rest of unit tests. Running them by default means CI pipelines results are overall less stable but those "less stable" unit test need to be run somewhere for them to ever become stable enough. The discussion started on [Mattermost](https://mattermost.isc.org/isc/channels/bind9/qxx36uts4jyxmmtt8yijf5598h). The [suggested solution](https://mattermost.isc.org/isc/pl/nz9ruc73dtb1uf3b37jwjm7pga) is to run them on AWS stress test machines.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/kea/-/issues/1769UT IOSignalTest.mixedSignals fails on CentOS 72021-06-03T18:36:02ZAndrei Pavelandrei@isc.orgUT IOSignalTest.mixedSignals fails on CentOS 7It passes on 1.9.4 and below, so might be caused by IOSignal changes done under #1657.
It passes on all versions on CentOS 8.
```
[ RUN ] IOSignalTest.mixedSignals
io_service_signal_unittests.cc:274: Failure
Expected equality of t...It passes on 1.9.4 and below, so might be caused by IOSignal changes done under #1657.
It passes on all versions on CentOS 8.
```
[ RUN ] IOSignalTest.mixedSignals
io_service_signal_unittests.cc:274: Failure
Expected equality of these values:
sigint_cnt
Which is: 21
(stop_at_count_/3)
Which is: 7
io_service_signal_unittests.cc:275: Failure
Expected equality of these values:
sigusr1_cnt
Which is: 0
(stop_at_count_/3)
Which is: 7
io_service_signal_unittests.cc:276: Failure
Expected equality of these values:
sigusr2_cnt
Which is: 0
(stop_at_count_/3)
Which is: 7
[ FAILED ] IOSignalTest.mixedSignals (24 ms)
```
The following UTs are in the same boat. They also fail consistently on CentOS 7:
* HAServiceTest.sendUpdatesControlResultErrorMultiThreading
* HAServiceTest.sendUpdatesControlResultUnauthorizedMultiThreading
* NameChangeUDPTest.roundTripTest
If possible, it would be nice to fix these as part of this issue.
Reproduced on a CentOS 7.9: [config.report](/uploads/ba34f63adb23f81d6cf1473c3dd949cc/config.report)kea1.9.9Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1770bc in xml_reporting_test_lib is not available on all systems2021-03-26T10:03:14ZAndrei Pavelandrei@isc.orgbc in xml_reporting_test_lib is not available on all systemsJenkins reports `bc: command not found` on two of our machines which results in failed shell tests en-gros.
https://jenkins.aws.isc.org/job/kea-dev/job/ut-basic/244/Jenkins reports `bc: command not found` on two of our machines which results in failed shell tests en-gros.
https://jenkins.aws.isc.org/job/kea-dev/job/ut-basic/244/kea1.9.6Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2600general: error: managed-keys-zone: dns_journal_compact failed: no more2021-04-26T10:22:12ZJean-Christophe Manciotgeneral: error: managed-keys-zone: dns_journal_compact failed: no more- Ubuntu hirsute and Debian bullseye
- bind9 9.17.11
```
# echo 'q' | sudo systemctl --no-pager --full status named
● named.service - BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset...- Ubuntu hirsute and Debian bullseye
- bind9 9.17.11
```
# echo 'q' | sudo systemctl --no-pager --full status named
● named.service - BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-03-26 08:39:18 CET; 19min ago
Docs: man:named(8)
Main PID: 1469485 (named)
Tasks: 14 (limit: 9260)
Memory: 27.3M
CGroup: /system.slice/named.service
└─1469485 /usr/sbin/named -f -u bind
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.331 zoneload: info: zone 0.in-addr.arpa/IN: loaded serial 2020100901
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.339 zoneload: info: zone 127.in-addr.arpa/IN: loaded serial 2020100901
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.347 zoneload: info: zone 255.in-addr.arpa/IN: loaded serial 2020100901
...
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.355 zoneload: info: zone localhost/IN: loaded serial 2020100901
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.367 general: notice: all zones loaded
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.375 general: notice: running
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.375 general: info: zone sdxlive.com/IN (signed): receive_secure_serial: unchanged
Mar 26 08:39:48 hostname named[1469485]: 26-Mar-2021 08:39:48.491 general: error: managed-keys-zone: dns_journal_compact failed: no more
```
This issue appeared with 9.17.11 and was not present with previous releases.
Is there a workaround?April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)