BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2020-02-25T00:52:36Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1629contrib/dlz/modules/filesystem no longer builds 9.16.02020-02-25T00:52:36ZMark Andrewscontrib/dlz/modules/filesystem no longer builds 9.16.0clang-format reordered the includes causing isc_result_t to not be typedef'd early enough.clang-format reordered the includes causing isc_result_t to not be typedef'd early enough.https://gitlab.isc.org/isc-projects/bind9/-/issues/1626Algorithm rollover is stuck on publishing DS2020-03-09T13:43:21ZMatthijs Mekkingmatthijs@isc.orgAlgorithm rollover is stuck on publishing DSThe keymgr logic prevents to introduce the DS record (move it to RUMOURED state) because it thinks that will move DNSSEC into an invalid state.The keymgr logic prevents to introduce the DS record (move it to RUMOURED state) because it thinks that will move DNSSEC into an invalid state.March 2020 (9.11.17, 9.16.1, 9.17.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/1625Algorithm rollover takes too long to introduce2020-03-09T13:43:20ZMatthijs Mekkingmatthijs@isc.orgAlgorithm rollover takes too long to introduceAlgorithm rollover takes too long (but luckily not too short) because when introducing new zone signatures the time to wait before the signatures are omnipresent includes the sign delay. This is the delay that ensures all zone signature...Algorithm rollover takes too long (but luckily not too short) because when introducing new zone signatures the time to wait before the signatures are omnipresent includes the sign delay. This is the delay that ensures all zone signatures have been refreshed. Thus publishing the DS record is delayed. Since there is no predecessor key with the same algorithm, all signatures need to be resigned anyway and adding the sign delay is unnecessary.March 2020 (9.11.17, 9.16.1, 9.17.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/1624dnssec-policy change does not retire keys2020-03-09T13:43:21ZMatthijs Mekkingmatthijs@isc.orgdnssec-policy change does not retire keysWhen changing a policy for a zone (for example to perform an algorithm rollover), existing keys with no longer matching properties (for example that now have the wrong algorithm) are not being retired, thus are being kept in the zone and...When changing a policy for a zone (for example to perform an algorithm rollover), existing keys with no longer matching properties (for example that now have the wrong algorithm) are not being retired, thus are being kept in the zone and maintain active.March 2020 (9.11.17, 9.16.1, 9.17.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/1620dnssec-policy NSEC3 support2021-01-04T12:47:31ZMatthijs Mekkingmatthijs@isc.orgdnssec-policy NSEC3 supportDecember 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1619RPZ wildcard passthru ignored2020-08-20T19:36:01ZDaniel StirnimannRPZ wildcard passthru ignored### Summary
I have two response-policy zones configured. The first zone is a local whitelist with the policy passthru. The second zone is a local blacklist with the policy given. If the blacklist rpz zone contains `www.example.com CNAME...### Summary
I have two response-policy zones configured. The first zone is a local whitelist with the policy passthru. The second zone is a local blacklist with the policy given. If the blacklist rpz zone contains `www.example.com CNAME .` (nxdomain) and the whitelist rpz zone contains a wildcard to whitelist *.example.com with `*.example.com CNAME rpz-passthru.` then this wildcard is ignored.
This has worked from 9.8 up to 9.14.5 and started not working in 9.14.6 and later (I tested up to 9.16.1)
### BIND version used
```
BIND 9.14.6 (Stable Release) <id:efd3496>
running on Linux x86_64 3.10.0-1062.12.1.el7.x86_64 #1 SMP Tue Feb 4 23:02:59 UTC 2020
built by make with '--build=x86_64-koji-linux-gnu' '--host=x86_64-koji-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/named' '--bindir=/opt/named/bin' '--sbindir=/opt/named/sbin' '--sysconfdir=/etc' '--datadir=/opt/named/share' '--includedir=/opt/named/include' '--libdir=/opt/named/lib64' '--libexecdir=/opt/named/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/opt/named/share/man' '--infodir=/opt/named/share/info' '--exec-prefix=/opt/named' '--disable-static' '--enable-threads' '--enable-ipv6' '--enable-dnstap' '--disable-openssl-version-check' '--enable-largefile' '--with-tuning=large' '--with-randomdev=/dev/urandom' '--with-pic' '--with-libjson' '--with-libtool' '--with-libxml2' '--with-python-install-dir=/opt/named/usr/lib/python2.7/site-packages' '--with-docbook-xsl=/opt/named/share/sgml/docbook/xsl-stylesheets' '--includedir=/opt/named/include/bind9' 'build_alias=x86_64-koji-linux-gnu' 'host_alias=x86_64-koji-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'PKG_CONFIG_PATH=:/opt/named/lib64/pkgconfig:/opt/named/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
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
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
1. Install bind release 9.14.6
2. Use the `named.conf` and `whitelist.zone`, `blacklist.zone` listed in the configuration file section.
3. Start bind e.g. systemctl start named
4. Use dig to check the behavior and check the logs
```
dig @::1 www.example.com
```
### What is the current *bug* behavior?
The wildcard passthru entry in the `whitelist.zone` is ignored.
### What is the expected *correct* behavior?
The wildcard passthru entry in the `whitelist.zone` is used.
### Relevant configuration files
Used `named.conf`
```
logging {
channel "default_debug" {
file "named.log";
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
};
options {
directory "/var/named/data";
listen-on port 53 {
127.0.0.1/32;
};
listen-on-v6 port 53 {
::1/128;
};
dnssec-enable yes;
dnssec-validation auto;
empty-zones-enable yes;
recursion yes;
response-policy {
zone "whitelist.zone" policy passthru;
zone "blacklist.zone" policy given;
} break-dnssec yes;
allow-query {
"localhost";
};
allow-transfer {
"localhost";
};
};
zone "whitelist.zone" {
type master;
file "whitelist.zone";
allow-query {
"none";
};
};
zone "blacklist.zone" {
type master;
file "blacklist.zone";
allow-query {
"none";
};
};
```
Used `whitelist.zone`
```
$ORIGIN whitelist.zone.
$TTL 3600
@ IN SOA ns.whitelist.zone. hostmaster.whitelist.zone. 1 600 300 604800 3600
IN NS ns2.switch.ch.
example.com CNAME rpz-passthru.
*.example.com CNAME rpz-passthru.
```
Used `blacklist.zone`
```
$ORIGIN blacklist.zone.
$TTL 3600
@ IN SOA ns.blacklist.zone. hostmaster.blacklist.zone. 1 600 300 604800 3600
IN NS ns2.switch.ch.
www.example.com CNAME .
; test record
test.example.org CNAME .
```
### Relevant logs and/or screenshots
Log entry on 9.14.6 where it breaks wildcards for passthru:
```
12-Feb-2020 15:12:30.481 rpz: info: client @0x7fd7200a2cb0 ::1#58427 (www.example.com): rpz QNAME Local-Data rewrite www.example.com/A/IN via www.example.com.blacklist.zone
```
Log entry on 9.14.5 where wildcard passthru still works:
```
12-Feb-2020 15:14:36.229 rpz: info: client @0x7fd5440a2cb0 ::1#45028 (www.example.com): rpz QNAME PASSTHRU rewrite www.example.com/A/IN via www.example.com.whitelist.zone
```
### Possible fixes
It may has something to do with this change in 9.14.6
```
5282. [bug] Fixed a bug in searching for possible wildcard matches
for query names in the RPZ summary database. [GL #1146]
```
https://ftp.isc.org/isc/bind9/9.14.6/CHANGESAugust 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/1616autosign not waiting long enough for zone to be signed v9_11 and maybe others2020-02-12T20:44:16ZMark Andrewsautosign not waiting long enough for zone to be signed v9_11 and maybe othersJob [#661978](https://gitlab.isc.org/isc-projects/bind9/-/jobs/661978) failed for 8d0b59a5f5fc13c11931b25a9f05dd2845bad854:
```
I:autosign:checking scheduled key activation (72)
I:autosign:waiting for changes to take effect
I:autosign:f...Job [#661978](https://gitlab.isc.org/isc-projects/bind9/-/jobs/661978) failed for 8d0b59a5f5fc13c11931b25a9f05dd2845bad854:
```
I:autosign:checking scheduled key activation (72)
I:autosign:waiting for changes to take effect
I:autosign:failed
```
```
echo_i "checking scheduled key activation ($n)"
ret=0
$SETTIME -K ns3 -A now+3s $zsk > settime.out.test$n.zsk || ret=1
$SETTIME -K ns3 -A now+3s $ksk > settime.out.test$n.ksk || ret=1
($RNDCCMD 10.53.0.3 loadkeys delay.example. 2>&1 | sed 's/^/ns2 /' | cat_i) || ret=1
echo_i "waiting for changes to take effect"
sleep 3
wait_for_notifies "delay.example" "ns3" || ret=1
$DIG $DIGOPTS +noall +answer dnskey delay.example. @10.53.0.3 > dig.out.ns3.1.test$n || ret=1
# DNSKEY expected:
awk 'BEGIN {r=1} $4=="DNSKEY" {r=0} END {exit r}' dig.out.ns3.1.test$n || ret=1
# RRSIG expected:
awk 'BEGIN {r=1} $4=="RRSIG" {r=0} END {exit r}' dig.out.ns3.1.test$n || ret=1
$DIG $DIGOPTS +noall +answer a a.delay.example. @10.53.0.3 > dig.out.ns3.2.test$n || ret=1
# A expected:
awk 'BEGIN {r=1} $4=="A" {r=0} END {exit r}' dig.out.ns3.2.test$n || ret=1
# RRSIG expected:
awk 'BEGIN {r=1} $4=="RRSIG" {r=0} END {exit r}' dig.out.ns3.2.test$n || ret=1
n=`expr $n + 1`
if [ $ret != 0 ]; then echo_i "failed"; fi
status=`expr $status + $ret
```
```
head autosign/*test72*
==> autosign/dig.out.ns3.1.test72 <==
delay.example. 300 IN DNSKEY 256 3 7 AwEAAcpWc1D81h1jDWcL3DuvIgB9cqYNusfcPMyh0/GAypygpJHaOGlV dbPbEbwtgjv9Kj0LYGhswjesQcTjayJAgQfqFeh1QPcq5TpNGUvptybS F+iw3Vnc6QqZZ9uW0H9dcpmWrcSxp3z+FAqfqC+eEgp7jQog9DHcGrqS XKRDLuR/
delay.example. 300 IN DNSKEY 257 3 7 AwEAAc1i4SBAfPGkfKeVCHbhKsZ3zNPAvfWTZUQQ7jXu8APcv4/zFeyr IXs8e1itifPNpbZrOqT0lx/4sEH0eYOKaliWYDJd3A+gIpRhHcUTQQmM mQsSVkk/zXWCnJpTHxtiz8nT2cAwcKrUKdh8rSOfs/MfHjV657qCKgK4 UCWkl/H0vARcnKD0xE261GzKWq3YPu5+XnFOcXC5Bn7aceUjhrCmm7Lc DJBXjdg+t7kKH+AFZoN95qQnCKFnfg72nH4cITZz1Bca/W+PRKuCjsn5 TIkobYSZGlUU+8xgQToIZv7D544SfyOctvGL+J8SXL2zhHIcfKEdrWcy siWZDuMzAVc=
==> autosign/dig.out.ns3.2.test72 <==
a.delay.example. 300 IN A 10.0.0.1
==> autosign/settime.out.test72.ksk <==
ns3/Kdelay.example.+007+64764.key
ns3/Kdelay.example.+007+64764.private
==> autosign/settime.out.test72.zsk <==
ns3/Kdelay.example.+007+07832.key
ns3/Kdelay.example.+007+07832.private
```
```
11-Feb-2020 13:09:24.248 received control channel command 'loadkeys delay.example.'
11-Feb-2020 13:09:27.250 writing to journal
11-Feb-2020 13:09:27.250 add re-sign delay.example. 300 IN RRSIG DNSKEY 7 2 300 20200312130927 20200211120927 7832 delay.example. WGIO8hlCkXJ+3U4yDLsdPI14suvhF/ATYA4ulGVjbwre0TLkXf7cmhf4 VaNGbRiFpYY/r9Lv0GXWjqjUbZET20raH4ngQmHz1lKrHdHqvXEkqZW4 DNIM9StLs1ylke5WNT4nT7SGkWibycBa+CAdcFOix1m4oK/WSbR+ihto zoU=
11-Feb-2020 13:09:27.250 add re-sign delay.example. 300 IN RRSIG DNSKEY 7 2 300 20200312130927 20200211120927 64764 delay.example. vEIGbSFdYF5UNouyrnrGO3peuKkZYNqp1I8qeEsM1Lm5HTNWFPtndp4N 0uPkv1PN3yPqpNL74LuCU5fy8RnziVS+V5ggDzpOi3dio9yb0vh4PJdP 0W0ltY3IJXRmgTjpYxZRlvP2kT3Lozg+bg2gerQAUMY2A3YjKycG/sCl 2Im1dIEi/3o/+PUdgWRYB3UHVizMgpBWo/JEAF2lvEIeV7HQd1f/RnFc hUYaTicKSENkvwxzT/7bcNU3+w69Ot1zk5PYe8Xiwou2MyV3VoVufG2F 2tGxia0QqzHTSJe1mahnowhgGp8zAPTnHRWkd+mH+do66HBgEQdFgEYc SDFIvA==
11-Feb-2020 13:09:28.691 zone_needdump: zone delay.example/IN: enter
11-Feb-2020 13:09:28.692 zone delay.example/IN: sending notifies (serial 2009102724)
11-Feb-2020 13:09:28.694 writing to journal
11-Feb-2020 13:09:28.694 add re-sign a.delay.example. 300 IN RRSIG A 7 3 300 20200228153842 20200211120928 7832 delay.example. vn8NKJWewQk2d6ZyiRpeNb5uvnbRDOoFfY+7d2+IjWdtXAJp40EIItxn GnfQEv1XjsbhbM6NspiSE/p6tI2lz2pu/U/UNwSaOn5iFrhU4qE24Nvs kK3dJWBMF8vGL6U5bwDMwTBdtaQeh2JVUQj9oX2E3vlDOLQNmCPTLt7p bmA=
11-Feb-2020 13:09:29.473 client @0x7f261c1e4d90 10.53.0.1#54783 (delay.example): query 'delay.example/DNSKEY/IN' approved
11-Feb-2020 13:09:29.489 client @0x7f2630f8ddc0 10.53.0.1#59149 (a.delay.example): query 'a.delay.example/A/IN' approved
11-Feb-2020 13:09:31.874 zone_needdump: zone delay.example/IN: enter
11-Feb-2020 13:09:31.903 writing to journal
11-Feb-2020 13:09:31.904 add delay.example. 3600 IN NSEC a.delay.example. NS SOA RRSIG NSEC DNSKEY
11-Feb-2020 13:09:31.909 zone_needdump: zone delay.example/IN: enter
11-Feb-2020 13:09:33.692 zone delay.example/IN: sending notifies (serial 2009102726)
```February 2020 (9.11.16, 9.14.11, 9.16.0, 9.16.0-S)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1613Signal DS submitting via rndc2020-08-31T12:08:46ZMatthijs Mekkingmatthijs@isc.orgSignal DS submitting via rndcWe need a way, via rndc or some other command, to signal that we have submitted the DS.We need a way, via rndc or some other command, to signal that we have submitted the DS.September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1612Get current state of DNSSEC keys (kasp) via rndc2020-07-01T20:23:25ZMatthijs Mekkingmatthijs@isc.orgGet current state of DNSSEC keys (kasp) via rndcWe need a way, via rndc zonestatus or some other command, to see what the current state of the keys are and when they're going to be changing to a new state (e.g. rumored to omnipresent). the log file says "wait 7500 seconds" or somethin...We need a way, via rndc zonestatus or some other command, to see what the current state of the keys are and when they're going to be changing to a new state (e.g. rumored to omnipresent). the log file says "wait 7500 seconds" or something if you run in debug mode but I haven't found any other way to figure it outJuly 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1608catalog zones reconfig crash2021-12-01T09:58:09ZTony Finchcatalog zones reconfig crashWith a configuration like https://www.dns.cam.ac.uk/code/nsconfig/catz.named.conf
I can crash `named` by disabling and re-enabling the catalog zone.
I comment out the catalog-zones clause to disable it, and run `rndc reconfig`; then I u...With a configuration like https://www.dns.cam.ac.uk/code/nsconfig/catz.named.conf
I can crash `named` by disabling and re-enabling the catalog zone.
I comment out the catalog-zones clause to disable it, and run `rndc reconfig`; then I uncomment the catalog-zones clause to re-enable it, then when I run `rndc reconfig` again, `named` crashes.
```
2020-02-07.15:43:47.596 general: critical: zone.c:1806: INSIST(zone->catzs == ((void *)0) || zone->catzs == catzs) failed, back trace
```
I am running BIND 9.15.8 revision 9943c5dce5550e3111d4064b9d6ec8a1c67da285 plus patchesDecember 2021 (9.16.24, 9.16.24-S1, 9.17.21)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1604named assertion failed in mem.c2021-10-05T08:43:59ZMichal Nowaknamed assertion failed in mem.cI have a FreeBSD 12.1 under KVM (6 vCPU, 8 G RAM), where I am able to trigger core dump of `named` by running system test under a tight loop (e.g. `while true; do make -j6 -k test V=1; done`) and press-and-hold `Ctrl-C` until everything ...I have a FreeBSD 12.1 under KVM (6 vCPU, 8 G RAM), where I am able to trigger core dump of `named` by running system test under a tight loop (e.g. `while true; do make -j6 -k test V=1; done`) and press-and-hold `Ctrl-C` until everything eventually gets terminated. The test from which `named` originated varies but all the `named` backtraces are the same:
Here's the backtrace:
```
Core was generated by `/usr/home/newman/bind9/bin/named/.libs/named -D case-ns1 -X named.lock -m record'.
Program terminated with signal SIGABRT, Aborted.
#0 0x0000000800e0845a in thr_kill () from /lib/libc.so.7
[Current thread is 1 (LWP 102024)]
(gdb) bt
#0 0x0000000800e0845a in thr_kill () from /lib/libc.so.7
#1 0x0000000800e06844 in raise () from /lib/libc.so.7
#2 0x0000000800d79079 in abort () from /lib/libc.so.7
#3 0x00000000002309e5 in assertion_failed (file=0x8006dc1d7 "mem.c", line=2371, type=<optimized out>, cond=0x8006d29a5 "((mctx) != ((void *)0) && (mctx)->magic == (('A') << 24 | ('m') << 16 | ('c') << 8 | ('x')))") at ./main.c:261
#4 0x000000080070333a in isc_assertion_failed (file=0x18e88 <error: Cannot access memory at address 0x18e88>, line=6, type=isc_assertiontype_require, cond=0x800e0847a <thr_self+10> "\017\202\224\064") at assertions.c:48
#5 0x0000000800711dc5 in isc__mem_put (mctx=<optimized out>, ptr=<optimized out>, size=<optimized out>, file=<optimized out>, line=0) at mem.c:2371
#6 0x00000008002cb3b5 in ns_clientmgr_create (mctx=0x8011a8000, sctx=0x801911bd0, taskmgr=0x801901bd0, timermgr=0x801903bd0, interface=0x802a0a010, managerp=0x802a0a518) at client.c:2496
#7 0x00000008002d02b2 in ns_interface_create (mgr=0x801b7f010, addr=<optimized out>, name=0x7fffdf3f7960 "lo0", ifpret=0x7fffdf3f76f0) at interfacemgr.c:426
#8 0x00000008002cfb86 in ns_interface_setup (mgr=0x801b7f010, addr=0x6, name=0x0, ifpret=0x7fffdf3f7bf0, accept_tcp=true, dscp=-1, addr_in_use=0x7fffdf3f7c16) at interfacemgr.c:511
#9 0x00000008002cf8da in do_scan (mgr=<optimized out>, ext_listen=<optimized out>, verbose=<optimized out>) at interfacemgr.c:1081
#10 0x00000008002cea33 in ns_interfacemgr_scan0 (mgr=0x801b7f010, ext_listen=0x0, verbose=<optimized out>) at interfacemgr.c:1141
#11 0x00000008002ce9d9 in ns_interfacemgr_scan (mgr=0x801b7f010, verbose=false) at interfacemgr.c:1188
#12 0x000000000023ea9f in load_configuration (filename=<optimized out>, server=0x801906bd0, first_time=<optimized out>) at ./server.c:8638
#13 0x0000000000233815 in run_server (task=<optimized out>, event=0x0) at ./server.c:9580
#14 0x0000000800727329 in dispatch (manager=0x801901bd0, threadid=<optimized out>) at task.c:1150
#15 0x00000008007254af in run (queuep=<optimized out>) at task.c:1340
#16 0x0000000800c32776 in ?? () from /lib/libthr.so.3
#17 0x0000000000000000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffdf3f8000
```
BIND (7fae1ef12b8adffa223d3d11cd241454e42d96d9) was configured with `CC=clang CFLAGS="-fno-omit-frame-pointer -fno-optimize-sibling-calls -O1 -g -Wall -Wextra" ./configure --disable-maintainer-mode --enable-developer --with-libtool --disable-static --with-cmocka --with-libxml2 --with-json-c --prefix=$HOME/.local --without-make-clean`.
A more detailed backtrace attached: [gdb.case-ns1.out](/uploads/0d42822aad52c3a8308d3f68e2e31771/gdb.case-ns1.out).BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1600Core dump in resolver.c when shutting down.2023-11-02T16:51:27ZMark AndrewsCore dump in resolver.c when shutting down.Job [#637123](https://gitlab.isc.org/isc-projects/bind9/-/jobs/637123) failed for 4e2ac5f6c79d91cc0c58d4c3c097e47b79d1f647:
```
05-Feb-2020 08:49:12.254 resolver.c:9813: INSIST(((res->dbuckets[i].list).head == ((void *)0))) failed, back...Job [#637123](https://gitlab.isc.org/isc-projects/bind9/-/jobs/637123) failed for 4e2ac5f6c79d91cc0c58d4c3c097e47b79d1f647:
```
05-Feb-2020 08:49:12.254 resolver.c:9813: INSIST(((res->dbuckets[i].list).head == ((void *)0))) failed, back trace
05-Feb-2020 08:49:12.254 #0 0x5620b7b6cc74 in ??
05-Feb-2020 08:49:12.254 #1 0x7f7c47de1857 in ??
05-Feb-2020 08:49:12.254 #2 0x7f7c48318728 in ??
05-Feb-2020 08:49:12.254 #3 0x7f7c48352808 in ??
05-Feb-2020 08:49:12.254 #4 0x7f7c4835345d in ??
05-Feb-2020 08:49:12.254 #5 0x7f7c4835355c in ??
05-Feb-2020 08:49:12.254 #6 0x7f7c47e06159 in ??
05-Feb-2020 08:49:12.254 #7 0x7f7c47699fa3 in ??
05-Feb-2020 08:49:12.254 #8 0x7f7c475ac4cf in ??
05-Feb-2020 08:49:12.254 exiting (due to assertion failure)
```
Artifacts saved. core dump present (rpzrecurs/ns3/core.7909).Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1593dnssec-policy always generates new keys2020-03-09T08:22:54Zkalfeherdnssec-policy always generates new keys
### Summary
I've been testing the dnssec-policy feature, but either I've
come across a bug, or my understanding of the configuration is incomplete.
Whenever BIND restarts, it adds a new key (or keys, depending on the
policy) into the...
### Summary
I've been testing the dnssec-policy feature, but either I've
come across a bug, or my understanding of the configuration is incomplete.
Whenever BIND restarts, it adds a new key (or keys, depending on the
policy) into the configured key directory. It uses this new key or keys
to sign the zone, apparently ignoring previously created keys, although
the DNSKEY records remain within the zone. I have observed the same
behaviour if I initiate an rndc loadkeys <zone>.
I've tried both the default policy and an explicitly configured policy
with the same results.
There's nothing in the logs indicating an error loading previous keys.
Although the behaviour I described above appeared to apply to both ZSK and KSKs, I have not been able to reliably reproduce the fault with ZSKs. The behaviour is repeatable for KSKs.
### BIND version used
```
BIND 9.15.8 (Development Release) <id:9c5547b>
running on Linux x86_64 3.10.0-1062.9.1.el7.x86_64 #1 SMP Fri Dec 6 15:49:49 UTC 2019
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr' '--exec-prefix=/opt/isc/isc-bind/root/usr' '--bindir=/opt/isc/isc-bind/root/usr/bin' '--sbindir=/opt/isc/isc-bind/root/usr/sbin' '--sysconfdir=/etc/opt/isc/isc-bind' '--datadir=/opt/isc/isc-bind/root/usr/share' '--includedir=/opt/isc/isc-bind/root/usr/include' '--libdir=/opt/isc/isc-bind/root/usr/lib64' '--libexecdir=/opt/isc/isc-bind/root/usr/libexec' '--localstatedir=/var/opt/isc/isc-bind' '--sharedstatedir=/var/opt/isc/isc-bind/lib' '--mandir=/opt/isc/isc-bind/root/usr/share/man' '--infodir=/opt/isc/isc-bind/root/usr/share/info' '--disable-static' '--enable-dnstap' '--with-pic' '--with-gssapi' '--with-json-c' '--with-libtool' '--with-libxml2' '--without-lmdb' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--with-python' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS= -L/opt/isc/isc-bind/root/usr/lib64' 'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
compiled with protobuf-c version: 1.3.1
linked to protobuf-c version: 1.3.1
threads support is enabled
default paths:
named configuration: /etc/opt/isc/isc-bind/named.conf
rndc configuration: /etc/opt/isc/isc-bind/rndc.conf
DNSSEC root key: /etc/opt/isc/isc-bind/bind.keys
nsupdate session key: /var/opt/isc/isc-bind/run/named/session.key
named PID file: /var/opt/isc/isc-bind/run/named/named.pid
named lock file: /var/opt/isc/isc-bind/run/named/named.lock
```
### Steps to reproduce
Add dnssec-policy to a zone.
This can be the default policy or an explicitly defined policy.
Restart BIND or reconfig or rndc loadkeys <zone> all result in the same behaviour
### What is the current *bug* behavior?
a new KSK is created each time BIND restarts, is reloaded or loadkeys is called.
These keys are added to the configured key directory.
DNSKEY RRset is signed by all relevant keys (type 257)
### What is the expected *correct* behavior?
New keys are only generated to replace soon to be inactive keys.
Keys which are within their active period are used to sign the zone.
### Relevant configuration files
Explicit dnssec-policy from named.conf
```
dnssec-policy simple {
dnskey-ttl 3600;
keys {
ksk key-directory lifetime P6M algorithm 13;
zsk key-directory lifetime P2M algorithm 13;
};
parent-ds-ttl P1D;
parent-propagation-delay PT1H;
parent-registration-delay P1D;
publish-safety PT4H;
retire-safety PT4H;
signatures-refresh P7D;
signatures-validity P4W;
signatures-validity-dnskey P4W;
zone-max-ttl PT48H;
zone-propagation-delay PT1H;
};
```
Zone statement:
```
zone "new.org.example" IN {
type primary;
file "pri/new.org.example/new.org.example.db";
//also-notify ;
allow-query { any; };
update-policy local;
dnssec-policy "simple";
key-directory "pri/new.org.example/keys";
};
```
### Relevant logs and/or screenshots
log from
```
03-Feb-2020 00:15:38.176 general: info: received control channel command 'loadkeys new.org.example'
03-Feb-2020 00:15:38.179 dnssec: info: zone new.org.example/IN (signed): reconfiguring zone keys
03-Feb-2020 00:15:38.185 dnssec: info: keymgr: DNSKEY new.org.example/ECDSAP256SHA256/58804 (KSK) created for policy simple
03-Feb-2020 00:15:38.195 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/11836 (KSK) is now inactive
03-Feb-2020 00:15:38.196 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/17734 (KSK) is now inactive
03-Feb-2020 00:15:38.196 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/1093 (KSK) is now inactive
03-Feb-2020 00:15:38.196 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/40789 (KSK) is now inactive
03-Feb-2020 00:15:38.196 dnssec: info: Fetching new.org.example/ECDSAP256SHA256/58804 (KSK) from key repository.
03-Feb-2020 00:15:38.196 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/58804 (KSK) is now published
03-Feb-2020 00:15:38.196 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/58804 (KSK) is now active
03-Feb-2020 00:15:38.210 dnssec: info: zone new.org.example/IN (signed): next key event: 03-Feb-2020 02:00:22.179
03-Feb-2020 00:15:38.210 notify: info: zone new.org.example/IN (signed): sending notifies (serial 1580649338)
03-Feb-2020 00:19:54.330 general: info: received control channel command 'loadkeys new.org.example'
03-Feb-2020 00:19:54.331 dnssec: info: zone new.org.example/IN (signed): reconfiguring zone keys
03-Feb-2020 00:19:54.336 dnssec: info: keymgr: DNSKEY new.org.example/ECDSAP256SHA256/39638 (KSK) created for policy simple
03-Feb-2020 00:19:54.349 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/11836 (KSK) is now inactive
03-Feb-2020 00:19:54.349 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/17734 (KSK) is now inactive
03-Feb-2020 00:19:54.349 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/1093 (KSK) is now inactive
03-Feb-2020 00:19:54.349 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/40789 (KSK) is now inactive
03-Feb-2020 00:19:54.349 dnssec: info: Fetching new.org.example/ECDSAP256SHA256/39638 (KSK) from key repository.
03-Feb-2020 00:19:54.349 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/39638 (KSK) is now published
03-Feb-2020 00:19:54.349 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/39638 (KSK) is now active
03-Feb-2020 00:19:54.364 dnssec: info: zone new.org.example/IN (signed): next key event: 03-Feb-2020 02:00:22.331
03-Feb-2020 00:19:54.364 notify: info: zone new.org.example/IN (signed): sending notifies (serial 1580649594)
```
### Possible fixesFebruary 2020 (9.11.16, 9.14.11, 9.16.0, 9.16.0-S)https://gitlab.isc.org/isc-projects/bind9/-/issues/1592catalog zones fail if a zone name contains a slash2020-02-04T03:18:53ZEvan Huntcatalog zones fail if a zone name contains a slashFrancisco Obispo at Uniregistry reported that a catalog zone was failing with:
`Jan 22 12:19:40 ns2 named[7408]: catz: error "unexpected token" while trying to generate config for zone "0/27.145.96.64.in-addr.arpa"`
This is likely due ...Francisco Obispo at Uniregistry reported that a catalog zone was failing with:
`Jan 22 12:19:40 ns2 named[7408]: catz: error "unexpected token" while trying to generate config for zone "0/27.145.96.64.in-addr.arpa"`
This is likely due to the zone name containing a slash, which can't be used when it's expanded into a filename.
There's already code in `catz.c` to substitute a hash when the zone name is too long; it needs to also do so when an illegal character is found in the zone name.February 2020 (9.11.16, 9.14.11, 9.16.0, 9.16.0-S)https://gitlab.isc.org/isc-projects/bind9/-/issues/1579dnstap system test appears to be timing sensitive2020-01-23T21:20:25ZMark Andrewsdnstap system test appears to be timing sensitiveJob [#594683](https://gitlab.isc.org/isc-projects/bind9/-/jobs/594683) failed for b3f06729e51b05626ce03d31871d0d5341a9d66d:
Looking at the output below the overall counts are correct but some are are on the wrong side of the reopens.
`...Job [#594683](https://gitlab.isc.org/isc-projects/bind9/-/jobs/594683) failed for b3f06729e51b05626ce03d31871d0d5341a9d66d:
Looking at the output below the overall counts are correct but some are are on the wrong side of the reopens.
```
S:dnstap:Thu Jan 23 01:57:23 UTC 2020
T:dnstap:1:A
A:dnstap:System test dnstap
I:dnstap:PORTRANGE:14300 - 14399
I:dnstap:checking that named-checkconf detects error in bad-fstrm-reopen-interval.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-buffer-hint-max.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-buffer-hint-min.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-flush-timeout-max.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-flush-timeout-min.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-input-queue-size-max.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-input-queue-size-min.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-input-queue-size-po2.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-output-notify-threshold.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-output-queue-size-max.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-output-queue-size-min.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-reopen-interval-max.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-reopen-interval-min.conf
I:dnstap:checking that named-checkconf detects error in bad-missing-dnstap-output-view.conf
I:dnstap:checking that named-checkconf detects error in bad-missing-dnstap-output.conf
I:dnstap:checking that named-checkconf detects error in bad-size-version.conf
I:dnstap:checking that named-checkconf detects no error in good-dnstap-in-options.conf
I:dnstap:checking that named-checkconf detects no error in good-dnstap-in-view.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-reopen-interval.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-buffer-hint.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-flush-timeout.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-input-queue-size.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-output-notify-threshold.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-output-queue-model-mpsc.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-output-queue-model-spsc.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-output-queue-size.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-reopen-interval.conf
I:dnstap:checking that named-checkconf detects no error in good-size-unlimited.conf
I:dnstap:checking that named-checkconf detects no error in good-size-version.conf
I:dnstap:checking initial message counts
I:dnstap:checking UDP message counts
I:dnstap:checking TCP message counts
I:dnstap:ns1 4 expected 6
I:dnstap:failed
I:dnstap:checking AUTH_QUERY message counts
I:dnstap:ns1 2 exepcted 3
I:dnstap:failed
I:dnstap:checking AUTH_RESPONSE message counts
I:dnstap:ns1 1 expected 2
I:dnstap:failed
I:dnstap:checking CLIENT_QUERY message counts
I:dnstap:checking CLIENT_RESPONSE message counts
I:dnstap:checking RESOLVER_QUERY message counts
I:dnstap:checking RESOLVER_RESPONSE message counts
I:dnstap:checking UPDATE_QUERY message counts
I:dnstap:checking UPDATE_RESPONSE message counts
I:dnstap:checking reopened message counts
I:dnstap:checking UDP message counts
I:dnstap:checking TCP message counts
I:dnstap:ns1 2 expected 0
I:dnstap:failed
I:dnstap:checking AUTH_QUERY message counts
I:dnstap:ns1 1 exepcted 0
I:dnstap:failed
I:dnstap:checking AUTH_RESPONSE message counts
I:dnstap:ns1 1 expected 0
I:dnstap:failed
I:dnstap:checking CLIENT_QUERY message counts
I:dnstap:checking CLIENT_RESPONSE message counts
I:dnstap:checking RESOLVER_QUERY message counts
I:dnstap:checking RESOLVER_RESPONSE message counts
I:dnstap:checking UPDATE_QUERY message counts
I:dnstap:checking UPDATE_RESPONSE message counts
I:dnstap:checking dnstap-read hex output
I:dnstap:checking unix socket message counts
I:dnstap:checking UDP message counts
I:dnstap:checking TCP message counts
I:dnstap:checking AUTH_QUERY message counts
I:dnstap:checking AUTH_RESPONSE message counts
I:dnstap:checking CLIENT_QUERY message counts
I:dnstap:checking CLIENT_RESPONSE message counts
I:dnstap:checking RESOLVER_QUERY message counts
I:dnstap:checking RESOLVER_RESPONSE message counts
I:dnstap:checking UPDATE_QUERY message counts
I:dnstap:checking UPDATE_RESPONSE message counts
I:dnstap:checking reopened unix socket message counts
I:dnstap:checking UDP message counts
I:dnstap:checking TCP message counts
I:dnstap:checking AUTH_QUERY message counts
I:dnstap:checking AUTH_RESPONSE message counts
I:dnstap:checking CLIENT_QUERY message counts
I:dnstap:checking CLIENT_RESPONSE message counts
I:dnstap:checking RESOLVER_QUERY message counts
I:dnstap:checking RESOLVER_RESPONSE message counts
I:dnstap:checking UPDATE_QUERY message counts
I:dnstap:checking UPDATE_RESPONSE message counts
I:dnstap:checking large packet printing
I:dnstap:exit status: 6
R:dnstap:FAIL
E:dnstap:Thu Jan 23 01:57:39 UTC 2020
```
ns1/named.run
```
23-Jan-2020 01:57:32.093 query client=0x804949178 thread=0x8011e6400 (a.example/A): query_reset
23-Jan-2020 01:57:32.115 received control channel command 'dnstap-reopen'
23-Jan-2020 01:57:32.156 reopening dnstap destination 'dnstap.out'
23-Jan-2020 01:57:32.157 query client=0x804e3c178 thread=0x8011e5a00 (./NS): query_reset
```February 2020 (9.11.16, 9.14.11, 9.16.0, 9.16.0-S)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1572Wait for mirror zone to be deleted2020-01-23T05:19:53ZMark AndrewsWait for mirror zone to be deletedJob [#589745](https://gitlab.isc.org/isc-projects/bind9/-/jobs/589745) failed for 1c371c1dfa13733521f39dcb7a4e530293362b66:
```
I:mirror:checking that a mirror zone can be deleted using rndc (28)
I:mirror:failed
I:mirror:exit status: 1
...Job [#589745](https://gitlab.isc.org/isc-projects/bind9/-/jobs/589745) failed for 1c371c1dfa13733521f39dcb7a4e530293362b66:
```
I:mirror:checking that a mirror zone can be deleted using rndc (28)
I:mirror:failed
I:mirror:exit status: 1
R:mirror:FAIL
E:mirror:Tue Jan 21 22:28:27 UTC 2020
```
```
n=`expr $n + 1`
echo_i "checking that a mirror zone can be deleted using rndc ($n)"
ret=0
# Remove the mirror zone added in the previous test.
$RNDCCMD 10.53.0.3 delzone verify-addzone > rndc.out.ns3.test$n 2>&1 || ret=1
# Check whether the mirror zone was removed.
$DIG $DIGOPTS @10.53.0.3 +norec verify-addzone SOA > dig.out.ns3.test$n 2>&1 || ret=1
grep "NXDOMAIN" dig.out.ns3.test$n > /dev/null || ret=1
grep "flags:.* aa" dig.out.ns3.test$n > /dev/null && ret=1
grep "flags:.* ad" dig.out.ns3.test$n > /dev/null || ret=1
if [ $ret != 0 ]; then echo_i "failed"; fi
status=`expr $status + $ret`
```
```
21-Jan-2020 22:28:23.184 received control channel command 'delzone verify-addzone'
21-Jan-2020 22:28:26.422 zone verify-addzone/IN: mirror zone is no longer in use; reverting to normal recursion
21-Jan-2020 22:28:26.422 shutting down
21-Jan-2020 22:28:26.425 client @0x7f59b8010370 10.53.0.1#34239: no matching view in class 'IN'
21-Jan-2020 22:28:26.425 client @0x7f59b8010370 10.53.0.1#34239: no matching view in class
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24320
;; flags: ad; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: cde32bbbac68a62b
;; QUESTION SECTION:
;verify-addzone. IN SOA
21-Jan-2020 22:28:26.425 client @0x7f59b8010370 10.53.0.1#34239: error
21-Jan-2020 22:28:26.425 client @0x7f59b8010370 10.53.0.1#34239: send
21-Jan-2020 22:28:26.425 client @0x7f59b8010370 10.53.0.1#34239: sendto
21-Jan-2020 22:28:26.425 client @0x7f59b8010370 10.53.0.1#34239: senddone
21-Jan-2020 22:28:26.425 client @0x7f59b8010370 10.53.0.1#34239: next
21-Jan-2020 22:28:26.425 client @0x7f59b8010370 10.53.0.1#34239: endrequest
```https://gitlab.isc.org/isc-projects/bind9/-/issues/1561crash in validator2020-02-11T07:58:24ZEvan Huntcrash in validatorThe refactoring of validator.c made an intermittent crash possible if `validator_start()` is called with `val->event->message` set to `NULL`, which can occur when validating a negative cache entry.The refactoring of validator.c made an intermittent crash possible if `validator_start()` is called with `val->event->message` set to `NULL`, which can occur when validating a negative cache entry.Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1560isc_httpd and isc_httpdmgr structures are not reference counted and magic2020-02-14T13:52:47ZOndřej Surýisc_httpd and isc_httpdmgr structures are not reference counted and magicThe `isc_httpd_t` and `isc_httpdmgr_t` structures are being used in callbacks, but they don't have:
* reference counting
* magic and VALID checks
leading to crash on shutdown when the `isc_httpdmgr_t` structure being destroyed while in...The `isc_httpd_t` and `isc_httpdmgr_t` structures are being used in callbacks, but they don't have:
* reference counting
* magic and VALID checks
leading to crash on shutdown when the `isc_httpdmgr_t` structure being destroyed while in use in the `isc_socket_accept()` callback.February 2020 (9.11.16, 9.14.11, 9.16.0, 9.16.0-S)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1551Customer feature request - dnssec-signzone to handle zone signing key pre-pub...2021-08-17T08:11:03ZCathy AlmondCustomer feature request - dnssec-signzone to handle zone signing key pre-publish RRSIGs rollover gradually [ISC-support #15374]Further to the 'generating big IXFRs is undesirable' set of bug reports and feature requests, this is another wish to add to the list.
From Support ticket [#15374](https://support.isc.org/Ticket/Display.html?id=15374) and friends (who...Further to the 'generating big IXFRs is undesirable' set of bug reports and feature requests, this is another wish to add to the list.
From Support ticket [#15374](https://support.isc.org/Ticket/Display.html?id=15374) and friends (whose general theme is around manually managing zone DNSSEC keys, DNSSEC signing and zone validation ahead of propagation to client-facing authoritative edge slaves).
The use case stems from the desire to be able to have in-propagation-path zone validation to make sure that the zone is never DNSSEC-broken as a result of a botched DNSSEC-related update (user/software/process error). There is also the need to move away from single-point-of-failure in the set-up and to have a disaster recovery plan in place for all eventualities. With the current tools available, it seems that there is a move amongst TLD operators away from automatic and inline DNSSEC maintenance and in the direction of more manual processes. Another driver for this is tooling that generates zone content, with the DNSSEC maintenance being a later 'add-on' to the process.
The bottom line is, that dnssec-signzone is being used increasingly for DNSSEC signature and NSEC/NSEC3 maintenance in production environments. This is working (mostly) just fine, including it parsing the input (a previously-signed zone, either as is, or with some pre-processing to re-inject the existing RRSIGs into a modified unsigned zone) and generating only the RRSIGs that are actually needed (didn't exist before, or older RRSIG needs refreshing etc..).
All good - except when we approach ZSK key rollover. In most instances, the favoured method is pre-publication of the new ZSK, followed by a gradual replacement of RRSIGs as they reach expiry, until all have been replaced, following which the old ZSK can be removed from the zone. Inline signing and 'auto-dnssec maintain' handle this exactly as needed (except that it's then not impossible, but harder to introduce a signed-zone validation step between zone update and zone propagation to client-facing slaves - and don't forget also, the other requirement for high-availability and disaster recovery).
The lack of support for pre-publication ZSK rollover by dnssec-signzone has been tackled once before - see:
```
3686. [func] "dnssec-signzone -Q" drops signatures from keys
that are still published but no longer active.
[RT #34990]
9.10.0, 9.9.5
```
This, at least, allows the RRSIGs to be 'swapped' between the old and the new keys. But alas, it then generates a massive diff between the old and new version of the zone, instead of the desired gradual roll of RRSIGs. We already know that large IXFRs are undesirable (ref #1515, #1516, #1518, #1519), so the lack of support by dnssec-signzone for gradual RRSIG replacement is disappointing.
Please could we have a new option - one that runs hand in hand with -Q and controls whether or not unexpired RRSIGs from the old key are replaced with new ones from the new key, or not, on this specific run of dnssec-sigzone. (It is assumed that the operator will run dnssec-signzone many times during rollover period - this is under their control and not something that dnssec-signzone itself would need to manage).September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1529Add ThreadSanitizer core dumping flags when we are ThreadSanitizer-clean2021-03-23T08:05:15ZMichal NowakAdd ThreadSanitizer core dumping flags when we are ThreadSanitizer-clean`abort_on_error=1 disable_coredump=0` should be added to `TSAN_OPTIONS_COMMON` in the .gitlab-ci.yml when we are ThreadSanitizer-clean so we get GDB to analyze core dumps in TSAN CI jobs. (Originated here https://gitlab.isc.org/isc-proje...`abort_on_error=1 disable_coredump=0` should be added to `TSAN_OPTIONS_COMMON` in the .gitlab-ci.yml when we are ThreadSanitizer-clean so we get GDB to analyze core dumps in TSAN CI jobs. (Originated here https://gitlab.isc.org/isc-projects/bind9/merge_requests/2699#note_99092.)March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)