BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-03-03T10:57:44Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2312Lint generated manual pages2021-03-03T10:57:44ZMichal NowakLint generated manual pagesFor man page generation we rely on Sphinx and DocBook (`v9_11`) and although we don't control the manual page output, we may lint them with `mandoc -T lint` and thus try harder in CI to produce legible content.
On `main` and `v9_16` onl...For man page generation we rely on Sphinx and DocBook (`v9_11`) and although we don't control the manual page output, we may lint them with `mandoc -T lint` and thus try harder in CI to produce legible content.
On `main` and `v9_16` only three *types* of warnings and no errors are produced:
```
$ find doc/man/ -not -path '*/_build/*' -name "*.[0-9]" -exec mandoc -Tlint "{}" \;
WARNING: skipping paragraph macro: sp after SH
WARNING: unknown font, skipping request: ft C
WARNING: skipping paragraph macro: sp after SS
```
There are more types of warnings and one type of error on `v9_11`.
We could filter out these and rely on `mandoc -T lint` as a sanity check of generated man pages.
The case of https://gitlab.isc.org/isc-projects/bind9/-/issues/2310 seems to be covered (though probably only by a chance):
```
$ find /tmp/mozilla_newman0/bind-9.11.24 -name '*.[0-9]' -not -path '*/tests/*' -not -path '*/contrib/*' -exec mandoc -Tlint -Werror {} \;
$ find /tmp/mozilla_newman0/bind-9.11.25 -name '*.[0-9]' -not -path '*/tests/*' -not -path '*/contrib/*' -exec mandoc -Tlint -Werror {} \;
mandoc: /tmp/mozilla_newman0/bind-9.11.25/bin/named/named.8:189:2: ERROR: skipping unknown macro: .\}
mandoc: /tmp/mozilla_newman0/bind-9.11.25/bin/named/lwresd.8:194:2: ERROR: skipping unknown macro: .\}
```
The risk here is inherent from the fact that we don't control the generated output and `mandoc` may fail CI job, even-thought the content is legible by `man(1)` program "standards".March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2311Release Checklist for BIND 9.11.26, BIND 9.11.26-S1, BIND 9.16.10, BIND 9.16....2021-01-04T06:08:24ZMichał KępieńRelease Checklist for BIND 9.11.26, BIND 9.11.26-S1, BIND 9.16.10, BIND 9.16.10-S1, BIND 9.17.8## Release Schedule
**Code Freeze:** Wednesday, December 2nd, 2020
**Tagging Deadline:** Monday, December 7th, 2020
**Public Release:** Wednesday, December 16th, 2020
## Documentation Review Links
**Closed issues assigned to the mil...## Release Schedule
**Code Freeze:** Wednesday, December 2nd, 2020
**Tagging Deadline:** Monday, December 7th, 2020
**Public Release:** Wednesday, December 16th, 2020
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.17.8](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
- [9.16.10](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
- [9.11.26](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.11)
**Merge requests merged into the milestone without a release note:**
- [9.17.8](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)¬[label_name][]=Release%20Notes&target_branch=main)
- [9.16.10](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)¬[label_name][]=Release%20Notes&target_branch=v9_16)
- [9.11.26](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)¬[label_name][]=Release%20Notes&target_branch=v9_11)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.17.8](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)&label_name[]=No%20CHANGES&target_branch=main)
- [9.16.10](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)&label_name[]=No%20CHANGES&target_branch=v9_16)
- [9.11.26](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=December%202020%20(9.11.26%2C%209.11.26-S1%2C%209.16.10%2C%209.16.10-S1%2C%209.17.8)&label_name[]=No%20CHANGES&target_branch=v9_11)
## 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.
### 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)*** 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.
- [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 all confidential issues assigned to the release milestone and make them public.
- [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.December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Michał KępieńMichał Kępień2020-12-16https://gitlab.isc.org/isc-projects/bind9/-/issues/2310BIND 9.11.25 has wrong formatted man pages2021-03-03T10:57:44ZPetr MenšíkBIND 9.11.25 has wrong formatted man pages### Summary
Manual pages from BIND 9.11.25 tarball are not well formatted
### BIND version used
BIND 9.11.25 source archive. No tag v9_11_25 is published on gitlab, could not compare exact commit.
man-db-2.9.0-3.fc32.x86_64
### Steps...### Summary
Manual pages from BIND 9.11.25 tarball are not well formatted
### BIND version used
BIND 9.11.25 source archive. No tag v9_11_25 is published on gitlab, could not compare exact commit.
man-db-2.9.0-3.fc32.x86_64
### Steps to reproduce
```
tar xzf bind-9.11.25.tar.gz
man bind-9.11.25/bin/named/named.8
```
### What is the current *bug* behavior?
```
NAMED(8) BIND9 NAMED(8)
.SH "NAME" named - Internet domain name server
.SH "SYNOPSIS"
.HP 144u
```
All generated manual pages have spaces before .SH, .PP etc. sections of man. At least man from Fedora cannot cope with it and display those sections when
### What is the expected *correct* behavior?
The same output as done on v9_11 branch
```
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]
```
All manual pages seems to have the same issue, not just named.8.
### Relevant configuration files
none
### Relevant logs and/or screenshots
none
### Possible fixes
regenerate all pages with proper indentationDecember 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Michał KępieńMichał Kępień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/2308RUNTIME_CHECK(tresult == 0) failed when reloading a catalog zone2021-10-28T10:31:03ZDan MahoneyRUNTIME_CHECK(tresult == 0) failed when reloading a catalog zone<!--
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
RUNTIME_CHECK(tresult == 0) failed when reloading a catalog zone
### BIND version used
```
BIND 9.14.8 (Stable Release) <id:5d87f66>
running on FreeBSD amd64 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC
built by make with '--localstatedir=/var' '--disable-linux-caps' '--with-libxml2=/usr/local' '--with-readline=-L/usr/local/lib -ledit' '--with-dlopen=yes' '--with-openssl=/usr' '--sysconfdir=/usr/local/etc/namedb' '--with-dlz-filesystem=yes' '--disable-dnstap' '--disable-fixed-rrset' '--without-geoip2' '--without-gssapi' '--with-libidn2=/usr/local' '--with-libjson=/usr/local' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python' '--disable-querytrace' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-tcp-fastopen' '--with-tuning=default' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.0' 'build_alias=amd64-portbld-freebsd12.0' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)
compiled with OpenSSL version: OpenSSL 1.1.1a-freebsd 20 Nov 2018
linked to OpenSSL version: OpenSSL 1.1.1a-freebsd 20 Nov 2018
compiled with libxml2 version: 2.9.9
linked to libxml2 version: 20909
compiled with libjson-c version: 0.13.1
linked to libjson-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
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
Have been trying to reproduce, and cannot. Putting it here to note it.
This happened when I told named to retransfer my catalog zone, and then do an rndc reconfig. RNDC reported the connection had been closed, and I found in the logs:
### What is the current *bug* behavior?
Named crashes.
### What is the expected *correct* behavior?
Not a crash
### Relevant configuration files
```
options {
catalog-zones {
zone "catalog.example"
default-masters { red.ac.te.d; }
in-memory no
zone-directory "/usr/local/etc/namedb/catzones"
min-update-interval 10;
};
```
Pretty standard stuff.
### Relevant logs and/or screenshots
```
Nov 24 20:03:35 he 1 2020-11-24T20:03:35.194329+00:00 he.gushi.org named 12049 - - catz: catz_delzone_taskaction: zone 'redacted.com' deleted
Nov 24 20:04:02 he 1 2020-11-24T20:04:02.087641+00:00 he.gushi.org named 12049 - - /usr/local/etc/namedb/named.conf:13: catz: catalog zone 'catalog.example' will not be reconfigured
Nov 24 20:04:02 he 1 2020-11-24T20:04:02.088032+00:00 he.gushi.org named 12049 - - ./server.c:2961: fatal error:
Nov 24 20:04:02 he 1 2020-11-24T20:04:02.088049+00:00 he.gushi.org named 12049 - - RUNTIME_CHECK(tresult == 0) failed
Nov 24 20:04:02 he 1 2020-11-24T20:04:02.088059+00:00 he.gushi.org named 12049 - - exiting (due to fatal error in library)
Nov 24 20:04:02 he kernel: pid 12049 (named), uid 53: exited on signal 6
Nov 24 20:04:13 he 1 2020-11-24T20:04:13.666558+00:00 he.gushi.org named 200 - - starting BIND 9.14.8 (Stable Release) <id:5d87f66>
```
### Possible fixes
As above, server.c:2961November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2307"dig @localhost" does not fall back to 127.0.0.1 if ::1 is not answering2022-04-26T13:32:59ZMichał Kępień"dig @localhost" does not fall back to 127.0.0.1 if ::1 is not answeringThis started happening after !4115. It seems that each UDP query does
time out after 5 seconds, but `dig` never tries the "next server"
(127.0.0.1) after its "first pick" (::1) fails to respond.
The problem is easily reproducible with ...This started happening after !4115. It seems that each UDP query does
time out after 5 seconds, but `dig` never tries the "next server"
(127.0.0.1) after its "first pick" (::1) fails to respond.
The problem is easily reproducible with the following `named.conf`:
```
options {
listen-on port 5300 { 127.0.0.1; };
listen-on-v6 { none; };
};
```
Test with: `dig @localhost isc.org.` - it will time out even though it
should not. This is a change in behavior that was caught by [automated
RPM tests][1].
[1]: https://gitlab.isc.org/isc-private/rpms/bind/-/pipelines/57751April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Mark AndrewsMark Andrewshttps://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/2305Did we set the max-recursion-queries limit too low in our CVE-2020-8616 fix?2020-12-16T20:50:12ZMichael McNallyDid we set the max-recursion-queries limit too low in our CVE-2020-8616 fix?A [Support customer](https://support.isc.org/Ticket/Display.html?id=17319) has reported to us that the first time they query google.de on a server with a cold cache they get a SERVFAIL. Subsequent queries succeed. They asked us about t...A [Support customer](https://support.isc.org/Ticket/Display.html?id=17319) has reported to us that the first time they query google.de on a server with a cold cache they get a SERVFAIL. Subsequent queries succeed. They asked us about this because the behavior differed from an earlier version of BIND which did not exhibit the issue.
After some troubleshooting, it turns out that, due to a combination of factors -- some specific to the domain but also some applying to the server, they are hitting the max-recursion-queries limit of 75 queries that was set as part of the remediation for [CVE-2020-8616](https://kb.isc.org/docs/cve-2020-8616) (intended to prevent an exploit, demonstrated as a proof-of-concept by the researchers who reported it, that could send a server chasing a huge number of queries when processing a referral.)
The situation reported by the customer seems to demonstrate that a server with a not-very-unusual configuration can hit the limit while processing a common, fairly high-profile zone. Should we then adjust the limit, make changes to the log message visibility when the limit is hit, and/or make other changes?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/2304Insecure data handling and null pointer dereferences in test-async.c2021-09-03T05:05:05ZMichal NowakInsecure data handling and null pointer dereferences in test-async.c@each Coverity identified following problems in the new `bin/tests/system/hooks/driver/test-async.c`:
```
*** CID 313488: Insecure data handling (TAINTED_SCALAR)
/bin/tests/system/hooks/driver/test-async.c: 345 in async_query_done_begi...@each Coverity identified following problems in the new `bin/tests/system/hooks/driver/test-async.c`:
```
*** CID 313488: Insecure data handling (TAINTED_SCALAR)
/bin/tests/system/hooks/driver/test-async.c: 345 in async_query_done_begin()
339 }
340
341 /* initial call */
342 state->async = true;
343 state->hookpoint = NS_QUERY_DONE_BEGIN;
344 state->origresult = *resp;
>>> CID 313488: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted variable "qctx->client" to a tainted sink.
345 ns_query_hookasync(qctx, doasync, state);
346 return (NS_HOOK_RETURN);
347 }
348
349 static ns_hookresult_t
350 async_qctx_destroy(void *arg, void *cbdata, isc_result_t *resp) {
```
```
*** CID 281450: Null pointer dereferences (REVERSE_INULL)
/bin/tests/system/hooks/driver/test-async.c: 163 in plugin_register()
157
158 *instp = inst;
159
160 return (ISC_R_SUCCESS);
161
162 cleanup:
>>> CID 281450: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "inst" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
163 if (result != ISC_R_SUCCESS && inst != NULL) {
164 plugin_destroy((void **)&inst);
165 }
166
167 return (result);
168 }
```
More information at https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=37570751&defectInstanceId=11302475&mergedDefectId=313488.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2303Override fetch-limits when stale-answer-enable is 'yes' for queries that are ...2021-06-08T09:11:23ZCathy AlmondOverride fetch-limits when stale-answer-enable is 'yes' for queries that are attempting to refresh positive stale RRsetsSee also #2066, #2273, #2247 and #2248
The final piece of the puzzle is having Serve Stale play nicely with fetch-limits.
See also [https://bugs.isc.org/Ticket/Display.html?id=41259](https://bugs.isc.org/Ticket/Display.html?id=41259)
...See also #2066, #2273, #2247 and #2248
The final piece of the puzzle is having Serve Stale play nicely with fetch-limits.
See also [https://bugs.isc.org/Ticket/Display.html?id=41259](https://bugs.isc.org/Ticket/Display.html?id=41259)
Q. When fetch-limits are triggered, how do you give precedence to known 'good' client queries?
A. You base this on the existence of stale content already in cache.
Q. How do you override fetch-limits in a safe way (so that you don't override fetch-limits for every 'good' client query and still overwhelm the authoritative servers?
A. You have to have serving of stale answers enabled - that way you already have a built-in mechanism to rate-limit the refresh retries.
The current (and soon to be improved) implementation of serve-stale still only triggers serving of stale content if there is a stale answer already in cache that could be used, AND an attempt to refresh the stale content has timed out. If we don't attempt to refresh it, then it won't be served stale and the stale-refresh-time countdown won't be started for this query.
The same also applies if we served it stale once, but the stale-refresh-time has now expired again, and we need to try again to contact the authoritative servers - if we get blocked by fetch-limits (fetches-per-zone or fetches-per-server) we still won't use the stale data.
My request is that if these three condition are met, that we bypass fetchlimits and try to resolve the query anyway. The conditions are:
- The server has `stale-answer-enable yes;`
- The name/type being resolved can be answered from cache, should it be necessary to serve a stale answer
- This is not a negative response (NXDOMAIN or NXRRSET)
The risk of bypassing fetchlimits is low
a) we know that this query has been resolved before, so it might be possible to again and it is a better candidate query to bypass fetchlimits than a brand new name that this resolver hasn't encountered before - particularly if this resolver is also being used to participate in a PRSD-style attack
b) even if the query times out, this will trigger serving of the stale answer to all other clients who arrive with the same query during `stale-refresh-time`
It would be really good to get this into the December releases with the other improvements to Serve Stalehttps://gitlab.isc.org/isc-projects/bind9/-/issues/2298multiple definition of `librpz_dnsrpzd_path'2021-03-04T10:29:10ZDavid Fordmultiple definition of `librpz_dnsrpzd_path'<!--
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
during compilation, a link failure is returned because of multiple definitions of the `librpz_dnsrpzd_path` symbol
### BIND version used
source of 9.14.7
### Steps to reproduce
compile with dnsrps enabled
### What is the current *bug* behavior?
```
gcc -I/tmp/bind/trunk/src/bind-9.14.7 -I../.. -I. -I../../lib/dns -Iinclude -I/tmp/bind/trunk/src/bind-9.14.7/lib/dns/include -I../../lib/dns/include -I/tmp/bind/trunk/src/bind-9.14.7/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I/usr/include -I/usr/include -DGSSAPI -DUSE_ISC_SPNEGO -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DDIG_SIGCHASE -I/usr/include -pthread -I/usr/include/libxml2 -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -fno-delete-null-pointer-checks -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Wl,--export-dynamic -o libdns.la -rpath /usr/lib \
-version-info 1310:2:0 \
acl.lo adb.lo badcache.lo byaddr.lo cache.lo callbacks.lo catz.lo clientinfo.lo compress.lo db.lo dbiterator.lo dbtable.lo diff.lo dispatch.lo dlz.lo dns64.lo dnsrps.lo dnssec.lo ds.lo dyndb.lo ecs.lo fixedname.lo forward.lo ipkeylist.lo iptable.lo journal.lo keydata.lo keytable.lo lib.lo log.lo lookup.lo master.lo masterdump.lo message.lo name.lo ncache.lo nsec.lo nsec3.lo nta.lo order.lo peer.lo portlist.lo private.lo rbt.lo rbtdb.lo rcode.lo rdata.lo rdatalist.lo rdataset.lo rdatasetiter.lo rdataslab.lo request.lo resolver.lo result.lo rootns.lo rpz.lo rrl.lo rriterator.lo sdb.lo sdlz.lo soa.lo ssu.lo ssu_external.lo stats.lo tcpmsg.lo time.lo timer.lo tkey.lo tsec.lo tsig.lo ttl.lo update.lo validator.lo version.lo view.lo xfrin.lo zone.lo zonekey.lo zoneverify.lo zt.lo spnego.lo dst_api.lo dst_parse.lo dst_result.lo gssapi_link.lo gssapictx.lo hmac_link.lo openssl_link.lo openssldh_link.lo opensslecdsa_link.lo openssleddsa_link.lo opensslrsa_link.lo pkcs11rsa_link.lo pkcs11ecdsa_link.lo pkcs11eddsa_link.lo pkcs11.lo key.lo client.lo ecdb.lo geoip.lo ../../lib/isc/libisc.la -L/usr/lib -lcrypto -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -ljson-c -llmdb -lm -lGeoIP -L/usr/lib -lxml2 -lz -llzma -licui18n -licuuc -licudata -lm -ldl
libtool: link: gcc -shared -fPIC -DPIC .libs/acl.o .libs/adb.o .libs/badcache.o .libs/byaddr.o .libs/cache.o .libs/callbacks.o .libs/catz.o .libs/clientinfo.o .libs/compress.o .libs/db.o .libs/dbiterator.o .libs/dbtable.o .libs/diff.o .libs/dispatch.o .libs/dlz.o .libs/dns64.o .libs/dnsrps.o .libs/dnssec.o .libs/ds.o .libs/dyndb.o .libs/ecs.o .libs/fixedname.o .libs/forward.o .libs/ipkeylist.o .libs/iptable.o .libs/journal.o .libs/keydata.o .libs/keytable.o .libs/lib.o .libs/log.o .libs/lookup.o .libs/master.o .libs/masterdump.o .libs/message.o .libs/name.o .libs/ncache.o .libs/nsec.o .libs/nsec3.o .libs/nta.o .libs/order.o .libs/peer.o .libs/portlist.o .libs/private.o .libs/rbt.o .libs/rbtdb.o .libs/rcode.o .libs/rdata.o .libs/rdatalist.o .libs/rdataset.o .libs/rdatasetiter.o .libs/rdataslab.o .libs/request.o .libs/resolver.o .libs/result.o .libs/rootns.o .libs/rpz.o .libs/rrl.o .libs/rriterator.o .libs/sdb.o .libs/sdlz.o .libs/soa.o .libs/ssu.o .libs/ssu_external.o .libs/stats.o .libs/tcpmsg.o .libs/time.o .libs/timer.o .libs/tkey.o .libs/tsec.o .libs/tsig.o .libs/ttl.o .libs/update.o .libs/validator.o .libs/version.o .libs/view.o .libs/xfrin.o .libs/zone.o .libs/zonekey.o .libs/zoneverify.o .libs/zt.o .libs/spnego.o .libs/dst_api.o .libs/dst_parse.o .libs/dst_result.o .libs/gssapi_link.o .libs/gssapictx.o .libs/hmac_link.o .libs/openssl_link.o .libs/openssldh_link.o .libs/opensslecdsa_link.o .libs/openssleddsa_link.o .libs/opensslrsa_link.o .libs/pkcs11rsa_link.o .libs/pkcs11ecdsa_link.o .libs/pkcs11eddsa_link.o .libs/pkcs11.o .libs/key.o .libs/client.o .libs/ecdb.o .libs/geoip.o -Wl,-rpath -Wl,/tmp/bind/trunk/src/bind-9.14.7/lib/isc/.libs ../../lib/isc/.libs/libisc.so -L/usr/lib -lcrypto -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -ljson-c -llmdb -lGeoIP -lxml2 -lz -llzma -licui18n -licuuc -licudata -lm -ldl -march=x86-64 -mtune=generic -O2 -pthread -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--export-dynamic -pthread -Wl,-soname -Wl,libdns.so.1310 -o .libs/libdns.so.1310.0.2
/usr/bin/ld: .libs/rpz.o:(.bss+0x0): multiple definition of `librpz_dnsrpzd_path'; .libs/dnsrps.o:(.bss+0x80): first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:580: libdns.la] Error 1
make[2]: Leaving directory '/tmp/bind/trunk/src/bind-9.14.7/lib/dns'
make[1]: *** [Makefile:84: subdirs] Error 1
make[1]: Leaving directory '/tmp/bind/trunk/src/bind-9.14.7/lib'
make: *** [Makefile:91: subdirs] Error 1
```
### What is the expected *correct* behavior?
normal compile
### Relevant configuration files
```
└─> grep -iP 'rp(s|z)' config.log config.h
config.log: $ ./configure --prefix=/usr --sysconfdir=/etc --sbindir=/usr/bin --localstatedir=/var --disable-static --enable-fixed-rrset --enable-full-report --enable-dnsrps --with-python=/usr/bin/python --with-geoip --with-openssl --with-libidn2 --with-libjson --with-libxml2 --with-lmdb --with-libtool --with-dlz-postgres
config.log:configure:17485: checking for librpz __attribute__s
config.log:config.status:1482: creating bin/tests/system/rpz/Makefile
config.log:BIND9_CONFIGARGS='CONFIGARGS='\''--prefix=/usr'\'' '\''--sysconfdir=/etc'\'' '\''--sbindir=/usr/bin'\'' '\''--localstatedir=/var'\'' '\''--disable-static'\'' '\''--enable-fixed-rrset'\'' '\''--enable-full-report'\'' '\''--enable-dnsrps'\'' '\''--with-python=/usr/bin/python'\'' '\''--with-geoip'\'' '\''--with-openssl'\'' '\''--with-libidn2'\'' '\''--with-libjson'\'' '\''--with-libxml2'\'' '\''--with-lmdb'\'' '\''--with-libtool'\'' '\''--with-dlz-postgres'\'' '\''CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DDIG_SIGCHASE'\'' '\''LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'\'' '\''CPPFLAGS=-D_FORTIFY_SOURCE=0'\'''
config.log:#define LIBRPZ_HAVE_ATTR 1
config.log:#define DNSRPS_LIBRPZ_PATH "librpz.so"
config.log:#define DNSRPS_LIB_OPEN 2
config.log:#define USE_DNSRPS 1
config.h:/* dnsrps $librpz_name */
config.h:#define DNSRPS_LIBRPZ_PATH "librpz.so"
config.h:/* 0=no DNSRPS 1=static link 2=dlopen() */
config.h:#define DNSRPS_LIB_OPEN 2
config.h:/* have __attribute__s used in librpz.h */
config.h:#define LIBRPZ_HAVE_ATTR 1
config.h:#define USE_DNSRPS 1
```
### Relevant logs and/or screenshots
└─> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)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/2295Add the ability to specify that a server supports COOKIES.2022-09-20T13:44:03ZMark AndrewsAdd the ability to specify that a server supports COOKIES.We currently learn whether a server supports cookies or not as part of the lookup process. This leaves an exposure window where a spoofed UDP response without a cookie can be accepted. Fallback to TCP if the response does not have a va...We currently learn whether a server supports cookies or not as part of the lookup process. This leaves an exposure window where a spoofed UDP response without a cookie can be accepted. Fallback to TCP if the response does not have a valid TSIG or client cookie when `require-cookie` is true.
`server <prefix> { require-cookie <bool>; };`October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Mark AndrewsMark Andrewshttps://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/2289cache dump sometimes reports nonsense values with "stale (will be retained f...2021-04-28T09:11:11ZBrian Conrycache dump sometimes reports nonsense values with "stale (will be retained for %u more seconds)"Several customers have reported this issue, but the cause had been completely baffling.
Examples include:
```
; stale (will be retained for 4294362497 more seconds)
```
While reviewing the relevant areas of the code for other issues, I...Several customers have reported this issue, but the cause had been completely baffling.
Examples include:
```
; stale (will be retained for 4294362497 more seconds)
```
While reviewing the relevant areas of the code for other issues, I realized that the decision about whether or not to report the record as stale, and report how long it will be retained for (as modified by the recorded stale intervals), is based solely on the `STALE` flag in the header.
This is an accurate decision, but I wonder if this might lead to odd results if the record expiration is actually in the future because it has been forcibly expired due to the cache being overmem.
I've also wondered if there might be some incorrect reporting if/when the max-stale-ttl is changed after data has been added to the cache.
I will investigate both of these issues further using customer data I already have on hand, but I won't complain if it is fixed before I get to it.May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2288"dig" crashes when interrupted while waiting for a TCP connection2022-04-26T13:15:52ZMichał Kępień"dig" crashes when interrupted while waiting for a TCP connectionTo reproduce, fire up a `dig` query that will not connect over TCP
before it times out, e.g.:
dig @192.0.2.1 isc.org. A +time=10 +vc
and then hit CTRL+C:
dighost.c:3232: REQUIRE((__builtin_expect(!!(((query)) != ((void *)0)), ...To reproduce, fire up a `dig` query that will not connect over TCP
before it times out, e.g.:
dig @192.0.2.1 isc.org. A +time=10 +vc
and then hit CTRL+C:
dighost.c:3232: REQUIRE((__builtin_expect(!!(((query)) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)((query)))->magic == ((('D') << 24 | ('i') << 16 | ('g') << 8 | ('q')))), 1))) failed, back trace
Looks like `arg` (which gets cast to `dig_query_t *query`) passed to
`tcp_connected()` is broken in this case.
See #2287 for the UDP counterpart of this 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/2287"dig" crashes when interrupted while listening for UDP responses2020-12-09T10:08:46ZMichał Kępień"dig" crashes when interrupted while listening for UDP responsesTo reproduce, fire up a `dig` query that will not get a response before
it times out, e.g.:
dig @192.0.2.1 isc.org. A +time=10
and then hit CTRL+C:
dighost.c:4262: REQUIRE(isc_refcount_current(&recvcount) == 0) failed, back tr...To reproduce, fire up a `dig` query that will not get a response before
it times out, e.g.:
dig @192.0.2.1 isc.org. A +time=10
and then hit CTRL+C:
dighost.c:4262: REQUIRE(isc_refcount_current(&recvcount) == 0) failed, back trace
It looks like `current_lookup->q` is empty in `cancel_all()` and thus
the [code block which decrements `recvcount`][1] is not evaluated.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/ff2bc7891e99442df51acea1110ad599ddc6756a/bin/dig/dighost.c#L4203-4211December 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/2286Using "rndc delzone" during zone transfer may crash named2021-09-02T10:34:46ZMichał KępieńUsing "rndc delzone" during zone transfer may crash namedThe following crash occurred during the `inline` system test:
```
17-Nov-2020 04:26:19.900 queue_xfrin: zone test-l/IN (unsigned): enter
17-Nov-2020 04:26:19.900 zone test-l/IN (unsigned): Transfer started.
17-Nov-2020 04:26:19.900 zone...The following crash occurred during the `inline` system test:
```
17-Nov-2020 04:26:19.900 queue_xfrin: zone test-l/IN (unsigned): enter
17-Nov-2020 04:26:19.900 zone test-l/IN (unsigned): Transfer started.
17-Nov-2020 04:26:19.900 zone test-l/IN (unsigned): no database exists yet, requesting AXFR of initial version from 10.53.0.2#12100
17-Nov-2020 04:26:19.904 received control channel command 'delzone test-l'
17-Nov-2020 04:26:19.904 zone test-l scheduled for removal via delzone
17-Nov-2020 04:26:19.904 transfer of 'test-l/IN (unsigned)' from 10.53.0.2#12100: connected using 10.53.0.2#12100
17-Nov-2020 04:26:19.904 deleting zone test-l in view _default via delzone
17-Nov-2020 04:26:19.904 transfer of 'test-l/IN (unsigned)' from 10.53.0.2#12100: sent request data
17-Nov-2020 04:26:19.904 transfer of 'test-l/IN (unsigned)' from 10.53.0.2#12100: received 148 bytes
17-Nov-2020 04:26:19.904 received message from 10.53.0.2#12100
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19176
;; flags: qr aa; QUESTION: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;test-l. IN AXFR
;; ANSWER SECTION:
test-l. 300 IN SOA ns2.test-l. . 2000042407 20 20 1814400 3600
test-l. 300 IN NS ns3.test-l.
ns2.test-l. 300 IN A 10.53.0.2
ns3.test-l. 300 IN A 10.53.0.3
test-l. 300 IN SOA ns2.test-l. . 2000042407 20 20 1814400 3600
17-Nov-2020 04:26:19.904 transfer of 'test-l/IN (unsigned)' from 10.53.0.2#12100: got nonincremental response
17-Nov-2020 04:26:19.904 zone_shutdown: zone test-l/IN (signed): shutting down
17-Nov-2020 04:26:19.904 zone_shutdown: zone test-l/IN (unsigned): shutting down
17-Nov-2020 04:26:19.904 transfer of 'test-l/IN (unsigned)' from 10.53.0.2#12100: shut down: operation canceled
17-Nov-2020 04:26:19.904 dns_zone_verifydb: zone test-l/IN (unsigned): enter
17-Nov-2020 04:26:19.904 zone test-l/IN (unsigned): zone transfer finished: operation canceled
17-Nov-2020 04:26:19.904 removing journal file
17-Nov-2020 04:26:19.904 zone test-l/IN (unsigned): replacing zone database
17-Nov-2020 04:26:19.904 zone test-l/IN (unsigned): zone transfer finished: success
17-Nov-2020 04:26:19.904 zone test-l/IN (unsigned): transferred serial 2000042407
17-Nov-2020 04:26:19.904 zone_needdump: zone test-l/IN (unsigned): enter
17-Nov-2020 04:26:19.904 zone_settimer: zone test-l/IN (unsigned): enter
17-Nov-2020 04:26:19.904 zone_settimer: zone test-l/IN (unsigned): enter
17-Nov-2020 04:26:19.904 transfer of 'test-l/IN (unsigned)' from 10.53.0.2#12100: Transfer status: success
17-Nov-2020 04:26:19.904 transfer of 'test-l/IN (unsigned)' from 10.53.0.2#12100: Transfer completed: 1 messages, 5 records, 148 bytes, 0.001 secs (148000 bytes/sec) (serial 2000042407)
17-Nov-2020 04:26:19.904 transfer of 'test-l/IN (unsigned)' from 10.53.0.2#12100: freeing transfer context
17-Nov-2020 04:26:19.904 zone.c:16915: INSIST(((__extension__ ({ __auto_type __atomic_load_ptr = ((&(zone)->flags)); __typeof__ (*__atomic_load_ptr) __atomic_load_tmp; __atomic_load (__atomic_load_ptr, &__atomic_load_tmp, (memory_order_relaxed)); __atomic_load_tmp; }) & (DNS_ZONEFLG_REFRESH)) != 0)) failed, back trace
17-Nov-2020 04:26:19.904 /builds/isc-projects/bind9/bin/named/.libs/lt-named() [0x428fcc]
17-Nov-2020 04:26:19.904 /builds/isc-projects/bind9/lib/isc/.libs/libisc.so.1705(isc_assertion_failed+0xa) [0x7ff0d8adfc7a]
17-Nov-2020 04:26:19.904 /builds/isc-projects/bind9/lib/dns/.libs/libdns.so.1706(+0x185385) [0x7ff0d8812385]
17-Nov-2020 04:26:19.904 /builds/isc-projects/bind9/lib/dns/.libs/libdns.so.1706(+0x16f8e1) [0x7ff0d87fc8e1]
17-Nov-2020 04:26:19.904 /builds/isc-projects/bind9/lib/dns/.libs/libdns.so.1706(dns_xfrin_shutdown+0x31) [0x7ff0d87fca61]
17-Nov-2020 04:26:19.904 /builds/isc-projects/bind9/lib/dns/.libs/libdns.so.1706(+0x19111e) [0x7ff0d881e11e]
17-Nov-2020 04:26:19.904 /builds/isc-projects/bind9/lib/isc/.libs/libisc.so.1705(+0x5a879) [0x7ff0d8b00879]
17-Nov-2020 04:26:19.904 /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7ff0d71576ba]
17-Nov-2020 04:26:19.904 /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7ff0d66ad4dd]
17-Nov-2020 04:26:19.904 exiting (due to assertion failure)
```
Looks like the `test-l` zone was deleted using `rndc` while its transfer
was in progress.
While I do not have any proof that this is related to migrating zone
transfer code to netmgr, this particular `INSIST` has been in place for
the past 20 years, so it would be quite a coincidence to only start
hitting it now. If that turned out to be the case, branches other than
~"v9.17" might be affected, too, but I am sticking with the netmgr
theory for now.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)