ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-05-18T22:19:28Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1855"check max-journal-size limits" failed as not enough time allowed2020-05-18T22:19:28ZMark Andrews"check max-journal-size limits" failed as not enough time allowedJob [#890395](https://gitlab.isc.org/isc-projects/bind9/-/jobs/890395) failed for d9f357d082da2f8ad68818771ccee96cbe72c0ee:
Test looped for 6 seconds when it took ~13 second.
```
n=`expr $n + 1`
echo_i "check max-journal-size limits ($...Job [#890395](https://gitlab.isc.org/isc-projects/bind9/-/jobs/890395) failed for d9f357d082da2f8ad68818771ccee96cbe72c0ee:
Test looped for 6 seconds when it took ~13 second.
```
n=`expr $n + 1`
echo_i "check max-journal-size limits ($n)"
ret=0
rm -f nsupdate.out1-$n
# add one record
$NSUPDATE << EOF >> nsupdate.out1-$n 2>&1
server 10.53.0.1 ${PORT}
zone maxjournal.test
update add z.maxjournal.test 300 IN A 10.20.30.40
send
EOF
for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20; do
# repeatedly add and remove the same set of records to fill up
# the journal file without changing the zone content
$NSUPDATE << EOF >> nsupdate.out1-$n 2>&1
server 10.53.0.1 ${PORT}
zone maxjournal.test
update add a.maxjournal.test 300 IN A 1.2.3.4
update add b.maxjournal.test 300 IN A 1.2.3.4
update add c.maxjournal.test 300 IN A 1.2.3.4
update add d.maxjournal.test 300 IN A 1.2.3.4
send
update del a.maxjournal.test
update del b.maxjournal.test
update del c.maxjournal.test
update del d.maxjournal.test
send
EOF
done
# check that the journal is big enough to require truncation.
size=`$PERL -e 'use File::stat; my $sb = stat(@ARGV[0]); printf("%s\n", $sb->size);' ns1/maxjournal.db.jnl`
[ "$size" -gt 6000 ] || ret=1
sleep 1
$RNDCCMD 10.53.0.1 sync maxjournal.test
for i in 1 2 3 4 5 6
do
sleep 1
size=`$PERL -e 'use File::stat; my $sb = stat(@ARGV[0]); printf("%s\n", $sb->size);' ns1/maxjournal.db.jnl`
[ "$size" -lt 5000 ] && break
done
size=`$PERL -e 'use File::stat; my $sb = stat(@ARGV[0]); printf("%s\n", $sb->size);' ns1/maxjournal.db.jnl`
[ "$size" -lt 5000 ] || ret=1
[ $ret = 0 ] || { echo_i "failed"; status=1; }
```
```
18-May-2020 06:17:34.729 received control channel command 'sync maxjournal.test'
18-May-2020 06:17:34.733 zone_dump: zone maxjournal.test/IN: enter
18-May-2020 06:17:34.737 zone_gotwritehandle: zone maxjournal.test/IN: enter
18-May-2020 06:17:34.737 sync: dumping zone 'maxjournal.test/IN': success
18-May-2020 06:17:34.737 socket 0x7fb57ffdc778: socket_recv: event 0x7fb57ffde180 -> task 0x7fb58fc8b020
18-May-2020 06:17:34.737 sockmgr 0x7fb58fc79020 thread 11: watcher got message -3 for socket 155
18-May-2020 06:17:34.737 sockmgr 0x7fb58fc79020 thread 11: watcher got message -2 for socket -1
18-May-2020 06:17:34.737 socket 0x7fb57ffdc778: internal_recv: event 0x7fb57ffde180 -> task 0x7fb58fc8b020
18-May-2020 06:17:34.737 socket 0x7fb57ffdc778: destroying
18-May-2020 06:17:34.737 sockmgr 0x7fb58fc79020 thread 11: watcher got message -5 for socket 155
18-May-2020 06:17:34.737 sockmgr 0x7fb58fc79020 thread 11: watcher got message -2 for socket -1
18-May-2020 06:17:36.025 zone_timer: managed-keys-zone: enter
18-May-2020 06:17:36.025 zone_maintenance: managed-keys-zone: enter
18-May-2020 06:17:36.025 zone_dump: managed-keys-zone: enter
18-May-2020 06:17:36.025 zone_settimer: managed-keys-zone: enter
18-May-2020 06:17:45.393 dump_done: zone maxjournal.test/IN: enter
18-May-2020 06:17:45.393 zone_journal_compact: zone maxjournal.test/IN: target journal size 318
18-May-2020 06:17:45.393 journal file maxjournal.db.jnw does not exist, creating it
18-May-2020 06:17:47.353 zone maxjournal.test/IN: dns_journal_compact: success
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1854Extend loop limit by 1.2020-05-21T04:11:46ZMark AndrewsExtend loop limit by 1.Job [#889797](https://gitlab.isc.org/isc-projects/bind9/-/jobs/889797) failed for 46c4e5d96f4b024117b4e462d3929bb68cb63136:
Extend the loop count by 1 to account for non-exact timing in `usleep(100000)`.
```
[==========] Running 6 test...Job [#889797](https://gitlab.isc.org/isc-projects/bind9/-/jobs/889797) failed for 46c4e5d96f4b024117b4e462d3929bb68cb63136:
Extend the loop count by 1 to account for non-exact timing in `usleep(100000)`.
```
[==========] Running 6 test(s).
[ RUN ] getoriginnode_test
[ OK ] getoriginnode_test
[ RUN ] getsetservestalettl_test
[ OK ] getsetservestalettl_test
[ RUN ] dns_dbfind_staleok_test
21 is not within the range 0-20
db_test.c:214: error: Failure!
[ FAILED ] dns_dbfind_staleok_test
[ RUN ] class_test
[ OK ] class_test
[ RUN ] dbtype_test
[ OK ] dbtype_test
[ RUN ] version_test
[ OK ] version_test
[==========] 6 test(s) run.
[ PASSED ] 5 test(s).
[ FAILED ] 1 test(s), listed below:
[ FAILED ] dns_dbfind_staleok_test
1 FAILED TEST(S)
FAIL db_test (exit status: 1)
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1853Force promotion to unsigned int.2020-06-04T05:59:46ZMark AndrewsForce promotion to unsigned int.Job [#889498](https://gitlab.isc.org/isc-projects/bind9/-/jobs/889498) failed for 6ca026b31399e62dba5a6b3ca3d41c7a3dc5c730:
lwinetaton.c:188:20: runtime error: left shift of 213 by 24 places cannot be represented in type 'int'Job [#889498](https://gitlab.isc.org/isc-projects/bind9/-/jobs/889498) failed for 6ca026b31399e62dba5a6b3ca3d41c7a3dc5c730:
lwinetaton.c:188:20: runtime error: left shift of 213 by 24 places cannot be represented in type 'int'June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1852race in autosign system test.2020-05-18T13:41:13ZMark Andrewsrace in autosign system test.Job [#889493](https://gitlab.isc.org/isc-projects/bind9/-/jobs/889493) failed for 6ca026b31399e62dba5a6b3ca3d41c7a3dc5c730:
`wait_for_log "add delay\.example\..*NSEC.a\.delay\.example\. NS SOA RRSIG NSEC DNSKEY" ns3/named.run`
returns b...Job [#889493](https://gitlab.isc.org/isc-projects/bind9/-/jobs/889493) failed for 6ca026b31399e62dba5a6b3ca3d41c7a3dc5c730:
`wait_for_log "add delay\.example\..*NSEC.a\.delay\.example\. NS SOA RRSIG NSEC DNSKEY" ns3/named.run`
returns before the zone is marked as secure. This can result in the subsequent lookups being returned
without RRSIGs. Retry these lookups if they fail.
```
I:autosign:checking scheduled key activation (72)
I:autosign:waiting for changes to take effect
I:autosign:failed
```
```
echo_i "checking scheduled key activation ($n)"
ret=0
$SETTIME -K ns3 -A now+3s $zsk > settime.out.test$n.zsk || ret=1
$SETTIME -K ns3 -A now+3s $ksk > settime.out.test$n.ksk || ret=1
($RNDCCMD 10.53.0.3 loadkeys delay.example. 2>&1 | sed 's/^/ns2 /' | cat_i) || ret=1
echo_i "waiting for changes to take effect"
sleep 3
wait_for_log "add delay\.example\..*NSEC.a\.delay\.example\. NS SOA RRSIG NSEC DNSKEY" ns3/named.run
$DIG $DIGOPTS +noall +answer dnskey delay.example. @10.53.0.3 > dig.out.ns3.1.test$n || ret=1
# DNSKEY expected:
awk 'BEGIN {r=1} $4=="DNSKEY" {r=0} END {exit r}' dig.out.ns3.1.test$n || ret=1
# RRSIG expected:
awk 'BEGIN {r=1} $4=="RRSIG" {r=0} END {exit r}' dig.out.ns3.1.test$n || ret=1
$DIG $DIGOPTS +noall +answer a a.delay.example. @10.53.0.3 > dig.out.ns3.2.test$n || ret=1
# A expected:
awk 'BEGIN {r=1} $4=="A" {r=0} END {exit r}' dig.out.ns3.2.test$n || ret=1
# RRSIG expected:
awk 'BEGIN {r=1} $4=="RRSIG" {r=0} END {exit r}' dig.out.ns3.2.test$n || ret=1
n=`expr $n + 1`
if [ $ret != 0 ]; then echo_i "failed"; fi
status=`expr $status + $ret`
```
```
head autosign/dig.out.ns3.[12].test72
==> autosign/dig.out.ns3.1.test72 <==
delay.example. 300 IN DNSKEY 256 3 7 AwEAAb0FjNazob/oUqj6yoPtX2zHZZBJ4lTMY6Dj5PFNIUnugIh3DtTf uyPRuby+6OAjTn24FNxOrlu/UcIpJllSI5U3hWEMRrowOL0UnkqB7GaC zxPcbTbyHvj51/fijdeFhK4mWzLDZPEbTYLNaxjOHsAI2Kyti3LelRzH VEw/wTU5
delay.example. 300 IN DNSKEY 257 3 7 AwEAAbZ3JQjYj4J0bbHfC496OClZx8PVTSsXEGPj9BFnlWQ8Zb7rhQn8 H45RuUYh/gt0btmjPetD9ANKPj/S2vB62lkZo+X8FoU8h2tSLtkJ7Rsp XGCSyldNgzgtYSjTcU1SD0vpaVGNxSVShF8tSrQyO66xBpeQOl/hXQBq ncBxffBABsMdNLPKW3SYJGX6WqgasNh0/RjZbA5mWtYA+6v1nNXY8m9Z cJwkTN7X64tOrNbEizaphRqumbeRen9EmqZ58hvpklDMA8fZz99vwDnS flPVLoM/jlSPGyMIKJpH8EJW2kxSrsXRz/cXVhZfEZ5fAj7iCkfInktp B1C7Al4A6U8=
==> autosign/dig.out.ns3.2.test72 <==
a.delay.example. 300 IN A 10.0.0.1
```
```
17-May-2020 23:47:49.971 received control channel command 'loadkeys delay.example.'
...
17-May-2020 23:47:52.976 add re-sign delay.example. 300 IN RRSIG DNSKEY 7 2 300 20200616234752 20200517224752 57189 delay.example. HnZUVSTqk2heuru5n2ju+SZYk64836po4FLbEhkC1Ox71mJCdSvLG5SH 16ZM03Nx2P4eu7NzYNNpj+Ndn04cHzT3Q5TczYDxu6PY7YpdaYrNT2ng TLHcvfSbzqdYISJPmyC1y39zufR/tg1y3BVgpcOXdT9tnH6Odihgn6mM 9vE=
...
17-May-2020 23:47:52.976 add re-sign delay.example. 300 IN RRSIG DNSKEY 7 2 300 20200616234752 20200517224752 19579 delay.example. k6VYi0hXM8wPowFry2TncPgoUAdH9tjqeMCLEmvW8MkUwsXer334fe+E tKU4K3/2WwujBwF1828EIR4ts03rtYCsDT2WQVbDaC1S3dy71CdErDDZ e3COggxN/opGiS+7Bp5w1SH2ctdCViV/jJkRp10Y+ByjPHVTqiBl13OW kaP/NZlUOKcWZyzVnBtF0hrUkDds1rKy8D7Uwm7/Qm1gyPIKSRJ7HM76 kfBdoWsyAwuU7CzoD8yEHxDHeAqtpblCcN71rjEy085DLcab0oB83knU 12BoQx/7rgAo3fJHv1IHZR4vQdVVJcAI87KfaKZvlhRXwOpTrAb5JGVt TPIHoQ==
...
17-May-2020 23:47:53.624 add re-sign a.delay.example. 300 IN RRSIG A 7 3 300 20200602150652 20200517224753 57189 delay.example. F5sae3NdEnj250wHmWQkdxwotLvM41EQCY7xwgFXX8L0x6Bucy0adAYH 9fJpGX9q07D1FTesi1Jz8i6r00U4PNLoR82qPSBY6CAQmpoTLKxi7Shq PL4eN6j9+Z1wrMhLFmZmJmOO92g6Sfe1Sa02VAc/0tU3NUacCYuzawZl gk0=
...
17-May-2020 23:47:54.024 add delay.example. 3600 IN NSEC a.delay.example. NS SOA RRSIG NSEC DNSKEY
...
17-May-2020 23:47:54.045 query client=0x7fcc6807fcd0 thread=0x7fcc9c821700 (delay.example/DNSKEY): query_find
...
17-May-2020 23:47:54.066 query client=0x7fcc9121dc40 thread=0x7fcc9a81d700 (a.delay.example/A): query_find
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1851single-query trace logging2022-04-26T13:10:59ZEvan Huntsingle-query trace logging@wpk proposed a useful method of tracing the progress of a single query by turning up the debugging level to maximum on a per-thread level for the duration of a client if the query ID is set to a particular value.@wpk proposed a useful method of tracing the progress of a single query by turning up the debugging level to maximum on a per-thread level for the duration of a client if the query ID is set to a particular value.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1850[CVE-2020-8618] A buffer boundary check assertion in rdataset.c can fail inco...2020-06-18T08:26:37ZWitold Krecicki[CVE-2020-8618] A buffer boundary check assertion in rdataset.c can fail incorrectly during zone transferAssertion failure: `rdataset.c:527: INSIST(rrbuffer.used < 65536) failed, back trace`
This one was reported in https://support.isc.org/Ticket/Display.html?id=16195 .
The problem is in lib/ns/include/ns/client.h:
```
#define NS_CLIENT_T...Assertion failure: `rdataset.c:527: INSIST(rrbuffer.used < 65536) failed, back trace`
This one was reported in https://support.isc.org/Ticket/Display.html?id=16195 .
The problem is in lib/ns/include/ns/client.h:
```
#define NS_CLIENT_TCP_BUFFER_SIZE (65535 + 2)
```
It's a leftover from 'old' socket code where the TCP buffer for rendering included the 2 bytes length in front. With netmgr it's the buffer we do rendering to, and we might overflow it.
There are two 'modes' of this bug - the first one is when we don't render partial rdatasets in ANSWER section- and that's what happening when we have EDNS0 enabled (msg->reserved != 0). In this mode we can render a 65536 or 65537-byte-long message which is then sent over TCP. The 'length' is still set using htons, so the 2-byte length is then either [0 0] or [0 1] - we send a malformed packet.
The second mode is worse - with EDNS0 disabled msg->reserved == 0, and a carefully crafted zone we can go over 65535-bytes limit, then go over 65537-limit with triggers ISC_R_NOSPACE on the buffer, and then we check that the buffer 'used' was below 65536 bytes - which is untrue, triggering an assertion:
```
rollback:
if (partial && result == ISC_R_NOSPACE) {
INSIST(rrbuffer.used < 65536);
```
I wasn't able to trigger the issue with recursion (as we'd have to have a rdataset that's > 65535 bytes long in cache, and there's no way to receive that).
The fix is trivial (remove '+2' from the aforementioned line).June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1849CIDR rejected by 9.11.18 and higher2023-03-21T19:04:05ZWilliam D ColburnCIDR rejected by 9.11.18 and higher<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
ondrej@isc.org requested I file this as a regression rather than a feature drop. We have a very old setup that did something clever with CIDR notation. The two CIDRs we use are 10.80.201.0/19 and 10.80.211.0/19 which (as I understand it) covers a range of addresses in 5 class C networks that need access. Making changes is hard, and it was requested that we not change how this works during the pandemic. But the new secretiive bug announcement makes me worry that this is important and we should stop lurking at 9.11.7. When I wrote the email I assumed that the CIDR change had gone from warning to error.
My original email:
```
> On 14 May 2020, at 15:03, William D. Colburn <wcolburn@nrao.edu> wrote:
>
> That this upcoming security announcement is pre-announced makes me worry
> that it is very imporant, and not one we can ignore. Not that we should
> have ignored the last four either, but changes like this are hard.
>
> BIND stopped working for us at 9.11.8, and because of the intricacies of
> making massive changes to our infrastructure, we have been sitting at
> 9.11.7 for quite a while. The problem we have is that you deprecated
> support for legacy CIDR, and our configuration is now invalid. No one
> wants to attempt any changes to the BIND config right now because we are
> in an infectous disease status and almost no one is at work.
>
> The CIDRs in question are 10.80.201.0/19, and 10.80.211.0/19, which we
> use to control access of special hardware across a range of IP
> addresses. It's a "clever" solution, and clever is never really a good
> idea, but it has been in place for more than a decade. The official
> request was not to change those during this pandemic. Unfortunately,
> the system serving these systems is also the system public-facing to the
> internet.
>
> Is there something I can do when compiling this new bind to make CIDR
> notation work again, as in an option at compile time?
>
> --Schlake
```
### BIND version used
WORKS:
```
root@anotheruvula</home/anotheruvula/services/named># bind-9.11.7/*/named -V
BIND 9.11.7 (Extended Support Version) <id:084ef47>
running on Linux x86_64 3.10.0-957.21.3.el7.x86_64 #1 SMP Fri Jun 14 02:54:29 EDT 2019
built by make with '--disable-openssl-version-check' '--prefix=/opt/services/named/bind-9.11.7' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-ipv6' '--with-openssl=yes'
compiled by GCC 4.4.7 20120313 (Red Hat 4.4.7-18)
compiled with OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
linked to OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
compiled with libxml2 version: 2.7.6
linked to libxml2 version: 20901
compiled with zlib version: 1.2.3
linked to zlib version: 1.2.7
threads support is enabled
```
FAILS:
```
root@anotheruvula</home/anotheruvula/services/named># bind-9.11.18/*/named -V
BIND 9.11.18 (Extended Support Version) <id:bc6c00f>
running on Linux x86_64 3.10.0-957.21.3.el7.x86_64 #1 SMP Fri Jun 14 02:54:29 EDT 2019
built by make with '--disable-openssl-version-check' '--prefix=/opt/services/named/bind-9.11.18' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-ipv6' '--with-openssl=yes'
compiled by GCC 4.4.7 20120313 (Red Hat 4.4.7-23)
compiled with OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
linked to OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
compiled with libxml2 version: 2.7.6
linked to libxml2 version: 20901
compiled with zlib version: 1.2.3
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
```
allow-update {
10.80.201.0/19;
10.80.211.0/19;
}
```
### What is the current *bug* behavior?
The named exits without starting.
syslog errors:
```
May 14 11:54:15 anotheruvula named[9737]: /etc/named.conf:518: '10.80.201.0/19': address/prefix length mismatch '19'
May 14 11:54:15 anotheruvula named[9737]: loading configuration: failure
May 14 11:54:15 anotheruvula named[9737]: exiting (due to fatal error)
```
### What is the expected *correct* behavior?
I'd expect no error, but for many versions I got this warning:
```
May 14 11:54:31 anotheruvula named[9781]: /etc/named.conf:518: '10.80.201.0/19': address/prefix length mismatch
May 14 11:54:31 anotheruvula named[9781]: /etc/named.conf:519: '10.80.211.0/19': address/prefix length mismatch
```
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
Just the allow-update is needed, as above.
```
allow-update {
10.80.201.0/19;
10.80.211.0/19;
}
```
### Relevant logs and/or screenshots
```
May 14 11:54:31 anotheruvula named[9781]: /etc/named.conf:518: '10.80.201.0/19': address/prefix length mismatch
May 14 11:54:31 anotheruvula named[9781]: /etc/named.conf:519: '10.80.211.0/19': address/prefix length mismatch
```
and
```
May 14 11:54:15 anotheruvula named[9737]: /etc/named.conf:518: '10.80.201.0/19': address/prefix length mismatch '19'
May 14 11:54:15 anotheruvula named[9737]: loading configuration: failure
May 14 11:54:15 anotheruvula named[9737]: exiting (due to fatal error)
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1846kasp: bug in rollover: set retired on predecessor when creating a successor.2020-06-08T12:54:47ZMatthijs Mekkingmatthijs@isc.orgkasp: bug in rollover: set retired on predecessor when creating a successor.The key rollover logic does not remove the old predecessor since it is not retired when introducing a successor key.The key rollover logic does not remove the old predecessor since it is not retired when introducing a successor key.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1845kasp: bug in keymgr_key_has_successor()2020-06-08T12:54:39ZMatthijs Mekkingmatthijs@isc.orgkasp: bug in keymgr_key_has_successor()There is a bug in `keymgr_key_has_successor(key, keyring)`: It check if there is *any* key in the `keyring` with a successor, while the intention of the function is that it should check if the given `key` has a successor in the `keyring`.There is a bug in `keymgr_key_has_successor(key, keyring)`: It check if there is *any* key in the `keyring` with a successor, while the intention of the function is that it should check if the given `key` has a successor in the `keyring`.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1843kasp: Set correct keytimings2020-06-02T09:38:04ZMatthijs Mekkingmatthijs@isc.orgkasp: Set correct keytimingsWhile KASP (dnssec-policy) does not use the keytiming metadata to make decisions, this data is used by operators as an indication when certain key events will occur. Make sure the key times are set correctly and test them. Especially `S...While KASP (dnssec-policy) does not use the keytiming metadata to make decisions, this data is used by operators as an indication when certain key events will occur. Make sure the key times are set correctly and test them. Especially `SyncPublish` and `Removed` were neglected previously.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1842Correct the BIND ARM to say that the default session-key for use with 'update...2020-06-18T08:39:09ZCathy AlmondCorrect the BIND ARM to say that the default session-key for use with 'update-policy local;' is generated at startupThe BIND ARM says:
```
A pre-defined update-policy rule can be switched on with the command update-policy local;.
Switching on this rule in a zone causes named to generate a TSIG session key and place it in a file.
That key will then ...The BIND ARM says:
```
A pre-defined update-policy rule can be switched on with the command update-policy local;.
Switching on this rule in a zone causes named to generate a TSIG session key and place it in a file.
That key will then be allowed to update the zone, if the update request is sent from local- host.
By default, the session key is stored in the file /var/run/named/session.key; the key name
is "local-ddns" and the key algorithm is HMAC-SHA256. These values are configurable with the
session-keyfile, session-keyname and session-keyalg options, respectively).
```
This is not actually true - the session-key is generated when named starts up, irrespective of whether it's needed or not.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1841Test multiple SoftHSM versions in GitLab CI2020-06-04T12:16:14ZMichał KępieńTest multiple SoftHSM versions in GitLab CI@ondrej [suggested][1] that we should be testing multiple SoftHSM
versions in GitLab CI as algorithm support varies:
- SoftHSM < 2.6.0 lacks EdDSA support
- SoftHSM >= 2.6.0 has Ed25519 support
- SoftHSM >= 2.6.1 has Ed448 support...@ondrej [suggested][1] that we should be testing multiple SoftHSM
versions in GitLab CI as algorithm support varies:
- SoftHSM < 2.6.0 lacks EdDSA support
- SoftHSM >= 2.6.0 has Ed25519 support
- SoftHSM >= 2.6.1 has Ed448 support
[1]: https://mattermost.isc.org/isc/pl/xnbgms4n1tf3mnnm1a6tjwjseaJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1835Add the ability to parse and display Extended DNS Error code (EDE).2022-04-26T13:09:49ZMark AndrewsAdd the ability to parse and display Extended DNS Error code (EDE).Nnemonic EDE
Code point 15
15,Extended DNS Error,Standard,[RFC-ietf-dnsop-extended-error-16]Nnemonic EDE
Code point 15
15,Extended DNS Error,Standard,[RFC-ietf-dnsop-extended-error-16]June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1834IXFR of a new NSEC3 chain causes temporary performance drop2020-06-18T08:39:08ZEvan HuntIXFR of a new NSEC3 chain causes temporary performance dropWhen fully updating the NSEC3 chain for a large zone via IXFR, there is a temporary loss of performance on the secondary server when answering DO=1 queries for nonexistent data (in other words, queries that require returning NSEC3 data).When fully updating the NSEC3 chain for a large zone via IXFR, there is a temporary loss of performance on the secondary server when answering DO=1 queries for nonexistent data (in other words, queries that require returning NSEC3 data).June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1828util/check-categories.sh needs updating for doc/arm/logging-categories.rst2020-05-15T12:17:14ZMark Andrewsutil/check-categories.sh needs updating for doc/arm/logging-categories.rstJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1825Improperly formatted commands in BIND ARM2020-06-08T10:16:01ZSuzanne GoldlustImproperly formatted commands in BIND ARM3.3.1.2. Administrative Tools, under `rndc`, the usage message (rndc [-c config][-s server][-p port][-y key] command [command…]) is not formatted as a command.3.3.1.2. Administrative Tools, under `rndc`, the usage message (rndc [-c config][-s server][-p port][-y key] command [command…]) is not formatted as a command.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1817named-checkzone: [-s (full|relative)] missing from usage.2020-05-15T12:29:10ZMark Andrewsnamed-checkzone: [-s (full|relative)] missing from usage.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1812Unexpected output from named-checkconf2020-06-18T08:39:09ZPeter DaviesUnexpected output from named-checkconfUnexpected output from named-checkconf:
When run "named-checkconf -p " appends extra test to server lines in static-stub zones
input:
zone "10.in-addr.arpa" { type static-stub; server-addresses { 199.81.216.126; 204.135.12.254; }; };
e...Unexpected output from named-checkconf:
When run "named-checkconf -p " appends extra test to server lines in static-stub zones
input:
zone "10.in-addr.arpa" { type static-stub; server-addresses { 199.81.216.126; 204.135.12.254; }; };
expected output:
zone "10.in-addr.arpa" {
type static-stub;
server-addresses {
199.81.216.126;
204.135.12.254;
};
};
received output:
zone "10.in-addr.arpa" {
type static-stub;
server-addresses {
199.81.216.126 dscp 4294950590;
204.135.12.254 dscp 4294950590;
};
This behaviour appears to start at release 9.11.6
see RT [#16328](https://support.isc.org/Ticket/Display.html?id=16328)June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)https://gitlab.isc.org/isc-projects/bind9/-/issues/1808assertion failure in bind 9.16.22020-06-08T12:52:05ZOndřej Surýassertion failure in bind 9.16.2As reported to SO:
```
> Hello there,
>
> I'm running some dnsperf test against from in your testlab, and quite often i bind to crash with assertion failure.
>
> I'm running bind dnsperf with: dnsperf -f inet -t 10 -s <SANITIZED> -d...As reported to SO:
```
> Hello there,
>
> I'm running some dnsperf test against from in your testlab, and quite often i bind to crash with assertion failure.
>
> I'm running bind dnsperf with: dnsperf -f inet -t 10 -s <SANITIZED> -d dns_clear.txt -c 200 -T 4 -l 36000000 -q 5000 -S 1 (Attached dns_clear.txt, which is are reallife traffic dump from our prod bind servers). We're running CentOS Linux release 7.7.1908 (Core) in both test/prod.
>
> 29-Apr-2020 15:45:27.651 general: critical: netaddr.c:365: INSIST(0) failed, back trace
> 29-Apr-2020 15:45:27.651 general: critical: #0 0x42b890 in ??
> 29-Apr-2020 15:45:27.651 general: critical: #1 0x7f033062cada in ??
> 29-Apr-2020 15:45:27.651 general: critical: #2 0x7f033064a3d3 in ??
> 29-Apr-2020 15:45:27.651 general: critical: #3 0x7f033064fcc0 in ??
> 29-Apr-2020 15:45:27.651 general: critical: #4 0x7f033064ff56 in ??
> 29-Apr-2020 15:45:27.651 general: critical: #5 0x7f033195feaa in ??
> 29-Apr-2020 15:45:27.651 general: critical: #6 0x7f033187c448 in ??
> 29-Apr-2020 15:45:27.651 general: critical: #7 0x7f0331972a40 in ??
> 29-Apr-2020 15:45:27.651 general: critical: #8 0x7f0330652ada in ??
> 29-Apr-2020 15:45:27.651 general: critical: #9 0x7f032edc2e65 in ??
> 29-Apr-2020 15:45:27.651 general: critical: #10 0x7f032e6cd88d in ??
> 29-Apr-2020 15:45:27.651 general: critical: exiting (due to assertion failure)
>
> I've several coredumps.. Do you guys have a place where i can upload them?
>
> [root@srv07 data]# ls -lh
> total 5.7G
> -rw-------. 1 named named 1.7G Apr 22 08:48 core.11065
> -rw-------. 1 named named 1.6G Apr 22 12:58 core.11877
> -rw-------. 1 named named 2.6G Apr 21 21:17 core.126377
> -rw-------. 1 named named 1.4G Apr 29 15:45 core.15168
> -rw-------. 1 named named 166M Apr 27 17:03 core.21234
> -rw-------. 1 named named 175M Apr 27 17:07 core.21301
> -rw-------. 1 named named 2.2G Apr 21 15:33 core.72474
>
> [root@srv07 log]# named -V
> BIND 9.16.2 (Stable Release) <id:b310dc7>
> running on Linux x86_64 3.10.0-1062.18.1.el7.x86_64 #1 SMP Tue Mar 17 23:49:17 UTC 2020
> built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr' '--exec-prefix=/opt/isc/isc-bind/root/usr' '--bindir=/opt/isc/isc-bind/root/usr/bin' '--sbindir=/opt/isc/isc-bind/root/usr/sbin' '--sysconfdir=/etc/opt/isc/isc-bind' '--datadir=/opt/isc/isc-bind/root/usr/share' '--includedir=/opt/isc/isc-bind/root/usr/include' '--libdir=/opt/isc/isc-bind/root/usr/lib64' '--libexecdir=/opt/isc/isc-bind/root/usr/libexec' '--localstatedir=/var/opt/isc/isc-bind' '--sharedstatedir=/var/opt/isc/isc-bind/lib' '--mandir=/opt/isc/isc-bind/root/usr/share/man' '--infodir=/opt/isc/isc-bind/root/usr/share/info' '--disable-static' '--enable-dnstap' '--with-pic' '--with-gssapi' '--with-json-c' '--with-libtool' '--with-libxml2' '--without-lmdb' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--with-python' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS= -L/opt/isc/isc-bind/root/usr/lib64' 'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig'
> compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
> compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
> linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
> compiled with libxml2 version: 2.9.1
> linked to libxml2 version: 20901
> compiled with json-c version: 0.11
> linked to json-c version: 0.11
> compiled with zlib version: 1.2.7
> linked to zlib version: 1.2.7
> compiled with protobuf-c version: 1.3.2
> linked to protobuf-c version: 1.3.2
> threads support is enabled
>
> default paths:
> named configuration: /etc/opt/isc/isc-bind/named.conf
> rndc configuration: /etc/opt/isc/isc-bind/rndc.conf
> DNSSEC root key: /etc/opt/isc/isc-bind/bind.keys
> nsupdate session key: /var/opt/isc/isc-bind/run/named/session.key
> named PID file: /var/opt/isc/isc-bind/run/named/named.pid
> named lock file: /var/opt/isc/isc-bind/run/named/named.lock
>
>
>
> [root@srv07 log]# ldd /opt/isc/isc-bind/root/usr/sbin/named
> linux-vdso.so.1 => (0x00007ffcc594a000)
> libns.so.1602 => /opt/isc/isc-bind/root/usr/lib64/libns.so.1602 (0x00007f8aa0acf000)
> libdns.so.1602 => /opt/isc/isc-bind/root/usr/lib64/libdns.so.1602 (0x00007f8aa06a6000)
> libbind9.so.1600 => /opt/isc/isc-bind/root/usr/lib64/libbind9.so.1600 (0x00007f8aa0493000)
> libisccfg.so.1600 => /opt/isc/isc-bind/root/usr/lib64/libisccfg.so.1600 (0x00007f8aa0261000)
> libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f8aa0014000)
> libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f8a9fd2b000)
> libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f8a9faf8000)
> libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f8a9f8f4000)
> libisccc.so.1600 => /opt/isc/isc-bind/root/usr/lib64/libisccc.so.1600 (0x00007f8a9f6ea000)
> libisc.so.1602 => /opt/isc/isc-bind/root/usr/lib64/libisc.so.1602 (0x00007f8a9f475000)
> libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f8a9f012000)
> libjson-c.so.2 => /lib64/libjson-c.so.2 (0x00007f8a9ee07000)
> libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f8a9ea9d000)
> libz.so.1 => /lib64/libz.so.1 (0x00007f8a9e887000)
> libcap.so.2 => /lib64/libcap.so.2 (0x00007f8a9e682000)
> libprotobuf-c.so.1 => /opt/isc/isc-bind/root/usr/lib64/libprotobuf-c.so.1 (0x00007f8a9e479000)
> libfstrm.so.0 => /opt/isc/isc-bind/root/usr/lib64/libfstrm.so.0 (0x00007f8a9e26e000)
> libuv.so.1 => /opt/isc/isc-bind/root/usr/lib64/libuv.so.1 (0x00007f8a9e03f000)
> librt.so.1 => /lib64/librt.so.1 (0x00007f8a9de37000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8a9dc1b000)
> libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f8a9da01000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f8a9d7fd000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f8a9d42f000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f8aa0d16000)
> libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f8a9d21f000)
> libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f8a9d01b000)
> libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f8a9ce02000)
> liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f8a9cbdc000)
> libm.so.6 => /lib64/libm.so.6 (0x00007f8a9c8da000)
> libattr.so.1 => /lib64/libattr.so.1 (0x00007f8a9c6d5000)
> libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f8a9c4ae000)
> libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f8a9c24c000)
```
The reporter is using our packages:
> We've installed bind directly from your CentOS repo; Do you still want us to send your debug symbols?
and the coredumps have been uploaded to my <SANITIZED>.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1798Reject master zones with DS records at the apex.2020-06-08T12:30:22ZMark AndrewsReject master zones with DS records at the apex.DS records belong to the parent zone and should never appear at the zone apex. Reject zones which have a DS record at the apex when loading if they are a master zone.
ISC's operations managed to do this.DS records belong to the parent zone and should never appear at the zone apex. Reject zones which have a DS record at the apex when loading if they are a master zone.
ISC's operations managed to do this.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)