BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2020-12-01T12:31:46Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2315BIND 9.11.22 - 9.11.25 fails to build for AEP HSM native pkcs112020-12-01T12:31:46ZCathy AlmondBIND 9.11.22 - 9.11.25 fails to build for AEP HSM native pkcs11[Support ticket #17347](https://support.isc.org/Ticket/Display.html?id=17347)
./configure --enable-threads --enable-native-pkcs11 --with-ecdsa -with-pkcs11=/opt/Keyper/PKCS11Provider/pkcs11.so
I think it's the --enable-native-pkcs11 AN...[Support ticket #17347](https://support.isc.org/Ticket/Display.html?id=17347)
./configure --enable-threads --enable-native-pkcs11 --with-ecdsa -with-pkcs11=/opt/Keyper/PKCS11Provider/pkcs11.so
I think it's the --enable-native-pkcs11 AND using the AEP Keyper flavour of native pkcs11 that is setting the switch so that we fail the build
The build fail is this:
```
pkcs11rsa_link.c: In function 'pkcs11rsa_verify':
pkcs11rsa_link.c:1081:4: error: a label can only be part of a statement and a declaration is not a statement
```
This is in the flavour of pkcs11rsa_verify() that is inside the else section of #ifndef PK11_RSA_PKCS_REPLACE
By my reading of /lib/isc/include/pk11/site.h, we're defining PK11_RSA_PKCS_REPLACE if we're working with an AEP pkcs11 set of libs (but not apparently for anything else).
Here's the offending bit of code in `/lib/dns/pkcs11rsa_link.c` (the define for 'bits' was added by issue #2037 )
```
case CKA_PUBLIC_EXPONENT:
unsigned int bits;
INSIST(keyTemplate[6].type == attr->type);
```
From what I'm reading about this compiler error, the problem is that the C language standard says that labels can only be followed by statements. What we've got here is a declarations - and that's not perceived as a statement in C.
Apparently, the workaround is to add an empty statement - it's been suggested that comment after the label will do the trick (though I am not in a position to verify that) - but if yes, then this should work:
```
case CKA_PUBLIC_EXPONENT: /* Empty statement to make compiler happy */
unsigned int bits;
INSIST(keyTemplate[6].type == attr->type);
```
Please can someone look at this soonest!December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2275Tighten DNS COOKIE response handling2020-12-01T08:45:30ZMark AndrewsTighten DNS COOKIE response handlingFallback to TCP when we have already seen a DNS COOKIE response from the given address and don't have one in this UDP response. This could be a server that has turned off DNS COOKIE support, a misconfigured anycast server with partial D...Fallback to TCP when we have already seen a DNS COOKIE response from the given address and don't have one in this UDP response. This could be a server that has turned off DNS COOKIE support, a misconfigured anycast server with partial DNS COOKIE support, or a spoofed response. Falling back to TCP is the correct behaviour in all 3 cases.
Future work, once the percentage of DNS COOKIE aware servers increases enough, will be to fallback to TCP on all UDP responses w/o DNS COOKIE options.December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2224Fixup core back traces.2020-12-01T08:43:37ZMark AndrewsFixup core back traces.The back traces fail to identify which core they are from.
The back traces can be over written by another backtrace for the same executable.
Binary not correctly identified (subject of another MR).The back traces fail to identify which core they are from.
The back traces can be over written by another backtrace for the same executable.
Binary not correctly identified (subject of another MR).December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2280Check DNAME handling when QTYPE is CNAME/ANY2020-12-01T08:25:17ZMark AndrewsCheck DNAME handling when QTYPE is CNAME/ANYThe CNAME should be generated but not followed.The CNAME should be generated but not followed.December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2284DNAME: synthetized CNAME might be perfect answer to CNAME query2020-12-01T08:08:22ZSiva Kesava R KakarlaDNAME: synthetized CNAME might be perfect answer to CNAME query### Summary
When there is a `DNAME` record in the zone file (partial rewrite to the same zone), and that record handles the query, then the `RCODE` of the server should probably be different depending on whether the query is for `CNAME`...### Summary
When there is a `DNAME` record in the zone file (partial rewrite to the same zone), and that record handles the query, then the `RCODE` of the server should probably be different depending on whether the query is for `CNAME` or not. After the `DNAME` rewrite, the new query name belongs to the same zone but doesn't exist. The server currently returns `NXDOMAIN` for all the types, but it might be reasonable to return `NOERROR` for the `CNAME` type.
### BIND version used
BIND 9.11.3-1ubuntu1.13-Ubuntu (Extended Support Version) <id:a375815>
### Steps to reproduce
Consider the following sample zone file:
| | | |
|--------------------|-----------|----------------------------------------------------------|
| campus.edu. | 500 SOA | ns1.campus.edu. root.campus.edu. 3 86400 7200 604800 300 |
| campus.edu. | 500 NS | ns1.outside.edu. |
| c.d.campus.edu. | 500 DNAME | f.d.campus.edu. |
For the query `<a.c.d.campus.edu., CNAME>` the answer from the BIND server is:
```
"opcode QUERY",
"rcode NXDOMAIN",
"flags QR AA",
";QUESTION",
"a.c.d.campus.edu. IN CNAME",
";ANSWER",
"a.c.d.campus.edu. 500 IN CNAME a.f.d.campus.edu.",
"c.d.campus.edu. 500 IN DNAME f.d.campus.edu.",
";AUTHORITY",
";ADDITIONAL"
```
### What is the current *bug* behavior?
The `RCODE` is `NXDOMAIN.`
### What is the expected *correct* behavior?
The answer section would be the same for the above query, but the `RCODE` should likely be `NOERROR.` PowerDNS was doing it that way, but BIND, NSD, and Knot were returning `NXDOMAIN` for all types so I thought it might be an issue with PowerDNS. I have filed a [GitHub issue](https://github.com/PowerDNS/pdns/issues/9725) with PowerDNS, and they said it's intentional and they are doing it correctly. A patch was sent to [Knot server](https://gitlab.nic.cz/knot/knot-dns/-/merge_requests/1217) also to return `NOERROR` for the `CNAME` type.December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2316Is there something not right with the man pages in 9.11.25?2020-11-30T07:26:00ZCathy AlmondIs there something not right with the man pages in 9.11.25?As reported to [Support](https://support.isc.org/Ticket/Display.html?id=17348) :
```
I have heard two reports that man pages in the 9.11.25 release are
messed up.
The following link is a screenshot from a Slackware user:
https://i.im...As reported to [Support](https://support.isc.org/Ticket/Display.html?id=17348) :
```
I have heard two reports that man pages in the 9.11.25 release are
messed up.
The following link is a screenshot from a Slackware user:
https://i.imgur.com/CGmT1Na.png
I heard a similar report from https://github.com/pemensik in Red Hat.
```
Aside, I have just now realised (and this isn't new to 9.11.25) that the .html versions of the ARM don't include the man pages - if you look at /doc/arm/Bv9ARM.ch09.html, what you get is Appendix A, not chapter 9 (the man pages). In fact they're all named similarly and progress through the appendices this way with prev/next too - not sure how you get to the man pages from the index then? (Personally, I look at the .pdf version).
I installed 9.11.25 myself and confirmed this - looks like there's an issue with the on-board man pages as installed. Here's what I'm seeing:
```
NAMED(8) BIND9 NAMED(8)
.SH "NAME" named - Internet domain name server
.SH "SYNOPSIS"
.HP 144u
named
[ | [-4] | [-6]
]
[-c config-file]
[-d debug-level]
[-D string]
[-E engine-name]
[-f]
[-g]
[-L logfile]
[-M option]
[-m flag]
[-n #cpus]
[-p port]
[-s]
[-S #max-socks]
[-t directory]
[-U #listeners]
:
```
As opposed to with 9.11.24:
```
$ man named
NAMED(8) BIND9 NAMED(8)
NAME
named - Internet domain name server
SYNOPSIS
named [[-4] | [-6]] [-c config-file] [-d debug-level] [-D string]
[-E engine-name] [-f] [-g] [-L logfile] [-M option] [-m flag]
[-n #cpus] [-p port] [-s] [-S #max-socks] [-t directory]
[-U #listeners] [-u user] [-v] [-V] [-X lock-file]
[-x cache-file]
DESCRIPTION
named is a Domain Name System (DNS) server, part of the BIND 9
distribution from ISC. For more information on the DNS, see RFCs 1033,
1034, and 1035.
When invoked without arguments, named will read the default
configuration file /etc/named.conf, read any initial data, and listen
for queries.
OPTIONS
-4
```December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2037[CVE-2020-8623] A flaw in native PKCS#11 code can lead to a remotely triggera...2020-11-27T20:05:53ZOndřej Surý[CVE-2020-8623] A flaw in native PKCS#11 code can lead to a remotely triggerable assertion failure in pk11.c> Came from ...@yandex.ru:
>
> BIND should be compiled with --enable-native-pkcs11 and --with-pkcs11 options.
>
> The exploit triggers abort() in pk11_numbits function.
>
> Bug details:
> from lib/isc/pk11.c
>
> ```c
> unsigned int
>...> Came from ...@yandex.ru:
>
> BIND should be compiled with --enable-native-pkcs11 and --with-pkcs11 options.
>
> The exploit triggers abort() in pk11_numbits function.
>
> Bug details:
> from lib/isc/pk11.c
>
> ```c
> unsigned int
> pk11_numbits(CK_BYTE_PTR data, unsigned int bytecnt) {
> unsigned int bitcnt, i;
> CK_BYTE top;
>
> if (bytecnt == 0) {
> return (0);
> }
> bitcnt = bytecnt * 8;
> for (i = 0; i < bytecnt; i++) {
> top = data[i];
> if (top == 0) {
> bitcnt -= 8;
> continue;
> }
> ...
> }
> INSIST(0);
> ISC_UNREACHABLE();
> }
> ```
> Which means that if all bytes are 0, abort will be triggered.
>
> How to reproduce:
> 1) configure and build softhsm 2.6.1:
> ```
> $ ./configure --prefix=/var/softhsm --with-openssl=/var/openssl --with-crypto-backend=openssl
> $ make && sudo make install
> ```
>
> 2) compile BIND with PKCS11 support
> ```
> $ ./configure --prefix=/opt/bind --disable-chroot --enable-native-pkcs11 --with-pkcs11=/var/softhsm/lib/softhsm/libsofthsm2.so
> $ make && sudo make install
> ```
>
> 3) Configure BIND
> ```
> # init softhsm (PIN 1234)
> # /var/softhsm/bin//softhsm2-util --init-token --free --label softhsm
> Slot 1 has a free/uninitialized token.
> === SO PIN (4-255 characters) ===
> Please enter SO PIN: ****
> Please reenter SO PIN: ****
> === User PIN (4-255 characters) ===
> Please enter user PIN: ****
> Please reenter user PIN: ****
> The token has been initialized and is reassigned to slot 1294545520
>
> # export SLOT=1294545520
>
> # cd bin/tests/system/pkcs11
> ```
>
> Edit ns1/example.db.in and ns1/named.conf.in, change IP from 10.53.0.1 to your server IP
> After that run included setports.sh:
> ```
> # bash setports.sh
> ```
>
> Now you can generate the keys:
> ```
> # bash setup.sh
> ```
>
> ```
> # cp ns1/* /opt/bind/etc
> ```
>
> Fix permissions:
> ```
> # chown -R bind:bind /opt/bind/var/run
> ```
>
> Edit `/opt/bind/etc/named.conf` and change all paths to `*.example.db.signed` to full path, should be like this:
> ```
> zone "ecdsap384sha384.example." {
> type master;
> file "/opt/bind/etc/ecdsap384sha384.example.db.signed";
> allow-update { any; };
> };
> ```
>
>
> 4) Run BIND
> ```
> # cd /opt/bind/var/run
> # /opt/bind/sbin/named -g -d0 -u bind -c /opt/bind/etc/named.conf
> ```
>
> 5) run t1.py
> ```
> $ ./t1.py <your_server_ip> 53
> ```
>
> Example bind log:
>
> ```
> 25-Jun-2020 01:23:14.297 pk11.c:698: INSIST(0) failed, back trace
> 25-Jun-2020 01:23:14.297 #0 0x5583e7797e9b in __do_global_dtors_aux_fini_array_entry()+0x5583e6971623
> 25-Jun-2020 01:23:14.297 #1 0x5583e705686d in __do_global_dtors_aux_fini_array_entry()+0x5583e622fff5
> 25-Jun-2020 01:23:14.301 #2 0x5583e779783d in __do_global_dtors_aux_fini_array_entry()+0x5583e6970fc5
> 25-Jun-2020 01:23:14.301 #3 0x5583e77909d1 in __do_global_dtors_aux_fini_array_entry()+0x5583e696a159
> 25-Jun-2020 01:23:14.301 #4 0x5583e76de425 in __do_global_dtors_aux_fini_array_entry()+0x5583e68b7bad
> 25-Jun-2020 01:23:14.301 #5 0x5583e76c2080 in __do_global_dtors_aux_fini_array_entry()+0x5583e689b808
> 25-Jun-2020 01:23:14.301 #6 0x5583e76b4686 in __do_global_dtors_aux_fini_array_entry()+0x5583e688de0e
> 25-Jun-2020 01:23:14.305 #7 0x5583e734667e in __do_global_dtors_aux_fini_array_entry()+0x5583e651fe06
> 25-Jun-2020 01:23:14.305 #8 0x5583e7193db9 in __do_global_dtors_aux_fini_array_entry()+0x5583e636d541
> 25-Jun-2020 01:23:14.305 #9 0x5583e71a2181 in __do_global_dtors_aux_fini_array_entry()+0x5583e637b909
> 25-Jun-2020 01:23:14.305 #10 0x5583e7826f71 in __do_global_dtors_aux_fini_array_entry()+0x5583e6a006f9
> 25-Jun-2020 01:23:14.305 #11 0x5583e782800c in __do_global_dtors_aux_fini_array_entry()+0x5583e6a01794
> 25-Jun-2020 01:23:14.305 #12 0x7fd791aba6db in __do_global_dtors_aux_fini_array_entry()+0x7fd790c93e63
> 25-Jun-2020 01:23:14.305 #13 0x7fd7913d988f in __do_global_dtors_aux_fini_array_entry()+0x7fd7905b3017
> 25-Jun-2020 01:23:14.309 exiting (due to assertion failure)
> Aborted (core dumped)
> ```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1730Clean up no-op AC_SUBST calls2020-11-27T12:21:54ZMichał KępieńClean up no-op AC_SUBST callsThe following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_121372): (+1 comment)
> It seems that we can drop:
>
> - `...The following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_121372): (+1 comment)
> It seems that we can drop:
>
> - `STD_CDEFINES`
> - `STD_CINCLUDES`
> - `STD_CWARNINGS`
>
> That would require updating `OPTIONS`. There are also lots of other
> `AC_SUBST` calls for unused macros, so maybe let's tackle this in a
> separate issue?December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2276Update to CentOS 7.92020-11-27T09:55:52ZMichal NowakUpdate to CentOS 7.9CentOS 7.9 is [out](https://wiki.centos.org/action/show/Manuals/ReleaseNotes/CentOS7.2009), we should update.CentOS 7.9 is [out](https://wiki.centos.org/action/show/Manuals/ReleaseNotes/CentOS7.2009), we should update.December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2306Compilation broken on systems without <sys/un.h>2020-11-26T15:52:36ZMichal NowakCompilation broken on systems without <sys/un.h>Looking into https://gitlab.isc.org/isc-projects/bind9/-/issues/1770 I noticed that on systems without `<sys/un.h>` (`ISC_PLATFORM_HAVESYSUNH` undefined), the compilation fails with:
```
ssu_external.c: In function ‘ux_socket_connect’:
s...Looking into https://gitlab.isc.org/isc-projects/bind9/-/issues/1770 I noticed that on systems without `<sys/un.h>` (`ISC_PLATFORM_HAVESYSUNH` undefined), the compilation fails with:
```
ssu_external.c: In function ‘ux_socket_connect’:
ssu_external.c:59:31: warning: unused parameter ‘path’ [-Wunused-parameter]
59 | ux_socket_connect(const char *path) {
| ~~~~~~~~~~~~^~~~
getaddrinfo.c: In function ‘get_local’:
getaddrinfo.c:1243:32: error: invalid application of ‘sizeof’ to incomplete type ‘struct sockaddr_un’
1243 | ai = ai_alloc(AF_LOCAL, sizeof(*slocal));
| ^
getaddrinfo.c:1249:16: error: invalid use of undefined type ‘struct sockaddr_un’
1249 | strlcpy(slocal->sun_path, name, sizeof(slocal->sun_path));
| ^~
getaddrinfo.c:1249:47: error: invalid use of undefined type ‘struct sockaddr_un’
1249 | strlcpy(slocal->sun_path, name, sizeof(slocal->sun_path));
| ^~
```
I don't know what operating systems might be affected, probably none (even Solaris 10 has it), one can "emulate" it like this and rebuild with `autoreconf -fi`:
```patch
--- a/configure.ac
+++ b/configure.ac
@@ -1799,9 +1799,9 @@ AS_IF([test "$enable_linux_caps" = "yes"],
AC_SUBST([LIBCAP_LIBS])
AC_CHECK_HEADERS(sys/un.h,
-ISC_PLATFORM_HAVESYSUNH="#define ISC_PLATFORM_HAVESYSUNH 1"
-,
ISC_PLATFORM_HAVESYSUNH="#undef ISC_PLATFORM_HAVESYSUNH"
+,
+ISC_PLATFORM_HAVESYSUNH="#define ISC_PLATFORM_HAVESYSUNH 1"
)
AC_SUBST(ISC_PLATFORM_HAVESYSUNH)
```
I tried for a short while and followed the compiler in fixing warnings and disabling code with `#ifdef ISC_PLATFORM_HAVESYSUNH` but I end up with either failing `tsiggss` system test or crashing `named`.December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2309dig core dump on SIGINT2020-11-26T09:30:10ZPeter Daviesdig core dump on SIGINT
### Summary
dig core dumps when killed
### BIND version used
DiG 9.17.7
### Steps to reproduce
dig to a name server that does not reply in a timely fashion and kill the process with the Ctl/C.
```
root@haparanda:/home/named/log# d...
### Summary
dig core dumps when killed
### BIND version used
DiG 9.17.7
### Steps to reproduce
dig to a name server that does not reply in a timely fashion and kill the process with the Ctl/C.
```
root@haparanda:/home/named/log# dig @173.37.137.80 .
^Cdighost.c:4262: REQUIRE(isc_refcount_current(&recvcount) == 0) failed, back trace
/usr/local/lib/libisc.so.1706(+0x3d3e9) [0x7f67f2fca3e9]
/usr/local/lib/libisc.so.1706(isc_assertion_failed+0x10) [0x7f67f2fca320]
dig(+0x1728a) [0x56374da2028a]
dig(+0xc5fd) [0x56374da155fd]
dig(+0x6bb0) [0x56374da0fbb0]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f67f2afc1e3]
dig(+0x6bee) [0x56374da0fbee]
Aborted (core dumped)
```
### What is the current *bug* behavior?
Core dumps
### What is the expected *correct* behavior?
silent exit
### Relevant configuration files
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`.)
### Relevant logs and/or screenshots
(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
(If you can, link to the line of code that might be responsible for the
problem.)December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2296Dns RRs size bigger than 64k , but bind is allowed only 64k , because of that...2020-11-20T10:20:02Zvenkappa eDns RRs size bigger than 64k , but bind is allowed only 64k , because of that lossing some RRs in the DNs responseMy DNS db file have 2048 answer RRs and 2048 Additional RRs, but DNS response includes only 475 Answers, that means not sending all the RRs and noticed ISC_R_NOSPACE ISSUE on bind side, I hope this is because of TCP_BUFFER_SIZE limit ...My DNS db file have 2048 answer RRs and 2048 Additional RRs, but DNS response includes only 475 Answers, that means not sending all the RRs and noticed ISC_R_NOSPACE ISSUE on bind side, I hope this is because of TCP_BUFFER_SIZE limit is 65535, so how to send all the RRs if more than 64k.https://gitlab.isc.org/isc-projects/bind9/-/issues/2294./server.c:3881: unexpected error: when issuing rndc reload or reconfig2020-11-19T14:51:45ZKarl Wieman./server.c:3881: unexpected error: when issuing rndc reload or reconfig<!--
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
When issuing an rndc reload or reconfig command to two of my BIND instances, I receive this error: "rndc: 'reload' failed: unexpected error" The syslog logs show this: "Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.038 general: error: ./server.c:3881: unexpected error:"
### BIND version used
cozbdns001# /opt/named/sbin/named -V
BIND 9.11.23 (Extended Support Version) <id:4f70056>
running on Linux x86_64 3.10.0-1160.2.1.el7.x86_64 #1 SMP Mon Sep 21 21:00:09 EDT 2020
built by make with '--prefix=/opt/bind-9.11.23'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /opt/bind-9.11.23/etc/named.conf
rndc configuration: /opt/bind-9.11.23/etc/rndc.conf
DNSSEC root key: /opt/bind-9.11.23/etc/bind.keys
nsupdate session key: /opt/bind-9.11.23/var/run/named/session.key
named PID file: /opt/bind-9.11.23/var/run/named/named.pid
named lock file: /opt/bind-9.11.23/var/run/named/named.lock
### Steps to reproduce
Any rndc reload or reconfig after a successful start up causes the issue. I copied the full BIND deployment and configuration to a lab server and the issue does not occur.
### What is the current *bug* behavior?
The server does not appear to actually reload its configuration. A full restart is required.
### What is the expected *correct* behavior?
rndc reconfig and reload should succeed. Also, "Unexpected error" is a useless message that does not help identify the cause of the issue.
### 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`.)
### Relevant logs and/or screenshots
'
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.603 general: info: received control channel command 'reload'
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.603 general: info: loading configuration from '/etc/named.conf'
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.610 general: info: reading built-in trust anchors from file '/opt/bind-9.11.23/etc/bind.keys'
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.611 general: info: using default UDP/IPv4 port range: [1024, 65535]
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.611 general: info: using default UDP/IPv6 port range: [1024, 65535]
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.611 network: info: no IPv6 interfaces found
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.616 general: info: sizing zone task pool based on 462 zones
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.617 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.624 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.631 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.638 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.645 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.652 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.659 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.666 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.674 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.681 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.688 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.695 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.703 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.710 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.717 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.725 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.732 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.739 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.747 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.754 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.761 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.768 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.775 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.783 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.790 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.797 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.804 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.812 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.819 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.826 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.834 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.841 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.848 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.855 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.863 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.870 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.877 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.884 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.892 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.899 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.907 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.914 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.921 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.929 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.936 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.943 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.950 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.958 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.965 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.972 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.980 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.987 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:06 cozbdns001 named[18342]: 18-Nov-2020 16:48:06.994 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.002 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.009 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.016 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.024 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.031 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.038 config: info: none:100: 'max-cache-size 90%' - setting to 175921860444MB (out of 17592186044415MB)
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.038 general: error: ./server.c:3881: unexpected error:
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.038 general: error: unable to obtain neither an IPv4 nor an IPv6 dispatch
Nov 18 16:48:07 cozbdns001 named[18342]: 18-Nov-2020 16:48:07.042 general: error: reloading configuration failed: unexpected error
'
Note: Ommitted many "general: info: automatic empty zone: view <DOMAIN>: XXX" messages.
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/22929.16.8 can't create PID file at Centos72020-11-19T09:03:05ZDen Ivanov9.16.8 can't create PID file at Centos7<!--
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
BIND could not open '/var/opt/isc/isc-bind/run/named/named.pid' and systemd service terminates after start
### BIND version used
```
BIND 9.16.8 (Stable Release) <id:539f9f0>
running on Linux x86_64 3.10.0-1160.6.1.el7.x86_64 #1 SMP Tue Nov 17 13:59:11 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr' '--exec-prefix=/opt/isc/isc-bind/root/usr' '--bindir=/opt/isc/isc-bind/root/usr/bin' '--sbindir=/opt/isc/isc-bind/root/usr/sbin' '--sysconfdir=/etc/opt/isc/isc-bind' '--datadir=/opt/isc/isc-bind/root/usr/share' '--includedir=/opt/isc/isc-bind/root/usr/include' '--libdir=/opt/isc/isc-bind/root/usr/lib64' '--libexecdir=/opt/isc/isc-bind/root/usr/libexec' '--localstatedir=/var/opt/isc/isc-bind' '--sharedstatedir=/var/opt/isc/isc-bind/lib' '--mandir=/opt/isc/isc-bind/root/usr/share/man' '--infodir=/opt/isc/isc-bind/root/usr/share/info' '--disable-static' '--enable-dnstap' '--with-pic' '--with-gssapi' '--with-json-c' '--with-libtool' '--with-libxml2' '--without-lmdb' '--with-python' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro -L/opt/isc/isc-bind/root/usr/lib64' '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.16.8/sphinx/bin/sphinx-build'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libuv version: 1.38.0
linked to libuv version: 1.38.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.3.3
linked to protobuf-c version: 1.3.1
threads support is enabled
default paths:
named configuration: /etc/opt/isc/isc-bind/named.conf
rndc configuration: /etc/opt/isc/isc-bind/rndc.conf
DNSSEC root key: /etc/opt/isc/isc-bind/bind.keys
nsupdate session key: /var/opt/isc/isc-bind/run/named/session.key
named PID file: /var/opt/isc/isc-bind/run/named/named.pid
named lock file: /var/opt/isc/isc-bind/run/named/named.lock
```
### Steps to reproduce
systemctl start isc-bind-named.service
### What is the current *bug* behavior?
Service terminates
### What is the expected *correct* behavior?
Service must start and run
### Relevant configuration files
Doesn't matter for this case
### Relevant logs and/or screenshots
```
Nov 19 11:59:27 server named[893]: listening on IPv4 interface lo, 127.0.0.1#53
Nov 19 11:59:27 server named[893]: Could not open '/var/opt/isc/isc-bind/run/named/named.pid'.
Nov 19 11:59:27 server named[893]: Please check file and directory permissions or reconfigure the filename.
Nov 19 11:59:27 server named[893]: could not open file '/var/opt/isc/isc-bind/run/named/named.pid': Permission denied
<...skip...>
Nov 19 12:00:57 server systemd[1]: isc-bind-named.service start operation timed out. Terminating.
Nov 19 12:00:57 server named[893]: 19-Nov-2020 12:00:57.102 network: no longer listening on 127.0.0.1#53
Nov 19 12:00:57 server named[893]: 19-Nov-2020 12:00:57.139 general: shutting down
Nov 19 12:00:57 server named[893]: 19-Nov-2020 12:00:57.139 general: stopping command channel on 127.0.0.1#953
Nov 19 12:00:57 server named[893]: 19-Nov-2020 12:00:57.156 general: exiting
Nov 19 12:00:57 server systemd[1]: Failed to start isc-bind-named.service.
Nov 19 12:00:57 server systemd[1]: Unit isc-bind-named.service entered failed state.
Nov 19 12:00:57 server systemd[1]: isc-bind-named.service failed.
```
### Possible fixes
```
semanage fcontext -a -t var_run_t "/var/opt/isc/isc-bind/run"
semanage fcontext -a -t named_var_run_t "/var/opt/isc/isc-bind/run(/.*)"
restorecon -vr /var/opt/isc/isc-bind/run
```Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2291DNAME-DNAME loop generates ~17 length CNAME chain but a DNAME-CNAME loop ter...2020-11-17T23:25:16ZSiva Kesava R KakarlaDNAME-DNAME loop generates ~17 length CNAME chain but a DNAME-CNAME loop terminates early### Summary
When there is a `DNAME-DNAME` loop in the zone file, the BIND server generates 17 CNAMEs, but for a `DNAME-CNAME` chain, the BIND server stops after one iteration. The `DNAME-DNAME` loop behavior is also different from Knot ...### Summary
When there is a `DNAME-DNAME` loop in the zone file, the BIND server generates 17 CNAMEs, but for a `DNAME-CNAME` chain, the BIND server stops after one iteration. The `DNAME-DNAME` loop behavior is also different from Knot and NSD.
### BIND version used
BIND 9.11.3-1ubuntu1.13-Ubuntu (Extended Support Version) <id:a375815>
### Steps to reproduce
Consider the following zone file:
| | | |
|--------------------|-----------|----------------------------------------------------------|
| campus.edu. | 500 SOA | ns1.campus.edu. root.campus.edu. 3 86400 7200 604800 300 |
| campus.edu. | 500 NS | ns1.outside.edu. |
| d.campus.edu. | 500 DNAME | f.d.campus.edu. |
For the query `<a.f.d.campus.edu, A>`, the response returned by BIND was:
```
"opcode QUERY",
"rcode NOERROR",
"flags QR AA RA",
";QUESTION",
"a.f.d.campus.edu. IN A",
";ANSWER",
"d.campus.edu. 500 IN DNAME f.d.campus.edu.",
"a.f.d.campus.edu. 500 IN CNAME a.f.f.d.campus.edu.",
"a.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.d.campus.edu.",
"a.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
"a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu. 500 IN CNAME a.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.f.d.campus.edu.",
```
whereas the response from Knot and NSD was:
```
"opcode QUERY",
"rcode NOERROR",
"flags QR AA",
";QUESTION",
"a.f.d.campus.edu. IN A",
";ANSWER",
"d.campus.edu. 500 IN DNAME f.d.campus.edu.",
"a.f.d.campus.edu. 500 IN CNAME a.f.f.d.campus.edu.",
";AUTHORITY",
";ADDITIONAL"
```
**NSD logs mention -- `DNAME processing stopped due to loop, qname a.f.d.campus.edu.`**
Consider another zone file:
| | | |
|--------------------|-----------|----------------------------------------------------------|
| campus.edu. | 500 SOA | ns1.campus.edu. root.campus.edu. 3 86400 7200 604800 300 |
| campus.edu. | 500 NS | ns1.outside.edu. |
| d.campus.edu. | 500 DNAME | f.campus.edu. |
| e.f.campus.edu. | 500 CNAME | e.d.campus.edu. |
The response from BIND, NSD, and Knot was:
```
"opcode QUERY",
"rcode NOERROR",
"flags QR AA RA",
";QUESTION",
"e.d.campus.edu. IN A",
";ANSWER",
"d.campus.edu. 500 IN DNAME f.campus.edu.",
"e.d.campus.edu. 500 IN CNAME e.f.campus.edu.",
"e.f.campus.edu. 500 IN CNAME e.d.campus.edu.",
";AUTHORITY",
";ADDITIONAL"
```
### What is the current *bug* behavior?
BIND authoritative server goes on for an infinite (17) CNAME synthesis.
### What is the expected *correct* behavior?
In the `DNAME-CNAME` case, it is evident that after the second `CNAME,` the new query is the same as the original one, so the implementations stop. For the `DNAME-DNAME` case, it is harder to say which behavior (BIND or others) is the correct behavior as the zone file is not proper. I expected BIND also to stop after the first iteration in both cases.
(I looked in the repo for this issue and did not find it, so I am filing a new issue and please excuse me if it's a duplicate.)https://gitlab.isc.org/isc-projects/bind9/-/issues/2075Enable the implicit "max-cache-size 90%;" default to be overridden2020-11-13T18:31:42ZMichał KępieńEnable the implicit "max-cache-size 90%;" default to be overridden!3865 caused RBT hash tables to be pre-allocated. This makes `named`
use more memory immediately from startup; how much more memory it uses
depends on the size of memory available on the host as the default value
of `max-cache-size` is ...!3865 caused RBT hash tables to be pre-allocated. This makes `named`
use more memory immediately from startup; how much more memory it uses
depends on the size of memory available on the host as the default value
of `max-cache-size` is `90%` (and the hash table size is derived from
that value).
This is not expected to cause problems on systems which run a single
instance of BIND, but it may trigger memory use issues e.g. on CI hosts,
which run numerous instances of BIND in parallel and each of these
instances assumes it is okay for it to use all of the memory available
on the host. The most prominent display of that problem was addressed
by !3919, but certain issues are still manifesting themselves
intermittently - most notably, the FreeBSD QEMU VMs are often being
killed off, which causes the FreeBSD GitLab CI jobs to appear to be
hung, e.g.:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1082066
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1082411
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1082632
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1082794
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1083286
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1083287
Since `named` instances used in BIND system tests do not really need
large caches, what would address these memory use issues is a way of
overriding the default `max-cache-size 90%;` setting present in
`bin/named/config.c`. Any mechanism implemented for that purpose would
still need to honor explicit `max-cache-size` settings present in
`named.conf`.September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1775Resizing (growing) of cache hash tables causes delays in processing of client...2020-11-13T18:31:42ZCathy AlmondResizing (growing) of cache hash tables causes delays in processing of client queriesFrom [Support ticket #16212](https://support.isc.org/Ticket/Display.html?id=16212)
During investigations of intermittent 'brownouts' - periods in which named seemingly stops actioning client queries for a short period, and then resumes ...From [Support ticket #16212](https://support.isc.org/Ticket/Display.html?id=16212)
During investigations of intermittent 'brownouts' - periods in which named seemingly stops actioning client queries for a short period, and then resumes processing a second or two later (yes, delays of seconds not ms from this) we 'caught' one culprit red-handed in a pstack run that was automatically triggered by an 'alarm' in monitoring inbound and outbound server traffic rates.
The thread in question was holding the cache tree lock, while growing the hash table:
```
Thread 21 (Thread 0x7f54d8b2f700 (LWP 19115)):
#0 0x000000000052bc7b in rehash (rbt=0x7f54b8c04058, newcount=<optimized out>) at rbt.c:2376
#1 0x000000000052da99 in hash_node (name=0x7f53d9562bb0, node=0x7f541cf79538, rbt=0x7f54b8c04058) at rbt.c:2389
#2 dns_rbt_addnode (rbt=0x7f54b8c04058, name=0x7f53d9562bb0, nodep=0x7f54d8b2dd28) at rbt.c:1451
#3 0x00000000005367ef in rbt_addnode_withdata (rbtdb=0x7f54b8c03010, rbt=0x7f54b8c04058, name=<optimized out>, nodep=0x7f54d8b2dd28) at rbtdb.c:2016
#4 0x000000000053ba42 in findnodeintree (rbtdb=0x7f54b8c03010, tree=0x7f54b8c04058, name=0x7f53d9562bb0, create=true, nodep=0x7f54d8b2ed30) at rbtdb.c:3339
#5 0x00000000005babb5 in cache_name (now=1587326409, zerottl=false, name=0x7f53d9562bb0, section=1, query=0x7f54600100d0, fctx=0x7f5449e172d0) at resolver.c:5876
#6 cache_message (now=1587326409, zerottl=false, query=0x7f54600100d0, fctx=0x7f5449e172d0) at resolver.c:6336
#7 resquery_response (task=0x7f5387cbb628, event=<optimized out>) at resolver.c:9166
#8 0x000000000068a8b1 in dispatch (manager=0x7f54dedc7010) at task.c:1157
#9 run (uap=0x7f54dedc7010) at task.c:1331
#10 0x00007f54dd90cdd5 in start_thread () from /lib64/libpthread.so.0
#11 0x00007f54dd635ead in clone () from /lib64/libc.so.6
```
The other cause of similar problems is when growing the ADB tables - that one however is logged, whereas it doesn't look like 'rehash' or anything that calls it owns up (via logging) to what it is doing.
Our immediate quick-fix wish is for a solution to the delays caused by growing hash tables that is along the lines of being able to specify the starting size as named is launched. This needs to be either run-time or configurable in named.conf. (It is *not* helpful to make it build-time only because in many environments there will be a single build that is distributed to many servers whose needs/sizing can vary.)
It would also be really helpful if any hash table growing could be logged - to include what the size is expanding to (this will help admins to tune their servers accordingly).
====
Longer term, I understand that the wish is to replace the current and now fairly ancient hashing solution with something more modern, faster, and in particular, that doesn't need to block access when resizing - I'll leave engineering to open a new and independent ticket for that. For the here and now, we need a quicker fix, not a new development feature that can't be back-ported or easily applied.August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2230legacy system test fails intermittently2020-11-13T11:17:19ZMark Andrewslegacy system test fails intermittentlyJob [#1241880](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1241880) failed for 4f4a728dee3253d628f15e2bd902c88b69d1dd64:
```
I:legacy:checking recursive lookup to edns 512 server fails (16)
7549I:legacy:failed
```
The SOA record b...Job [#1241880](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1241880) failed for 4f4a728dee3253d628f15e2bd902c88b69d1dd64:
```
I:legacy:checking recursive lookup to edns 512 server fails (16)
7549I:legacy:failed
```
The SOA record being queried for is learnt via the AAAA response over TCP due to the UDP response setting tc=1.November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2220Update OS images (Fedora 33, OpenBSD 6.8, FreeBSD 12.2)2020-11-13T11:17:10ZMichal NowakUpdate OS images (Fedora 33, OpenBSD 6.8, FreeBSD 12.2)Update OS images, all are either already out or out in a few weeks.
- [x] OpenBSD 6.8: https://gitlab.isc.org/isc-projects/images/-/merge_requests/81
- [x] Fedora 33: https://gitlab.isc.org/isc-projects/images/-/merge_requests/82
- [x] F...Update OS images, all are either already out or out in a few weeks.
- [x] OpenBSD 6.8: https://gitlab.isc.org/isc-projects/images/-/merge_requests/81
- [x] Fedora 33: https://gitlab.isc.org/isc-projects/images/-/merge_requests/82
- [x] FreeBSD 12.2: https://gitlab.isc.org/isc-projects/images/-/merge_requests/83
- [x] Also there's Ubuntu 20.10 (Groovy Gorilla) a non-LTS release which we don't intend to add to our OS images, but should probably build and test on as a one-off sanity test.November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2253dnssec-signzone dumped core in PKCS11 job2020-11-13T11:16:06ZMichal Nowakdnssec-signzone dumped core in PKCS11 jobOn `v9_11` `dnssec-signzone` dumped core in `dnssec` test of [PKCS11 job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1281693):
```
I:dnssec:Core dump(s) found: dnssec/ns2/core.6516
R:dnssec:FAIL
D:dnssec:backtrace from dnssec/ns2/...On `v9_11` `dnssec-signzone` dumped core in `dnssec` test of [PKCS11 job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1281693):
```
I:dnssec:Core dump(s) found: dnssec/ns2/core.6516
R:dnssec:FAIL
D:dnssec:backtrace from dnssec/ns2/core.6516:
D:dnssec:--------------------------------------------------------------------------------
D:dnssec:Core was generated by `/builds/isc-projects/bind9/bin/dnssec/.libs/dnssec-signzone -P -g -r /builds/is'.
D:dnssec:Program terminated with signal SIGSEGV, Segmentation fault.
D:dnssec:#0 0x00007fa35a5e1eec in ?? () from /usr/lib/softhsm/libsofthsm2.so
D:dnssec:[Current thread is 1 (Thread 0x7fa34e935700 (LWP 6553))]
D:dnssec:#0 0x00007fa35a5e1eec in ?? () from /usr/lib/softhsm/libsofthsm2.so
D:dnssec:#1 0x00007fa35a58936e in ?? () from /usr/lib/softhsm/libsofthsm2.so
D:dnssec:#2 0x00007fa35a56e18f in C_DestroyObject () from /usr/lib/softhsm/libsofthsm2.so
D:dnssec:#3 0x00007fa35d090cfc in pkcs_C_DestroyObject (hSession=24, hObject=49) at pk11_api.c:242
D:dnssec:#4 0x00007fa35d5f5881 in pkcs11rsa_destroyctx (dctx=0x7fa35a82c808) at pkcs11rsa_link.c:500
D:dnssec:#5 0x00007fa35d5fbcaa in dst_context_destroy (dctxp=dctxp@entry=0x7fa34e932a68) at dst_api.c:395
D:dnssec:#6 0x00007fa35d4a8095 in dns_dnssec_sign (name=<optimized out>, set=<optimized out>, key=<optimized out>, inception=<optimized out>, expire=<optimized out>, mctx=0x561d5c0efe70, buffer=0x7fa34e932c50, sigrdata=0x7fa34e933490) at dnssec.c:360
D:dnssec:#7 0x0000561d5bfbe509 in signwithkey (name=0x7fa35a844430, rdataset=0x7fa34e934d60, key=0x7fa35a82d0c8, ttl=3600, add=0x7fa34e934d10, logmsg=0x561d5bfcd6bb "signing with dnskey") at ./dnssec-signzone.c:298
D:dnssec:#8 0x0000561d5bfc46a6 in signset (set=0x7fa34e934d60, name=0x7fa35a844430, node=0x7fa35a827410, add=0x7fa34e934d10, del=0x7fa34e934d30) at ./dnssec-signzone.c:700
D:dnssec:#9 signname (node=0x7fa35a827410, name=0x7fa35a844430) at ./dnssec-signzone.c:1101
D:dnssec:#10 0x0000561d5bfc480a in sign (task=0x7fa35a839268, event=<optimized out>) at ./dnssec-signzone.c:1599
D:dnssec:#11 0x00007fa35d08940d in dispatch (manager=0x7fa35a810eb0) at task.c:1157
D:dnssec:#12 run (uap=0x7fa35a810eb0) at task.c:1331
D:dnssec:#13 0x00007fa35cddefa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
D:dnssec:#14 0x00007fa35cb664cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
D:dnssec:--------------------------------------------------------------------------------
D:dnssec:full backtrace from dnssec/ns2/core.6516 saved in core.6516-backtrace.txt
D:dnssec:core dump dnssec/ns2/core.6516 archived as dnssec/ns2/core.6516.gz
```
[core.6516.gz](/uploads/9660bac0f82322f21c8ebb31b715d1cd/core.6516.gz)
[core.6516-backtrace.txt](/uploads/819a6d5d2ae5ddbaf9e05aca486f76ca/core.6516-backtrace.txt)
[dnssec-signzone](/uploads/5ea5936415a18153b05f5391f0c552a7/dnssec-signzone)November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)