BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-02-24T07:54:16Zhttps://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/3146Known issues with "dig" in BIND 9.182022-06-14T14:04:06ZMichał KępieńKnown issues with "dig" in BIND 9.18This issue attempts to be an exhaustive list of all known post-!4115
(BIND 9.18+) issues with `dig`.
- [x] #2307 "dig @localhost" does not fall back to 127.0.0.1 if ::1 is not answering
- [ ] #2331 Check whether `dig +trace` works o...This issue attempts to be an exhaustive list of all known post-!4115
(BIND 9.18+) issues with `dig`.
- [x] #2307 "dig @localhost" does not fall back to 127.0.0.1 if ::1 is not answering
- [ ] #2331 Check whether `dig +trace` works on main
- [ ] #2345 dig fails with "isc_nm_tcpdnsconnect: address in use" on OpenBSD
- [x] #3020 netmgr/netmgr.c:1737: (...) failed
- [x] #3028 dig crashes when interrupted while waiting for TCP response
- [x] #3128 "dig" from BIND 9.18.0 does not recover from a isc_nm_udpconnect() failure
- [x] #3144 "dig { +trace | +nssearch } +tcp" always crashes in BIND 9.18+
- [x] #3145 "dig +nssearch" does not exit until interrupted in BIND 9.18+
- [x] #3205 Assertion failure in dig with "+tcp" option and multiple servers when there is a connection error
- [x] #3207 dig +nssearch org crashes when network is unreachable
- [ ] #3217 dig +dscp stopped working
- [x] #3244 use-after-free in dighost.c/dig.c
- [x] #3248 dig can get stuck when using a server with a IPv4 mapped IPv6 addressNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4303dnstap logging based on rcode2023-09-13T14:09:41ZPetr Špačekpspacek@isc.orgdnstap logging based on rcode### Motivation
When FORMERR or SERVFAIL happen in the middle of resolution, we don't have exact information what we have sent and what exactly came back. We have to guess and attempt to reproduce the problem with `dig` or other tools.
#...### Motivation
When FORMERR or SERVFAIL happen in the middle of resolution, we don't have exact information what we have sent and what exactly came back. We have to guess and attempt to reproduce the problem with `dig` or other tools.
### Request
Add parameter to `dnstap` statement which would allow logging just selected RCODEs. Presumably FORMERR and/or SERVFAIL. I imagine that this could be so low-touch that it could be running in production indefinitely (as a cyclic buffer).
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4233dig: add +human option2023-08-08T13:04:27ZJulia Evansdig: add +human option### Description
I've spent a lot of time explaining `dig` to newcomers to DNS over the years, and I've found that they generally find `dig`'s output format to be very inscrutable. Of course, there's always `+short` or `+noall +answer` f...### Description
I've spent a lot of time explaining `dig` to newcomers to DNS over the years, and I've found that they generally find `dig`'s output format to be very inscrutable. Of course, there's always `+short` or `+noall +answer` for a terser output, but I generally want to explain more advanced DNS concepts to people (like glue records or SOA records for example), and for that you do need the full output.
Some specific things that I find confusing in dig's default output: ([example output here](https://gist.github.com/jvns/2d252e3f54a86ee6b2ea001e733a8e78))
* There's some ASCII art decoration (`<<>> DiG 9.10.6 <<>>`, `->>HEADER<<-`) that feels very ad hoc and it's hard to tell initially if those symbols are supposed to have some technical meaning. (why is `->>HEADER<--` styled like that, but not `OPT PSEUDOSECTION`?)
* the header is split across 2 lines, and it's not completely clear that the second line is also part of the header
* overall, it's not obvious which pieces of information are part of the DNS response itself and which aren't. For example, is `global options: +cmd` part of the DNS response? (of course it isn't, I don't think that's immediately obvious)
* There's no newline between `OPT PSEUDOSECTION` and `QUESTION SECTION`, but there is a newline between `QUESTION SECTION` and `ANSWER SECTION`. There seems to be no reason for that inconsistency.
* In `MSG SIZE rcvd: 56`, why are there two spaces between `SIZE` and `rcvd`? Are there more fields in `MSG SIZE`? (I checked the source code and the answer is no, the code says `printf(";; MSG SIZE rcvd: %u\n", bytes);`, so it seems like this is just an ad hoc choice)
* The `;;` prefix is confusing to many people. I realize it's because `;` it's the comment character in a zone file, but I personally do not use `bind` or zone files and most DNS users I talk to don't either: they either use web-based admin consoles to administrate their DNS records or do it through an API like Route 53. So the `;` character isn't familiar.
These might sound a little nitpicky -- each of these things on its own is pretty minor, and of course most users of dig learn to ignore them. But taken together I've found that newcomers are often misled into thinking that DNS responses are much more complicated than they actually are, which is really unfortunate.
I find the way Wireshark displays DNS packets to be much more clear ([screenshot](https://jvns.ca/images/dns-wireshark.png)), even though they're both working at around the same level of detail.
### Request
I realize that `dig`'s default output format needs to remain relatively stable because people parse it in scripts. But would ISC be open to adding a `+human` (or something) option to dig that's designed to be more intuitive for newcomers to dig? Similarly to how `du` has an `-h` option.
I'm imagining something like this:
```
$ dig +human example.com
Received response from 192.168.1.1:53 (UDP), 68 bytes in 16ms
HEADER:
status: NOERROR
opcode: QUERY
id: 15451
flags: qr rd ra
records: QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
OPT PSEUDOSECTION:
EDNS: version: 0, flags: None, udp: 4096
QUESTION SECTION:
example.com. IN A
ANSWER SECTION:
example.com. 78709 IN A 93.184.216.34
```
I think the important thing is to make it easy for a newcomer to see at a glance that there are 4 parts to this DNS response (the header, the EDNS record, the question, and the answer)
I created a very rough proof of concept at https://github.com/jvns/dig-pretty that parses dig's `+yaml` format and outputs a format like what I suggested above, with a tiny bit of syntax highlighting for the DNS status code.
### Alternatives I've considered
* `+short` or `+noall +answer` are great for a lot of use cases, but as I mentioned above, they don't work for more advanced usage like looking at the `SOA` record on a `NXDOMAIN` response.
* We already have `+yaml`, but I find `+yaml` to be extremely verbose (the output for `dig +yaml example.com` doesn't fit in my terminal window), and it's really a machine format and not a human format.
* There are also alternative DNS tools (like `dog`) that aim to be more user friendly, but in general I've found those tools to be missing important features that `dig` has.
Thanks for considering this! I love dig and would love to see it become a little more approachable.
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4446deprecate --enable-fixed-rrset / rrset-order fixed2024-03-07T19:20:29ZPetr Špačekpspacek@isc.orgdeprecate --enable-fixed-rrset / rrset-order fixed### Discussion
I wonder if we should deprecate `configure --enable-fixed-rrset`? It seems that it might create trouble down the road when we try to improve database/node structure...
We don't have to touch it for QPDB in 9.20, but I th...### Discussion
I wonder if we should deprecate `configure --enable-fixed-rrset`? It seems that it might create trouble down the road when we try to improve database/node structure...
We don't have to touch it for QPDB in 9.20, but I think it will get in our way when we fix #3405.
### Proposal
Deprecate deprecate `configure --enable-fixed-rrset` / `rrset-order fixed` statement in 9.20, remove in 9.21.
### Links / referencesBIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4370Check that a zone is served by IPv6 servers if it has AAAA records2023-12-05T09:04:32ZMark AndrewsCheck that a zone is served by IPv6 servers if it has AAAA recordsOne thing that is often forgotten when turning on an IPv6 service is to ensure that the zone holding the AAAA records for that service is also served over IPv6. This can be relatively easy be checked for by named-checkzone by looking fo...One thing that is often forgotten when turning on an IPv6 service is to ensure that the zone holding the AAAA records for that service is also served over IPv6. This can be relatively easy be checked for by named-checkzone by looking for AAAA records in the zone contents, including glue AAAA records, and then checking that there are AAAA records published for some of the nameservers if any are found (in zone or elsewhere). This can also sometimes be determined by named without needing to look beyond the zone's contents, but cannot be guaranteed.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3729Drop RHEL/CentOS 7 support after 30. June 20242023-03-14T16:11:32ZOndřej SurýDrop RHEL/CentOS 7 support after 30. June 2024RHEL/CentOS 7 Maitentance Phase 2 ends on 30. June 2024. As BIND 9.20 will be released in Q.I 2024, there's little point in supporting RHEL/CentOS/Oracle/RockyLinux/... 7 in BIND 9.19 now. We should also drop the support for RHEL-and-c...RHEL/CentOS 7 Maitentance Phase 2 ends on 30. June 2024. As BIND 9.20 will be released in Q.I 2024, there's little point in supporting RHEL/CentOS/Oracle/RockyLinux/... 7 in BIND 9.19 now. We should also drop the support for RHEL-and-clones 7 support after 30. June 2024 in BIND 9.18.
- Phase I - drop EL7 support in 9.19+
- [x] Drop EL7 jobs from GitLab CI for `main` (https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7346)
- [x] Remove EL7 bind-dev RPM builds from Cloudsmith pipeline (https://gitlab.isc.org/isc-private/rpms/bind/-/merge_requests/19)
- [x] Remove EL7 buildroot from [isc/bind-dev](https://copr.fedorainfracloud.org/coprs/isc/bind-dev/) COPR
- [x] Update installation instructions on `isc/bind-dev` COPR so that they do not include EL7-specific bits
- [ ] [Remove](https://help.cloudsmith.io/docs/delete-a-package#bulk-package-delete) old 9.19 EL7 packages from bind-dev Cloudsmith repo (after a few months)
- Phase II - drop EL7 support in 9.18 (after EOL - 2024-06-30)
- [ ] Drop EL7 jobs from GitLab CI for `v9_18`
- [ ] Drop EL7-specific parts from all Packer image recipes
- [ ] Drop EL7 support from the `packager:rpm` Docker image
- [ ] Drop EL7-specific parts from BIND RPM build&test scripts
- [ ] Remove EL7 buildroots from COPR
- [ ] Update installation instructions on COPR so that they do not include EL7-specific bits
- [ ] Remove EL7 from CI images build scripts ([Docker](https://gitlab.isc.org/isc-projects/images/-/blob/main/docker/bind9/oraclelinux-template/Dockerfile), [Packer](https://gitlab.isc.org/isc-projects/images/-/tree/main/packer/oraclelinux), ...)
- [ ] Remove all EL7 packages from Cloudsmith (after a few months); update "Due date"Michał KępieńMichał Kępień2024-06-30https://gitlab.isc.org/isc-projects/bind9/-/issues/3650Support not crossing the XFR streams2023-11-09T21:01:32ZMark AndrewsSupport not crossing the XFR streams### Description
#### Goal
Make BIND in the role of **secondary** to play nicely with multi-master infrastructures.
In large topologies people want to avoid SPOF anywhere in the DNS infrastructure. Other people provide tools to accept D...### Description
#### Goal
Make BIND in the role of **secondary** to play nicely with multi-master infrastructures.
In large topologies people want to avoid SPOF anywhere in the DNS infrastructure. Other people provide tools to accept DNS UPDATE at multiple servers in parallel and then resynchronize databases using their own protocols, which is not consistent with monotonic and unique SOA SERIAL mapping to a single version of zone data.
Multi-master primaries can go up and down at any time - that's why people do want multi-master in the first place!
#### Problems in practice
- Replication between primaries (using proprietary protocols) takes non-zero time.
- SOA serials are generally not consistent/cannot be relied upon.
- IXFR is total mess when switching between primaries.
- AXFR and NOTIFY is unreliable - SOA serial might indicate there are no new data while there actually are.
- Primaries might do independent signing - RRSIGs inconsistent (IXFR trouble again).
### Request
Extend the primaries the syntax to support **sets** of primaries to which server the same zone contents, and switch between them when the current set is unreachable.
Sets are needed to support topologies where BIND secondary is not speaking directly to the primaries but is somewhere deeper down in the replication tree.
Proposal:
```
primaries [set #] ... { ... };
```
Record the set number in the raw file. "255 sets must be good enough for everyone."
#### Caveats
- Secondaries with sets configured now require `masterfile-format raw`.
- Config change might mess up mapping between primary sets and number recorded in the raw zone file.
### Links / references
Who is doing multi-master, for different purposes:
- Windows Active Directory DNS - very common, does not maintain SOA serial consistency across topology.
- Some TLDs do independent DNSSEC signers to avoid SPOF.
- FreeIPA - multi-master DNS - like Windows AD but for Unix, independent DNSSEC signers (different RRSIGs on each DNS server), does not maintain strict SOA serial consistency.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3218Enable the deferred fatality of missing glue / servers from BIND 9.5.02022-06-01T15:46:12ZMark AndrewsEnable the deferred fatality of missing glue / servers from BIND 9.5.0Missing glue on referral and address record on SRV records was supposed to be made fatal in BIND 9.5.0.
See the comments in lib/dns/zone.c of the form "/* XXX950 make fatal for 9.5.0. */"
Delegating NS records that refer to CNAMEs or n...Missing glue on referral and address record on SRV records was supposed to be made fatal in BIND 9.5.0.
See the comments in lib/dns/zone.c of the form "/* XXX950 make fatal for 9.5.0. */"
Delegating NS records that refer to CNAMEs or names below DNAMEs, NS records that provably refer to names in the parent zone that don't exist or don't have address records, and missing glue records where all intended to be made fatal errors when loading a primary zone in BIND 9.5.0. They either make the delegation fail or make it less robust (perceived redundancy is not present). Additionally many users expect named-checkzone to reject such broken delegations when they can be detected. These checks are controlled by check-integrity, check-sibling determines if address records under sibling delegations are also checked for.
These configuration errors where made warnings during the 9.4.0 maintenance period.
Additionally SRV records which refer to non-existing names or names without addresses where also flagged to be made fatal errors for primary zones. Again this is done under the check-integrity umbrella. Again many users expect named-checkzone to fail on such obvious errors.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1836Return Extended EDNS Errors (EDE)2023-11-02T16:58:15ZMark AndrewsReturn Extended EDNS Errors (EDE)This is a Summary issue. Please open individual issues for individual code points.
There are 25 defined EDE codes. Some will be possible to return easily, others not so. See [RFC 8914](https://datatracker.ietf.org/doc/html/rfc8914) for...This is a Summary issue. Please open individual issues for individual code points.
There are 25 defined EDE codes. Some will be possible to return easily, others not so. See [RFC 8914](https://datatracker.ietf.org/doc/html/rfc8914) for explanation of the error codes.
* [ ] 0 - Other
* [ ] 1 - Unsupported DNSKEY Algorithm #2715
* [ ] 2 - Unsupported DS Digest Type #2715
* [x] 3 - Stale Answer #2267 (9.18.3, 9.19.1)
* [x] 4 - Forged Answer #3410 (9.19.5)
* [ ] 5 - DNSSEC Indeterminate #2715
* [ ] 6 - DNSSEC Bogus #2715
* [ ] 7 - Signature Expired #2715
* [ ] 8 - Signature Not Yet Valid #2715
* [ ] 9 - DNSKEY Missing #2715
* [ ] 10 - RRSIGs Missing #2715
* [ ] 11 - No Zone Key Bit Set #2715
* [ ] 12 - NSEC Missing #2715
* [ ] 13 - Cached Error
* [ ] 14 - Not Ready
* [x] 15 - Blocked #3410 (9.19.5)
* [x] 16 - Censored #3410 (9.19.5)
* [x] 17 - Filtered #3410 (9.19.5)
* [x] 18 - Prohibited (9.17.21), #3410 (9.19.5)
* [x] 19 - Stale NXDOMAIN Answer #2267 (9.18.3, 9.19.1)
* [ ] 20 - Not Authoritative
* [ ] 21 - Not Supported
* [ ] 22 - No Reachable Authority #2268
* [ ] 23 - Network Error
* [ ] 24 - Invalid DataNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2545Add standalone journal downgrade tool.2022-03-01T09:41:17ZMark AndrewsAdd standalone journal downgrade tool.This should be in python / perl. Without this users who upgrade to 9.16/9.17 will be unable to rollback if they find they need to.This should be in python / perl. Without this users who upgrade to 9.16/9.17 will be unable to rollback if they find they need to.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2301Add FIPS mode enabled builds to GitLab CI2022-06-22T15:06:44ZMichal NowakAdd FIPS mode enabled builds to GitLab CIBIND9 supports FIPS mode (`--enable-fips-mode`) but is not regularly tested in the CI. For this to happen this needs to be accomplished:
- [ ] Basic FIPS build fixes integrated https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/...BIND9 supports FIPS mode (`--enable-fips-mode`) but is not regularly tested in the CI. For this to happen this needs to be accomplished:
- [ ] Basic FIPS build fixes integrated https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4281 ([performs](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4281/diffs#87db583be5c13c1f7b3c958b10e03d67b6a2ca06) builds with `--enable-fips-mode`)
- [ ] System test can run without MD5 (there's plenty of `algorithm hmac-md5;` in system test or implicit expectation of MD5 in `dig` invocations in `acl` and `allow-query` system tests)
- [ ] Red Hat FIPS patches by @pemensik at https://src.fedoraproject.org/rpms/bind/tree/master for `v9_11` evaluated
- [ ] FIPS-enabled host or VM image (most likely with CentOS)
- [ ] CI job(s) with `--enable-fips-mode` in the build stage and subsequent unit and system test CI jobsNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4482Remove the "dnssec-must-be-secure" feature2023-12-07T10:23:58ZMichał KępieńRemove the "dnssec-must-be-secure" featureSee #4263 for the deprecation issue.
Full removal is expected to happen in the 9.21/9.22 development cycle
and it should only affect the development branch.See #4263 for the deprecation issue.
Full removal is expected to happen in the 9.21/9.22 development cycle
and it should only affect the development branch.BIND 9.21.x2024-12-01https://gitlab.isc.org/isc-projects/bind9/-/issues/3843Remove options allowing source ports to be specified2024-01-31T08:53:45ZMichał KępieńRemove options allowing source ports to be specifiedWith the options allowing source ports to be specified being deprecated
in 9.18 & 9.19/9.20, all the code associated with those options should
subsequently be completely removed in the 9.21/9.22 cycle, as previously
announced on *bind-us...With the options allowing source ports to be specified being deprecated
in 9.18 & 9.19/9.20, all the code associated with those options should
subsequently be completely removed in the 9.21/9.22 cycle, as previously
announced on *bind-users*:
https://lists.isc.org/pipermail/bind-users/2023-January/107165.html
The following features are going to be marked as ancient and made
non-functional:
* specifying `port` in the following statements:
- `query-source`
- `query-source-v6`
- `transfer-source`
- `transfer-source-v6`
- `notify-source`
- `notify-source-v6`
- `parental-source`
- `parental-source-v6`
* the following statements as a whole:
- `use-v4-udp-ports`
- `use-v6-udp-ports`
- `avoid-v4-udp-ports`
- `avoid-v6-udp-ports`
See #3781 for the corresponding option deprecation issue.Not plannedMichał KępieńMichał Kępień2024-03-01https://gitlab.isc.org/isc-projects/bind9/-/issues/3442Remove the "max-zone-ttl" option (on options/zone level)2024-03-01T04:29:28ZMichał KępieńRemove the "max-zone-ttl" option (on options/zone level)The `max-zone-ttl` option should now be configured as part of
`dnssec-policy`. The option with the same name on `options` and `zone`
levels should be removed.
!6542 deprecated that sort of use. This issue serves as a reminder to
ultim...The `max-zone-ttl` option should now be configured as part of
`dnssec-policy`. The option with the same name on `options` and `zone`
levels should be removed.
!6542 deprecated that sort of use. This issue serves as a reminder to
ultimately remove the relevant code altogether.
The due date for this issue has been set to an arbitrary date that is
presumed to fall within the BIND 9.21 development cycle.
See #2918, !6542Not plannedEvan HuntEvan Hunt2024-08-01https://gitlab.isc.org/isc-projects/bind9/-/issues/1905Forbid the asterisk (*) single character domains on non-leaf level in the mas...2023-11-02T16:58:16ZOndřej SurýForbid the asterisk (*) single character domains on non-leaf level in the master zonesCurrently, the `sub.*.example.com` is a valid and legal domain name. But not everything that's legal is right and this is a perfect example, as the domain in question is not a wildcard domain name covering `sub.<anything>.example.com`, ...Currently, the `sub.*.example.com` is a valid and legal domain name. But not everything that's legal is right and this is a perfect example, as the domain in question is not a wildcard domain name covering `sub.<anything>.example.com`, but a single domain name `sub.*.example.com` where `*` is literal asterisk character. Remember that `*` has no special meaning in the `QNAME`, it is only processed as `*` when loading the zone files.Not planned