BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2020-05-21T04:11:46Zhttps://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/1848The table in /doc/arm/logging-categories.rst is too wide2020-08-13T00:40:05ZSuzanne GoldlustThe table in /doc/arm/logging-categories.rst is too wideThe table in /doc/arm/logging-categories.rst appears to be formatted correctly, but it is way too wide for the RTD page. There is a horizontal scroll bar at the very bottom, but the table is long and there's no way to scroll when you're ...The table in /doc/arm/logging-categories.rst appears to be formatted correctly, but it is way too wide for the RTD page. There is a horizontal scroll bar at the very bottom, but the table is long and there's no way to scroll when you're in the middle.BIND 9.17 BackburnerOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/18479.16.* recursor has issues recursing2020-09-02T14:52:51ZArsen Stasic9.16.* recursor has issues recursingHi,
we have rolled out 9.16.2 (and 9.16.1) and discovered a recurser issue with following "awkward" query:
```
dig @127.0.0.1 rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa...Hi,
we have rolled out 9.16.2 (and 9.16.1) and discovered a recurser issue with following "awkward" query:
```
dig @127.0.0.1 rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa txt
```
>>>
; <<>> DiG 9.16.2 <<>> @127.0.0.1 rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5790
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 59d6fa9f053c5865010000005ebd47c3e8421c3834504eb2 (good)
;; QUESTION SECTION:
;rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa. IN TXT
;; Query time: 556 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Do Mai 14 15:29:39 CEST 2020
;; MSG SIZE rcvd: 166
>>>
Resolving works with bind up to version 9.11.18, unbound, knot-resolver, powerdns-recursor and following public-resolvers 1.1.1.1, 8.8.8.8, 9.9.9.9:
```
dig @1.1.1.1 rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa txt
```
>>>
; <<>> DiG 9.16.2 <<>> @1.1.1.1 rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 689
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa. IN TXT
;; ANSWER SECTION:
rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa. 68400 IN TXT "recursiontest"
;; Query time: 3984 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Do Mai 14 15:38:48 CEST 2020
;; MSG SIZE rcvd: 273
>>>
And querying the authoritative NS for this zone works as well:
```
dig @ns3.univie.ac.at. rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa txt
```
>>>
; <<>> DiG 9.16.2 <<>> @ns3.univie.ac.at. rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa txt
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37613
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 40d61bae24f2455a010000005ebd4c9c5b4182e0414b7787 (good)
;; QUESTION SECTION:
;rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa. IN TXT
;; ANSWER SECTION:
rec-test-dom-158937817846788.test123.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.3.4.3.5.4.0.8.2.6.0.1.0.0.2.ip6.arpa. 68400 IN TXT "recursiontest"
;; Query time: 0 msec
;; SERVER: 2001:62a:4:322::53:3#53(2001:62a:4:322::53:3)
;; WHEN: Do Mai 14 15:50:20 CEST 2020
;; MSG SIZE rcvd: 192
>>>
If you need anything for further debugging don't hesitate to contact me.September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)Diego dos Santos FronzaDiego dos Santos Fronzahttps://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/1840Add TLS support to BIND2022-04-26T13:10:29ZWitold KrecickiAdd TLS support to BINDNovember 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1839Follow-up from "TCP accept refactoring" - clean up naming of isc__netievent etc.2021-10-05T12:16:35ZWitold KrecickiFollow-up from "TCP accept refactoring" - clean up naming of isc__netievent etc.The following discussion from !3320 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3320#note_127617):
> It isn't urgent, or even new in this branch, but I just no...The following discussion from !3320 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3320#note_127617):
> It isn't urgent, or even new in this branch, but I just noticed for the first time that in some of these names you have a double underscore after `netievent` as well as before, and I'm wondering what that signifies?BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1838Integrate RFC compliance list into ARM on RTD2020-11-12T00:25:37ZVicky Riskvicky@isc.orgIntegrate RFC compliance list into ARM on RTDWe have a request to publish a list of supported RFCs.
I know this is very difficult to do with extreme accuracy, but we do have a list at a reasonable level of accuracy (https://gitlab.isc.org/isc-projects/bind9/-/blob/master/doc/misc/...We have a request to publish a list of supported RFCs.
I know this is very difficult to do with extreme accuracy, but we do have a list at a reasonable level of accuracy (https://gitlab.isc.org/isc-projects/bind9/-/blob/master/doc/misc/rfc-compliance) but this is not incorporated into the ARM.
This issue is to add an appendix to the ARM (in Sphinx at least) to include the rfc-compliance file, so I can link to it on the web site.BIND 9.17 BackburnerSuzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1837[ISC-support #14369] Considering changing ECS caching strategy or negative data2024-03-13T13:17:48ZBrian Conry[ISC-support #14369] Considering changing ECS caching strategy or negative dataCurrently our ECS implementation caches all negative responses at the global scope.
A customer has requested that we store them at the learned scope.
RFC 7871 (Informational only) section 7.4, paragraph 4 notes that the original spec w...Currently our ECS implementation caches all negative responses at the global scope.
A customer has requested that we store them at the learned scope.
RFC 7871 (Informational only) section 7.4, paragraph 4 notes that the original spec was ambiguous and hints that the interpretation of scoping negative answers is more likely to be used in future protocol specifications (if any) than caching them globally.
> This issue is expected to be revisited in a future revision of the protocol, possibly blessing the mixing of positive and negative answers. There are implications for cache data structures that developers should consider when writing new ECS code.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1836Return Extended EDNS Errors (EDE)2023-11-02T16:58:15ZMark AndrewsReturn Extended EDNS Errors (EDE)This is a Summary issue. Please open individual issues for individual code points.
There are 25 defined EDE codes. Some will be possible to return easily, others not so. See [RFC 8914](https://datatracker.ietf.org/doc/html/rfc8914) for...This is a Summary issue. Please open individual issues for individual code points.
There are 25 defined EDE codes. Some will be possible to return easily, others not so. See [RFC 8914](https://datatracker.ietf.org/doc/html/rfc8914) for explanation of the error codes.
* [ ] 0 - Other
* [ ] 1 - Unsupported DNSKEY Algorithm #2715
* [ ] 2 - Unsupported DS Digest Type #2715
* [x] 3 - Stale Answer #2267 (9.18.3, 9.19.1)
* [x] 4 - Forged Answer #3410 (9.19.5)
* [ ] 5 - DNSSEC Indeterminate #2715
* [ ] 6 - DNSSEC Bogus #2715
* [ ] 7 - Signature Expired #2715
* [ ] 8 - Signature Not Yet Valid #2715
* [ ] 9 - DNSKEY Missing #2715
* [ ] 10 - RRSIGs Missing #2715
* [ ] 11 - No Zone Key Bit Set #2715
* [ ] 12 - NSEC Missing #2715
* [ ] 13 - Cached Error
* [ ] 14 - Not Ready
* [x] 15 - Blocked #3410 (9.19.5)
* [x] 16 - Censored #3410 (9.19.5)
* [x] 17 - Filtered #3410 (9.19.5)
* [x] 18 - Prohibited (9.17.21), #3410 (9.19.5)
* [x] 19 - Stale NXDOMAIN Answer #2267 (9.18.3, 9.19.1)
* [ ] 20 - Not Authoritative
* [ ] 21 - Not Supported
* [ ] 22 - No Reachable Authority #2268
* [ ] 23 - Network Error
* [ ] 24 - Invalid DataNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/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 Hunt