BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-02-24T07:53:48Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4554Signature expiration calculation backwards compatibility bug2024-02-24T07:53:48ZMatthijs Mekkingmatthijs@isc.orgSignature expiration calculation backwards compatibility bugThe `signatures-refresh` option determines when RRSIG records need to be refreshed. Signatures that expire within this time are refreshed.
However, the code is also using this to determine the jitter. It uses a jitter range of 0 to `sig...The `signatures-refresh` option determines when RRSIG records need to be refreshed. Signatures that expire within this time are refreshed.
However, the code is also using this to determine the jitter. It uses a jitter range of 0 to `signatures-validity - signatures-refresh`) which is wrong: it should be using a range of 0 to `signatures-refresh`.
The `sig-validity-interval` that was used for `auto-dnssec` defined two parameters, the first being the signatures validity (same as `dnssec-policy`'s `signatures-validity`), the optional second one being the minimum bound of the signatures validity. It also serves as a signatures refresh. Basically the refresh value is the difference between the first and second parameter.
So the second parameter actually has two meanings: It serves as a jitter and a refresh value.
With `dnssec-policy` there is not yet a way to define `jitter`. The `signatures-refresh` is actually defined as the.
Two things need to be done:
- [x] Add a configuration option to `dnssec-policy` to set desired jitter.
- [x] Ensure resign interval is used correctly.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4458dnssec auto fails across multiple views + unable to add/remove DS records fro...2023-12-04T05:39:28ZTom Shawdnssec auto fails across multiple views + unable to add/remove DS records from second view + invalid DS records### Summary
- When using multiple views, the affected views fail to manage dnssec properly
- When using dnssec to auto sign zones, across multiple views, all but one of the views will fail to add DS records through nsupdate.
- The view ...### Summary
- When using multiple views, the affected views fail to manage dnssec properly
- When using dnssec to auto sign zones, across multiple views, all but one of the views will fail to add DS records through nsupdate.
- The view fails to manage and purge old key/state/private files and these start to build up over time
- Unable to get DS records, publish CDS log entries stop appearing for the view
### BIND version used
BIND 9.18.20-1+ubuntu22.04.1+deb.sury.org+1-Ubuntu
### Steps to reproduce
Create a config which has two views, with the same domain in each view. One of the views must only be available to an internal ip range (internal), the other must be available from all (external). Enable dnssec on both domains in both views using separate policies.
### What is the current *bug* behavior?
- keys in the internal view will not be managed correctly and will build up over time
- nsupdate will appear to add/delete the DS records correctly but these are not added or deleted in bind.
### What is the expected *correct* behavior?
- keys in both views should be managed correctly
- nsupdate should be able to manipulate the DS records in the internal view
### Relevant configuration files
I will share my configs privately if possible
Use this yearly internal policy for TDL level domains
```
dnssec-policy "yearly-internal" {
keys {
ksk lifetime P365D algorithm ECDSAP384SHA384;
zsk lifetime P1D algorithm ECDSAP384SHA384;
};
//
dnskey-ttl PT5M;
publish-safety PT3M;
retire-safety PT5M;
purge-keys PT10M;
// Signature timings
signatures-refresh PT5M;
signatures-validity PT10M;
signatures-validity-dnskey PT10M;
//
max-zone-ttl PT5M;
parent-ds-ttl PT3M;
parent-propagation-delay PT3M;
nsec3param iterations 10 optout no salt-length 16;
};
Use this aggressive standard internal policy for sub domains
dnssec-policy "standard" {
keys {
ksk lifetime PT40M algorithm ECDSAP384SHA384;
zsk lifetime PT20M algorithm ECDSAP384SHA384;
};
//
dnskey-ttl 60;
publish-safety PT2M;
retire-safety PT2M;
purge-keys PT10M;
// Signature timings
signatures-refresh PT5M;
signatures-validity PT10M;
signatures-validity-dnskey PT10M;
//
max-zone-ttl 300;
parent-ds-ttl 60;
parent-propagation-delay 60;
nsec3param iterations 10 optout no salt-length 16;
};
options {
check-names master ignore;
check-names slave ignore;
check-names response ignore;
masterfile-format text;
listen-on-v6 { none; };
listen-on port 53 { 127.0.0.1; 165.227.238.11; 10.0.254.1; 10.0.254.2; };
directory "/var/cache/bind";
auth-nxdomain no; # conform to RFC1035
querylog yes;
pid-file "/var/run/named/named.pid";
include "/etc/bind/named.options.transfer.conf";
# if running a natted server, set the public ip address here
# this will not work in a multihomed box (specifically linode fails)
# notify the NS servers - only on master
notify yes;
# some dnssec stuff
include "/etc/bind/named.options.dnssec.conf";
max-cache-size 10485760;
};
```
Zone file
```
#ns1.node.flipkick.media
zone "entitywind.dev" {
key-directory "/var/cache/bind/keys/internals-master";
file "internals.master.dev.entitywind.db";
update-policy {
grant 127.0.0.1 subdomain entitywind.dev;
grant internal subdomain entitywind.dev;
grant internal zonesub any;
grant internal-externaldns subdomain entitywind.dev;
grant internal-externaldns zonesub any;
grant internal-rndc-key subdomain entitywind.dev;
grant internal-rndc-key zonesub any;
};
include "/etc/bind/named.zone.internals-master.conf";
include "/etc/bind/named.zone.dnssec.policy.yearly-internal.conf";
parental-agents { "externals"; };
};
#ns1.node.flipkick.media
zone "node.entitywind.dev" {
key-directory "/var/cache/bind/keys/internals-master";
file "internals.master.dev.entitywind.db";
update-policy {
grant 127.0.0.1 subdomain entitywind.dev;
grant internal subdomain entitywind.dev;
grant internal zonesub any;
grant internal-externaldns subdomain entitywind.dev;
grant internal-externaldns zonesub any;
grant internal-rndc-key subdomain entitywind.dev;
grant internal-rndc-key zonesub any;
};
include "/etc/bind/named.zone.internals-master.conf";
include "/etc/bind/named.zone.dnssec.policy.yearly-internal.conf";
parental-agents { "externals"; };
};
```
### Relevant logs and/or screenshots
```
28-Nov-2023 12:58:02.305 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/25339 (KSK) is now inactive
28-Nov-2023 12:58:02.309 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/53449 (KSK) is now inactive
28-Nov-2023 12:58:02.309 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/43625 (KSK) is now inactive
28-Nov-2023 12:58:02.309 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/26195 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/33520 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/26171 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/37281 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/7041 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/63692 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/9156 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/29571 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/44364 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/44662 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/40817 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/22890 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/64449 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/39830 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/30931 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/57355 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/23733 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/25059 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/20634 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/2754 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/19617 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/61960 (KSK) is now inactive
```
### Possible fixes
Run two bind servers and attach to differing ipshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4453Switching to a different dnssec-policy broke my zone.2024-02-24T07:54:16ZBjörn PerssonSwitching to a different dnssec-policy broke my zone.### Summary
My zone was previously signed with a KSK and a ZSK with unlimited lifetime. I switched the zone over to a dnssec-policy using CSKs and automatic key rotation. After the DS record was updated, most of the RRSIG records were r...### Summary
My zone was previously signed with a KSK and a ZSK with unlimited lifetime. I switched the zone over to a dnssec-policy using CSKs and automatic key rotation. After the DS record was updated, most of the RRSIG records were removed, leaving the zone broken to validating resolvers.
### BIND version used
```
# named -V
BIND 9.18.19-1~deb12u1-Debian (Extended Support Version) <id:>
running on Linux x86_64 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/bind9-9.18.19=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 12.2.0
compiled with OpenSSL version: OpenSSL 3.0.10 1 Aug 2023
linked to OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.52.0
linked to libnghttp2 version: 1.52.0
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
linked to maxminddb version: 1.7.1
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
I have two zones that both exist in an external and an internal view. Each zone was previously signed with a KSK and a ZSK with unlimited lifetime. To proceed cautiously with the change to `dnssec-policy` I defined one policy that matched the existing keys and another that would use CSKs and automatic key rotation:
```
dnssec-policy "as_it_was" {
keys {
ksk lifetime unlimited algorithm rsasha256 2048;
zsk lifetime unlimited algorithm rsasha256 2048;
};
dnskey-ttl P1D;
purge-keys 0;
};
dnssec-policy "automation" {
keys {
csk lifetime P1M algorithm rsasha256 2048;
};
dnskey-ttl P1D;
max-zone-ttl P1D;
signatures-validity P1W;
signatures-refresh P2D;
};
```
First I switched the zones from "`auto-dnssec maintain;`" to "`dnssec-policy as_it_was;`". Bind continued using the existing keys. Once I had the exchange of CDS and DS records working between my zones and the parent zone, I switched one zone over to "`dnssec-policy automation;`" in both views.
The rollover from the old keys to a CSK seemed to go smoothly, but after a while I discovered that the zone was only partially signed in the external view. Several records lacked RRSIG records. Dynamic updates of the unsigned records caused corresponding RRSIG records to appear.
After that initial problem, the following rollover from one CSK to another worked fine, so I proceeded to switch the second zone over to "`dnssec-policy automation;`". This time I took notes and watched for missing signatures.
2023-11-18 16:05:49 a CSK was generated. DNSKEY, CDS and CDNSKEY were signed with both the old KSK and the CSK. SOA got a new signature by the old ZSK. All other records kept their existing signatures.
2023-11-19 17:10:49 CDS and CDNSKEY records for the CSK were published. DNSKEY, CDS and CDNSKEY got new signatures by the KSK and the CSK. SOA was signed with the ZSK and the CSK.
2023-11-20 17:10:49 Bind noticed that DS had been updated in the parent zone.
2023-11-20 18:15:49 the ZSK and all its signatures were removed. DNSKEY, CDS and CDNSKEY got new signatures by the CSK and the KSK. SOA got a new signature by the CSK. All other records were left without RRSIG records.
This time I fixed the external view with "`rndc sign xn--rombobjrn-67a.se IN external`". All the unsigned records were then signed with the CSK. DNSKEY, CDS, CDNSKEY and SOA had their signatures renewed. I left the internal view alone.
2023-11-21 19:10:50 the KSK was removed. DNSKEY, CDS, CDNSKEY and SOA got new signatures by the CSK. At the same time, many but not all other records in the internal view were finally signed with the CSK, having lacked signatures for 24 hours and 55 minutes. Some more records were signed a few minutes later.
As I'm posting this, one NS and one MX record in the internal view are still unsigned after more than four days.
### What is the current *bug* behavior?
The zone becomes only partially signed. Validating resolvers reject the unsigned records.
### What is the expected *correct* behavior?
All records should be signed with the new key before the old keys and signatures are removed.
### Relevant configuration files
See the policies above. After the changes, all the zone declarations look essentially like this:
```
zone "xn--rombobjrn-67a.se" {
type master;
file "/var/lib/bind/db.xn--rombobjrn-67a.se.external";
dnssec-policy automation;
parental-agents { ::1; };
inline-signing no;
update-policy { [omitted] };
};
```
### Relevant logs and/or screenshots
Excerpts from the system log:
```
2023-11-19T17:10:49.436468+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-19T17:10:49.437286+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-19T17:10:49.488666+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-19T17:10:49.489192+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-19T17:10:49.501444+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-19T17:10:49.502076+01:00 cutie named[443161]: CDS (SHA-256) for key xn--rombobjrn-67a.se/RSASHA256/53584 is now deleted
2023-11-19T17:10:49.502515+01:00 cutie named[443161]: CDNSKEY for key xn--rombobjrn-67a.se/RSASHA256/53584 is now deleted
2023-11-19T17:10:49.502904+01:00 cutie named[443161]: CDS for key xn--rombobjrn-67a.se/RSASHA256/17339 is now published
2023-11-19T17:10:49.503279+01:00 cutie named[443161]: CDNSKEY for key xn--rombobjrn-67a.se/RSASHA256/17339 is now published
2023-11-19T17:10:49.530343+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-19T17:10:49.530897+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-19T17:10:49.534298+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-19T17:10:49.534962+01:00 cutie named[443161]: CDS (SHA-256) for key xn--rombobjrn-67a.se/RSASHA256/53584 is now deleted
2023-11-19T17:10:49.535337+01:00 cutie named[443161]: CDNSKEY for key xn--rombobjrn-67a.se/RSASHA256/53584 is now deleted
2023-11-19T17:10:49.535684+01:00 cutie named[443161]: CDS for key xn--rombobjrn-67a.se/RSASHA256/17339 is now published
2023-11-19T17:10:49.536038+01:00 cutie named[443161]: CDNSKEY for key xn--rombobjrn-67a.se/RSASHA256/17339 is now published
2023-11-19T17:10:49.637732+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 19-Nov-2023 18:10:49.432
2023-11-19T17:10:49.638433+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092737)
2023-11-19T17:10:49.651717+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 19-Nov-2023 18:10:49.432
2023-11-19T17:10:49.673263+01:00 cutie named[443161]: client @0x7efdf9b21368 10.1.0.5#54619 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092736 -> 2023092737)
2023-11-19T17:10:49.674244+01:00 cutie named[443161]: client @0x7efdf9b21368 10.1.0.5#54619 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 1 messages, 23 records, 5465 bytes, 0.004 secs (1366250 bytes/sec) (serial 2023092737)
2023-11-19T17:10:50.192637+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.2.1#57043 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092736 -> 2023092737)
2023-11-19T17:10:50.193661+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.2.1#57043 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 1 messages, 23 records, 5465 bytes, 0.001 secs (5465000 bytes/sec) (serial 2023092737)
```
```
2023-11-20T17:10:49.472806+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-20T17:10:49.473891+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-20T17:10:49.525113+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T17:10:49.525655+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T17:10:49.529210+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T17:10:49.530341+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 20-Nov-2023 18:10:49.466
2023-11-20T17:10:49.557565+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T17:10:49.558183+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T17:10:49.561418+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T17:10:49.562620+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 20-Nov-2023 18:10:49.466
2023-11-20T17:10:49.617384+01:00 cutie named[443161]: keymgr: checkds DS for key xn--rombobjrn-67a.se/RSASHA256/17339 seen published at Mon Nov 20 17:10:49 2023
2023-11-20T17:10:49.621343+01:00 cutie named[443161]: keymgr: checkds DS for key xn--rombobjrn-67a.se/RSASHA256/53584 seen withdrawn at Mon Nov 20 17:10:49 2023
2023-11-20T17:10:49.624985+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-20T17:10:49.667546+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T17:10:49.668097+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T17:10:49.671602+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T17:10:49.672714+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 20-Nov-2023 18:15:49.618
2023-11-20T17:10:50.027333+01:00 cutie named[443161]: keymgr: checkds DS for key xn--rombobjrn-67a.se/RSASHA256/17339 seen published at Mon Nov 20 17:10:50 2023
2023-11-20T17:10:50.031352+01:00 cutie named[443161]: keymgr: checkds DS for key xn--rombobjrn-67a.se/RSASHA256/53584 seen withdrawn at Mon Nov 20 17:10:50 2023
2023-11-20T17:10:50.035151+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-20T17:10:50.077904+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T17:10:50.078540+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T17:10:50.081828+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T17:10:50.083015+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 20-Nov-2023 18:15:49.030
```
```
2023-11-20T18:15:49.036472+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-20T18:15:49.076389+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T18:15:49.077010+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T18:15:49.088905+01:00 cutie named[443161]: Removing expired key xn--rombobjrn-67a.se/13398/RSASHA256 from DNSKEY RRset.
2023-11-20T18:15:49.089406+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK) is now deleted
2023-11-20T18:15:49.089784+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T18:15:49.192756+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 20-Nov-2023 18:20:49.033
2023-11-20T18:15:49.193416+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092738)
2023-11-20T18:15:49.275467+01:00 cutie named[443161]: client @0x7efdebdc6d68 10.1.0.5#41397 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092737 -> 2023092739)
2023-11-20T18:15:49.278365+01:00 cutie named[443161]: client @0x7efdebdc6d68 10.1.0.5#41397 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 3 messages, 128 records, 38648 bytes, 0.004 secs (9662000 bytes/sec) (serial 2023092739)
2023-11-20T18:15:49.622949+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-20T18:15:49.664238+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-20T18:15:49.664712+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-20T18:15:49.667624+01:00 cutie named[443161]: Removing expired key xn--rombobjrn-67a.se/13398/RSASHA256 from DNSKEY RRset.
2023-11-20T18:15:49.668019+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK) is now deleted
2023-11-20T18:15:49.668373+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-20T18:15:49.764336+01:00 cutie named[443161]: client @0x7efdebdc5168 10.1.2.1#58091 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092737 -> 2023092739)
2023-11-20T18:15:49.767341+01:00 cutie named[443161]: client @0x7efdebdc5168 10.1.2.1#58091 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 3 messages, 128 records, 38648 bytes, 0.004 secs (9662000 bytes/sec) (serial 2023092739)
2023-11-20T18:15:49.779256+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 20-Nov-2023 18:20:49.621
2023-11-20T18:15:54.192437+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092739)
```
```
2023-11-21T13:15:40.402451+01:00 cutie named[443161]: received control channel command 'sign xn--rombobjrn-67a.se IN external'
2023-11-21T13:15:40.405362+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-21T13:15:40.431241+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T13:15:40.431697+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T13:15:40.433742+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now inactive
2023-11-21T13:15:40.528574+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 21-Nov-2023 19:10:50.395
2023-11-21T13:15:40.529172+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092740)
2023-11-21T13:15:40.773096+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.0.5#33623 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092739 -> 2023092742)
2023-11-21T13:15:40.774513+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.0.5#33623 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 1 messages, 46 records, 12419 bytes, 0.004 secs (3104750 bytes/sec) (serial 2023092742)
2023-11-21T13:15:41.172719+01:00 cutie named[443161]: client @0x7efdf9b20568 10.1.2.1#33203 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092739 -> 2023092745)
2023-11-21T13:15:41.174657+01:00 cutie named[443161]: client @0x7efdf9b20568 10.1.2.1#33203 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 2 messages, 89 records, 24907 bytes, 0.004 secs (6226750 bytes/sec) (serial 2023092745)
2023-11-21T13:15:45.528370+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092750)
2023-11-21T13:15:45.561710+01:00 cutie named[443161]: client @0x7efdebdc6d68 10.1.0.5#52787 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092742 -> 2023092750)
2023-11-21T13:15:45.564494+01:00 cutie named[443161]: client @0x7efdebdc6d68 10.1.0.5#52787 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 2 messages, 114 records, 31108 bytes, 0.004 secs (7777000 bytes/sec) (serial 2023092750)
2023-11-21T13:15:46.078928+01:00 cutie named[443161]: client @0x7efdfa51bd68 10.1.2.1#60701 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092745 -> 2023092750)
2023-11-21T13:15:46.080874+01:00 cutie named[443161]: client @0x7efdfa51bd68 10.1.2.1#60701 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 2 messages, 71 records, 18769 bytes, 0.001 secs (18769000 bytes/sec) (serial 2023092750)
```
```
2023-11-21T19:10:50.400377+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-21T19:10:50.432532+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:10:50.433038+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:10:50.443664+01:00 cutie named[443161]: Removing expired key xn--rombobjrn-67a.se/53584/RSASHA256 from DNSKEY RRset.
2023-11-21T19:10:50.444123+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now deleted
2023-11-21T19:10:50.511795+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 21-Nov-2023 19:15:50.396
2023-11-21T19:10:50.512265+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092751)
2023-11-21T19:10:50.576696+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.0.5#54307 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092750 -> 2023092752)
2023-11-21T19:10:50.577645+01:00 cutie named[443161]: client @0x7efdfa51af68 10.1.0.5#54307 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 1 messages, 27 records, 5832 bytes, 0.001 secs (5832000 bytes/sec) (serial 2023092752)
2023-11-21T19:10:50.626991+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-21T19:10:50.660686+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:10:50.661150+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:10:50.663077+01:00 cutie named[443161]: Removing expired key xn--rombobjrn-67a.se/53584/RSASHA256 from DNSKEY RRset.
2023-11-21T19:10:50.663489+01:00 cutie named[443161]: DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK) is now deleted
2023-11-21T19:10:50.738310+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 21-Nov-2023 19:15:50.624
2023-11-21T19:10:51.191122+01:00 cutie named[443161]: client @0x7efdf9b20568 10.1.2.1#43631 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR started (serial 2023092750 -> 2023092752)
2023-11-21T19:10:51.191859+01:00 cutie named[443161]: client @0x7efdf9b20568 10.1.2.1#43631 (xn--rombobjrn-67a.se): view external: transfer of 'xn--rombobjrn-67a.se/IN': IXFR ended: 1 messages, 27 records, 5832 bytes, 0.001 secs (5832000 bytes/sec) (serial 2023092752)
2023-11-21T19:10:55.511787+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: sending notifies (serial 2023092752)
2023-11-21T19:15:50.404325+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-21T19:15:50.427941+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:15:50.428397+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:15:50.440377+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 21-Nov-2023 19:20:49.398
2023-11-21T19:15:50.630905+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-21T19:15:50.656580+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:15:50.657098+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:15:50.659929+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 21-Nov-2023 19:20:49.626
2023-11-21T19:20:49.405293+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-21T19:20:49.429191+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:20:49.429646+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:20:49.438021+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 21-Nov-2023 19:20:50.399
2023-11-21T19:20:49.630959+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-21T19:20:49.656677+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:20:49.657172+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:20:49.659897+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 21-Nov-2023 19:20:50.627
2023-11-21T19:20:50.401138+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: reconfiguring zone keys
2023-11-21T19:20:50.427552+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:20:50.428010+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:20:50.434902+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/external: next key event: 21-Nov-2023 20:20:50.399
2023-11-21T19:20:50.629148+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: reconfiguring zone keys
2023-11-21T19:20:50.654607+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/13398 (ZSK)
2023-11-21T19:20:50.655054+01:00 cutie named[443161]: keymgr: retire DNSKEY xn--rombobjrn-67a.se/RSASHA256/53584 (KSK)
2023-11-21T19:20:50.657686+01:00 cutie named[443161]: zone xn--rombobjrn-67a.se/IN/internal: next key event: 21-Nov-2023 20:20:50.627
```
Some possibly useful status data from when the zone lacked signatures:
```
# rndc dnssec -status xn--rombobjrn-67a.se IN external
dnssec-policy: automatik
current time: Tue Nov 21 12:57:26 2023
key: 17339 (RSASHA256), CSK
published: yes - since Sat Nov 18 16:05:49 2023
key signing: yes - since Sat Nov 18 16:05:49 2023
zone signing: yes - since Sat Nov 18 16:05:49 2023
Next rollover scheduled on Mon Dec 18 15:00:49 2023
- goal: omnipresent
- dnskey: omnipresent
- ds: rumoured
- zone rrsig: omnipresent
- key rrsig: omnipresent
key: 13398 (RSASHA256), ZSK
published: no
zone signing: no
Key has been removed from the zone
- goal: hidden
- dnskey: hidden
- zone rrsig: unretentive
key: 53584 (RSASHA256), KSK
published: yes - since Sun Nov 3 04:26:07 2019
key signing: yes - since Sun Nov 3 04:26:07 2019
Rollover is due since Sun Nov 19 18:05:49 2023
- goal: hidden
- dnskey: omnipresent
- ds: unretentive
- key rrsig: omnipresent
# rndc zonestatus xn--rombobjrn-67a.se IN external
name: xn--rombobjrn-67a.se
type: primary
files: /var/lib/bind/db.xn--rombobjrn-67a.se.external
serial: 2023092739
nodes: 42
last loaded: Tue, 24 Oct 2023 12:43:57 GMT
secure: no
key maintenance: automatic
next key event: Tue, 21 Nov 2023 18:10:50 GMT
dynamic: yes
frozen: no
reconfigurable via modzone: no
```
The output of `rndc zonestatus` changed when I ran `rndc sign`:
```
# rndc zonestatus xn--rombobjrn-67a.se IN external
name: xn--rombobjrn-67a.se
type: primary
files: /var/lib/bind/db.xn--rombobjrn-67a.se.external
serial: 2023092750
nodes: 42
last loaded: Tue, 24 Oct 2023 12:43:57 GMT
secure: yes
inline signing: no
key maintenance: automatic
next key event: Tue, 21 Nov 2023 18:10:50 GMT
next resign node: 7c2ecd07f155648431e0f94b89247d713c5786e1e73e953f2fe7eca3._openpgpkey.xn--rombobjrn-67a.se/NSEC
next resign time: Wed, 22 Nov 2023 22:55:09 GMT
dynamic: yes
frozen: no
reconfigurable via modzone: no
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4423named starts up slow when many zones reference the same dnssec-policy2024-02-24T07:54:22ZMatthijs Mekkingmatthijs@isc.orgnamed starts up slow when many zones reference the same dnssec-policyWhile rolling out KASP to many zones, it is more efficient to use more DNSSEC policies in order to improve
reload/reconfig times.
When all zones or referenced by the same `dnssec-policy`, it takes quite some time to process all zones af...While rolling out KASP to many zones, it is more efficient to use more DNSSEC policies in order to improve
reload/reconfig times.
When all zones or referenced by the same `dnssec-policy`, it takes quite some time to process all zones after reload/reconfig and CPU usage of the named process remains at 100% and it takes quite a few minutes for named to start responding to queries after such a reload/reconfig request.
When spreading my zones to 10 identical policies, cpu usage goes well above 100% (using more threads I assume) and this is speeding
things up really nice.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4161Support quantum safe DNSSEC algorithms2023-06-27T07:27:28ZPetr Špačekpspacek@isc.orgSupport quantum safe DNSSEC algorithms### Description
Reportedly US government is going to mandate post-quantum algorithm support from 2026 onward, with no legacy algorithms allowed after 2033.
### Request
Explore how we can integrate quantum safe algorithms for early exp...### Description
Reportedly US government is going to mandate post-quantum algorithm support from 2026 onward, with no legacy algorithms allowed after 2033.
### Request
Explore how we can integrate quantum safe algorithms for early experimentation.
Many algorithms are already available as OpenSSL provider here: https://github.com/open-quantum-safe/oqs-provider
### Additional details
* [FALCON implementation in PowerDNS](https://indico.dns-oarc.net/event/42/contributions/902/attachments/871/1601/Post-Quantum%20DNSSEC%20with%20FALCON-512%20and%20PowerDNS(2).pdf)
* [Verisign's presentation](https://indico.dns-oarc.net/event/46/contributions/985/attachments/938/1728/OARC40-ResearchAgendaForAPQCDNSSEC-Final.pdf)
Word of mouth from Red Hat crypto people I talked to:
Right now it seems that NIST might standardize 5 algorithms, with several variants for each algorithm with intent to provide 128/256 bit-equivalent of security.
Rambling about candidate algorithms for DNSSEC:
- HSS/LMS & XMSS^MT algorithms are extremely susceptible to key reuse. One key reuse ruins the whole thing. Don't use it.
- Falcon-512 has smallest signatures by large margin (around 666 bytes). CRYSTALS-Dillithium are built on the same principle but have larger signatures (about 2420 bytes). The problem is, both are reportedly built on shaky grounds because we as humankind don't fully understand the math behind them, so chances for breaking these algorithms in couple years are non-negligible.
- The remaining candidate algorithm is SPHINCS+-128. That one is most solid because it's based on ordinary hashes, which are well understood. The catch is that one signature is about 7856 bytes :exploding_head:
Consequently, this sounds like we need very good very solid TCP/TLS/QUIC support in client and server, so we are not limited to UDP packet sizes. That's IMHO the only way to go without significantly changing the protocol.
(Or we can go and engineer DNS 2.0 :grinning:)
### Links / referencesLong-term2026-01-01https://gitlab.isc.org/isc-projects/bind9/-/issues/3277Follow-up from "Draft: Don't delete CDS DELETE after zone sign"2022-04-12T13:18:41ZMatthijs Mekkingmatthijs@isc.orgFollow-up from "Draft: Don't delete CDS DELETE after zone sign"The following discussion from !5706 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5706#note_259110):
While the changes are fine. I'm worried about a disconnect betwe...The following discussion from !5706 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5706#note_259110):
While the changes are fine. I'm worried about a disconnect between parent and child over the signalling method (CDS vs CDNSKEY) in use. Always publishing matching CDS DELETE and CDNSKEY DELETE records avoids this.
When an update adds a CDS DELETE record, BIND should also add the corresponding CDNSKEY DELETE record (if not already done in the update), and vice versa. Also when an update removes a CDS DELETE record, BIND should remove the corresponding CDNSKEY DELETE record (if not already done in the update), and vice versa.
It is unclear what the desired behavior is if an update adds a CDS DELETE record and removes a CDNSKEY DELETE record at the same time.
Note that with `dnssec-policy` the CDS DELETE and CDNSKEY DELETE records are already synced (when setting `dnssec-policy` to `insecure`).Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1756Derive maximum zone TTL from zone contents2023-07-26T08:54:49ZMatthijs Mekkingmatthijs@isc.orgDerive maximum zone TTL from zone contentsThe dnssec-policy system should look into the Zone as the default method of finding the "maximum zone TTL".
Currently `max-zone-ttl` defaults to 24 h. This silently breaks RRs with larger TTLs if rollover is happening. This is rare, but...The dnssec-policy system should look into the Zone as the default method of finding the "maximum zone TTL".
Currently `max-zone-ttl` defaults to 24 h. This silently breaks RRs with larger TTLs if rollover is happening. This is rare, but still a bug.
TTL caps for caches
-------------------
* BIND v9_19_0 default for 7 days
* Knot Resolver 5.5.0: 6 days
Knot DNS 3.1 (authoritative) computes the value from zone data already.Not plannedMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1732"rndc loadkeys" and "rndc sign" provide no feedback on missing or unreadable ...2023-11-02T16:51:56ZMichael Graff"rndc loadkeys" and "rndc sign" provide no feedback on missing or unreadable keysWhen using inline-signing, issuing a "rndc loadkeys" where there are no keys, the key directory specified in the config is unreadable, or the key files themselves are unreadable due to permission issues, no error is logged.
This made de...When using inline-signing, issuing a "rndc loadkeys" where there are no keys, the key directory specified in the config is unreadable, or the key files themselves are unreadable due to permission issues, no error is logged.
This made debugging fairly difficult.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1690BIND signer should enforce RFC6840 Section 5.112023-11-02T16:51:55ZOndřej SurýBIND signer should enforce RFC6840 Section 5.11There are couple issues I found when investigating #1689:
1. RSASHA256 CSK (SEP bit set), publish-only ED25519 ZSK
```
Verifying the zone using the following algorithms: RSASHA512.
Zone fully signed:
Algorithm: RSASHA512: KSKs: 1 active...There are couple issues I found when investigating #1689:
1. RSASHA256 CSK (SEP bit set), publish-only ED25519 ZSK
```
Verifying the zone using the following algorithms: RSASHA512.
Zone fully signed:
Algorithm: RSASHA512: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 0 active, 0 stand-by, 0 revoked
Algorithm: ED25519: KSKs: 0 active, 0 stand-by, 0 revoked
ZSKs: 0 active, 1 stand-by, 0 revoked
```
2. RSASHA256 CSK (SEP bit set), ED25519 ZSK (treated as CSK)
```
Verifying the zone using the following algorithms: RSASHA512 ED25519.
Zone fully signed:
Algorithm: RSASHA512: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 0 active, 0 stand-by, 0 revoked
Algorithm: ED25519: KSKs: 0 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
```
3. Single ZSK key (no SEP bit) is treated as CSK
```
Verifying the zone using the following algorithms: ED25519.
Zone fully signed:
Algorithm: ED25519: KSKs: 0 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
```
All of these scenarios should be rejected both by `dnssec-signzone` and inline signing.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1634Simplify adding CDS and CDNSKEY deletion records to a inline zone.2023-11-02T16:51:54ZMark AndrewsSimplify adding CDS and CDNSKEY deletion records to a inline zone.From bind-users.
```
There are no DNSKEY records in that zone. CDS and CDNSKEY must be signed for the
parent to accept them. There must be DNSKEY records present for them to be signed.
Add a DNSKEY record to that test zone and it will...From bind-users.
```
There are no DNSKEY records in that zone. CDS and CDNSKEY must be signed for the
parent to accept them. There must be DNSKEY records present for them to be signed.
Add a DNSKEY record to that test zone and it will load.
For inline zone just copy the final DNSKEY RRset from the signed version of the
zone to the raw zone when adding the deletion CDS and CDNSKEY records. Wait for
the parent zone to remove the DS records, then remove the CDS, CDNSKEY, and DNSKEY
records from the raw zone.
```
Possibly extend `rndc signing` to add and remove CDS and CDNSKEY deletion records
from the zone signed zone.
If the DNSKEY RRset becomes empty as a result of key timings remove CDS and CDNSKEY
records from the zone.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1307More jitter distribution tests2021-10-04T20:08:32ZMatthijs Mekkingmatthijs@isc.orgMore jitter distribution testsThe following discussion from !2451 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/2451#note_83060):
> A couple of more jitter tests could be added:
> 1. In...The following discussion from !2451 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/2451#note_83060):
> A couple of more jitter tests could be added:
> 1. Initial zone sign.
> 2. Changing from NSEC to NSEC3.
> 3. Changing from NSEC3 to NSEC.
> 4. Changing the NSEC3PARAM record.
> 5. Large dynamic update.
> 6. Large change in zone file (inline-signing) that triggers a zone resign.https://gitlab.isc.org/isc-projects/bind9/-/issues/1128[ISC-support #22100] Offline KSK2024-03-26T10:42:53ZMatthijs Mekkingmatthijs@isc.org[ISC-support #22100] Offline KSKImplement offline key support.
This will require signatures for `DNSKEY`, `CDS`, and `CDNSKEY` RRsets to be generated in advance. This is done with a Key Signing Request (`KSR`). On the system with the KSK provide the `KSR` and ask to c...Implement offline key support.
This will require signatures for `DNSKEY`, `CDS`, and `CDNSKEY` RRsets to be generated in advance. This is done with a Key Signing Request (`KSR`). On the system with the KSK provide the `KSR` and ask to create signed RRsets for each period (resulting in Signed Key Responses (`SKR`)).
This also means that `DNSKEY` records for the ZSK need to be pregenerated, because ZSK rollovers may take place while the KSK is offline.
This also means that "Offline KSK" does not work in conjunction with a CSK because we need to resign the zone contents periodically.
Pregenerating keys can be done with `dnssec-keygen`, or some other method. But we need to provide a `dnssec-policy` and a duration for how long a period we need to create SKRs. For example if you have a policy where ZSKs are rolled every 3 months, and you want to keep the KSK offline for a year, the key generation utility should create 4 keys. The keys should have additional metadata that sets `Predecessor` and `Successor` key metadata and/or set the `Published` and `Remove` timing metadata.
We need to load the `SKR` files. Probably import it before hand with `rndc reconfig` or `rndc import skr` or something. Then when BIND decides to rekey it needs to lookup the correct `DNSKEY`, `CDNSKEY`, and `CDS` records from the `SKR` sign, and when BIND decides to resign it needs to lookup the signatures from the same `SKR` data.
When BIND starts a new key rollover, it should select the right key. This is determined by the metadata. The new keyset must match the `SKR` data.
If the `dnssec-policy` changes, the KSR process needs to be done again and the new SKR files should be imported.
So the following changes to the code and documentation need to be made:
- [ ] Create a tool `dnssec-ksr` for dealing with KSRs (!8188)
- [ ] Add an option to `dnssec-ksr` to generate keys given an interval and a DNSSEC policy (!8188)
- [ ] Add an option to `dnssec-ksr` to create `KSR` files given an interval, a DNSSEC policy, and some keys (!8188)
- [ ] Add an option to `dnssec-ksr` to sign `KSR` files, generating `SKR` files to be imported into BIND (!8188)
- [ ] Create signed `CDS` and `CDNSKEY` RRsets in the `SKR` files (!8188)
- [ ] Add a configuration option for `named` to set a `SKR` directory.
- [ ] Add a command line option for `rndc` to import a `SKR` file or directory.
- [ ] When rekeying, make sure that the `DNSKEY`, `CDNSKEY`, and `CDS` records match the `SKR` data.
- [ ] When resigning, lookup the signature in the `SKR` data rather than trying to generate a new signature.
- [ ] Add a checkconf check that Offline KSK cannot work with CSK.
- [ ] Add documentation about Offline KSK to the ARM and DNSSEC guide.BIND 9.19.xMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1127Add configuration for type of key rollover2023-09-07T05:11:21ZMatthijs Mekkingmatthijs@isc.orgAdd configuration for type of key rolloverWe can either decide to choose the optimal key rollover, or we can let the user to configure what key rollover they want to use.We can either decide to choose the optimal key rollover, or we can let the user to configure what key rollover they want to use.Not plannedMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/928DNSSEC utilities truncate existing files when saving keys2023-11-02T16:42:09ZMichał KępieńDNSSEC utilities truncate existing files when saving keys[`dst_key_tofile()`][1] and [`dst__privstruct_writefile()`][2] open their destination files using `fopen()` with mode `w`, which causes the opened file to be truncated. These functions are used by certain DNSSEC utilities which work on ...[`dst_key_tofile()`][1] and [`dst__privstruct_writefile()`][2] open their destination files using `fopen()` with mode `w`, which causes the opened file to be truncated. These functions are used by certain DNSSEC utilities which work on existing files, e.g. `dnssec-settime`. If such a utility is used to modify a key file just as named tries to read it, the latter may consider the file to be empty and abort or postpone the operation in progress.
While the time window within which this issue can be triggered is pretty narrow, it already happened in practice - in https://gitlab.isc.org/isc-projects/bind9/-/jobs/189696, during the `autosign` test:
1. The `delzsk.example` zone is switched to NSEC3:
```
06-Mar-2019 14:27:20.682 received control channel command 'signing -nsec3param 1 1 10 12345678 delzsk.example.'
```
2. `zone_nsec3chain()` starts creating the NSEC3 chain and finally adds the NSEC3PARAM record at zone apex:
```
06-Mar-2019 14:27:20.695 add delzsk.example. 0 IN NSEC3PARAM 1 0 10 12345678
```
3. The test checks whether the NSEC3PARAM is present before moving on:
```
06-Mar-2019 14:27:20.720 client @0x7f6768039350 10.53.0.1#34567 (delzsk.example): query 'delzsk.example/NSEC3PARAM/IN' approved
```
4. Right after this happens, `dnssec-settime` is called to set the deletion date for the inactive ZSK. This happens to coincide with the final `zone_nsec3chain()` call:
```
06-Mar-2019 14:27:20.735 zone_nsec3chain: zone delzsk.example/IN: enter
06-Mar-2019 14:27:20.736 dns_dnssec_findzonekeys2: error reading Kdelzsk.example.+007+19943.private: end of file
06-Mar-2019 14:27:20.736 zone delzsk.example/IN: zone_nsec3chain:dns__zone_findkeys -> end of file
06-Mar-2019 14:27:20.736 zone delzsk.example/IN: zone_nsec3chain: end of file
```
This temporarily prevents the private record indicating that the NSEC3 chain is being created from being removed from the zone apex, triggering a false positive for the above check due to an extra line being present in the `rndc signing -list` output inspected after running `rndc loadkeys`.
The way I see it, there are two separate issues to address here:
1. **DNSSEC utilities should never cause key files to become truncated.** I think this problem should be addressed by writing the key to a temporary file first and then moving it into the existing key file's place. However, that would be a functional change which I believe could not be backported because it would break e.g. `dnssec-settime` for users storing key files in non-writable directories.
2. **The aforementioned check in the `autosign` system test should be tweaked to prevent false positives from occurring.** This change should be backported to all maintained branches.
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/f285dd9a0828ba472645e61e5e9608c852aa31b6/lib/dns/dst_api.c#L1582
[2]: https://gitlab.isc.org/isc-projects/bind9/blob/f285dd9a0828ba472645e61e5e9608c852aa31b6/lib/dns/dst_parse.c#L642Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/844dnssec-checkds KSK rollover enhancements2023-11-02T16:32:29ZTony Finchdnssec-checkds KSK rollover enhancementsThis issue is a list of enhancements to `dnssec-checkds` intended to support automatic KSK rollovers.
The context for this is that `dnssec-keymgr` needs to have an interlock in the KSK rollover process to make sure the parent zone is u...This issue is a list of enhancements to `dnssec-checkds` intended to support automatic KSK rollovers.
The context for this is that `dnssec-keymgr` needs to have an interlock in the KSK rollover process to make sure the parent zone is up-to-date before `dnssec-keymgr` proceeds to make any potentially breaking changes. The current manual page sensibly suggests using `dnssec-checkds` for this purpose.
I intend to work on these features; this issue is for sketching out what I plan to work on and for refining the plan.
## CDS / CDNSKEY support
At the moment, `dnssec-checkds` is unaware of CDS and CDNSKEY records.
It should be improved so that (in its normal mode of operation) `dnssec-checkds` will verify that the parent DS records match the child's CDS records. Unlike the current behaviour (which checks the delegation works, rather than being consistent) no differences will be permitted.
The idea is that CDS records are used to communicate the rollover state from `dnssec-keymgr` to `dnssec-checkds`, so `dnssec-checkds` only needs to look at the DNS, not at the keys on disk.
## DS digest algorithm control
At the moment, `dnssec-checkds` expects both SHA-1 and SHA-256 DS digests. This should be amended to SHA-256 only by default.
When `dnssec-checkds` is comparing DS records against CDNSKEY or DNSKEY RRsets, it should be possible for the invoker to specify algorithms that must be present, or must not be present, or no preference.
## Recursive vs authoritative lookups
At the moment, `dnssec-checkds` queries via the default recursive server. There is a risk that it will get a falsely positive answer if there is a large propagation delay between parental authoritative servers, but the local resolver happens to be talking to a parental server with a low delay.
In authoritative mode, `dnssec-checkds` should get the list of parent servers from the local resolver, then query each of them, and ensure they all give the OK.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/704named fails to generate missing DNSSEC signatures for NSEC3 records generated...2023-11-02T16:25:43ZMichał Kępieńnamed fails to generate missing DNSSEC signatures for NSEC3 records generated by a previous instanceIf NSEC3 chain creation is requested when no signing keys are available, NSEC3 records will be created but not signed. If `named` is shutdown in the middle of such a chain creation process and subsequently restarted, NSEC3 records gener...If NSEC3 chain creation is requested when no signing keys are available, NSEC3 records will be created but not signed. If `named` is shutdown in the middle of such a chain creation process and subsequently restarted, NSEC3 records generated by the previous `named` instance will remain unsigned.
This is due to the fact that when `named` is restarted, NSEC3 chain creation is started from scratch (since database iterator state is not maintained between restarts) and if a pre-existing NSEC3 record is found by `dns_nsec3_addnsec3()`, it will [first remove the old record and then re-add an identical one][1]. This is not an issue in itself but the subsequent call to `do_one_tuple()` involves [invoking `dns_diff_appendminimal()`][2], which in turn removes changes which cancel each other out from the diff structure. In the case of `dns_nsec3_addnsec3()`, the diff structure in question is the one that is subsequently [passed to `dns__zone_updatesigs()`][3], which means that in order for any NSEC3 record to be (re)signed, it must be present in that diff structure; this will be the case for newly created NSEC3 records but not for these which were already present in the zone database; it will also not be an issue for records which were both pre-existing and signed before `named` was restarted since their signatures would simply be preserved.
(Related to [Support RT #13752][4])
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/026817bd9c6c58c8ee98cccf12a9308b0ed8f25a/lib/dns/nsec3.c#L707-716
[2]: https://gitlab.isc.org/isc-projects/bind9/blob/026817bd9c6c58c8ee98cccf12a9308b0ed8f25a/lib/dns/nsec3.c#L318
[3]: https://gitlab.isc.org/isc-projects/bind9/blob/026817bd9c6c58c8ee98cccf12a9308b0ed8f25a/lib/dns/zone.c#L8080-8082
[4]: https://support.isc.org/Ticket/Display.html?id=13752Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/697Do not attempt to generate DNSSEC records when required keys are not present2022-03-01T09:36:55ZMichael McNallyDo not attempt to generate DNSSEC records when required keys are not present### Description
Recently a customer who is responsible for a very large zone accidentally initiated resigning when no ZSK was present (they keep it off-line and only mount it when required.) The results were not good.
### Request
If ...### Description
Recently a customer who is responsible for a very large zone accidentally initiated resigning when no ZSK was present (they keep it off-line and only mount it when required.) The results were not good.
### Request
If BIND cannot properly perform a signing action because required keys are not present it should fail (loudly) without altering the zone.
### Links / references
https://support.isc.org/Ticket/Display.html?id=13752Not planned