BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-12-04T05:39:28Zhttps://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/4449too long CNAME chains do not elicit SERVFAIL or even log message2023-11-23T15:08:44ZPetr Špačekpspacek@isc.orgtoo long CNAME chains do not elicit SERVFAIL or even log message### Summary
CNAME chain length is currently limited to ~ 16 steps. Chains longer than this limit are cut short, but the RDCODE is still NOERROR. This creates impression that the final hop might be NODATA answer.
Also I can't see any lo...### Summary
CNAME chain length is currently limited to ~ 16 steps. Chains longer than this limit are cut short, but the RDCODE is still NOERROR. This creates impression that the final hop might be NODATA answer.
Also I can't see any log message in logs that resolution was terminated prematurely.
### BIND version used
* ~"Affects v9.19": a819d3644634997a78b162988156e90f409e1ce8
* ~"Affects v9.18": 6817bf1284fe8aea303365d2dd17bc5523e7a41b
* ~"Affects v9.16": 161d69aba357fa830bb6ef2b097b0447929041f0
* ~"Affects v9.11 (EoL)" : v9.11.37-S1
* Other versions were not tested
### Steps to reproduce
* Setup an auth zone with too long CNAME chain:
- [local.zone](/uploads/af4b4f699adb8b3bf87d5cac31b5d33f/local.zone)
- [named.conf](/uploads/2a0c44310bfbe99a2ffe6bbc1b36bacc/named.conf)
Query for it in default resolver config.
### What is the current *bug* behavior?
RCODE=NOERROR despite the incomplete CNAME chain.
```
$ dig c0000.local.testiscorg.ch. A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20544
;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 102100bdc30994f717d0d76d655f5b7d3a1f039d04cd3a86 (good)
;; QUESTION SECTION:
;c0000.local.testiscorg.ch. IN A
;; ANSWER SECTION:
c0000.local.testiscorg.ch. 0 IN CNAME c0001.local.testiscorg.ch.
c0001.local.testiscorg.ch. 0 IN CNAME c0002.local.testiscorg.ch.
c0002.local.testiscorg.ch. 0 IN CNAME c0003.local.testiscorg.ch.
c0003.local.testiscorg.ch. 0 IN CNAME c0004.local.testiscorg.ch.
c0004.local.testiscorg.ch. 0 IN CNAME c0005.local.testiscorg.ch.
c0005.local.testiscorg.ch. 0 IN CNAME c0006.local.testiscorg.ch.
c0006.local.testiscorg.ch. 0 IN CNAME c0007.local.testiscorg.ch.
c0007.local.testiscorg.ch. 0 IN CNAME c0008.local.testiscorg.ch.
c0008.local.testiscorg.ch. 0 IN CNAME c0009.local.testiscorg.ch.
c0009.local.testiscorg.ch. 0 IN CNAME c0010.local.testiscorg.ch.
c0010.local.testiscorg.ch. 0 IN CNAME c0011.local.testiscorg.ch.
c0011.local.testiscorg.ch. 0 IN CNAME c0012.local.testiscorg.ch.
c0012.local.testiscorg.ch. 0 IN CNAME c0013.local.testiscorg.ch.
c0013.local.testiscorg.ch. 0 IN CNAME c0014.local.testiscorg.ch.
c0014.local.testiscorg.ch. 0 IN CNAME c0015.local.testiscorg.ch.
c0015.local.testiscorg.ch. 0 IN CNAME c0016.local.testiscorg.ch.
c0016.local.testiscorg.ch. 0 IN CNAME c0017.local.testiscorg.ch.
```
### What is the expected *correct* behavior?
Same output but SERVFAIL.
### Relevant logs and/or screenshots
There is no log message indicating that the chain was cut prematurely. Here's named log running at `-d 99` from the main branch: [named.log](/uploads/4e9e9f8c70bf4fbc187082914a4b06ac/named.log)
### Other implementations
- PowerDNS Recursor 4.9.1 SERVFAILs and cuts the chain on c0011
- Knot Resolver 5.7.0 SERVFAILs and cuts the chain on c0013
- Unbound 1.19.0 commit 197bf154 SERVFAILs and does not return anything in the ANSWER section. [PCAP](/uploads/abb00b0409388e4a5cedf867a934e9f7/dns.pcap) suggests it stops chasing after encountering c0011.https://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/4444TCP fallback does not happen on bind 9.18.112023-12-19T09:16:56ZShota HinoTCP fallback does not happen on bind 9.18.11
### Summary
After upgrading bind9 from v9.18.10 to v9.18.11, we found that TCP fallback no longer happens. The previous behavior on bind v9.18.10 was that after UDP queries time out, named falls back to TCP. We identified that this ch...
### Summary
After upgrading bind9 from v9.18.10 to v9.18.11, we found that TCP fallback no longer happens. The previous behavior on bind v9.18.10 was that after UDP queries time out, named falls back to TCP. We identified that this change in behavior was introduced by this change https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7212.
### BIND version used
v9.18.11
### Steps to reproduce
1. Block UDP queries.
2. Observe that named does not fall back to TCP
### What is the current *bug* behavior?
TCP fallback does not happen after UDP queries time out.
### What is the expected *correct* behavior?
After UDP timeout, named falls back to use TCP.
### Relevant configuration files
```
options {
listen-on { 192.168.4.1; 127.0.0.1; }; # see warning above before changing
version "not currently available";
forwarders {
75.75.75.75;
75.75.76.76;
8.8.8.8;
8.8.4.4;
208.67.222.222;
208.67.220.220;
};
querylog yes;
# Cache and forward
recursion yes;
forward only;
# Enable dnssec
dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
max-cache-size 2m;
max-cache-ttl 3600;
# Default path is at the root directory, which is not writable by bind.
dump-file "/run/named/named_dump.db";
};
```
### Relevant logs and/or screenshots
This is the packet capture from the working version - v9.18.10. You can see that TCP fallback happens.
![Screenshot_from_2023-11-21_12-19-39](/uploads/9b85a9cac9e0b2900ac60c3baa619668/Screenshot_from_2023-11-21_12-19-39.png)
### Possible fixes
I have not fully traced the code, but TCP fallback might have been happening via the code here? https://gitlab.isc.org/isc-projects/bind9/-/blob/bind-9.18/lib/dns/resolver.c?ref_type=heads#L2600-2625.
With the said commit https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7249/diffs?commit_id=095f634f48d621da1e26e5ada5026b5427e0a0bb#23711d1cafba45a6f9e0b84f76c786435421f0e8_2631_2631, this may not happen if the retry counter never gets incremented. I could be wrong on this analysis because I did not carefully trace the code, so please take this with a grain of salt.BIND 9.21.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4434dispatch unit test is unstable2024-03-28T14:42:25ZMichal Nowakdispatch unit test is unstableEven after #4392, we keep seeing failures of the `dispatch` unit test.
`dispatch_getnext`:
- https://gitlab.isc.org/isc-projects/bind9/-/issues/4392#note_415175
- https://gitlab.isc.org/isc-projects/bind9/-/issues/4392#note_416028
`dis...Even after #4392, we keep seeing failures of the `dispatch` unit test.
`dispatch_getnext`:
- https://gitlab.isc.org/isc-projects/bind9/-/issues/4392#note_415175
- https://gitlab.isc.org/isc-projects/bind9/-/issues/4392#note_416028
`dispatch_newtcp`: Job [#3799293](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3799293) failed for 25cfec4d2b7b2d33c041a8543ab7f21191e6241c.
```
[==========] Running 10 test(s).
[ RUN ] dispatch_gettcp
[ OK ] dispatch_gettcp
[ RUN ] dispatch_newtcp
[ OK ] dispatch_newtcp
[ RUN ] dispatch_timeout_udp_response
[ OK ] dispatch_timeout_udp_response
[ RUN ] dispatchset_create
[ OK ] dispatchset_create
[ RUN ] dispatchset_get
[ OK ] dispatchset_get
[ RUN ] dispatch_timeout_tcp_response
[ OK ] dispatch_timeout_tcp_response
[ RUN ] dispatch_timeout_tcp_connect
[ OK ] dispatch_timeout_tcp_connect
[ RUN ] dispatch_tcp_response
[ OK ] dispatch_tcp_response
[ RUN ] dispatch_tls_response
[ OK ] dispatch_tls_response
[ RUN ] dispatch_getnext
0x2 != 0
[ LINE ] --- dispatch_test.c:419: error: Failure!I:dispatch_test:Core dump found: ./core.23758
D:dispatch_test:backtrace from ./core.23758 start
warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing
warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing
warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing
warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing
[New LWP 23758]
[New LWP 23799]
[New LWP 23798]
[New LWP 24634]
Downloading separate debug info for /lib/x86_64-linux-gnu/libcmocka.so.0...
Downloading separate debug info for /lib/x86_64-linux-gnu/libuv.so.1...
Downloading separate debug info for /lib/x86_64-linux-gnu/libssl.so.3...
Downloading separate debug info for /lib/x86_64-linux-gnu/libcrypto.so.3...
Downloading separate debug info for /lib/x86_64-linux-gnu/libz.so.1...
Downloading separate debug info for /lib/x86_64-linux-gnu/libjson-c.so.5...
Downloading separate debug info for /lib/x86_64-linux-gnu/libnghttp2.so.14...
Downloading separate debug info for /lib/x86_64-linux-gnu/libxml2.so.2...
Downloading separate debug info for /lib/x86_64-linux-gnu/liburcu.so.8...
Downloading separate debug info for /root/.cache/debuginfod_client/be4446e17e11dc07dd007465b7e3008bc69f905a/debuginfo...
Downloading separate debug info for /lib/x86_64-linux-gnu/liburcu-common.so.8...
Downloading separate debug info for /lib/x86_64-linux-gnu/libgssapi_krb5.so.2...
Downloading separate debug info for /lib/x86_64-linux-gnu/libkrb5.so.3...
Downloading separate debug info for /lib/x86_64-linux-gnu/libmaxminddb.so.0...
Downloading separate debug info for /lib/x86_64-linux-gnu/libfstrm.so.0...
Downloading separate debug info for /lib/x86_64-linux-gnu/libprotobuf-c.so.1...
Downloading separate debug info for /lib/x86_64-linux-gnu/liblmdb.so.0...
Downloading separate debug info for /lib/x86_64-linux-gnu/liburcu-cds.so.8...
Downloading separate debug info for /lib/x86_64-linux-gnu/libicuuc.so.72...
Downloading separate debug info for /root/.cache/debuginfod_client/0bc79e91cbc31da5a4c73b10bff30734ec138da0/debuginfo...
Downloading separate debug info for /lib/x86_64-linux-gnu/liblzma.so.5...
Downloading separate debug info for /lib/x86_64-linux-gnu/libk5crypto.so.3...
Downloading separate debug info for /lib/x86_64-linux-gnu/libcom_err.so.2...
Downloading separate debug info for /lib/x86_64-linux-gnu/libkrb5support.so.0...
Downloading separate debug info for /lib/x86_64-linux-gnu/libkeyutils.so.1...
Downloading separate debug info for /lib/x86_64-linux-gnu/libicudata.so.72...
Downloading separate debug info for /lib/x86_64-linux-gnu/libstdc++.so.6...
Downloading separate debug info for /lib/x86_64-linux-gnu/libgcc_s.so.1...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/builds/isc-projects/bind9/tests/dns/.libs/dispatch_test'.
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
Download failed: Invalid argument. Continuing without source file ./nptl/./nptl/pthread_kill.c.
44 ./nptl/pthread_kill.c: Inappropriate ioctl for device.
[Current thread is 1 (Thread 0x7f91a32d6b80 (LWP 23758))]
Thread 4 (LWP 24634):
#0 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: Cannot access memory at address 0x0
Thread 3 (Thread 0x7f91a304d680 (LWP 23798)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1 0x00007f91a55bcbf4 in futex (val3=0, uaddr2=0x0, timeout=0x0, val=-1, op=0, uaddr=0x557352879600) at ../include/urcu/futex.h:81
No locals.
#2 futex_async (timeout=0x0, uaddr2=0x0, val3=0, val=-1, op=0, uaddr=0x557352879600) at ../include/urcu/futex.h:113
ret = <optimized out>
ret = <optimized out>
#3 futex_wait (futex=futex@entry=0x557352879600) at ./src/workqueue.c:135
__func__ = "futex_wait"
#4 0x00007f91a55bd035 in workqueue_thread (arg=0x5573528795c0) at ./src/workqueue.c:246
cbs_tmp_n = <optimized out>
splice_ret = <optimized out>
cbs_tmp_head = {node = {next = 0x55735285fa40}, lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}}
cbs_tmp_tail = {p = 0x557352898e50}
cbs = <optimized out>
cbcount = <optimized out>
workqueue = 0x5573528795c0
rt = 0
__func__ = "workqueue_thread"
__PRETTY_FUNCTION__ = "workqueue_thread"
#5 0x00007f91a5ea63ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
ret = <optimized out>
pd = <optimized out>
out = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140263530586416, -6319514938243892525, -808, 0, 140723762111680, 140263473598464, 6300488242360924883, 6300493485668219603}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f91a5f26a4c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.
Thread 2 (Thread 0x7f91a284c680 (LWP 23799)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1 0x00007f91a626d3ad in futex (val3=0, uaddr2=0x0, timeout=0x0, val=-1, op=0, uaddr=0x557352852020) at ../include/urcu/futex.h:81
No locals.
#2 futex_noasync (timeout=0x0, uaddr2=0x0, val3=0, val=-1, op=0, uaddr=0x557352852020) at ../include/urcu/futex.h:90
ret = <optimized out>
ret = <optimized out>
#3 call_rcu_wait (crdp=0x557352851fe0) at ./src/urcu-call-rcu-impl.h:248
__func__ = "call_rcu_wait"
#4 call_rcu_thread (arg=0x557352851fe0) at ./src/urcu-call-rcu-impl.h:400
cbs_tmp_n = <optimized out>
splice_ret = <optimized out>
cbs_tmp_head = {node = {next = 0x55735287d778}, lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}}
cbs_tmp_tail = {p = 0x557352876df0}
cbs = <optimized out>
cbcount = <optimized out>
crdp = 0x557352851fe0
rt = 0
__func__ = "call_rcu_thread"
__PRETTY_FUNCTION__ = "call_rcu_thread"
#5 0x00007f91a5ea63ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
ret = <optimized out>
pd = <optimized out>
out = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140263530586416, -6319514938243892525, -808, 115, 140723762111824, 140263465205760, 6300491538211453651, 6300493485668219603}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f91a5f26a4c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.
Thread 1 (Thread 0x7f91a32d6b80 (LWP 23758)):
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
tid = <optimized out>
ret = 0
pd = <optimized out>
old_mask = {__val = {24576}}
ret = <optimized out>
#1 0x00007f91a5ea815f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
No locals.
#2 0x00007f91a5e5a472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
ret = <optimized out>
#3 0x00007f91a5e444b2 in __GI_abort () at ./stdlib/abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {93953797214704, 140263484650848, 4294934528, 7, 140263531945088, 7, 0, 12880216814053340279, 9278577283777313019, 6439199540737383679, 93953794348112, 140263536447415, 140263530288466, 8, 140263530288466, 0}}, sa_flags = 1373274116, sa_restorer = 0x1a3}
#4 0x00007f91a63b7f45 in exit_test (quit_application=1) at ./src/cmocka.c:404
env = 0x7ffccdda8a0a "1"
abort_test = <optimized out>
#5 0x00007f91a63b7fda in _fail (file=file@entry=0x557351da8004 "dispatch_test.c", line=line@entry=419) at ./src/cmocka.c:2196
output = <optimized out>
#6 0x00007f91a63ba0bf in _assert_int_equal (a=<optimized out>, b=b@entry=0, file=file@entry=0x557351da8004 "dispatch_test.c", line=line@entry=419) at ./src/cmocka.c:1800
No locals.
#7 0x0000557351da695a in response_getnext (result=<optimized out>, region=<optimized out>, arg=0x55735283e170) at dispatch_test.c:419
test = 0x55735283e170
#8 0x00007f91a60596e5 in udp_recv (handle=0x557352899450, eresult=ISC_R_TIMEDOUT, region=0x7ffccdda6bb0, arg=<optimized out>) at dispatch.c:618
resp = 0x557352898340
disp = <optimized out>
id = 0
dres = <optimized out>
source = {magic = 1384304336, base = 0x6e8, length = 1494, used = 0, current = 3453643520, active = 32764, extra = 1384304336, dynamic = 115, link = {prev = 0x7f91a64127d8 <add_trace_entry+296>, next = 0x8}, mctx = 0x1a800000000}
flags = 3453643280
peer = {type = {sa = {sa_family = 27408, sa_data = "\332\315\374\177\000\000\212GA\246\221\177\000"}, sin = {sin_family = 27408, sin_port = 52698, sin_addr = {s_addr = 32764}, sin_zero = "\212GA\246\221\177\000"}, sin6 = {sin6_family = 27408, sin6_port = 52698, sin6_flowinfo = 32764, sin6_addr = {__in6_u = {__u6_addr8 = "\212GA\246\221\177\000\000 k\332\315\374\177\000", __u6_addr16 = {18314, 42561, 32657, 0, 27424, 52698, 32764, 0}, __u6_addr32 = {2789296010, 32657, 3453643552, 32764}}}, sin6_scope_id = 1384603504}, ss = {ss_family = 27408, __ss_padding = "\332\315\374\177\000\000\212GA\246\221\177\000\000 k\332\315\374\177\000\000p_\207RsU\000\000p_\207RsU\000\000\240\255\264RsU\000\000\000\000\000\000\000\000\000\000`\232\203RsU\000\000`k\332\315\374\177\000\000\324EA\246\221\177\000\000@k\332\315\374\177\000\000{\240C\246\221\177\000\000\000\000\000\000\000\000\000\000\326\005", '\000' <repeats 13 times>, __ss_align = 93953794203504}}, length = 1384603504, link = {prev = 0x7f91a643a07b, next = 0x0}}
netaddr = {family = 2789449851, type = {in = {s_addr = 32657}, in6 = {__in6_u = {__u6_addr8 = "\221\177\000\000\240\255\264RsU\000\000w\264\2517", __u6_addr16 = {32657, 0, 44448, 21172, 21875, 0, 46199, 14249}, __u6_addr32 = {32657, 1387572640, 21875, 933868663}}}, un = "\221\177\000\000\240\255\264RsU\000\000w\264\2517\363\270\277\262%\310%\001\304\370\241\215\221\237\355\250li\301\345\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\320k\332\315\374\177\000\0008e\207RsU\000\000\001", '\000' <repeats 15 times>, "`\232\203RsU\000\000\240\255\264RsU\000\000\320\316\202RsU\000"}, zone = 64}
match = 32764
timeout = <optimized out>
respond = <optimized out>
now = {seconds = 1533, nanoseconds = 0}
done = <optimized out>
#9 0x00007f91a63e8f28 in isc___nm_readcb (arg=<optimized out>) at netmgr/netmgr.c:1764
uvreq = 0x557352b4ada0
region = {base = 0x0, length = 0}
#10 isc__nm_readcb (sock=sock@entry=0x557352875f70, uvreq=<optimized out>, eresult=eresult@entry=ISC_R_TIMEDOUT, async=async@entry=false) at netmgr/netmgr.c:1779
No locals.
#11 0x00007f91a63e9009 in isc__nmsocket_readtimeout_cb (timer=0x5573528763b0) at netmgr/netmgr.c:1113
req = <optimized out>
sock = 0x557352875f70
#12 0x00007f91a638def6 in uv__run_timers (loop=loop@entry=0x55735287c5b0) at ./src/timer.c:178
heap_node = 0x557352876418
handle = 0x5573528763b0
#13 0x00007f91a639243a in uv_run (loop=loop@entry=0x55735287c5b0, mode=mode@entry=UV_RUN_DEFAULT) at ./src/unix/core.c:465
timeout = <optimized out>
r = <optimized out>
can_sleep = <optimized out>
#14 0x00007f91a640f554 in loop_thread (arg=arg@entry=0x55735287c590) at loop.c:282
loop = 0x55735287c590
r = <optimized out>
__func__ = "loop_thread"
ret = <optimized out>
#15 0x00007f91a641f893 in thread_body (wrap=0x55735283e170) at thread.c:85
func = 0x7f91a640f4d0 <loop_thread>
arg = 0x55735287c590
ret = 0x0
jemalloc_enforce_init = 0x557352b52d00
#16 isc_thread_main (func=func@entry=0x7f91a640f4d0 <loop_thread>, arg=0x55735287c590) at thread.c:116
No locals.
#17 0x00007f91a64106ac in isc_loopmgr_run (loopmgr=0x55735287d4c0) at loop.c:454
__func__ = "isc_loopmgr_run"
#18 0x0000557351da5766 in run_test_dispatch_getnext (state=<optimized out>) at dispatch_test.c:741
setup_loop = 0x0
teardown_loop = 0x0
#19 0x00007f91a63ba8f8 in cmocka_run_one_test_or_fixture (function_name=0x557351da813c "dispatch_getnext", test_func=0x557351da5740 <run_test_dispatch_getnext>, setup_func=setup_func@entry=0x0, teardown_func=teardown_func@entry=0x0, state=<optimized out>, state@entry=0x55735282ac80, heap_check_point=heap_check_point@entry=0x0) at ./src/cmocka.c:2801
check_point = 0x7f91a32d68d0
handle_exceptions = <optimized out>
current_state = 0x0
rc = 0
#20 0x00007f91a63bafdb in cmocka_run_one_tests (test_state=0x55735282ac70) at ./src/cmocka.c:2909
start = {tv_sec = 1700007173, tv_nsec = 801457005}
finish = {tv_sec = 0, tv_nsec = 0}
rc = 0
start = <optimized out>
finish = <optimized out>
rc = <optimized out>
#21 _cmocka_run_group_tests (group_name=group_name@entry=0x557351da806e "tests", tests=tests@entry=0x557351da9be0 <tests>, num_tests=num_tests@entry=10, group_setup=group_setup@entry=0x0, group_teardown=group_teardown@entry=0x0) at ./src/cmocka.c:3040
cmtest = 0x55735282ac70
test_number = 10
cm_tests = 0x55735282aac0
group_check_point = <optimized out>
group_state = 0x0
total_tests = <optimized out>
total_failed = <optimized out>
total_passed = 9
total_executed = 9
total_errors = 0
total_skipped = 0
total_runtime = 20.010910813999995
i = 9
rc = <optimized out>
#22 0x0000557351da5493 in main () at dispatch_test.c:855
r = <optimized out>
D:dispatch_test:backtrace from ./core.23758 end
FAIL dispatch_test (exit status: 134)
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4427Various improvements to hashing and hash table management2024-02-24T08:19:32ZMichał KępieńVarious improvements to hashing and hash table managementThis is a meta issue to keep track of various improvements to hashing
and hash table management that were implemented since ~"v9.18".
Sparked by a [Mattermost discussion][1].
---
- [x] #4306/!8288 Implement incremental hashing
---
...This is a meta issue to keep track of various improvements to hashing
and hash table management that were implemented since ~"v9.18".
Sparked by a [Mattermost discussion][1].
---
- [x] #4306/!8288 Implement incremental hashing
---
[1]: https://mattermost.isc.org/isc/pl/rsyemrkwhtfcbxhtyxddhkn58yMay 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4426Feature request - client.bind chaos class queries2023-11-20T10:39:24ZRay BellisFeature request - client.bind chaos class queriesNot plannedhttps://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/4422No supported algorithms on platform2024-02-29T15:26:01ZMark AndrewsNo supported algorithms on platformJob [#3783240](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3783240) failed for 5d20a7ce254dabe1d4a99f7bd0fd1cfa6309124b:
```
$ PYTHON="$(source bin/tests/system/conf.sh; echo $PYTHON)"
Traceback (most recent call last):
File "/bu...Job [#3783240](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3783240) failed for 5d20a7ce254dabe1d4a99f7bd0fd1cfa6309124b:
```
$ PYTHON="$(source bin/tests/system/conf.sh; echo $PYTHON)"
Traceback (most recent call last):
File "/builds/isc-projects/bind9/bin/tests/system/get_algorithms.py", line 241, in <module>
main()
File "/builds/isc-projects/bind9/bin/tests/system/get_algorithms.py", line 227, in main
algs = filter_supported(algs)
^^^^^^^^^^^^^^^^^^^^^^
File "/builds/isc-projects/bind9/bin/tests/system/get_algorithms.py", line 138, in filter_supported
raise RuntimeError(
RuntimeError: no DEFAULT algorithm from "stable" set supported on this platform
$
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4416ccmsg doesn't support multiple message read in the single TCP read2023-11-09T09:35:42ZDominik Thalhammerccmsg doesn't support multiple message read in the single TCP read### Summary
Sending multiple messages (without waiting for the previous responses to arrive) to bind via rndc causes messages to get lost/bind to loose sync on the stream.
### BIND version used
Docker image `ubuntu/bind9:9.18-22.04_be...### Summary
Sending multiple messages (without waiting for the previous responses to arrive) to bind via rndc causes messages to get lost/bind to loose sync on the stream.
### BIND version used
Docker image `ubuntu/bind9:9.18-22.04_beta`
```
BIND 9.18.12-0ubuntu0.22.04.3-Ubuntu (Extended Support Version) <id:>
running on Linux x86_64 6.2.0-36-generic #37~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 9 15:34:04 UTC 2
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' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-B5s8Yi/bind9-9.18.12=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 11.4.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.43.0
linked to libuv version: 1.43.0
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.2
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
Send multiple requests via rndc in rapid succession. The particular program used to initially observe the issue is closed source and tightly integrated, however the following script using `bind9-rndc-node` experiences the same behaviour.
```js
var RNDC = require('bind9-rndc');
var key = 'BzDBJ1B/JbQg9iXJYAGZLQ==';
var session = RNDC.connect('172.17.0.2', 953, key, 'md5');
var test_count = 10;
var recv_count = 0;
session.on('ready', () => {
for(var i = 0; i < test_count; i++)
session.send('status');
});
session.on('data', (obj) => {
recv_count++;
console.log("Got " + recv_count);
console.log(obj);
});
session.on('error', console.log);
```
### What is the current *bug* behavior?
Bind correctly handles some of the requests but drops others. Depending on the message size and timing the indices of the recognized messages vary and sometimes bind looses track entirely until it drops the connection with a timeout.
### What is the expected *correct* behavior?
The number of responses is equal to the number of requests (the order can vary, thats what `_ser` is for) and the stream stays in sync, regardless of the timing when sending messages. If bind can not keep up with the client it should use the tcp blocking to signal this instead of dropping data.
### Relevant configuration files
named.conf
```
key "rndc-key" {
algorithm hmac-md5;
secret "BzDBJ1B/JbQg9iXJYAGZLQ==";
};
controls {
inet 0.0.0.0 allow { any; } keys { "rndc-key"; };
};
options {
directory "/var/cache/bind";
version none;
allow-query { any; };
allow-recursion { any; };
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { };
listen-on { any; };
};
```
### Relevant logs and/or screenshots
Sample output of script (note theres a rather long pause before `warning: unread...`):
```
(node:10142) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Got 1
Map(0) {
type: 'status',
result: '0',
text: 'version: BIND 9.18.12-0ubuntu0.22.04.3-Ubuntu (Extended Support Version) <id:> (version.bind/txt/ch disabled)\n' +
'running on 54d01852d58b: Linux x86_64 6.2.0-36-generic #37~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 9 15:34:04 UTC 2\n' +
'boot time: Sat, 04 Nov 2023 14:45:41 GMT\n' +
'last configured: Sat, 04 Nov 2023 14:45:41 GMT\n' +
'configuration file: /etc/bind/named.conf\n' +
'CPUs found: 16\n' +
'worker threads: 16\n' +
'UDP listeners per interface: 16\n' +
'number of zones: 101 (99 automatic)\n' +
'debug level: 0\n' +
'xfers running: 0\n' +
'xfers deferred: 0\n' +
'soa queries in progress: 0\n' +
'query logging is OFF\n' +
'recursive clients: 0/900/1000\n' +
'tcp clients: 0/150\n' +
'TCP high-water: 0\n' +
'server is up and running'
}
warning: unread data left over
```
Relevant log output for this transaction:
`04-Nov-2023 15:12:17.519 invalid command from 172.17.0.1#40764: timed out`
### Possible fixes
I am not familiar with the bind9 source code, but I will take a look if I can find something (along with retesting on the master branch).
A fix for clients is to ensure that there is never more than one message in flight. This fixes the issue, but vastly degrades performance if the latency between server and client is huge.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4403Resolve spike in memory when named starts2023-12-05T15:58:58ZMatthijs Mekkingmatthijs@isc.orgResolve spike in memory when named starts9.19 resolver does better parallelization of work with cold cache, and thus consumes a more memory and CPU resources right after startup.
We should investigate if it works fine in face of limited resources, e.g. when the initial memory ...9.19 resolver does better parallelization of work with cold cache, and thus consumes a more memory and CPU resources right after startup.
We should investigate if it works fine in face of limited resources, e.g. when the initial memory spike exceeds available memory.
![all-groups-resmon.memory.current-docker](/uploads/b5fa63c677bb0c903ffca45b994375ac/all-groups-resmon.memory.current-docker.png)
![all-groups-resmon.cpu.usage_percent.cg-docker](/uploads/314f7c9f1c396f303bdd6397dd2dc73a/all-groups-resmon.cpu.usage_percent.cg-docker.png)
![all-groups-latency-since_0-until_150](/uploads/3ba559d2fd3a18335eaf45796874482c/all-groups-latency-since_0-until_150.png)BIND 9.19.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4400CID 467118: Control flow issue in lib/dns/message.c2024-02-24T07:55:29ZMichal NowakCID 467118: Control flow issue in lib/dns/message.cCoverity Scan claims control flow issue in `lib/dns/message.c` (suspect: !8400).
```
*** CID 467118: Control flow issues (DEADCODE)
/lib/dns/message.c: 1076 in getquestions()
1070 return (DNS_R_RECOVERABLE);
1071 }
1072 ...Coverity Scan claims control flow issue in `lib/dns/message.c` (suspect: !8400).
```
*** CID 467118: Control flow issues (DEADCODE)
/lib/dns/message.c: 1076 in getquestions()
1070 return (DNS_R_RECOVERABLE);
1071 }
1072 return (ISC_R_SUCCESS);
1073
1074 cleanup:
1075 if (rdataset != NULL) {
>>> CID 467118: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "dns_message_puttemprdataset...".
1076 dns_message_puttemprdataset(msg, &rdataset);
1077 }
1078 if (free_name) {
1079 dns_message_puttempname(msg, &name);
1080 }
1081
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4374modernize systemd.service file2023-10-24T08:33:22ZPetr Špačekpspacek@isc.orgmodernize systemd.service fileTurns out that our systemd.service file is from the age of dinosaurs.
Looking at https://gitlab.isc.org/isc-private/rpms/bind/-/blob/5b649ff34e7047ac4be6c82993c6f9784958533c/named.service.in ([named.service.in](/uploads/5dd91c2fc03c7620...Turns out that our systemd.service file is from the age of dinosaurs.
Looking at https://gitlab.isc.org/isc-private/rpms/bind/-/blob/5b649ff34e7047ac4be6c82993c6f9784958533c/named.service.in ([named.service.in](/uploads/5dd91c2fc03c762068b98741f3e1e358/named.service.in)):
- type should be `notify-reload`
- `ExecReload`, `ExecStop`, `PIDFile` commands should go away
Pros:
This will provide sensible integration and detection when BIND is ready (including reload) - at least for the simple cases where no catalog zones or RPZ is involved.
It might also make debugging a bit easier as tighter integration should avoid corner cases around `kill` invocation.
Edit: fixed the link.https://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/4358Randomize client address to improve security against cache poisoning2023-10-10T12:46:26ZKasper DupontRandomize client address to improve security against cache poisoning### Description
Existing solutions to increase request entropy only provide a few extra bits. Port number randomization provide at most 16 bits of entropy and randomizing casing of the name will often provide less than that. Moreover fo...### Description
Existing solutions to increase request entropy only provide a few extra bits. Port number randomization provide at most 16 bits of entropy and randomizing casing of the name will often provide less than that. Moreover for responses spanning multiple packets that extra entropy may only protect the first packet of the response.
### Request
Take advantage of the larger address space provided by IPv6 to randomize both client IP address and port. Using a /72 prefix would leave 56 bits for randomization which is more than request ID, port number, and name randomization combined. The IP address is part of each packet and will thus protect all packets of the response. It does not require the other methods of adding entropy to be disabled, combined the entropy can be even higher.
Ideally the prefix length used will be configurable. Supporting only multiples of 8 will keep the implementation simpler. A /72 prefix length will be preferred in at least some deployments. It avoids randomizing the multicast and globally unique bits of the address. Additionally it's usable with providers who only route a /64 to customers. (Use cases exist for /48, /56, /64, /72, and /104 with /72 being the best compromise if only a single prefix length is supported.)
To use this feature the server administrator would need to:
- Ensure a prefix is routed to the host
- Choose a sub-prefix of that to use for source IP randomization (could be the entire range if the routed prefix is used for nothing else)
- Add a local route for the chosen sub-prefix (this functionality exists on Linux, I don't know which other OS supports this functionality.)
- Configure the chosen sub-prefix for address randomization in the BIND configuration.
The BIND recursion code will need to do the following:
- Before calling bind on a newly created socket set the IP_FREEBIND option.
- In the arguments for bind provide not just a port number but also a local IP address constructed by combining the configured prefix with a random bitstring to produce a total of 128 bits.
- Ensure that any replies not sent to the correct local IP address are ignored either by the kernel or by BIND itself.
When using TCP IP randomization should also be used, but it should not change how long the TCP connections are kept alive. So multiple queries could be sent over a TCP connection where IP randomization was applied only once.
### Links / references
The security feature requested here already exists in Unbound and can be configured using outgoing-interface: https://nlnetlabs.nl/documentation/unbound/unbound.conf/Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4352inline-signing breaks nsdiff2024-02-24T07:55:39ZBjörn Perssoninline-signing breaks nsdiff### Summary
When both inline-signing and update-policy are in use, I can't detect race conditions with the method described in RFC 2136 section 5.7, which nsdiff uses.
In a zone that uses dnssec-policy and relies on the default value o...### Summary
When both inline-signing and update-policy are in use, I can't detect race conditions with the method described in RFC 2136 section 5.7, which nsdiff uses.
In a zone that uses dnssec-policy and relies on the default value of inline-signing, the method in RFC 2136 section 5.7 will stop working on upgrade to BIND 9.20, as inline-signing will then be switched on by default, if I understand correctly.
### BIND version used
```
$ named -V
BIND 9.18.19-1~deb12u1-Debian (Extended Support Version) <id:>
running on Linux x86_64 5.10.0-25-amd64 #1 SMP Debian 5.10.191-1 (2023-08-16)
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.9 30 May 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
Here I start from a working state with serial number 2023091800. The prerequisite matches the reply to the SOA query, and the update is answered with NOERROR. This is correct as far as I understand:
```
$ (echo 'prereq yxrrset xn--rombobjrn-67a.se. IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400' ; echo send) | nsupdate -k internal -d
Creating key...
Creating key...
namefromtext
keycreate
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23595
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; ANSWER SECTION:
xn--rombobjrn-67a.se. 86400 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400
Found zone name: xn--rombobjrn-67a.se
The primary is: ns1.xn--rombobjrn-67a.se
Sending update to 192.168.72.1#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 44980
;; flags:; ZONE: 1, PREREQ: 1, UPDATE: 0, ADDITIONAL: 1
;; PREREQUISITE SECTION:
xn--rombobjrn-67a.se. 0 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695171088 300 64 [...] 44980 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 44980
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695171088 300 64 [...] 44980 NOERROR 0
```
Later, the server has automatically increased the serial number to 2023091802. I use the new serial number in the prerequisite, so it looks identical to the new SOA value, but this time the update is rejected with NXRRSET:
```
$ (echo 'prereq yxrrset xn--rombobjrn-67a.se. IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091802 14400 3600 3024000 86400' ; echo send) | nsupdate -k internal -d
Creating key...
Creating key...
namefromtext
keycreate
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65052
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; ANSWER SECTION:
xn--rombobjrn-67a.se. 86400 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091802 14400 3600 3024000 86400
Found zone name: xn--rombobjrn-67a.se
The primary is: ns1.xn--rombobjrn-67a.se
Sending update to 192.168.72.1#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 52912
;; flags:; ZONE: 1, PREREQ: 1, UPDATE: 0, ADDITIONAL: 1
;; PREREQUISITE SECTION:
xn--rombobjrn-67a.se. 0 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091802 14400 3600 3024000 86400
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695259647 300 64 [...] 52912 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NXRRSET, id: 52912
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695259647 300 64 [...] 52912 NOERROR 0
```
Now I change the prerequisite back to 2023091800. The SOA hasn't changed again. The serial number is still 2023091802. This update should be rejected as the prerequisite contains an outdated serial number, but is in fact answered with NOERROR:
```
$ (echo 'prereq yxrrset xn--rombobjrn-67a.se. IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400' ; echo send) | nsupdate -k internal -d
Creating key...
Creating key...
namefromtext
keycreate
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6226
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; ANSWER SECTION:
xn--rombobjrn-67a.se. 86400 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091802 14400 3600 3024000 86400
Found zone name: xn--rombobjrn-67a.se
The primary is: ns1.xn--rombobjrn-67a.se
Sending update to 192.168.72.1#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 49961
;; flags:; ZONE: 1, PREREQ: 1, UPDATE: 0, ADDITIONAL: 1
;; PREREQUISITE SECTION:
xn--rombobjrn-67a.se. 0 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695263626 300 64 [...] 49961 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 49961
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695263626 300 64 [...] 49961 NOERROR 0
```
### What is the current *bug* behavior?
It seems that a serial number specified in a prerequisite of an update is compared to the unsigned version of the zone, but the serial number retrieved with a SOA or AXFR query is from the signed version. As far as I know a client can't look up the unsigned serial number, and thus can't specify it in the prerequisite. Thus the update fails when the two serial numbers differ.
### What is the expected *correct* behavior?
It seems to me that a prerequisite that specifies a SOA record should be checked against the same record that a client gets in response to a SOA or AXFR query. I don't know what other usecases that might break though.
### Relevant excerpts from the configuration file
```
dnssec-policy "some_name" {
keys {
ksk lifetime unlimited algorithm rsasha256 2048;
zsk lifetime unlimited algorithm rsasha256 2048;
};
dnskey-ttl P1D;
purge-keys 0;
};
view "internal" {
allow-transfer { key internal.beorn.tag.xn--rombobjrn-67a.se.; };
zone "xn--rombobjrn-67a.se" {
type master;
file "/var/lib/bind/db.xn--rombobjrn-67a.se.internal";
dnssec-policy some_name;
parental-agents { ::1; };
inline-signing yes;
update-policy {
grant internal.beorn.tag.xn--rombobjrn-67a.se. zonesub ANY;
};
};
};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/4348implement QPDB databases2024-03-08T23:38:09ZEvan Huntimplement QPDB databasesCreate QP-trie based databases to take the place of RBTDB, for use as a:
- [ ] zone database
- [ ] cacheCreate QP-trie based databases to take the place of RBTDB, for use as a:
- [ ] zone database
- [ ] cacheBIND 9.21.xEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/4345Debug messages logging network traffic only include the address of one peer2024-02-24T08:19:42ZMichał KępieńDebug messages logging network traffic only include the address of one peerEven with `-d 99` used on the command line, `named` only logs lines
like:
28-Sep-2023 14:31:23.212 sending packet to 2001:503:ba3e::2:30#53
or:
28-Sep-2023 14:31:23.232 received packet from 2001:503:ba3e::2:30#53
However, net...Even with `-d 99` used on the command line, `named` only logs lines
like:
28-Sep-2023 14:31:23.212 sending packet to 2001:503:ba3e::2:30#53
or:
28-Sep-2023 14:31:23.232 received packet from 2001:503:ba3e::2:30#53
However, network traffic is always sent **from** one socket **to**
another. The currently available debug messages do not include the
sender's address (first example) or the receiver's address (second
example). As a result, just bumping up the log level is often not
enough to diagnose certain issues and a network traffic sniffer has to
be used in order to learn the details of the packets being exchanged.
This lack of detail sometimes also makes debugging system test issues
harder than it has to be. With multiple tests being run in parallel,
knowing the exact addresses and ports that were used by each running
`named` instance is crucial for determining whether a test failure was
caused by an unexpected interaction between tests or not. (Such issues
happened more than once in the past, particularly when network code
and/or the system test framework were being worked on.)
Debug messages logging network traffic should be extended to include
information about both sides of each communication channel.
While this issue is technically only tangential to #4344, having
detailed network-level information available would greatly improve the
benefits of the feature proposed here.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4344Enable extraction of exact local socket addresses2024-02-24T08:19:47ZMichał KępieńEnable extraction of exact local socket addressesThe Network Manager API is currently unable to expose the exact
address/port that a local wildcard/TCP socket is bound to. This limits
the level of detail available to all sorts of traffic-logging code
(debug messages, dnstap, etc.)
Th...The Network Manager API is currently unable to expose the exact
address/port that a local wildcard/TCP socket is bound to. This limits
the level of detail available to all sorts of traffic-logging code
(debug messages, dnstap, etc.)
This has been previously discussed (in dnstap context) in #3143. Back
then, it quickly [emerged][1] that extracting the exact address that a
local wildcard/TCP socket is bound to requires issuing a system call.
Unfortunately, the function that would be responsible for doing this is
[called on a hot path][2]. After running some performance tests, it
[became obvious][3] that doing that unconditionally is a non-starter
performance-wise. The proposal was scrapped and replaced with a [note
in documentation](!6472).
However, the problem persists and limits the capabilities of not just
dnstap, but also logging code. In some cases, more detailed logging is
preferred over raw performance and there should be some way for the user
to express their preference in that regard.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5816#note_272336
[2]: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5816#note_272404
[3]: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5816#note_272407May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Michał KępieńMichał Kępień