BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-10-07T04:58:15Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2939TLS protocol Statement Grammar may be incorrect2021-10-07T04:58:15ZkalfeherTLS protocol Statement Grammar may be incorrect<!--
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
The documentation for the tls `protocols` statement indicates placing the protocol between curly braces, however this results in the following error with both `named-checkconf` and when attempting an `rndc reconfig`:
`protocols { TLSv1.3; };`
```
/etc/opt/isc/scls/isc-bind/named.conf: 10:expected string near '{'
```
When quotes are used instead of brackets, there is no error.
`protocols "TLSv1.3";`
### BIND version used
```
BIND 9.17.18 (Development Release) <id:019a476>
running on Linux x86_64 4.18.0-305.19.1.el8_4.x86_64 #1 SMP Wed Sep 15 15:39:39 UTC 2021
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/scls/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/scls/isc-bind' '--sharedstatedir=/var/opt/isc/scls/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-libxml2'
'--without-lmdb' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu'
'CFLAGS=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
'LDFLAGS=-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/opt/isc/isc-bind/root/usr/lib64'
'CPPFLAGS= -I/opt/isc/isc-bind/root/usr/include' 'LT_SYS_LIBRARY_PATH=/usr/lib64'
'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig'
'SPHINX_BUILD=/builddir/build/BUILD/bind-9.17.18/sphinx/bin/sphinx-build'
compiled by GCC 8.4.1 20200928 (Red Hat 8.4.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libnghttp2 version: 1.33.0
linked to libnghttp2 version: 1.33.0
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
default paths:
named configuration: /etc/opt/isc/scls/isc-bind/named.conf
rndc configuration: /etc/opt/isc/scls/isc-bind/rndc.conf
DNSSEC root key: /etc/opt/isc/scls/isc-bind/bind.keys
nsupdate session key: /var/opt/isc/scls/isc-bind/run/named/session.key
named PID file: /var/opt/isc/scls/isc-bind/run/named/named.pid
named lock file: /var/opt/isc/scls/isc-bind/run/named/named.lock
```
### Steps to reproduce
Using the statement grammar for the `protocols` option found here:
https://bind9.readthedocs.io/en/latest/reference.html?highlight=DoH#tls-statement-grammar
for example the following protocols line in the tls statement will fail:
`protocols { TLSv1.3; };`
When quotes are used, no error is encountered:
`protocols "TLSv1.3";`
### What is the current *bug* behavior?
When `rndc reconfig` is run:
```
rndc: 'reconfig' failed: unexpected token
```
In bind logs the following entry is included:
`config: error: /etc/opt/isc/scls/isc-bind/named.conf:10: expected string near '{'`
Line 10 is where I have protocols configured.
### What is the expected *correct* behavior?
no errors and rndc reconfig succeeds.
### Relevant configuration files
Full TLS statement below:
```
tls resolver01 {
cert-file "/etc/certificates/isc_bind/resolver01-cert.pem";
key-file "/etc/certificates/isc_bind/resolver01.pem";
hostname "resolver01.lab.home";
protocols "TLSv1.3"; // This works as expected
// protocols { TLSv1.3; }; // This fails.
};
```
### Possible fixes
Quoting appears to work fine, so updating the documentation may be an option. However it feels more idiomatic to support brackets.https://gitlab.isc.org/isc-projects/bind9/-/issues/2937DIG defaults to A only rather than A+AAAA search2021-10-06T18:24:29ZOwen DeLongDIG defaults to A only rather than A+AAAA search### Summary
when using dig in the dig <host> form, only A records are searched. AAAA records are ignored.
### BIND version used
DiG 9.10.6
Also DiG 9.16.11-RedHat-9.16.11-5.fc34
### Steps to reproduce
dig split-pao1-64.e-r.fsi.io
o...### Summary
when using dig in the dig <host> form, only A records are searched. AAAA records are ignored.
### BIND version used
DiG 9.10.6
Also DiG 9.16.11-RedHat-9.16.11-5.fc34
### Steps to reproduce
dig split-pao1-64.e-r.fsi.io
or
dig split-pao1-6.e-r.fsi.io
### What is the current *bug* behavior?
Returns A record only in the first case.
Worse, returns NXDOMAIN in the second case.
### What is the expected *correct* behavior?
In the first case, should see A and AAAA records.
In the second case, should see AAAA record and not NXDOMAIN.
### Relevant configuration files
None... DIG is not configurable or at least does not require any configuration for this exercise.
### Relevant logs and/or screenshots
```
kiev:owen (129) ~ % dig split-pao1-64.e-r.fsi.io 2021/10/06 11:14:43
; <<>> DiG 9.10.6 <<>> split-pao1-64.e-r.fsi.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50746
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;split-pao1-64.e-r.fsi.io. IN A
;; ANSWER SECTION:
split-pao1-64.e-r.fsi.io. 2702 IN A 104.244.13.23
;; Query time: 79 msec
;; SERVER: 104.244.14.16#53(104.244.14.16)
;; WHEN: Wed Oct 06 11:14:55 PDT 2021
;; MSG SIZE rcvd: 69
0.001u 0.003s 0:00.08 0.0% 0+0k 0+0io 0pf+0w
; <<>> DiG 9.10.6 <<>> split-pao1-6.e-r.fsi.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21958
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;split-pao1-6.e-r.fsi.io. IN A
;; AUTHORITY SECTION:
fsi.io. 2657 IN SOA fsi.io. hostmaster.fsi.io. 2021100601 7200 3600 604800 3600
;; Query time: 76 msec
;; SERVER: 104.244.14.16#53(104.244.14.16)
;; WHEN: Wed Oct 06 11:14:43 PDT 2021
;; MSG SIZE rcvd: 99
0.001u 0.003s 0:00.08 0.0% 0+0k 0+0io 0pf+0w
```
### Possible fixes
In this day and age, I would expect any default search for name resolution to include both protocols. The fact that dig has not changed this default even now is surprising.https://gitlab.isc.org/isc-projects/bind9/-/issues/2934CID 339111: Memory - corruptions (USE_AFTER_FREE)2021-10-11T13:05:43ZMark AndrewsCID 339111: Memory - corruptions (USE_AFTER_FREE)```
*** CID 339111: Memory - corruptions (USE_AFTER_FREE)
/lib/dns/dispatch.c: 1533 in dns_dispatch_cancel()
1527 } else if (resp->response != NULL) {
1528 resp->response(ISC_R_CANCELED, NULL, resp->arg);
1529 }
1530...```
*** CID 339111: Memory - corruptions (USE_AFTER_FREE)
/lib/dns/dispatch.c: 1533 in dns_dispatch_cancel()
1527 } else if (resp->response != NULL) {
1528 resp->response(ISC_R_CANCELED, NULL, resp->arg);
1529 }
1530 }
1531
1532 done:
CID 339111: Memory - corruptions (USE_AFTER_FREE)
Calling "dns_dispatch_done" frees pointer "*respp" which has already been freed.
1533 dns_dispatch_done(respp);
1534 }
1535
1536 void
1537 dns_dispatch_done(dns_dispentry_t **respp) {
1538 dns_dispatchmgr_t *mgr = NULL;
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2928Coverity issues in the merged dispatch branch2023-01-11T13:58:16ZOndřej SurýCoverity issues in the merged dispatch branch```
** CID 339073: Error handling issues (CHECKED_RETURN)
/lib/dns/resolver.c: 4379 in fctx_doshutdown()
________________________________________________________________________________________________________
*** CID 339073: Error ...```
** CID 339073: Error handling issues (CHECKED_RETURN)
/lib/dns/resolver.c: 4379 in fctx_doshutdown()
________________________________________________________________________________________________________
*** CID 339073: Error handling issues (CHECKED_RETURN)
/lib/dns/resolver.c: 4379 in fctx_doshutdown()
4373 */
4374 fctx_increference(fctx);
4375 fctx_cancelqueries(fctx, false, false);
4376 fctx_cleanup(fctx);
4377
4378 LOCK(&res->buckets[bucketnum].lock);
CID 339073: Error handling issues (CHECKED_RETURN)
Calling "fctx_decreference" without checking return value (as is done elsewhere 6 out of 7 times).
4379 fctx_decreference(fctx);
4380
4381 FCTX_ATTR_SET(fctx, FCTX_ATTR_SHUTTINGDOWN);
4382
4383 INSIST(fctx->state == fetchstate_active ||
4384 fctx->state == fetchstate_done);
```
```
** CID 339072: Error handling issues (CHECKED_RETURN)
/lib/dns/rpz.c: 2247 in rpz_detach()
________________________________________________________________________________________________________
*** CID 339072: Error handling issues (CHECKED_RETURN)
/lib/dns/rpz.c: 2247 in rpz_detach()
2241 false);
2242 }
2243 dns_db_detach(&rpz->updb);
2244 }
2245 }
2246
CID 339072: Error handling issues (CHECKED_RETURN)
Calling "isc_timer_reset" without checking return value (as is done elsewhere 9 out of 10 times).
2247 isc_timer_reset(rpz->updatetimer, isc_timertype_inactive, NULL,
2248 NULL, true);
2249 isc_timer_detach(&rpz->updatetimer);
2250
2251 isc_ht_destroy(&rpz->nodes);
2252
```
```
** CID 339071: (USE_AFTER_FREE)
/lib/dns/resolver.c: 2846 in resquery_connected()
/lib/dns/resolver.c: 2846 in resquery_connected()
/lib/dns/resolver.c: 2846 in resquery_connected()
/lib/dns/resolver.c: 2846 in resquery_connected()
________________________________________________________________________________________________________
*** CID 339071: (USE_AFTER_FREE)
/lib/dns/resolver.c: 2846 in resquery_connected()
2840 fctx_cancelquery(query, NULL, false, false);
2841 fctx_done(fctx, eresult, __LINE__);
2842 break;
2843 }
2844
2845 detach:
CID 339071: (USE_AFTER_FREE)
Calling "resquery_detach" frees pointer "query" which has already been freed.
2846 resquery_detach(&query);
2847 }
2848
2849 static void
2850 fctx_finddone(isc_task_t *task, isc_event_t *event) {
2851 fetchctx_t *fctx;
/lib/dns/resolver.c: 2846 in resquery_connected()
2840 fctx_cancelquery(query, NULL, false, false);
2841 fctx_done(fctx, eresult, __LINE__);
2842 break;
2843 }
2844
2845 detach:
CID 339071: (USE_AFTER_FREE)
Calling "resquery_detach" frees pointer "query" which has already been freed.
2846 resquery_detach(&query);
2847 }
2848
2849 static void
2850 fctx_finddone(isc_task_t *task, isc_event_t *event) {
2851 fetchctx_t *fctx;
/lib/dns/resolver.c: 2846 in resquery_connected()
2840 fctx_cancelquery(query, NULL, false, false);
2841 fctx_done(fctx, eresult, __LINE__);
2842 break;
2843 }
2844
2845 detach:
CID 339071: (USE_AFTER_FREE)
Calling "resquery_detach" frees pointer "query" which has already been freed.
2846 resquery_detach(&query);
2847 }
2848
2849 static void
2850 fctx_finddone(isc_task_t *task, isc_event_t *event) {
2851 fetchctx_t *fctx;
/lib/dns/resolver.c: 2846 in resquery_connected()
2840 fctx_cancelquery(query, NULL, false, false);
2841 fctx_done(fctx, eresult, __LINE__);
2842 break;
2843 }
2844
2845 detach:
CID 339071: (USE_AFTER_FREE)
Calling "resquery_detach" frees pointer "query" which has already been freed.
2846 resquery_detach(&query);
2847 }
2848
2849 static void
2850 fctx_finddone(isc_task_t *task, isc_event_t *event) {
2851 fetchctx_t *fctx;
```
```
** CID 339070: Memory - corruptions (USE_AFTER_FREE)
________________________________________________________________________________________________________
*** CID 339070: Memory - corruptions (USE_AFTER_FREE)
/lib/dns/request.c: 920 in request_cancel()
914
915 request->flags |= DNS_REQUEST_F_CANCELED;
916 request->flags &= ~DNS_REQUEST_F_CONNECTING;
917
918 if (request->dispentry != NULL) {
919 dns_dispatch_cancel(request->dispentry);
CID 339070: Memory - corruptions (USE_AFTER_FREE)
Calling "dns_dispatch_removeresponse" frees pointer "request->dispentry" which has already been freed.
920 dns_dispatch_removeresponse(&request->dispentry);
921 }
922
923 dns_dispatch_detach(&request->dispatch);
924 }
925 }
```
```
** CID 339069: (USE_AFTER_FREE)
/lib/dns/resolver.c: 1776 in resquery_senddone()
/lib/dns/resolver.c: 1776 in resquery_senddone()
________________________________________________________________________________________________________
*** CID 339069: (USE_AFTER_FREE)
/lib/dns/resolver.c: 1776 in resquery_senddone()
1770 fctx_cancelquery(query, NULL, false, false);
1771 fctx_done(fctx, eresult, __LINE__);
1772 break;
1773 }
1774
1775 detach:
CID 339069: (USE_AFTER_FREE)
Calling "resquery_detach" frees pointer "query" which has already been freed.
1776 resquery_detach(&query);
1777 }
1778
1779 static inline isc_result_t
1780 fctx_addopt(dns_message_t *message, unsigned int version, uint16_t udpsize,
1781 dns_ednsopt_t *ednsopts, size_t count) {
/lib/dns/resolver.c: 1776 in resquery_senddone()
1770 fctx_cancelquery(query, NULL, false, false);
1771 fctx_done(fctx, eresult, __LINE__);
1772 break;
1773 }
1774
1775 detach:
CID 339069: (USE_AFTER_FREE)
Calling "resquery_detach" frees pointer "query" which has already been freed.
1776 resquery_detach(&query);
1777 }
1778
1779 static inline isc_result_t
1780 fctx_addopt(dns_message_t *message, unsigned int version, uint16_t udpsize,
1781 dns_ednsopt_t *ednsopts, size_t count) {
```
```
** CID 339068: Memory - corruptions (USE_AFTER_FREE)
________________________________________________________________________________________________________
*** CID 339068: Memory - corruptions (USE_AFTER_FREE)
/lib/dns/resolver.c: 1397 in fctx_cancelquery()
1391 /*
1392 * Check for any outstanding dispatch responses and if they
1393 * exist, cancel them.
1394 */
1395 if (query->dispentry != NULL) {
1396 dns_dispatch_cancel(query->dispentry);
CID 339068: Memory - corruptions (USE_AFTER_FREE)
Calling "dns_dispatch_removeresponse" frees pointer "query->dispentry" which has already been freed.
1397 dns_dispatch_removeresponse(&query->dispentry);
1398 }
1399
1400 if (ISC_LINK_LINKED(query, link)) {
1401 ISC_LIST_UNLINK(fctx->queries, query, link);
1402 }
```January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2926use netmgr for route sockets and remove isc_socket2022-01-21T13:44:36ZEvan Huntuse netmgr for route sockets and remove isc_socketThe last remaining use of `isc_socket` and `isc_socketmgr` in BIND is for the netlink/route sockets that are used to scan for interface changes.
The libuv documentation indicates that any socket that honors the datagram contract can be ...The last remaining use of `isc_socket` and `isc_socketmgr` in BIND is for the netlink/route sockets that are used to scan for interface changes.
The libuv documentation indicates that any socket that honors the datagram contract can be passed to `uv_udp_open()`, so we should be able to make the netmgr do this instead.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2925Defining "default" "http" clause should not be allowed in the configuration2021-10-05T10:12:27ZArtem BoldarievDefining "default" "http" clause should not be allowed in the configurationDefining 'default' 'http' configuration should not be allowed in configuration files, as `default` is reserved for internal use in `listen-on` statements. For example, the following configuration file should be rejected:
```
tls local-t...Defining 'default' 'http' configuration should not be allowed in configuration files, as `default` is reserved for internal use in `listen-on` statements. For example, the following configuration file should be rejected:
```
tls local-tls {
key-file "key.pem";
cert-file "cert.pem";
};
http default {
endpoints { "/dns-query"; };
listener-clients 100;
streams-per-connection 100;
};
options {
listen-on { 10.53.0.1; };
http-port 80;
https-port 443;
http-listener-clients 100;
http-streams-per-connection 100;
listen-on port 443 tls local-tls http default { 10.53.0.1; };
listen-on port 8080 tls none http default { 10.53.0.1; };
};
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2921Unhandled NULL returns from jemalloc's mallocx()2021-10-01T04:19:29ZMichał KępieńUnhandled NULL returns from jemalloc's mallocx()As [documented][1], jemalloc's `mallocx()` function can return `NULL`:
> The mallocx() and rallocx() functions return a pointer to the
> allocated memory if successful; otherwise a NULL pointer is returned
> to indicate insufficient con...As [documented][1], jemalloc's `mallocx()` function can return `NULL`:
> The mallocx() and rallocx() functions return a pointer to the
> allocated memory if successful; otherwise a NULL pointer is returned
> to indicate insufficient contiguous memory was available to service
> the allocation request.
However, `mem_get()` [does not account for that possibility][2] as
commit fcc6814776c285cb64608f5ac18281fdf8a063fe (!5012) removed a `NULL`
check which was previously there. This raises several issues:
1. Segmentation faults may now happen instead of `abort()`s. This was
[proven][3] to be possible by GitLab CI (see GDB output below).
2. Behavior is inconsistent between jemalloc-enabled and non-jemalloc
builds. The latter [checks][4] whether each pointer returned by the
system `malloc()` function is `NULL` and `abort()`s if it is. The
former does not (see GDB output below).
<details>
<summary>Click here to fold/expand GDB output</summary>
```
Core was generated by `/builds/isc-projects/bind9/lib/isc/tests/.libs/mem_test'.
Program terminated with signal SIGABRT, Aborted.
#0 0xf7f29069 in __kernel_vsyscall ()
[Current thread is 1 (Thread 0xe13f8b40 (LWP 7031))]
(gdb) bt
#0 0xf7f29069 in __kernel_vsyscall ()
#1 0xf7cae382 in raise () from /lib/i386-linux-gnu/libc.so.6
#2 0xf7c982b6 in abort () from /lib/i386-linux-gnu/libc.so.6
#3 0xf7e80cf7 in ?? () from /usr/lib/i386-linux-gnu/libcmocka.so.0
#4 0xf7e80d40 in ?? () from /usr/lib/i386-linux-gnu/libcmocka.so.0
#5 <signal handler called>
#6 0xf7dc06ca in ?? () from /lib/i386-linux-gnu/libc.so.6
#7 0xf7ed108a in memset (__len=<optimized out>, __ch=190, __dest=0x0) at /usr/i686-linux-gnu/include/bits/string_fortified.h:71
#8 mem_get (size=<optimized out>, ctx=0xf5437000) at mem.c:344
#9 isc__mem_get (ctx=0xf5437000, size=65534, file=0x565c4008 "mem_test.c", line=439) at mem.c:752
#10 0x565c164e in mem_thread (arg=0xf5437000) at mem_test.c:439
#11 0xf7ef1996 in isc__trampoline_run (arg=0x57bb1d00) at trampoline.c:185
#12 0xf7e63fd2 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#13 0xf7d796d6 in clone () from /lib/i386-linux-gnu/libc.so.6
(gdb) frame 8
#8 mem_get (size=<optimized out>, ctx=0xf5437000) at mem.c:344
344 memset(ret, 0xbe, size); /* Mnemonic for "beef". */
(gdb) print ret
$1 = 0x0
```
</details>
[1]: http://jemalloc.net/jemalloc.3.html
[2]: https://gitlab.isc.org/isc-projects/bind9/-/blob/eeec53eb5da5c0968e099f01c6236127f9813a97/lib/isc/mem.c#L341-345
[3]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2004301
[4]: https://gitlab.isc.org/isc-projects/bind9/-/blob/eeec53eb5da5c0968e099f01c6236127f9813a97/lib/isc/jemalloc_shim.h#L30October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2917axfr problems bind 9.17.18 under FreeBSD2022-01-26T11:33:40ZAndrey Blokhintsevaxfr problems bind 9.17.18 under FreeBSD<!--
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
Unstable zone tranfer with bind 9.17.18 under FreeBSD
### BIND version used
```
BIND 9.17.18 (Development Release) <id:be99fc92b63ef2463cadb2f90162982ed3ed289d>
running on FreeBSD amd64 12.2-STABLE FreeBSD 12.2-STABLE stable/12-n233232-db3515d03dd ZURBAGAN
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr/local' '--enable-dnsrps' '--with-readline=libedit' '--with-dlz-filesystem=yes' '--enable-dnstap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-querytrace' '--enable-tcp-fastopen' '--prefix=/usr/local' '--mandir=/usr/local/man' '--disable-silent-rules' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.2' 'build_alias=amd64-portbld-freebsd12.2' 'CC=cc' 'CFLAGS=-O2 -pipe -mtune=native -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c -Wl,-rpath,/usr/local/lib -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf' 'READLINE_CFLAGS=-L/usr/local/lib'
compiled by CLANG FreeBSD Clang 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)
compiled with OpenSSL version: OpenSSL 1.1.1l 24 Aug 2021
linked to OpenSSL version: OpenSSL 1.1.1l 24 Aug 2021
compiled with libuv version: 1.42.0
linked to libuv version: 1.42.0
compiled with libnghttp2 version: 1.44.0
linked to libnghttp2 version: 1.44.0
compiled with libxml2 version: 2.9.12
linked to libxml2 version: 20912
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
compiled with protobuf-c version: 1.4.0
linked to protobuf-c version: 1.4.0
threads support is enabled
default paths:
named configuration: /usr/local/etc/namedb/named.conf
rndc configuration: /usr/local/etc/namedb/rndc.conf
DNSSEC root key: /usr/local/etc/namedb/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Build bind 9.17.18 from ports (port names: bind9-devel bind-tools) under 12.2-STABLE and setup as secondary server, or do "dig axfr zone @server". Zone tranfer will fail with 20-30% probability for zone with 10K records.
### What is the expected *correct* behavior?
100% sucessfull zone transfers
### Relevant configuration files
no configuration is requred for dig
### Relevant logs and/or screenshots
tcpdump of correct and failed "dig dn.ua @93.183.202.34 axfr" attached
dig dn.ua @93.183.202.34 axfr
;; ERROR: short (< header size) message
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
I have added debug to isc__nm_tcpdns_processbuffer() lib/isc/netmgr/tcpdns.c
```
len = ntohs(*(uint16_t *)sock->buf);
printf("BAG *** isc__nm_tcpdns_processbuffer len=%zu sock->buf_len=%zu\n", len, sock->buf_len);
if (len > sock->buf_len - 2) {
```
and found strange len zeroing.
Failed case:
```
BAG *** isc__nm_tcpdns_processbuffer len=11076 sock->buf_len=2896
BAG *** isc__nm_tcpdns_processbuffer len=0 sock->buf_len=4344
```
Sucessful case:
```
BAG *** isc__nm_tcpdns_processbuffer len=11076 sock->buf_len=4344
BAG *** isc__nm_tcpdns_processbuffer len=11076 sock->buf_len=11078
BAG *** isc__nm_tcpdns_processbuffer len=9949 sock->buf_len=18639
BAG *** isc__nm_tcpdns_processbuffer len=9881 sock->buf_len=8688
BAG *** isc__nm_tcpdns_processbuffer len=9881 sock->buf_len=20091
BAG *** isc__nm_tcpdns_processbuffer len=10206 sock->buf_len=10208
BAG *** isc__nm_tcpdns_processbuffer len=9960 sock->buf_len=38346
BAG *** isc__nm_tcpdns_processbuffer len=9558 sock->buf_len=28384
BAG *** isc__nm_tcpdns_processbuffer len=10070 sock->buf_len=18824
BAG *** isc__nm_tcpdns_processbuffer len=10091 sock->buf_len=8752
BAG *** isc__nm_tcpdns_processbuffer len=10091 sock->buf_len=49718
BAG *** isc__nm_tcpdns_processbuffer len=10497 sock->buf_len=39625
BAG *** isc__nm_tcpdns_processbuffer len=10300 sock->buf_len=29126
BAG *** isc__nm_tcpdns_processbuffer len=10016 sock->buf_len=18824
BAG *** isc__nm_tcpdns_processbuffer len=10057 sock->buf_len=8806
BAG *** isc__nm_tcpdns_processbuffer len=10057 sock->buf_len=74342
BAG *** isc__nm_tcpdns_processbuffer len=10171 sock->buf_len=64283
BAG *** isc__nm_tcpdns_processbuffer len=10319 sock->buf_len=54110
BAG *** isc__nm_tcpdns_processbuffer len=9700 sock->buf_len=43789
BAG *** isc__nm_tcpdns_processbuffer len=9972 sock->buf_len=34087
BAG *** isc__nm_tcpdns_processbuffer len=10476 sock->buf_len=24113
BAG *** isc__nm_tcpdns_processbuffer len=13692 sock->buf_len=13635
BAG *** isc__nm_tcpdns_processbuffer len=13692 sock->buf_len=18409
BAG *** isc__nm_tcpdns_processbuffer len=4713 sock->buf_len=4715
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/2914SW Bill of Materials, SPDX2022-12-14T13:46:18ZVicky Riskvicky@isc.orgSW Bill of Materials, SPDXWe need to support industry efforts to automate discovery of all the software contained in an open source project. The drivers include both compliance with open source licensing, and discovery of known vulnerable components.
[SPDX](http...We need to support industry efforts to automate discovery of all the software contained in an open source project. The drivers include both compliance with open source licensing, and discovery of known vulnerable components.
[SPDX](https://spdx.dev) is now the leading proposed solution, and was recently standardized by ISO.
We are going to implement this using https://reuse.software (selected by sweng) to support initially, license discovery.
The process will require updating every file:
- either use reuse addheader (as briefly documented in doc/dev/copyright);
- or add record to .reuse/dep5. There are already entries for ISC MPL-2.0, ISC CC0-1.0 and FSF (libtool files) as well as many other licenses.https://gitlab.isc.org/isc-projects/bind9/-/issues/2913Release checklist for BIND is missing a step for the official docker image2021-10-04T10:20:58ZHåkan LindqvistRelease checklist for BIND is missing a step for the official docker image<!--
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
The release checklist used for BIND releases (see eg https://gitlab.isc.org/isc-projects/bind9/-/issues/2893) does not have a step for publishing the official docker image, and new versions of said docker image seems to generally not get released unless users voice complaints.
### BIND version used
N/A
### Steps to reproduce
* Observe that a new BIND version has been announced by ISC
* Try to redeploy your containers to get the new version
### What is the current *bug* behavior?
There is usually no new docker image available
### What is the expected *correct* behavior?
There should be a new docker image available as part of the release
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
N/A
### Possible fixes
My thinking is that if this step is added to the release checklist, whatever issues cause the docker image to not be published will be found internally by ISC and fixed.October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2912Explicit support for conservative DNSSEC algorithm rollover (RFC 6781 4.1.4)2021-09-20T07:42:43ZEtienne DechampsExplicit support for conservative DNSSEC algorithm rollover (RFC 6781 4.1.4)I couldn't find an explicitly documented way to use `dnssec-settime` and `dnssec-signzone -S` (smart signing) to perform a "conservative" DNSSEC algorithm rollover as described in [RFC 6781 section 4.1.4](https://datatracker.ietf.org/doc...I couldn't find an explicitly documented way to use `dnssec-settime` and `dnssec-signzone -S` (smart signing) to perform a "conservative" DNSSEC algorithm rollover as described in [RFC 6781 section 4.1.4](https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.4).
That RFC describes a procedure that involves publishing additional RRSIGs with the algorithm *first*, wait until old RRSIG RRsets have expired, and only then add the new DNSKEY. The reason why algorithm rollovers have to be done in this precise order is because an RRSIG RRset must contain at least one key for each algorithm that is used in the DNSKEY RRset. (See [RFC 4035 2.2](https://datatracker.ietf.org/doc/html/rfc4035#section-2.2) and [RFC 6840 5.11](https://datatracker.ietf.org/doc/html/rfc6840#section-5.11).) If that order is not followed, a cache could end up with a new DNSKEY using the new algorithm, alongside RRSIGs that are missing the new algorithm, which is not standard-conformant.
The same applies in reverse when removing an algorithm: the DNSKEY should be removed *first*, and RRSIGs should only be removed after the DNSKEY removal has propagated.
The [Algorithm rollover](https://bind9.readthedocs.io/en/latest/dnssec-guide.html#algorithm-rollovers) section of the bind DNSSEC guide seems to describe a procedure where the DNSKEY and RRSIG records are added/removed at the same time, which violates RFC 6781 section 4.1.4.
Digging a little deeper, I noticed that `dnssec-settime` and `dnssec-signzone` (from bind 9.16.15-debian) can, in fact, be coerced into rolling out the `RRSIG`s before the `DNSKEY`:
```
$ echo '@ 300 IN SOA example. example. (123 5m 5m 5m 5m)' > example
$ dnssec-keygen -f KSK -a 8 example.
$ dnssec-keygen -f KSK -a 13 example.
$ dnssec-settime -A -1w -P +1w Kexample.+013+*.key
$ dnssec-signzone -z -S example
```
The resulting `example.signed` file will contain `RRSIG`s for algorithms 8 and 13, but only the `DNSKEY` for algorithm 8. This is great and can be used for RFC 6781-compliant algorithm rollover, but let's note that this behaviour seems somewhat unintended and is completely undocumented - in fact, it directly contradicts `dnssec-settime(8)`, which states that after the activation date the "key is included in the zone".
A more serious problem is that it doesn't seem possible to do this in reverse for algorithm removal:
```
$ dnssec-settime -D -1w -I +1w Kexample.+008+*.key
dnssec-settime: warning: Key is scheduled to be deleted before it is
scheduled to be inactive.
$ dnssec-signzone -z -S example
```
The resulting `example.signed` is missing both `RRSIG`s and the `DNSKEY` for algorithm 8. In order to be RFC 6781-compliant, we need to remove the `DNSKEY` before the `RRSIG`s but it doesn't look like that's possible with the current implementation of smart signing.
It looks like the following changes are required for bind9 smart signing to support conservative algorithm rollover as described in RFC 6781 4.1.4:
- `dnssec-signzone -S` should output `RRSIG`s (but not the `DNSKEY`) if the key deletion date is in the past but the key inactivation date is in the future. The `dnssec-settime` warning shown above should be removed. The `dnssec-settime` manpage should be updated accordingly.
- The "Algorithm rollovers" section of the DNSSEC guide should be updated to explain how to do a RFC 6781 conservative rollover using `dnssec-settime`, i.e. using reversed activation/publication and deletion/inactivation dates.https://gitlab.isc.org/isc-projects/bind9/-/issues/2906sig-signing-type breaks `named-checkconf -p` pretty output2021-09-16T08:41:28ZEgbertsig-signing-type breaks `named-checkconf -p` pretty output### Summary
When using the “sig-signing-type” keyword found inside a zone clause, it causes the named.conf file checker to silently exit with error code 1.
### BIND version used
named v9.16.15
### Steps to reproduce
The named.conf ...### Summary
When using the “sig-signing-type” keyword found inside a zone clause, it causes the named.conf file checker to silently exit with error code 1.
### BIND version used
named v9.16.15
### Steps to reproduce
The named.conf file simply has the following excerpt:
```
zone “public” {
# . . .
sig-signing-type 65243
# . . .
};
```
Running
```
named-checkconf -t . -p named.conf
```
will no longer output any content of the file.
### What is the current *bug* behavior?
No longer outputs any file content
Exit code 1
### What is the expected *correct* behavior?
Expected the original (but nicely rearranged) output of named.conf.
### Relevant configuration files
### Relevant logs and/or screenshots
No error output, no output output, just silent exit with an error code of 1.
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2897rndc thaw does not process manually made changes to a dynamic zone2021-09-09T19:36:12ZJakob Dhondtrndc thaw does not process manually made changes to a dynamic zone### Summary
When freezing a dynamic zone with `rndc freeze <zone>`, manually editing the zone file and then unfreezing the zone with `rndc thaw <zone>` the manual changes do not seem to be processed. E.g. when manually adding an entry i...### Summary
When freezing a dynamic zone with `rndc freeze <zone>`, manually editing the zone file and then unfreezing the zone with `rndc thaw <zone>` the manual changes do not seem to be processed. E.g. when manually adding an entry it won't be returned after unfreezing the zone, when querying it with dig. If I am not misunderstanding the [documentation](https://bind9.readthedocs.io/en/latest/advanced.html#the-journal-file) the following paragraph seems to suggest that manual changes to a dynamic zone should be immediately processed as described.
> To make changes to a dynamic zone manually, follow these steps: first, disable dynamic updates to the zone using rndc freeze zone. This updates the zone file with the changes stored in its .jnl file. Then, edit the zone file. Finally, run rndc thaw zone to reload the changed zone and re-enable dynamic updates.
This seems to be related to issue #2186.
### BIND version used
```
BIND 9.16.20 (Extended Support Version) <id:26db37f>
running on Linux x86_64 3.10.0-1160.25.1.el7.x86_64 #1 SMP Tue Apr 13 18:55:45 EDT 2021
built by make with '--build=x86_64-koji-linux-gnu' '--host=x86_64-koji-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/named' '--bindir=/opt/named/bin' '--sbindir=/opt/named/sbin' '--sysconfdir=/etc' '--datadir=/opt/named/share' '--includedir=/opt/named/include' '--libdir=/opt/named/lib64' '--libexecdir=/opt/named/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/opt/named/share/man' '--infodir=/opt/named/share/info' '--exec-prefix=/opt/named' '--disable-static' '--enable-dnstap' '--disable-openssl-version-check' '--with-randomdev=/dev/urandom' '--with-pic' '--with-json-c' '--with-libtool' '--with-libxml2' '--without-lmdb' '--with-tuning=large' '--with-python' '--with-python-install-dir=/opt/named/usr/lib/python2.7/site-packages' '--with-docbook-xsl=/opt/named/share/sgml/docbook/xsl-stylesheets' '--includedir=/opt/named/include/bind9' 'build_alias=x86_64-koji-linux-gnu' 'host_alias=x86_64-koji-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=-Wl,-z,relro ' 'PKG_CONFIG_PATH=:/opt/named/lib64/pkgconfig:/opt/named/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
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 libuv version: 1.41.0
linked to libuv version: 1.41.0
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.0.2
linked to protobuf-c version: 1.0.2
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
1. Have a dynamic zone with the following config and content.
```
zone "zone.dyn-test.rpz.switch.ch" {
type master;
file "dynamic/zone.dyn-test.rpz.switch.ch";
update-policy {
grant "zone.dyn-test.rpz.switch.ch.tsig" subdomain "zone.dyn-test.rpz.switch.ch" "ANY";
};
dnssec-policy "none";
};
```
```
$ORIGIN .
$TTL 300 ; 5 minutes
zone.dyn-test.rpz.switch.ch IN SOA bona.switch.ch. dns-operation.switch.ch. (
2021073347 ; serial
600 ; refresh (10 minutes)
300 ; retry (5 minutes)
604800 ; expire (1 week)
300 ; minimum (5 minutes)
)
NS bona.switch.ch.
```
2. Check that dynamic updates work
* on a different machine that is allowed to do dynamic updates:
```
nsupdate -k <tsig-key>
> server pepsi.switch.ch
> zone zone.dyn-test.rpz.switch.ch
> update add test.zone.dyn-test.rpz.switch.ch 300 a 127.0.0.1
> send
```
* check for the record on the nameserver:
```
$ dig test.zone.dyn-test.rpz.switch.ch @localhost +norec
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 <<>> test.zone.dyn-test.rpz.switch.ch @localhost +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23411
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;test.zone.dyn-test.rpz.switch.ch. IN A
;; ANSWER SECTION:
test.zone.dyn-test.rpz.switch.ch. 300 IN A 127.0.0.1
;; AUTHORITY SECTION:
zone.dyn-test.rpz.switch.ch. 300 IN NS bona.switch.ch.
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Sep 09 11:44:51 CEST 2021
;; MSG SIZE rcvd: 105
```
3. Freeze the zone, manually add a record and unfreeze the zone.
* `$ rndc freeze zone.dyn-test.rpz.switch.ch`
* Zone file correctly shows the dynamically added record.
```
$ cat zone.dyn-test.rpz.switch.ch
$ORIGIN .
$TTL 300 ; 5 minutes
zone.dyn-test.rpz.switch.ch IN SOA bona.switch.ch. dns-operation.switch.ch. (
2021073348 ; serial
600 ; refresh (10 minutes)
300 ; retry (5 minutes)
604800 ; expire (1 week)
300 ; minimum (5 minutes)
)
NS bona.switch.ch.
$ORIGIN zone.dyn-test.rpz.switch.ch.
test A 127.0.0.1
```
* Add another record e.g.
```
$ cat zone.dyn-test.rpz.switch.ch
$ORIGIN .
$TTL 300 ; 5 minutes
zone.dyn-test.rpz.switch.ch IN SOA bona.switch.ch. dns-operation.switch.ch. (
2021073348 ; serial
600 ; refresh (10 minutes)
300 ; retry (5 minutes)
604800 ; expire (1 week)
300 ; minimum (5 minutes)
)
NS bona.switch.ch.
$ORIGIN zone.dyn-test.rpz.switch.ch.
test A 127.0.0.1
A 127.0.0.2
```
* `$ rndc thaw zone.dyn-test.rpz.switch.ch`
* Logs:
```
09-Sep-2021 11:49:50.536 general: info: received control channel command 'freeze zone.dyn-test.rpz.switch.ch'
09-Sep-2021 11:49:52.203 general: info: freezing zone 'zone.dyn-test.rpz.switch.ch/IN': success
09-Sep-2021 11:53:06.670 general: info: received control channel command 'thaw zone.dyn-test.rpz.switch.ch'
09-Sep-2021 11:53:06.671 general: info: thawing zone 'zone.dyn-test.rpz.switch.ch/IN': success
```
4. Query the record again.
```
$ dig test.zone.dyn-test.rpz.switch.ch @localhost +norec
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 <<>> test.zone.dyn-test.rpz.switch.ch @localhost +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19316
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;test.zone.dyn-test.rpz.switch.ch. IN A
;; ANSWER SECTION:
test.zone.dyn-test.rpz.switch.ch. 300 IN A 127.0.0.1
;; AUTHORITY SECTION:
zone.dyn-test.rpz.switch.ch. 300 IN NS bona.switch.ch.
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Sep 09 11:54:39 CEST 2021
;; MSG SIZE rcvd: 105
```
### What is the current *bug* behavior?
After executing the 4 steps above only one A record is returned.
### What is the expected *correct* behavior?
After executing the 4 steps above I'd expect there to be two A records.
### Relevant configuration files
named.conf
```
...
some acls
...
controls {
inet 127.0.0.1 allow {
127.0.0.1/32;
} keys {
"rndc-key";
};
inet ::1 allow {
::1/128;
} keys {
"rndc-key";
};
};
dnssec-policy "test" {
dnskey-ttl 3600;
keys {
csk key-directory lifetime unlimited algorithm 13;
};
max-zone-ttl 3600;
parent-ds-ttl 3600;
parent-propagation-delay 3600;
publish-safety 3600;
retire-safety 3600;
signatures-refresh P1D;
zone-propagation-delay 300;
};
logging {
channel "switch_local" {
file "/var/log/named/named" versions 10 size 6291456;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel "switch_other" {
file "/var/log/named/other" versions 10 size 6291456;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
category "general" {
"switch_local";
};
category "notify" {
"switch_local";
};
category "xfer-in" {
"switch_local";
};
category "xfer-out" {
"switch_local";
};
category "network" {
"switch_local";
};
category "dnssec" {
"switch_local";
};
category "default" {
"switch_other";
};
};
options {
directory "/etc/bind/zones";
listen-on port 53 {
"any";
};
listen-on-v6 port 53 {
"any";
};
pid-file "/var/run/named/named.pid";
server-id hostname;
transfers-in 100;
transfers-out 100;
transfers-per-ns 10;
version "contact dns-operation@switch.ch";
allow-query-cache {
"none";
};
check-names master warn;
dnssec-validation no;
ixfr-from-differences yes;
query-source address 130.59.117.36 port 0;
query-source-v6 address 2001:620:0:1005:21a:4aff:fede:5a port 0;
recursion no;
allow-transfer {
"XFR-SWITCH";
};
check-integrity no;
check-sibling no;
notify explicit;
notify-source 130.59.117.36;
notify-source-v6 2001:620:0:1005:21a:4aff:fede:5a;
transfer-source 130.59.117.36;
transfer-source-v6 2001:620:0:1005:21a:4aff:fede:5a;
use-alt-transfer-source no;
};
statistics-channels {
inet 127.0.0.1 port 8053 allow {
127.0.0.1/32;
};
inet ::1 port 8053 allow {
::1/128;
};
};
key "rndc-key" {
algorithm "hmac-md5";
secret "????????????????????????";
};
...
more keys
...
key "zone.dyn-test.rpz.switch.ch.tsig" {
algorithm "HMAC-SHA512";
secret "????????????????????????????????????????????????????????????????????????????????????????";
};
...
more zones
...
zone "zone.dyn-test.rpz.switch.ch" {
type master;
file "dynamic/zone.dyn-test.rpz.switch.ch";
update-policy {
grant "zone.dyn-test.rpz.switch.ch.tsig" subdomain "zone.dyn-test.rpz.switch.ch" "ANY";
};
dnssec-policy "none";
};
```
I removed some parts of the config. I hope they're not relevant.
### Relevant logs and/or screenshots
See above.
### Possible fixeshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2896TXT record parsing interop issue in named-compilezone2021-09-08T11:23:35ZGavin BrownTXT record parsing interop issue in named-compilezone<!--
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
I have an interoperability issue where `named-compilezone` and `ldns-read-zone` handle the following TXT record differently:
```
example.com. 3600 IN TXT "foo""bar"
```
Note the lack of space between `"foo"` and `"bar"`. From reading RFC 1035 it's not clear whether the space between the two text segments is required or optional:
> ```
> 3.3.14. TXT RDATA format
>
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> / TXT-DATA /
> +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>
> where:
>
> TXT-DATA One or more <character-string>s.
> ```
A `<character-string>` is defined in Section 5 as follows:
> ```
> <character-string> is expressed in one or two ways: as a contiguous set
> of characters without interior spaces, or as a string beginning with a "
> and ending with a ". Inside a " delimited string any character can
> occur, except for a " itself, which must be quoted using \ (back slash).
> ```
RFC 1035 says nothing about how consecutive `<character-string>`s are delimited from each other.
`named-compilezone` parses the above TXT record without issue, and in its output, re-emits the TXT record with a space between each segment:
```
example.com. 3600 IN TXT "foo" "bar"
```
My question is whether or `named-compilezone` should reject the input above because it's malformed.
`ldns-read-zone` parses the record incorrectly and produces a mangled record, which I've already reported [here](https://github.com/NLnetLabs/ldns/issues/139).
### BIND version used
```
$ named-compilezone -v
9.16.7
```
Installed using Homebrew on macOS Big Sur, but this behaviour has also been reported on other versions/OSes.
### Steps to reproduce
`named-compilezone -i none -o /dev/stdout example.com example.com.txt`
[example.com.txt](/uploads/6f3e9f50560dbc932d1336da202a322c/example.com.txt)
### What is the current *bug* behavior?
```
$ named-compilezone -i none -o /dev/stdout example.com example.com.txt
zone example.com/IN: loaded serial 2021090201
example.com. 900 IN SOA ns.icann.org. noc.dns.icann.org. 2021090201 7200 3600 1209600 3600
example.com. 900 IN NS a.iana-servers.net.
example.com. 900 IN NS b.iana-servers.net.
example.com. 900 IN TXT "foo" "bar"
OK
```
### What is the expected *correct* behavior?
The existing behaviour *or* `named-compilezone` should reject the RR as malformed.
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
N/A
### Possible fixes
N/Ahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2894Windows Service Error 1067 for v. 9.16.202021-09-06T15:28:42ZmikeksWindows Service Error 1067 for v. 9.16.20### Summary
Unable to start ISC Bind v. 9.16.20 as Windows Service. It works with ISC Bind v. 9.11.35.
### BIND version used
The problem only occurs with ISC Bind 9.16.20, but not in 9.11.35
### Steps to reproduce
1. Download Windo...### Summary
Unable to start ISC Bind v. 9.16.20 as Windows Service. It works with ISC Bind v. 9.11.35.
### BIND version used
The problem only occurs with ISC Bind 9.16.20, but not in 9.11.35
### Steps to reproduce
1. Download Windows x64 binaries for ISC Bind 9.16.20
2. Run BINDInstall.exe as administrator, install the Bind.
3. Put your configs into ./etc folder
4. Allow full access to bind service account
5. Successfully run the Bind from command line: named -f
6. Attempt to run as service causes Windows error 1067
### What is the current *bug* behavior?
Attempt to run Windows service causes error 1067.
### What is the expected *correct* behavior?
Service should be able to start. The same configuration works with Bind 9.11.35.
### Relevant logs and/or screenshots
The Windows Application Events log doesn't reveal any error(s).https://gitlab.isc.org/isc-projects/bind9/-/issues/2893Release Checklist for BIND 9.16.21, BIND 9.16.21-S1, 9.17.182021-09-20T16:11:26ZMichał KępieńRelease Checklist for BIND 9.16.21, BIND 9.16.21-S1, 9.17.18## Notes
- BIND releases 9.11.36 & 9.11.36-S1, which were originally planned for September, are currently not expected to happen due to lack of code changes since 9.11.35(-S1).
## Release Schedule
**Code Freeze:** Wednesday, Septemb...## Notes
- BIND releases 9.11.36 & 9.11.36-S1, which were originally planned for September, are currently not expected to happen due to lack of code changes since 9.11.35(-S1).
## Release Schedule
**Code Freeze:** Wednesday, September 1st, 2021
**Tagging Deadline:** Monday, September 6th, 2021
**Public Release:** Wednesday, September 15th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.17.18](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
- [9.16.21](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
**Merge requests merged into the milestone without a release note:**
- [9.17.18](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)¬[label_name][]=Release%20Notes&target_branch=main)
- [9.16.21](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)¬[label_name][]=Release%20Notes&target_branch=v9_16)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.17.18](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)&label_name[]=No%20CHANGES&target_branch=main)
- [9.16.21](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)&label_name[]=No%20CHANGES&target_branch=v9_16)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is in effect.
### Before the Tagging Deadline
- [x] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Update API files for libraries with new version information.
- [x] ***(QA)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(QA)*** Update `CHANGES`.
- [x] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update `README.md`.
- [x] ***(QA)*** Update `version`.
- [x] ***(QA)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is over.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription Edition (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public packages (`*.deb`, RPMs).
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Merge the automatically prepared `prep 9.x.y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_x`).
- [x] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Michał KępieńMichał Kępień2021-09-15https://gitlab.isc.org/isc-projects/bind9/-/issues/2889LMDB should flush to disk2021-08-30T21:11:00ZPetr MenšíkLMDB should flush to disk### Description
When LMDB support adds new zone, no change occurs immediately in its view_name.nzd file. Unlike plain file view_name.nzf, changes are not stored immediately to permanent storage. I admit it would have much better perform...### Description
When LMDB support adds new zone, no change occurs immediately in its view_name.nzd file. Unlike plain file view_name.nzf, changes are not stored immediately to permanent storage. I admit it would have much better performance, but I think save to disk should be possible without restarting named.
### Request
named should allow automatic flushing to disk on some events. Be it periodic timer maintenance after some time or manual rndc call, for example during sync without zone name or for zone added via rndc addzone, ``mdb_env_sync`` should be called sometime. It is never used in current implementation, on any event. I think data safety is important too, not only performance.
It is especially problematic on distributions, because LMDB support cannot be disabled once its support is built-in. NZF files were much slower, but were more safe.
### Links / references
- https://bugzilla.redhat.com/show_bug.cgi?id=1975775
- http://www.lmdb.tech/doc/group__mdb.html#ga85e61f05aa68b520cc6c3b981dba5037https://gitlab.isc.org/isc-projects/bind9/-/issues/2887respdiff is really slow on Bullseyes2021-11-02T15:59:53ZMichal Nowakrespdiff is really slow on Bullseyes[respdiff on Bullseyes](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1945178) takes 91 minutes and identifies 1.5 % query disagreements (80 % of that are timeouts). On Buster the [test](https://gitlab.isc.org/isc-projects/bind9/-/job...[respdiff on Bullseyes](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1945178) takes 91 minutes and identifies 1.5 % query disagreements (80 % of that are timeouts). On Buster the [test](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1946373) takes 27 minutes and identifies just 0.34 % query disagreements (8 % of that are timeouts).
Locally I am able to identify something similar but instead of timeouts I get 15 % of SERVFAILs from the 100,000 query set. I can make it more stable by setting `jobs = 2` instead of the default `jobs = 16` in `respdiff.cfg`. When running `dig` manually for known working query, I get SERVFAIL in 99 % of attempts as if the query was over some limit. I don't know what might be the difference between Buster and Bullseye (I checked `./configure` and `sysctl` and there are not significant differences). Though, it might an unrelated problem on my system.
This needs to be fixed for the base image being switched to Bullseye.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2884Sometimes dig aborts on an AXFR query over TLS2021-11-04T13:43:09ZCesar KuroiwaSometimes dig aborts on an AXFR query over TLS<!--
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
Sometimes (not always) `dig` crashes with a core dump on a AXFR query over TLS
### BIND version used
DiG 9.17.17
### Steps to reproduce
Using dig to make successive AXFR requests over TLS, using a HMAC-SHA256 TSIG key
```
% dig @<server> -p 853 +tls bom axfr -y hmac-sha256:<tsig-key>:<secret>
```
### Relevant logs and/or screenshots
```
bom. 172800 IN SOA a.dns.br. hostmaster.registro.br. 2021238532 1800 900 604800 900
bom. 21600 IN DNSKEY 256 3 13 fBrEkmLy0X3ANfdXKdkj8fNPAUbwhpC5VvlBaQMzi+8h63iePUcM/dcT aJVVpWgas+HgkKlA3wCTAAFuJJ1uCA==
bom. 21600 IN DNSKEY 257 3 13 jBWA/GVSitmW8erjfZc6plKFXq2j8OOR5FR+3qgAz8nM8yW4+8egKfNO fV1ynbGKAzOzyiC3xuGm7x3RfPXmNg==
bom. 172800 IN NSEC3PARAM 1 0 10 D5193D4EFD6031FF646F
tsig-gtlds. 0 ANY TSIG hmac-sha256. 1630015887 300 32 xcJBeqP007hmCBgx9MXXGbN1m6MieWJJUJzQOGhPhrE= 9519 NOERROR 0
nic.bom. 3600 IN NS ns.dns.br.
nic.bom. 3600 IN NS ns2.dns.br.
nic.bom. 3600 IN DS 40126 13 2 2B666C945F28C2ADA55279798382CC1BCA19DED7A32E3E0B1680FE84 4B1C154F
nic.bom. 3600 IN RRSIG DS 13 2 3600 20210903143501 20210819133501 16861 bom. az4R7y6/rjAQia9lTlcjcISj182zosM35mIlSlub108MrMXVbOZUsrzZ 3rHNKGch4j23G0ljP8ELgo5+L3AGNw==
bom. 172800 IN NS a.dns.br.
bom. 172800 IN NS b.dns.br.
bom. 172800 IN NS c.dns.br.
bom. 172800 IN NS d.dns.br.
bom. 172800 IN NS e.dns.br.
bom. 172800 IN NS f.dns.br.
bom. 21600 IN RRSIG DNSKEY 13 1 21600 20210915000000 20210611000000 14600 bom. a8Tag5dWGGgKNF0nbZfIO+ODDnaDstPjrE7BG7rRojU+KUw8uewTN/Yd 5PrgjC4wUBVbaDTNkG0evhO9dGmVXA==
bom. 172800 IN RRSIG SOA 13 1 172800 20210910221001 20210826211001 16861 bom. 23yXB1pgr7N+SdI1MtDKELA7Vrjt7/rWT1wx5AXPbNXNBFiEPBRE30Fo vJE4fBT0l5ZLbffEfJKm65XmBGBtjw==
bom. 172800 IN RRSIG NSEC3PARAM 13 1 172800 20210910221001 20210826211001 16861 bom. LzCugkc0fnBsssqz7zkj/gasbnjKy5zkSWRrfgFI2c5HW6KpQ2ImXfSG xFtJgaVWl5+QjDWNzaMVublFHe/A5A==
bom. 172800 IN RRSIG NS 13 1 172800 20210910221001 20210826211001 16861 bom. kMcSAe8somkybKerjoCV8WG0WfnUXLAO88b0sutOrAVFJR1X4655hw9R CQZKqsC3RpqnDPcbN2QSVT91wcU5jg==
6mom8bvsn8og38k5j20nubclk3l258vi.bom. 900 IN RRSIG NSEC3 13 2 900 20210903143501 20210819133501 16861 bom. zSfR9WRP+xHbBflvdOpTQDleukg+sTaTB62FvPNC15pxroPkRdTlIOLW jg54yxwye+bBcnHH+HWRtzF0QbfxOA==
6mom8bvsn8og38k5j20nubclk3l258vi.bom. 900 IN NSEC3 1 1 10 D5193D4EFD6031FF646F SD3KLP44SLP2IB3IRND61I31V6ROG2PE NS DS RRSIG
sd3klp44slp2ib3irnd61i31v6rog2pe.bom. 900 IN RRSIG NSEC3 13 2 900 20210910221001 20210826211001 16861 bom. NL2n5iahzZF59faktxT+x22UA8548NwIoDZc/WHub8wdQ02F134kq0Uo 8NbEzvKJdB0/FQNWf222+l5HWYJzOw==
sd3klp44slp2ib3irnd61i31v6rog2pe.bom. 900 IN NSEC3 1 1 10 D5193D4EFD6031FF646F 6MOM8BVSN8OG38K5J20NUBCLK3L258VI NS SOA RRSIG DNSKEY NSEC3PARAM
bom. 172800 IN SOA a.dns.br. hostmaster.registro.br. 2021238532 1800 900 604800 900
tsig-gtlds. 0 ANY TSIG hmac-sha256. 1630015887 300 32 Y1j1OjfZqqmzPHeTvNvVrEIfiK4UbMLiWntNw/Vo5A4= 9519 NOERROR 0
;; Query time: 1 msec
;; WHEN: Thu Aug 26 19:11:27 -03 2021
;; XFR size: 23 records (messages 2, bytes 1777)
netmgr/netmgr.c:1703: REQUIRE(((__builtin_expect(!!((handle) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H') << 8 | ('D')))), 1)) && __c11_atomic_load(&(handle)->references, memory_order_seq_cst) > 0)) failed, back trace
0x8002ba7a0 <isc_assertion_setcallback+0x50> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002ba74a <isc_assertion_failed+0xa> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002aae6b <isc__nm_get_read_req+0x11b> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002b5295 <isc__nm_tlsdns_processbuffer+0x95> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002ab338 <isc__nm_process_sock_buffer+0x48> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002b4926 <isc__nm_async_tlsdnsshutdown+0x366> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002b5565 <isc__nm_tlsdns_read_cb+0xb5> at /home/cesar/named/lib/libisc-9.17.17.so
0x8007c5590 <uv__stream_init+0x500> at /usr/local/lib/libuv.so.1
0x8007cc12b <uv__io_poll+0x82b> at /usr/local/lib/libuv.so.1
0x8007bb551 <uv_run+0x1b1> at /usr/local/lib/libuv.so.1
0x8002a4deb <isc__netmgr_create+0x71b> at /home/cesar/named/lib/libisc-9.17.17.so
0x8002e9914 <isc__trampoline_run+0x54> at /home/cesar/named/lib/libisc-9.17.17.so
Abort (core dumped)
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2881bind 9 can not balance load with mode order cyclic2021-08-26T07:07:39Zqimangebind 9 can not balance load with mode order cyclicI configured bind as dns server on **centos 8** and create a zone file named test.com.zone,the contents as follow:
```
$TTL 1D
@ IN SOA test.com. root.test.com. (
2020072603 ; serial
...I configured bind as dns server on **centos 8** and create a zone file named test.com.zone,the contents as follow:
```
$TTL 1D
@ IN SOA test.com. root.test.com. (
2020072603 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
@ IN NS master.test.com.
@ IN NS slave.test.com.
slave IN A 100.100.5.21
master IN A 100.100.5.22
www IN A 101.101.5.21
www IN A 101.101.5.22
www IN A 101.101.5.23
www IN A 101.101.5.24
www IN A 101.101.5.25
www IN A 101.101.10.245
www IN A 101.101.10.246
www IN A 101.101.10.247
www IN A 101.101.10.248
www IN A 101.101.10.249
```
the Subnet Mask of ip in resource records above is all 16 bits,when i ping www.test.com from client for 10 times,the ip it allocates is 101.101.5.21 for 6 times and 101.101.5.22~25,it can not allocate the ip of 101.101.10.x,is it any limit for the ip in resource records?
and then I modified the resource records in zone file as follow:
```
www IN A 101.101.5.21
www IN A 101.101.5.22
www IN A 101.101.5.23
www IN A 101.101.5.24
www IN A 101.101.5.25
www IN A 101.101.5.26
www IN A 101.101.5.27
www IN A 101.101.5.28
www IN A 101.101.5.29
www IN A 101.101.5.30
```
and I also ping www.test.com from client for 10 times,when the clients' operarte system is centos 8,it can Poll all the ip(101.101.5.21~30) correctly,but when the clients' operarte system is centos 7,the ip it allocates is 101.101.5.21 for 5 times and 101.101.5.22~26,why does it happen?