BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-12-14T09:00:17Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1892Reuse nmsockets in TCP2022-12-14T09:00:17ZWitold KrecickiReuse nmsockets in TCPWe currently don't reuse isc_nmsocket_t sockets at all, destroying them after a connection is closed. That's a performance hit for TCP. We should put a semi-ready (allocated + cond/mutex initialized) objects on a stack for reuse, just li...We currently don't reuse isc_nmsocket_t sockets at all, destroying them after a connection is closed. That's a performance hit for TCP. We should put a semi-ready (allocated + cond/mutex initialized) objects on a stack for reuse, just like we do with uvreqs and handles.BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1893Not destroyed mutexes and conditionals lead to memory leaks on *BSD2020-06-10T11:26:17ZWitold KrecickiNot destroyed mutexes and conditionals lead to memory leaks on *BSDWhile on Linux mutexes and conditionals are self-contained within pthread_mutex_t and pthread_cond_t, respectively, on *BSD pthread_mutex_init and pthread_cond_init allocates memory. Not destroying those mutexes lead to memory leaksWhile on Linux mutexes and conditionals are self-contained within pthread_mutex_t and pthread_cond_t, respectively, on *BSD pthread_mutex_init and pthread_cond_init allocates memory. Not destroying those mutexes lead to memory leaksJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)https://gitlab.isc.org/isc-projects/bind9/-/issues/1894Edits to CONTRIBUTING.md2020-06-08T10:15:56ZSuzanne GoldlustEdits to CONTRIBUTING.mdContent updates to CONTRIBUTING.mdContent updates to CONTRIBUTING.mdJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1895Text edits in security.rst (take 2)2020-06-01T13:27:03ZSuzanne GoldlustText edits in security.rst (take 2)Various text edits in the security.rst section of the BIND ARM (my first attempt with this issue would not let me create a merge request)Various text edits in the security.rst section of the BIND ARM (my first attempt with this issue would not let me create a merge request)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1897max-transfer-time-* and max-transfer-idle-* broken since 9.15.62023-04-05T18:20:10ZBrian Conrymax-transfer-time-* and max-transfer-idle-* broken since 9.15.6In 53f0b6c34d3f ("convert ns_client and related objects to use netmgr"), the logic for setting a timer to enforce `max-transfer-time-out` and `max-transfer-idle-out` was removed.
In 49d53a4aa95682f9d94da4c6fa68ded66283cce9 ("use netmgr ...In 53f0b6c34d3f ("convert ns_client and related objects to use netmgr"), the logic for setting a timer to enforce `max-transfer-time-out` and `max-transfer-idle-out` was removed.
In 49d53a4aa95682f9d94da4c6fa68ded66283cce9 ("use netmgr for xfrin"), the `max-transfer-time-in` and `max-transfer-idle-in` options have met a similar destiny.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1898'.rst' files should be independent of configure option.2020-06-29T13:33:15ZMark Andrews'.rst' files should be independent of configure option.'.rst' files are being generated from doc/misc/options which has different line breaks depending upon which configure options are set as ' // not configured' differs. This impacts on the generated '.rst' files leading to churn in them. ...'.rst' files are being generated from doc/misc/options which has different line breaks depending upon which configure options are set as ' // not configured' differs. This impacts on the generated '.rst' files leading to churn in them. The '.rst' files are nominally independent of configure options.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/1899TCP Accept Refactoring broke Windows2020-06-08T12:19:30ZOndřej SurýTCP Accept Refactoring broke WindowsThe !3320 that got merged to master broke TCP connections on Windows. This needs to be fixed on master (before we release next 9.17.2) and also before we merged the backport to the BIND 9.16 branch.The !3320 that got merged to master broke TCP connections on Windows. This needs to be fixed on master (before we release next 9.17.2) and also before we merged the backport to the BIND 9.16 branch.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1901Add win32util/Configure path checks to CI2020-06-01T01:38:21ZMark AndrewsAdd win32util/Configure path checks to CIMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1902BIND build problems on NetBSD 92020-06-04T12:47:57ZMichal NowakBIND build problems on NetBSD 9There are three BIND 9.16.3 compilation issues on NetBSD 9 with Clang 9.0.1:
```
--- parser.o ---
clang -include /home/newman/bind-9.16.3/config.h -I/home/newman/bind-9.16.3 -I../.. -I. -I/home/newman/bind-9.16.3/lib/dns/include -I../....There are three BIND 9.16.3 compilation issues on NetBSD 9 with Clang 9.0.1:
```
--- parser.o ---
clang -include /home/newman/bind-9.16.3/config.h -I/home/newman/bind-9.16.3 -I../.. -I. -I/home/newman/bind-9.16.3/lib/dns/include -I../../lib/dns/include -I/home/newman/bind-9.16.3/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I/home/newman/bind-9.16.3/lib/isccfg/include -I../../lib/isccfg/include -DISC_MEM_DEFAULTFILL=1 -DISC_LIST_CHECKINIT=1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -O1 -g -Wall -Wextra -pthread -I/usr/pkg/include -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers -fno-strict-aliasing -Wshadow -Werror -c parser.c
--- parser.o ---
parser.c:1286:6: error: array subscript is of type 'char' [-Werror,-Wchar-subscripts]
if (toupper(TOKEN_STRING(pctx)[0]) == 'P') {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/sys/ctype_inline.h:60:46: note: expanded from macro 'toupper'
#define toupper(c) ((int)((_toupper_tab_ + 1)[(c)]))
^~~~
clang -include /home/newman/bind-9.16.3/config.h -I/home/newman/bind-9.16.3 -I../.. -I./include -I./unix/include -I. -I/home/newman/bind-9.16.3/lib/ns/include -I../../lib/ns/include -I/home/newman/bind-9.16.3/lib/dns/include -I../../lib/dns/include -I/home/newman/bind-9.16.3/lib/bind9/include -I../../lib/bind9/include -I/home/newman/bind-9.16.3/lib/isccfg/include -I../../lib/isccfg/include -I/home/newman/bind-9.16.3/lib/isccc/include -I../../lib/isccc/include -I/home/newman/bind-9.16.3/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I../../contrib/dlz/drivers/include -I/usr/pkg/include/json-c -I/usr/pkg/include/libxml2 -DCONTRIB_DLZ -DDLZ_FILESYSTEM -DISC_MEM_DEFAULTFILL=1 -DISC_LIST_CHECKINIT=1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -O1 -g -Wall -Wextra -pthread -I/usr/pkg/include -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers -fno-strict-aliasing -Wshadow -Werror -DVERSION=\"9.16.3\" -DPRODUCT=\""BIND"\" -DDESCRIPTION=\""(Stable Release)"\" -DSRCID=\"5ea41c1\" -DCONFIGARGS="\"'--disable-maintainer-mode' '--enable-developer' '--disable-static' '--with-cmocka' '--with-libxml2' '--with-json-c' '--without-make-clean' '--with-python=python3.7' '--disable-backtrace' '--disable-symtable' 'CC=clang' 'CFLAGS=-fno-omit-frame-pointer -fno-optimize-sibling-calls -O1 -g -Wall -Wextra'\"" -DBUILDER="\"make\"" -DNAMED_LOCALSTATEDIR=\"/usr/local/var\" -DNAMED_SYSCONFDIR=\"/usr/local/etc\" -c ./main.c
./main.c:358:8: error: array subscript is of type 'char' [-Werror,-Wchar-subscripts]
if (isalnum(*src) || *src == ',' || *src == '-' ||
^~~~~~~~~~~~~
/usr/include/sys/ctype_inline.h:48:44: note: expanded from macro 'isalnum'
#define isalnum(c) ((int)((_ctype_tab_ + 1)[(c)] & (_CTYPE_A|_CTYPE_D)))
^~~~
./main.c:362:15: error: array subscript is of type 'char' [-Werror,-Wchar-subscripts]
} else if (isprint(*src)) {
^~~~~~~~~~~~~
/usr/include/sys/ctype_inline.h:54:44: note: expanded from macro 'isprint'
#define isprint(c) ((int)((_ctype_tab_ + 1)[(c)] & _CTYPE_R))
^~~~
```
I fixed this by adding `(unsigned char)` before the parameter of failing macros:
- `toupper((unsigned char)TOKEN_STRING(pctx)[0]`
- `isalnum((unsigned char)*src)`
- `isprint((unsigned char)*src))`
There's also a `gen.c` linking problem:
```
clang -fno-omit-frame-pointer -fno-optimize-sibling-calls -O1 -g -Wall -Wextra -pthread -I/usr/pkg/include -fPIC -I../../lib/isc/include -Wl,-E -o gen ./gen.c -L/usr/pkg/lib -luv -lkvm -lrt -lpthread
make include/dns/enumtype.h
./gen -s . -t > include/dns/enumtype.h || { rm -f include/dns/enumtype.h ; exit 1; }
./gen: Shared object "libuv.so.1" not found
*** [include/dns/enumtype.h] Error code 1
```
I workedaround it with `LD_LIBRARY_PATH=/usr/pkg/lib make`, haven't look for a proper fix.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1903Authoritative server leaks 260 KB every 1-2 hours2023-11-03T06:59:46ZMichal NowakAuthoritative server leaks 260 KB every 1-2 hoursI run [stress test](https://gitlab.isc.org/isc-private/bind-qa/-/tree/master/bind9/stress) against BIND 9.16.3 authoritative server on Alpine Linux 3.12 (uses MUSL libc) for 18 hours and I noticed that in many cases `named`'s VSZ usage b...I run [stress test](https://gitlab.isc.org/isc-private/bind-qa/-/tree/master/bind9/stress) against BIND 9.16.3 authoritative server on Alpine Linux 3.12 (uses MUSL libc) for 18 hours and I noticed that in many cases `named`'s VSZ usage bumps 260 bytes every 1-2 hours. I haven't spotted this on Linux distributions with glibc. There are a few discrepancies from the "260 byte rule", but it seems too regular to be a coincidence. Although the mem usage bump is really tiny, there might be a leak of structure.
![named-memory-use-graph-alpine-3.12](/uploads/de49507ad28ed28fababf1b713f29b6d/named-memory-use-graph-alpine-3.12.png)
Here are `VSZ`/`RSS` data every 30 seconds: [alpine-vm.txt](/uploads/9942d3ad62e9c8ec145a2e9fb9bc815b/alpine-vm.txt)
Here's a sample of few last lines funneled via `uniq`:
```
...
422496
422756
423016
423276
423536
423796
424056
424316
424576
424836
425096
425356
425616
425876
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1906More BIND ARM text edits2020-06-08T12:11:06ZSuzanne GoldlustMore BIND ARM text editssecurity.rst updatessecurity.rst updatesJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1907nsupdate - handle "automatic chunking" for long rdata2021-10-05T12:36:37ZBrandon Applegatensupdate - handle "automatic chunking" for long rdataExample would be DKIM keys. Would be nice if one could feed nsupdate something like:
`"v=DKIM1;h=sha256;k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwNaasZOXcA/GFgbu+iAwOUhKKW+QHVdknaZNlh6NMv/r6A+kOpnGCvMsif1LYlas2ZGLFtq1KrjFhOz...Example would be DKIM keys. Would be nice if one could feed nsupdate something like:
`"v=DKIM1;h=sha256;k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwNaasZOXcA/GFgbu+iAwOUhKKW+QHVdknaZNlh6NMv/r6A+kOpnGCvMsif1LYlas2ZGLFtq1KrjFhOzlBpTNBN1hd/dceGC+rl39Y9VuAPxtNHRp9iZCz/Gs0ipJMzLlXEYE6DA5xKmq88Qk/9VNG5e5AECtCVYV3w7YftHGTuDWIRRMMS+IhyTzivCUYSRu4jl7HklhxplSuryPoKuPzzlVeS22HFtaTV4BXSrf1K9tmu1coe5fB4zbgodDZ5/yx6rFTgr3EjYzhWBqh72G0hHBTBufMu1hMej1Mt6KJsZw8GEGUUWLalfJnuoI8sxVPm3pII+9QoKXNqZtdiGtEQIDAQAB"`
And have nsupdate "chunk" this into < 255 byte parts:
`"v=DKIM1; h=sha256; k=rsa;" "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwNaasZOXcA/GFgbu+iAwOUhKKW+QHVdknaZNlh6NMv/r6A+kOpnGCvMsif1LYlas2ZGLFtq1KrjFhOzlBpTNBN1hd/dceGC+rl39Y9VuAPxtNHRp9iZCz/Gs0ipJMzLlXEYE6DA5xKmq88Qk/9VNG5e5AECtCVYV3w7YftHGTuDWIRRMMS+IhyTzivCUYSRu4jl7HklhxplSur"
"yPoKuPzzlVeS22HFtaTV4BXSrf1K9tmu1coe5fB4zbgodDZ5/yx6rFTgr3EjYzhWBqh72G0hHBTBufMu1hMej1Mt6KJsZw8GEGUUWLalfJnuoI8sxVPm3pII+9QoKXNqZtdiGtEQIDAQAB"`
Sorry for the formatting here as well, but hopefully the idea comes across.
As a human, I would naturally (try to) split on boundaries that make this a bit more readable (i.e. starting a new chunk at "p="). I wouldn't think you'd want to have corner cases and parsing logic to make it pretty, I suppose as long as it's valid syntax and the rdata goes in properly that's all that matters.BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1908Text edits in troubleshooting.rst2020-06-08T12:11:23ZSuzanne GoldlustText edits in troubleshooting.rstContent, clarity, grammar fixesContent, clarity, grammar fixesJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1909Text edits in history.rst2020-06-08T12:10:48ZSuzanne GoldlustText edits in history.rstContent, clarity, grammarContent, clarity, grammarJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1910Text edits in general.rst2020-06-08T12:20:23ZSuzanne GoldlustText edits in general.rstContent, clarity, and grammar updates in the BIND ARMContent, clarity, and grammar updates in the BIND ARMJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1912Refactor `fctx->client` to store just preformatted text2020-06-05T14:21:14ZOndřej SurýRefactor `fctx->client` to store just preformatted textPer https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3575#note_133991Per https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3575#note_133991BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1913Remove unused leftovers2020-11-12T14:09:33ZMichal NowakRemove unused leftoversThe following discussion from !3527 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3527#note_134700): (+2 comments)
> Reviewing this MR revealed a few interesti...The following discussion from !3527 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3527#note_134700): (+2 comments)
> Reviewing this MR revealed a few interesting findings:
>
> - there are some files which appear to be unused leftovers, e.g.
> `bin/rndc/include/rndc/os.h` - they are not included in source
> tarballs produced by `make dist` and yet these compile just fine,
>
> - some files tracked by Git are of questionable use, e.g.
> `bin/rndc/rndc.conf`.
>
> [1]: #1774November 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/1914Text edits in libdns.rst2020-06-08T12:20:44ZSuzanne GoldlustText edits in libdns.rstContent, clarity, and grammar updates to the DNS Library Support section of the BIND ARMContent, clarity, and grammar updates to the DNS Library Support section of the BIND ARMJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1915Edits to man pages for BIND ARM2021-01-12T14:39:10ZSuzanne GoldlustEdits to man pages for BIND ARMText and formatting edits for the man pages in the BIND ARMText and formatting edits for the man pages in the BIND ARMJuly 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1917danger, security and CVE.2021-01-29T12:54:56ZMark Andrewsdanger, security and CVE.It would be useful if danger checked that the CHANGES and release notes entries for [security] changes contain a CVE number.It would be useful if danger checked that the CHANGES and release notes entries for [security] changes contain a CVE number.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1918Remove IPv6 section from dns/arm/general.rst2022-03-01T11:42:54ZOndřej SurýRemove IPv6 section from dns/arm/general.rstThe following discussion from !3616 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3616#note_137265):
> @sgoldlust wrote in a commit message:
>
> > I a...The following discussion from !3616 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3616#note_137265):
> @sgoldlust wrote in a commit message:
>
> > I am not sure the IPv6 Addresses section belongs here; it is general DNS
> > reference information, but it seems like we either need to give a lot
> > more information about other general stuff, or just remove this bit. I
> > also question whether the Internet Drafts and Other Documents About BIND
> > sections are necessary here; Internet Drafts does not have any useful
> > information and Other Documents seems very incomplete.
> >
> > I recommend removing the Bibliography heading entirely and just making
> > this entire reference section about the RFCs.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Petr Špačekpspacek@isc.orgPetr Špačekpspacek@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1919Fix documentation install on Windows2020-09-03T10:09:46ZOndřej SurýFix documentation install on WindowsCurrently the `libisc.vcxproj` contains stuff like this:
```
echo Copying the ARM and the Installation Notes.
copy ..\COPYRIGHT ..\Build\Release
copy ..\README ..\Build\Release
copy ..\HISTORY ..\Build\Release
copy readme1st.txt ..\Buil...Currently the `libisc.vcxproj` contains stuff like this:
```
echo Copying the ARM and the Installation Notes.
copy ..\COPYRIGHT ..\Build\Release
copy ..\README ..\Build\Release
copy ..\HISTORY ..\Build\Release
copy readme1st.txt ..\Build\Release
copy index.html ..\Build\Release
copy ..\doc\arm\*.html ..\Build\Release
copy ..\doc\arm\Bv9ARM.pdf ..\Build\Release
copy ..\CHANGES ..\Build\Release
if Exist ..\CHANGES.SE copy ..\CHANGES.SE ..\Build\Release
copy ..\FAQ ..\Build\Release
```
As we currently don't build the documentation on Windows and we don't store it in git, I think the right way forward is to cherry-pick the artifact files from the `docs` build into the Windows zip file.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/1920[netmgr] tcpdns ineffective2020-12-09T09:53:34ZOndřej Surý[netmgr] tcpdns ineffectiveWhile reviewing some other stuff, in `lib/isc/netmgr/tcp.c` there's this code:
```
t->region = (isc_region_t){ .base = isc_mem_get(t->mctx,
region->length + 2),
...While reviewing some other stuff, in `lib/isc/netmgr/tcp.c` there's this code:
```
t->region = (isc_region_t){ .base = isc_mem_get(t->mctx,
region->length + 2),
.length = region->length + 2 };
*(uint16_t *)t->region.base = htons(region->length);
memmove(t->region.base + 2, region->base, region->length);
```
1) the memory returned by `isc_mem_get()` isn't guaranteed to be memory aligned, so you have unaligned write to the memory here.
2) doing `memmove()` just to add two bytes at the beginning of the buffer is inefficient.
Neither is to be fixed in this MR, but it should be fixed. The easiest way would be to rewrite the IO functions to work with `iovec`-like buffers, similar to what `uv_write()` does with `uv_buf_t[]`. Then it would be easy to just add two messages here, one with length, and one with the buffer.BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1921Adapt CI jobs involved in producing release tarballs to work with Automake & ...2020-06-09T12:56:40ZMichał KępieńAdapt CI jobs involved in producing release tarballs to work with Automake & Sphinx - Source tarballs for `master` should be produced using `make dist`.
- Release tarballs for `master` and `v9_16` must contain
Sphinx-generated documentation files.
Internal discussion led to the following solution:
- Include... - Source tarballs for `master` should be produced using `make dist`.
- Release tarballs for `master` and `v9_16` must contain
Sphinx-generated documentation files.
Internal discussion led to the following solution:
- Include the ARM in HTML, PDF, and EPUB formats in the release
tarball (i.e. in the FTP directory for a given release).
- Do not prepare any separate documents with just the release notes,
but point the reader towards them.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1922SoftHSM 2.6 is causing hangs in BIND 9.112021-01-29T13:12:58ZMichał KępieńSoftHSM 2.6 is causing hangs in BIND 9.11 - https://gitlab.isc.org/isc-projects/bind9/-/jobs/932569
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/933078 - https://gitlab.isc.org/isc-projects/bind9/-/jobs/932569
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/933078February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1923Teach danger about placeholder in CHANGES.2021-01-29T12:54:40ZMark AndrewsTeach danger about placeholder in CHANGES.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1924Release Checklist for BIND 9.11.20, BIND 9.11.20-S1, BIND 9.16.4, BIND 9.17.22020-06-18T09:49:12ZMichał KępieńRelease Checklist for BIND 9.11.20, BIND 9.11.20-S1, BIND 9.16.4, BIND 9.17.2## Release Schedule
**Code Freeze:** Friday, June 5th, 2020
**Tagging Deadline:** Wednesday, June 10th, 2020
**Public Release:** Wednesday, June 17th, 2020
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Su...## Release Schedule
**Code Freeze:** Friday, June 5th, 2020
**Tagging Deadline:** Wednesday, June 10th, 2020
**Public Release:** Wednesday, June 17th, 2020
## 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] ***(Support)*** Check release notes, ask QA to correct any mistakes found.
- [x] ***(Marketing)*** Check release notes, ask QA to correct any mistakes found.
- [x] ***(SwEng)*** Update API files for libraries with new version information.
- [x] ***(SwEng)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(SwEng)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(SwEng)*** Update `CHANGES`.
- [x] ***(SwEng)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(SwEng)*** Update `README.md`.
- [x] ***(SwEng)*** Update `version`.
- [x] ***(SwEng)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that all the above steps were performed correctly.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(SwEng)*** Tag the releases[^2]. (Tags may only be pushed to the public repository for releases which are *not* security releases.)
- [x] ***(SwEng)*** If this is the first tag for a release (e.g. beta), create a release branch named `release_v9_X_Y` to allow development to continue on the maintenance branch whilst release engineering continues.
### 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)*** 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] ***(SwEng)*** 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] ***(SwEng)*** Push tags for the published releases to the public repository.
- [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)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: Preferred command line: `git tag -u <DEVELOPER_KEYID> -a -s -m "BIND 9.X.Y[alphatag]" v9_X_Y[alphatag]`, where `[alphatag]` is an optional string such as `b1`, `rc1`, etc.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Michał KępieńMichał Kępień2020-06-17https://gitlab.isc.org/isc-projects/bind9/-/issues/1925Additional text edits to BIND ARM2021-01-12T14:46:44ZSuzanne GoldlustAdditional text edits to BIND ARMCleaning up various anomalies in formatting, contentCleaning up various anomalies in formatting, contentJuly 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1926Failed assertion in rdatalist.c: INSIST(list_rdata != ((void *)0))2020-07-01T13:39:04ZMichael McNallyFailed assertion in rdatalist.c: INSIST(list_rdata != ((void *)0))Kevan Benson wrote to security-officer@isc.org to say:
> We encountered an assertion failure in bind 9.16.3 running on an up to date CentOS 7 instance.
```
09-Jun-2020 13:27:19.816 cname: info: skipping nameserver 'ns1.fastclick.net' b...Kevan Benson wrote to security-officer@isc.org to say:
> We encountered an assertion failure in bind 9.16.3 running on an up to date CentOS 7 instance.
```
09-Jun-2020 13:27:19.816 cname: info: skipping nameserver 'ns1.fastclick.net' because it is a CNAME, while resolving '172.87.180.205.in-addr.arpa/PTR'
09-Jun-2020 13:27:19.816 cname: info: skipping nameserver 'ns2.fastclick.net' because it is a CNAME, while resolving '172.87.180.205.in-addr.arpa/PTR'
09-Jun-2020 13:27:20.007 trust-anchor-telemetry: info: client @0x7fdd09d71750 2602:24a:de40:7d90::#64256 (root-key-sentinel-not-ta-19036.d2a8n3.rootcanary.net): view internal-secure: root-key-sentinel-not-ta query label found
09-Jun-2020 13:27:20.018 trust-anchor-telemetry: info: client @0x7fdd116b9360 173.228.7.217#38979 (root-key-sentinel-not-ta-19036.d2a8n3.rootcanary.net): view internal-secure: root-key-sentinel-not-ta query label found
09-Jun-2020 13:27:20.581 general: critical: rdatalist.c:150: INSIST(list_rdata != ((void *)0)) failed
09-Jun-2020 13:27:20.582 general: critical: exiting (due to assertion failure)
```July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1927keepalive appears to be unused2021-08-31T13:36:34ZEvan Huntkeepalive appears to be unusedI just noticed in passing that the function `isc_nm_tcpdns_keepalive()` is defined in the netmgr, but is never called by `named`. I think the intent was to call it when the client sent an EDNS TCP KEEPALIVE option, so that named would sw...I just noticed in passing that the function `isc_nm_tcpdns_keepalive()` is defined in the netmgr, but is never called by `named`. I think the intent was to call it when the client sent an EDNS TCP KEEPALIVE option, so that named would switch to using a longer timeout.
The keepalive system test missed this because it only tests option processing and configuration, not timeout behavior. It would be nice to address that as well, though since it would necessarily be timing-dependent, it might be very difficult to make the test reliable.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1928error: socket.c:1540: unexpected error:2020-08-31T13:13:06ZPeter Davieserror: socket.c:1540: unexpected error:We have upgraded from 9.11.19 to 9.16.3 overnight and have now started to see these events in the syslog.
```
Jun 9 22:20:13 pad-res0 named[58819]: error: socket.c:1540: unexpected error:
Jun 9 22:20:13 pad-res0 named[58819]: error: ...We have upgraded from 9.11.19 to 9.16.3 overnight and have now started to see these events in the syslog.
```
Jun 9 22:20:13 pad-res0 named[58819]: error: socket.c:1540: unexpected error:
Jun 9 22:20:13 pad-res0 named[58819]: error: unable to convert errno to isc_result: 71: Protocol error
```
After restart last night:
```
Jun 9 16:14:34 pad-res0 named[58819]: starting BIND 9.16.3 (Stable Release) <id:5ea41c1>
Jun 9 16:14:34 pad-res0 named[58819]: running on Linux x86_64 2.6.32-754.17.1.el6.x86_64 #1 SMP Thu Jun 20 11:47:12 EDT 2019
Jun 9 16:14:34 pad-res0 named[58819]: built with '--prefix=/usr/local/' '--sysconfdir=/etc' '--with-python=no' '--with-json-c' 'PKG_CONFIG_PATH=:/usr/local/lib/pkgconfig:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Jun 9 16:14:34 pad-res0 named[58819]: running as: named -f -u named
Jun 9 16:14:34 pad-res0 named[58819]: compiled by GCC 4.4.7 20120313 (Red Hat 4.4.7-23)
Jun 9 16:14:34 pad-res0 named[58819]: compiled with OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
Jun 9 16:14:34 pad-res0 named[58819]: linked to OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
Jun 9 16:14:34 pad-res0 named[58819]: compiled with libxml2 version: 2.7.6
Jun 9 16:14:34 pad-res0 named[58819]: linked to libxml2 version: 20706
Jun 9 16:14:34 pad-res0 named[58819]: compiled with json-c version: 0.11
Jun 9 16:14:34 pad-res0 named[58819]: linked to json-c version: 0.11
Jun 9 16:14:34 pad-res0 named[58819]: compiled with zlib version: 1.2.3
Jun 9 16:14:34 pad-res0 named[58819]: linked to zlib version: 1.2.3
Jun 9 16:14:34 pad-res0 named[58819]: ----------------------------------------------------
Jun 9 16:14:34 pad-res0 named[58819]: BIND 9 is maintained by Internet Systems Consortium,
Jun 9 16:14:34 pad-res0 named[58819]: Inc. (ISC), a non-profit 501(c)(3) public-benefit
Jun 9 16:14:34 pad-res0 named[58819]: corporation. Support and training for BIND 9 are
Jun 9 16:14:34 pad-res0 named[58819]: available at https://www.isc.org/support
Jun 9 16:14:34 pad-res0 named[58819]: ----------------------------------------------------
Jun 9 16:14:34 pad-res0 named[58819]: adjusted limit on open files from 4096 to 1048576
Jun 9 16:14:34 pad-res0 named[58819]: /etc/named.conf:27: option 'dnssec-enable' is obsolete and should be removed
Jun 9 16:14:34 pad-res0 named[58819]: couldn't mkdir '/usr/local/var/run/named': Permission denied
Jun 9 16:14:34 pad-res0 named[58819]: couldn't mkdir '/usr/local/var/run/named': Permission denied
Jun 9 16:14:34 pad-res0 named[58819]: could not create /usr/local/var/run/named/session.key
Jun 9 16:14:34 pad-res0 named[58819]: failed to generate session key for dynamic DNS: permission denied
Jun 9 16:14:34 pad-res0 named[58819]: command channel listening on 127.0.0.1#953
Jun 9 16:14:34 pad-res0 named[58819]: command channel listening on ::1#953
Jun 9 16:14:34 pad-res0 named[58819]: notice: all zones loaded
Jun 9 16:14:34 pad-res0 named[58819]: notice: running
Jun 9 16:14:34 pad-res0 named[58819]: warning: checkhints: view defaultview: b.root-servers.net/A (199.9.14.201) missing from hints
Jun 9 16:14:34 pad-res0 named[58819]: warning: checkhints: view defaultview: b.root-servers.net/A (192.228.79.201) extra record in hints
Jun 9 16:14:34 pad-res0 named[58819]: warning: checkhints: view defaultview: b.root-servers.net/AAAA (2001:500:200::b) missing from hints
Jun 9 16:14:34 pad-res0 named[58819]: warning: checkhints: view defaultview: b.root-servers.net/AAAA (2001:500:84::b) extra record in hints
Jun 9 16:22:35 pad-res0 named[58819]: error: socket.c:1540: unexpected error:
Jun 9 16:22:35 pad-res0 named[58819]: error: unable to convert errno to isc_result: 71: Protocol error
Jun 9 16:22:35 pad-res0 named[58819]: error: socket.c:1540: unexpected error:
Jun 9 16:22:35 pad-res0 named[58819]: error: unable to convert errno to isc_result: 71: Protocol error
Jun 9 17:01:02 pad-res0 ntpdate[17116]: adjust time server 203.14.0.251 offset 0.047735 sec
Jun 9 17:13:02 pad-res0 named[58819]: error: socket.c:1540: unexpected error:
Jun 9 17:13:02 pad-res0 named[58819]: error: unable to convert errno to isc_result: 71: Protocol error
Jun 9 17:13:02 pad-res0 named[58819]: error: socket.c:1540: unexpected error:
Jun 9 17:13:02 pad-res0 named[58819]: error: unable to convert errno to isc_result: 71: Protocol error
Jun 9 17:28:28 pad-res0 named[58819]: error: socket.c:1540: unexpected error:
```
We are unsure what the error is relating to. Happy to provide any logs you require as these events are being recorded reasonably often.
RT #16586[](https://support.isc.org/Ticket/Display.html?id=16586)September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)https://gitlab.isc.org/isc-projects/bind9/-/issues/1929[v9_11] Drop "#define activeemtpynode activeemtpynode64" from lib/dns/rbtdb.c2020-06-29T13:05:52ZMichal Nowak[v9_11] Drop "#define activeemtpynode activeemtpynode64" from lib/dns/rbtdb.cc18dd943dab2124f2c04289fe164930455699334, among other things, renamed `activeemtpynode` to `activeemptynode`, but it seem that the `lib/dns/rbtdb.c:148:#define activeemtpynode activeemtpynode64` was kept (but it shouldn't?).c18dd943dab2124f2c04289fe164930455699334, among other things, renamed `activeemtpynode` to `activeemptynode`, but it seem that the `lib/dns/rbtdb.c:148:#define activeemtpynode activeemtpynode64` was kept (but it shouldn't?).July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1930Possible race in TCP accepting vs quota2020-06-10T18:49:37ZWitold KrecickiPossible race in TCP accepting vs quotaThere's a possibility of a race in TCP accepting code:
1. T1 accepts a connection C1
2. T2 accepts a connection C2
3. T1 tries to accept a connection C3, but we hit a quota, isc_quota_cb_init() sets quota_accept_cb for the socket, we ret...There's a possibility of a race in TCP accepting code:
1. T1 accepts a connection C1
2. T2 accepts a connection C2
3. T1 tries to accept a connection C3, but we hit a quota, isc_quota_cb_init() sets quota_accept_cb for the socket, we return from accept_connection
4. T2 drops C2, but we race in quota_release with accepting C3 so we don't see quota->waiting is > 0, we don't launch the callback
5. T1 accepts a connection C4, we are able to get the quota we clear the quota_accept_cb from sock->quotacb
6. T1 drops C1, tries to call the callback which is zeroed, sigsegv.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)https://gitlab.isc.org/isc-projects/bind9/-/issues/1931Fix out-of-order RFCs in general.rst file of BIND ARM2020-06-29T13:06:45ZSuzanne GoldlustFix out-of-order RFCs in general.rst file of BIND ARMA couple of the RFCs are out of numerical order.A couple of the RFCs are out of numerical order.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1932Text corrections in README.md2020-06-29T13:07:40ZSuzanne GoldlustText corrections in README.mdFixing grammar, typos, etc. in README.md fileFixing grammar, typos, etc. in README.md fileJuly 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1933'make test' fails with --enable-shared=no2020-06-29T13:38:22ZMark Andrews'make test' fails with --enable-shared=no`make test` does not skip the tests that depend on shared libraries when --enable-shared=no is passed to configure.
```
FAIL: dlzexternal
FAIL: dyndb
FAIL: filter-aaaa
FAIL: rpzrecurse
````make test` does not skip the tests that depend on shared libraries when --enable-shared=no is passed to configure.
```
FAIL: dlzexternal
FAIL: dyndb
FAIL: filter-aaaa
FAIL: rpzrecurse
```July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/1934back-port #1719 (closed) stats underflow fix to 9.112021-10-05T12:38:56ZBrian Conryback-port #1719 (closed) stats underflow fix to 9.11A customer has reported seeing:
```
named.stats: 4294967295 recursing clients
named.stats.old: 1 recursing clients
```
Looks like this is underflowing again, even with
```
5374. [bug] Statistics co...A customer has reported seeing:
```
named.stats: 4294967295 recursing clients
named.stats.old: 1 recursing clients
```
Looks like this is underflowing again, even with
```
5374. [bug] Statistics counters tracking recursive clients and
active connections could underflow. [GL #1087]
```
https://support.isc.org/Ticket/Display.html?id=16711BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1935[v9_11] "resolver" test broken on Windows after !35862020-06-29T09:22:18ZMichal Nowak[v9_11] "resolver" test broken on Windows after !3586After !3586, the `resolver` test is broken on `v9_11_20` and the subscription edition's `v9_11_20-S1` (see https://gitlab.isc.org/isc-private/bind9/-/jobs/950432 & https://gitlab.isc.org/isc-private/bind9/-/jobs/950429):
```
I:resolver:c...After !3586, the `resolver` test is broken on `v9_11_20` and the subscription edition's `v9_11_20-S1` (see https://gitlab.isc.org/isc-private/bind9/-/jobs/950432 & https://gitlab.isc.org/isc-private/bind9/-/jobs/950429):
```
I:resolver:check that the resolver limits the number of NS records it follows in a referral response (17)
I:resolver:query count error: 1 NS records: expected queries 1, actual 2
I:resolver:query count error: 2 NS records: expected queries 2, actual 4
I:resolver:query count error: 3 NS records: expected queries 3, actual 6
...
```
With !3586 reverted, `v9_11_20` Windows system tests pass (see https://gitlab.isc.org/mnowak/bind9/-/jobs/951334 & https://gitlab.isc.org/mnowak/bind9/-/jobs/951333).July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1936blackhole ACL broken2020-07-03T07:16:21ZMichael McNallyblackhole ACL broken<!--
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
A submitter who prefers to remain private sent this report to security-officer:
> Two weeks ago I upgraded my FreeBSD 11.4 BIND installs to 9.16.3 from a 2017 private build off 7fcd72f (right before your major query.c restructure). I was working with Cisco CSIRT this past week trying to trackdown DNS spoofers using Cisco address space and entered six addresses into my blackhole list, reloaded, and the spoofed packets kept coming in. So I reinstalled my 2017 private build and the blackhole ACL worked fine.
>
> For testing, I stripped my blackhole ACL down to a single IP address to test from and tested it against both my 2017 build and the 9.16.3 and same thing: works with my 2017 build but silently fails with 9.16.3. I tried with both the FreeBSD pkg version of BIND 9.16.3 and with the FreeBSD ports version of BIND 9.16.3 I built on the machine locally and both the pkg and ports versions fail.
### BIND version used
9.16.3, but we **suspect** probably introduced with netmgr in late 9.15.x and present in stable releases from 9.16.0
```
BIND 9.16.3 ports build named -V:
BIND 9.16.3 (Stable Release) <id:5ea41c1>
running on FreeBSD amd64 11.4-STABLE FreeBSD 11.4-STABLE #26 r361994: Wed Jun 10 00:36:44 UTC 2020 root@s203.sgt.com:/usr/obj/usr/src/sys/SGT11AMD64ZFS
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr/local' '--with-readline=-L/usr/local/lib -ledit' '--with-dlz-filesystem=yes' '--disable-dnstap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' '--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-freebsd11.4' 'build_alias=amd64-portbld-freebsd11.4' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c -Wl,-rpath,/usr/local/lib -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
compiled by CLANG FreeBSD Clang 10.0.0 (git@github.com:llvm/llvm-project.git llvmorg-10.0.0-0-gd32170dbd5b)
compiled with OpenSSL version: OpenSSL 1.1.1g 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g 21 Apr 2020
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.14
linked to json-c version: 0.14
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
```
### What is the current *bug* behavior?
Blackhole ACL does not appear to be appliedJuly 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/1937BIND 9.16.3 segfault in isc__nm_tcpdns_send2020-07-20T13:58:01ZCathy AlmondBIND 9.16.3 segfault in isc__nm_tcpdns_sendFrom [Support ticket #16727](https://support.isc.org/Ticket/Display.html?id=16727) (details of core dump etcetera can be found there).
Crash on a BIND 9.16.3 (Stable Release) <id:5ea41c1>
(with no rehash patch - that is the one to make ...From [Support ticket #16727](https://support.isc.org/Ticket/Display.html?id=16727) (details of core dump etcetera can be found there).
Crash on a BIND 9.16.3 (Stable Release) <id:5ea41c1>
(with no rehash patch - that is the one to make it possible to start named with larger hash tables so that there is no hash table resizing as cache expands)
```
core /var/log/splunk/core/core.19901
Core was generated by `/local/sbin/named -f -c /etc/named/named.conf -u named -n 12'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000000000637859 in isc__nm_tcpdns_send (handle=0x7f01eb0cdcf0, region=0x7f01ff3c2700, cb=0x478fc0 <client_senddone>, cbarg=0x7f01eb0cde60)
at tcpdns.c:483
483 tcpdns.c: No such file or directory.
Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7_6.5.x86_64 json-c-0.11-4.el7_0.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-37.el7_6.x86_64 libattr-2.4.46-13.el7.x86_64 libcap-2.22-9.el7.x86_64 libcom_err-1.42.9-13.el7.x86_64 libselinux-2.5-14.1.el7.x86_64 libuv-1.37.0-1.el7.x86_64 openssl-libs-1.0.2k-16.el7_6.1.x86_64 pcre-8.32-17.el7.x86_64 sssd-client-1.16.2-13.el7_6.8.x86_64 zlib-1.2.7-18.el7.x86_64
(gdb) bt
#0 0x0000000000637859 in isc__nm_tcpdns_send (handle=0x7f01eb0cdcf0, region=0x7f01ff3c2700, cb=0x478fc0 <client_senddone>, cbarg=0x7f01eb0cde60)
at tcpdns.c:483
#1 0x000000000063231d in isc_nm_send (handle=<optimized out>, region=<optimized out>, cb=<optimized out>, cbarg=<optimized out>) at netmgr.c:1309
#2 0x00000000004770d7 in client_sendpkg (client=client@entry=0x7f01eb0cde60, buffer=0x7f01ff3c2780, buffer=0x7f01ff3c2780) at client.c:366
#3 0x0000000000478064 in ns_client_send (client=client@entry=0x7f01eb0cde60) at client.c:634
#4 0x0000000000485a6c in query_send (client=0x7f01eb0cde60) at query.c:552
#5 0x000000000048dd13 in ns_query_done (qctx=qctx@entry=0x7f01ff3c4830) at query.c:10921
#6 0x000000000048f65d in query_respond (qctx=0x7f01ff3c4830) at query.c:7414
#7 query_prepresponse (qctx=qctx@entry=0x7f01ff3c4830) at query.c:9913
#8 0x000000000049170c in query_gotanswer (qctx=qctx@entry=0x7f01ff3c4830, res=res@entry=0) at query.c:6836
#9 0x0000000000496760 in query_resume (qctx=0x7f01ff3c4830) at query.c:6134
#10 fetch_callback (task=<optimized out>, event=0x7f0157df1490) at query.c:5716
#11 0x000000000064168a in dispatch (threadid=<optimized out>, manager=<optimized out>) at task.c:1152
#12 run (queuep=<optimized out>) at task.c:1344
#13 0x00007f020a26bdd5 in start_thread () from /lib64/libpthread.so.0
#14 0x00007f0209b76ead in clone () from /lib64/libc.so.6
(gdb) info frame 0
(gdb) info locals
t = 0x7f01a3fc7f28
sock = 0x7f015c8c9e10
(gdb) print *t
$1 = {mctx = 0x7f0193bfdd78, handle = 0x7f01eff53560, region = {base = 0x0, length = 215}, orighandle = 0x7f00f447c4a0, cb = 0x478fc0 <client_senddone>,
cbarg = 0x7f00f447c610}
(gdb) print *t->mtx
There is no member named mtx.
(gdb) print *(t->mctx)
$2 = {impmagic = 1337724176, magic = 32513, methods = 0x7f01dffd1690}
(gdb) print *(t->handle)
$3 = {magic = 0, references = 0, sock = 0x0, ah_pos = 0, inflight = false, peer = {type = {sa = {sa_family = 0, sa_data = '\000' <repeats 13 times>}, sin = {
sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 0, sin6_port = 0,
sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0,
0}}}, sin6_scope_id = 0}, ss = {ss_family = 0, __ss_padding = '\000' <repeats 117 times>, __ss_align = 0}, sunix = {sun_family = 0,
sun_path = '\000' <repeats 107 times>}}, length = 0, link = {prev = 0x0, next = 0x0}}, local = {type = {sa = {sa_family = 0,
sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"},
sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0,
0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}, ss = {ss_family = 0, __ss_padding = '\000' <repeats 117 times>, __ss_align = 0},
sunix = {sun_family = 0, sun_path = '\000' <repeats 107 times>}}, length = 0, link = {prev = 0x0, next = 0x0}}, doreset = 0x0, dofree = 0x0,
opaque = 0x0, extra = 0x7f01eff536d0 ""}
(gdb) print *(t->cbarg)
Attempt to dereference a generic pointer.
```
```
# ls -lst --full-time /var/log/splunk/core/core.19901
3243708 -rw------- 1 named named 3637059584 2020-06-13 21:42:52.861692911 +0200 /var/log/splunk/core/core.19901
```
Last syslog messages were:
```
2020-06-13T21:42:42.464+02:00 dispatch: dispatch 0x7f01b2a57550: shutting down due to TCP receive error: 172.105.106.137#53: connection reset
2020-06-13T21:42:42.558+02:00 dispatch: dispatch 0x7f01b3b48cc0: shutting down due to TCP receive error: 172.105.106.137#53: connection reset
```
And just before (as in, the logging is a bit out of sequence):
```
2020-06-13T21:42:42.000+02:00 2020-06-13T21:42:42+02:00 ti0016o823.ti.telenor.net kernel:
[30703183.144337] isc-worker0005[19921]: segfault at 118 ip 0000000000637859 sp 00007f01ff3c26c0
error 4 in named[400000+2f9000]
```
There is a full gdb backtrace of all the threads on the support ticket. Binaries and libs are on another support ticket [#16728](https://support.isc.org/Ticket/Display.html?id=16728)
====
Note that this server then had trouble restarting - repeated instances of another crash on startup.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/1938Repeated bind 9.16.3 assert error in libuv (attempting restart after an earli...2020-07-20T13:58:01ZCathy AlmondRepeated bind 9.16.3 assert error in libuv (attempting restart after an earlier/different crash)From [Support ticket #16728](https://support.isc.org/Ticket/Display.html?id=16728):
After a crash (see [Support ticket #16727](https://support.isc.org/Ticket/Display.html?id=16727) and also #1937 )
named repeatedly crashing during resta...From [Support ticket #16728](https://support.isc.org/Ticket/Display.html?id=16728):
After a crash (see [Support ticket #16727](https://support.isc.org/Ticket/Display.html?id=16727) and also #1937 )
named repeatedly crashing during restart from systemd.
At least 14 crashes before filesystem full of core files.
```
(gdb) core /var/log/splunk/core/core.10047
(gdb) bt
#0 0x00007fa36e777207 in raise () from /lib64/libc.so.6
#1 0x00007fa36e7788f8 in abort () from /lib64/libc.so.6
#2 0x00007fa36e770026 in __assert_fail_base () from /lib64/libc.so.6
#3 0x00007fa36e7700d2 in __assert_fail () from /lib64/libc.so.6
#4 0x00007fa36f36fed1 in uv__udp_finish_close () from /lib64/libuv.so.1
#5 0x00007fa36f361c68 in uv_run () from /lib64/libuv.so.1
#6 0x0000000000633c4a in nm_thread (worker0=0x1f35ac8) at netmgr.c:481
#7 0x00007fa36ef33dd5 in start_thread () from /lib64/libpthread.so.0
#8 0x00007fa36e83eead in clone () from /lib64/libc.so.6
(gdb) frame 4
#4 0x00007fa36f36fed1 in uv__udp_finish_close () from /lib64/libuv.so.1
(gdb) info frame 4
Stack frame at 0x7fa36a81ed30:
rip = 0x7fa36f36fed1 in uv__udp_finish_close; saved rip 0x7fa36f361c68
called by frame at 0x7fa36a81eda0, caller of frame at 0x7fa36a81ed20
Arglist at 0x7fa36a81ed18, args:
Locals at 0x7fa36a81ed18, Previous frame's sp is 0x7fa36a81ed30
Saved registers:
rbx at 0x7fa36a81ed20, rip at 0x7fa36a81ed28
ti0016o823(root) named 1329# /local/sbin/named -V
BIND 9.16.3 (Stable Release) <id:5ea41c1>
running on Linux x86_64 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019
built by make with 'CFLAGS=-m64 -g -O2' '--prefix=/local' '--localstatedir=/var' '--with-openssl=yes' '--with-libtool' '--enable-static=yes' '--disable-shared' '--enable-largefile' '--sysconfdir=/etc/named' '--with-libxml2=no' '--with-tuning=large' '--with-python=/usr/bin/python3' '--with-libjson'
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 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
threads support is enabled
default paths:
named configuration: /etc/named/named.conf
rndc configuration: /etc/named/rndc.conf
DNSSEC root key: /etc/named/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
They think they've run libuv 1.37 for a time.
It seems there is a 1.38 that they could upgrade to (under sysadmin discussion...)
```
Available Packages
Name : libuv
Arch : x86_64
Epoch : 1
Version : 1.38.0
Release : 2.el7
Size : 148 k
Repo : epel/x86_64
Summary : Platform layer for node.js
URL : http://libuv.org/
License : MIT and BSD and ISC
Description : libuv is a new platform layer for Node. Its purpose is to abstract
: IOCP on Windows and libev on Unix systems. We intend to eventually
: contain all platform differences in this library.
```July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/1939kasp system test intermittent test failures for "rumoured.kasp" zone2020-07-03T16:24:36ZMichał Kępieńkasp system test intermittent test failures for "rumoured.kasp" zoneSome checks recently added to the `kasp` system test fail very often as
they do not tolerate certain events taking more than 1 second to happen:
```
I:kasp:check key timing metadata for key KEY1 id 49258 zone rumoured.kasp (110)
I:kasp:...Some checks recently added to the `kasp` system test fail very often as
they do not tolerate certain events taking more than 1 second to happen:
```
I:kasp:check key timing metadata for key KEY1 id 49258 zone rumoured.kasp (110)
I:kasp:check key timing metadata for key KEY2 id 10506 zone rumoured.kasp (111)
I:kasp:check key timing metadata for key KEY3 id 25185 zone rumoured.kasp (112)
I:kasp:error: mismatch publish comment in ns3/Krumoured.kasp.+005+25185.key (expected 20200615091205)
I:kasp:error: mismatch publish in ns3/Krumoured.kasp.+005+25185.private (expected 20200615091205)
I:kasp:error: mismatch publish in ns3/Krumoured.kasp.+005+25185.state (expected 20200615091205)
I:kasp:error: mismatch active comment in ns3/Krumoured.kasp.+005+25185.key (expected 20200616091205)
I:kasp:error: mismatch active in ns3/Krumoured.kasp.+005+25185.private (expected 20200616091205)
I:kasp:error: mismatch active in ns3/Krumoured.kasp.+005+25185.state (expected 20200616091205)
I:kasp:error: mismatch retired comment in ns3/Krumoured.kasp.+005+25185.key (expected 20210616091205)
I:kasp:error: mismatch retired in ns3/Krumoured.kasp.+005+25185.private (expected 20210616091205)
I:kasp:error: mismatch retired in ns3/Krumoured.kasp.+005+25185.state (expected 20210616091205)
I:kasp:error: mismatch removed comment in ns3/Krumoured.kasp.+005+25185.key (expected 20210626101705)
I:kasp:error: mismatch removed in ns3/Krumoured.kasp.+005+25185.private (expected 20210626101705)
I:kasp:error: mismatch removed in ns3/Krumoured.kasp.+005+25185.state (expected 20210626101705)
I:kasp:failed
```
Meanwhile, in the artifacts:
```
$ cat bin/tests/system/kasp/ns3/Krumoured.kasp.+005+25185.key
; This is a zone-signing key, keyid 25185, for rumoured.kasp.
; Created: 20200615091204 (Mon Jun 15 09:12:04 2020)
; Publish: 20200615091204 (Mon Jun 15 09:12:04 2020)
; Activate: 20200616091204 (Tue Jun 16 09:12:04 2020)
; Inactive: 20210616091204 (Wed Jun 16 09:12:04 2021)
; Delete: 20210626101704 (Sat Jun 26 10:17:04 2021)
rumoured.kasp. 1234 IN DNSKEY 256 3 5 AwEAAbmPnkXcnAF0iTlpP57eQnoDD05ldTahTcUkOUVaeRqF1gSpYYU6 zp9mQrmYty57kLYe7EuG6xbPHIK2DT+7sAQxGM+J+oFLxFKkxCQE+Cm6 ubhaZZ5sbBpwQMy06iuZFJ3pNFT2Q1FzIz4zCjqbnupySShsC34SsvGT zgExa/73Jy9f7k8/8JT12mbcNYByamiSnvHzMTdyqGA/jiruRPRApgYG +Gh+nS0inf5r9pX/rzu54XrZ/n8CNYAYvp2wWgIO6uWJvDgj2oszgKn4 HUTsS/x6hu+CHiFeSOZPAyW2fXVRUTqARnDzLedyupO3WNgRVipBtE/X iwE=
```
Example instances of this failure mode taken from just one pipeline:
- https://gitlab.isc.org/isc-private/bind9/-/jobs/953093
- https://gitlab.isc.org/isc-private/bind9/-/jobs/953097
- https://gitlab.isc.org/isc-private/bind9/-/jobs/953103July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1940Removing more references to "master" and "slave" in BIND ARM2021-01-12T14:33:07ZSuzanne GoldlustRemoving more references to "master" and "slave" in BIND ARMContinued cleanup of ARM files to remove offensive terminology where possible.Continued cleanup of ARM files to remove offensive terminology where possible.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1941TCP performance regression on FreeBSD2021-01-19T10:49:09ZMichal NowakTCP performance regression on FreeBSDBIND 9.16.4 (and presumably `master`) on a FreeBSD 12.1 (in a VM) has a TCP query performance regression compared to 9.16.3.
The [stress test](https://gitlab.isc.org/isc-private/bind-qa/-/tree/master/bind9/stress) executes four instance...BIND 9.16.4 (and presumably `master`) on a FreeBSD 12.1 (in a VM) has a TCP query performance regression compared to 9.16.3.
The [stress test](https://gitlab.isc.org/isc-private/bind-qa/-/tree/master/bind9/stress) executes four instances of Flamethrower: UDP IPv6, UDP IPv4, TCP IPv6, and TCP IPv4. Knowing that each TCP Flamethrower runs with 30 concurrent generators, each sending 100 queries every 1000 ms we can calculate number of expected TCP queries processed by BIND. If at least 90 % of this target is processed, the test is considered pass.
This test does pass on Linux (Fedora 32) but fails on FreeBSD 12.1. Some difference can be accounted to difference between these two environments as the former is a bare metal, the latter a KVM VM, but still 9.16.3 on FreeBSD 12.1 performs close to Linux.
**9.16.3: Stress test (FreeBSD 12.1 / recursive / 1 hour)**
```
INFO: Recursive server 'ns3' received 21066269 TCP queries
INFO: About 21600000 TCP queries were expected
INFO: Minimum number of TCP queries required to pass is 19440000
INFO: BIND processed enough TCP queries
```
**9.16.4: Stress test (Fedora 32 / recursive / 1 hour)**
```
INFO: Recursive server 'ns3' received 20714111 TCP queries
INFO: About 21600000 TCP queries were expected
INFO: Minimum number of TCP queries required to pass is 19440000
INFO: BIND processed enough TCP queries
```
**9.16.4: Stress test (FreeBSD 12.1 / recursive / 1 hour)**
```
INFO: Recursive server 'ns3' received 11103214 TCP queries
INFO: About 21600000 TCP queries were expected
INFO: Minimum number of TCP queries required to pass is 19440000
ERROR: BIND did not process enough TCP queries
```
There's a performance problem on BIND 9.11 on FreeBSD [too](https://gitlab.isc.org/isc-projects/bind9/-/issues/1942), but the TCP code seems to be a bit different.January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/1942[v9_11] TCP performance on FreeBSD much lower than on Linux2021-01-07T21:03:15ZMichal Nowak[v9_11] TCP performance on FreeBSD much lower than on LinuxBIND 9.11.20 and 9.11.19 (and probably older versions too) on a FreeBSD 12.1 (in a VM) has about a half of TCP query performance of Linux.
The [stress test](https://gitlab.isc.org/isc-private/bind-qa/-/tree/master/bind9/stress) executes...BIND 9.11.20 and 9.11.19 (and probably older versions too) on a FreeBSD 12.1 (in a VM) has about a half of TCP query performance of Linux.
The [stress test](https://gitlab.isc.org/isc-private/bind-qa/-/tree/master/bind9/stress) executes four instances of Flamethrower: UDP IPv6, UDP IPv4, TCP IPv6, and TCP IPv4. Knowing that each TCP Flamethrower runs with 30 concurrent generators, each sending 100 queries every 1000 ms we can calculate number of expected TCP queries processed by BIND. If at least 90 % of this target is processed, the test is considered pass.
This test does pass on Linux (Fedora 32) but fails on FreeBSD 12.1. Some difference can be accounted to difference between these two environments as the former is a bare metal, the latter a KVM VM. (But still this test passes on 9.16.3 on FreeBSD 12.1.)
**9.16.3: Stress test (FreeBSD 12.1 / recursive / 1 hour)**
```
INFO: Recursive server 'ns3' received 21066269 TCP queries
INFO: About 21600000 TCP queries were expected
INFO: Minimum number of TCP queries required to pass is 19440000
INFO: BIND processed enough TCP queries
```
**9.11.20: Stress test (Fedora 32 / recursive / 1 hour)**
```
INFO: Recursive server 'ns3' received 21257316 TCP queries
INFO: About 21600000 TCP queries were expected
INFO: Minimum number of TCP queries required to pass is 19440000
INFO: BIND processed enough TCP queries
```
**9.11.20: Stress test (FreeBSD 12.1 / recursive / 12 hour)**
```
INFO: Recursive server 'ns3' received 136973904 TCP queries
INFO: About 259200000 TCP queries were expected
INFO: Minimum number of TCP queries required to pass is 233280000
ERROR: BIND did not process enough TCP queries
```
This is similar but believed to be different to https://gitlab.isc.org/isc-projects/bind9/-/issues/1941.January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/1943Remove references to "blacklist" and "whitelist" in BIND ARM2020-06-29T13:08:25ZSuzanne GoldlustRemove references to "blacklist" and "whitelist" in BIND ARMSince these are not actual commands, this terminology is unnecessary and could be considered offensive.Since these are not actual commands, this terminology is unnecessary and could be considered offensive.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1944prefer primary/secondary terminology in code2021-09-15T20:53:58ZEvan Huntprefer primary/secondary terminology in codeRelated to #1940, further cleanup of the code base would be good too.
- Change `master`/`slave` to `primary`/`secondary` in all system tests
- Change internal identifiers like `dns_zone_slave` and `CFG_ZONE_SLAVE` to match.
Goal state:...Related to #1940, further cleanup of the code base would be good too.
- Change `master`/`slave` to `primary`/`secondary` in all system tests
- Change internal identifiers like `dns_zone_slave` and `CFG_ZONE_SLAVE` to match.
Goal state: `master` and `slave` continue to work, but nothing calls attention to them.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1945system:clang:tsan has bad $SYMBOLIZER2020-06-29T13:04:21ZMark Andrewssystem:clang:tsan has bad $SYMBOLIZERJob [#954307](https://gitlab.isc.org/isc-projects/bind9/-/jobs/954307) failed for 183e1ace67a889b6b7a5bb146c0bba1e13755d28:
==named==1843==ERROR: External symbolizer path is set to '$SYMBOLIZER' which isn't a known symbolizer. Please se...Job [#954307](https://gitlab.isc.org/isc-projects/bind9/-/jobs/954307) failed for 183e1ace67a889b6b7a5bb146c0bba1e13755d28:
==named==1843==ERROR: External symbolizer path is set to '$SYMBOLIZER' which isn't a known symbolizer. Please set the path to the llvm-symbolizer binary or other known tool.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1946dnstap-read.1 man page installed when dnstap-read binary is missing2021-03-18T12:36:04ZAnand Buddhdevdnstap-read.1 man page installed when dnstap-read binary is missing### Summary
When BIND 9.16.4 is built without --enable-dnstap, it still installs the man page for dnstap-read. Earlier versions of BIND did not do this.
### BIND version used
9.16.4
### Steps to reproduce
When building BIND, do *not...### Summary
When BIND 9.16.4 is built without --enable-dnstap, it still installs the man page for dnstap-read. Earlier versions of BIND did not do this.
### BIND version used
9.16.4
### Steps to reproduce
When building BIND, do *not* pass the --enable-dnstap option to configure. Then "make install".
### What is the current *bug* behavior?
A man page for dnstap-read is installed in the PREFIX/share/man/man1 directory.
### What is the expected *correct* behavior?
The man page should not be installed.
### Relevant configuration files
n/a
### Relevant logs and/or screenshots
n/a
### Possible fixes
I don't have a fix.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1948add synonym for "masters"2021-01-12T14:24:13ZEvan Huntadd synonym for "masters"When I made `primary` and `secondary` valid zone types, I didn't add `primaries` as a synonym for `masters` because I didn't want to deal with the added complexity of both terms being used in the same context. Time to finish it though.When I made `primary` and `secondary` valid zone types, I didn't add `primaries` as a synonym for `masters` because I didn't want to deal with the added complexity of both terms being used in the same context. Time to finish it though.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1949check-names doesn't use 'primary' and 'secondary'2020-06-30T07:19:07ZEvan Huntcheck-names doesn't use 'primary' and 'secondary'`primary` and `secondary` are valid parameters for the `check-names` option in the parser, but they were never hooked in to `named_zone_configure()` correctly and are currently being ignored.`primary` and `secondary` are valid parameters for the `check-names` option in the parser, but they were never hooked in to `named_zone_configure()` correctly and are currently being ignored.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1950Build option for no unittest2020-06-29T13:12:31ZPeter DaviesBuild option for no unittestBuild option for no unittest
To ability to build without unittests.
To enable testing to be performed without error on system where necessary unittest tools cannot be installed
RT [#16737](https://support.isc.org/Ticket/Display.html?i...Build option for no unittest
To ability to build without unittests.
To enable testing to be performed without error on system where necessary unittest tools cannot be installed
RT [#16737](https://support.isc.org/Ticket/Display.html?id=16737)July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/1951Add BIND version number to introduction.rst file2020-07-03T07:16:29ZSuzanne GoldlustAdd BIND version number to introduction.rst fileAt the moment, there's no way to tell which version of the BIND ARM you're looking at, just from looking at the content. If we add the following text to the introduction.rst:
```
This guide covers BIND version |release|.
```
that should ...At the moment, there's no way to tell which version of the BIND ARM you're looking at, just from looking at the content. If we add the following text to the introduction.rst:
```
This guide covers BIND version |release|.
```
that should include it in the generated files.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1952IPv6 addresses can be unparsable in yaml2020-06-29T13:43:53ZEvan HuntIPv6 addresses can be unparsable in yamlIPv6 addresses sometimes end in two trailing colons. For example, in the current output of `dig +yaml ns by` there's a name server with address "2a05:4800:1:100::". This breaks YAML parsing.
To fix this we need to append "0". I think i...IPv6 addresses sometimes end in two trailing colons. For example, in the current output of `dig +yaml ns by` there's a name server with address "2a05:4800:1:100::". This breaks YAML parsing.
To fix this we need to append "0". I think it would be harmless in all IPv6 address expansions everywhere, but in any case we should always do it when using `dns_masterstyle_yaml`.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1953Release Checklist for BIND 9.11.21, BIND 9.11.21-S1, BIND 9.16.5, BIND 9.17.32020-07-16T15:27:04ZMichał KępieńRelease Checklist for BIND 9.11.21, BIND 9.11.21-S1, BIND 9.16.5, BIND 9.17.3## Release Schedule
**Code Freeze:** Wednesday, July 1st, 2020
**Tagging Deadline:** Monday, July 6th, 2020
**Public Release:** Wednesday, July 15th, 2020
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Sup...## Release Schedule
**Code Freeze:** Wednesday, July 1st, 2020
**Tagging Deadline:** Monday, July 6th, 2020
**Public Release:** Wednesday, July 15th, 2020
## 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] ***(Support)*** Check release notes, ask QA to correct any mistakes found.
- [x] ***(Marketing)*** Check release notes, ask QA to correct any mistakes found.
- [x] ***(SwEng)*** Update API files for libraries with new version information.
- [x] ***(SwEng)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(SwEng)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(SwEng)*** Update `CHANGES`.
- [x] ***(SwEng)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(SwEng)*** Update `README.md`.
- [x] ***(SwEng)*** Update `version`.
- [x] ***(SwEng)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that all the above steps were performed correctly.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(SwEng)*** Tag the releases[^2]. (Tags may only be pushed to the public repository for releases which are *not* security releases.)
- [x] ***(SwEng)*** If this is the first tag for a release (e.g. beta), create a release branch named `release_v9_X_Y` to allow development to continue on the maintenance branch whilst release engineering continues.
### 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)*** 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] ***(SwEng)*** 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] ***(SwEng)*** Push tags for the published releases to the public repository.
- [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)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: Preferred command line: `git tag -u <DEVELOPER_KEYID> -a -s -m "BIND 9.X.Y[alphatag]" v9_X_Y[alphatag]`, where `[alphatag]` is an optional string such as `b1`, `rc1`, etc.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Michael McNallyMichael McNally2020-07-15https://gitlab.isc.org/isc-projects/bind9/-/issues/1954Recursive queries are sent to roots when a root zone is defined2020-06-19T01:20:46ZMatt CoralloRecursive queries are sent to roots when a root zone is definedFreeBSD's BIND config suggests caching the root zone locally by AXFR'ing from ICANN (https://svnweb.freebsd.org/ports/head/dns/bind916/files/named.conf.in?revision=526548&view=markup#l101) but this doesn't actually appear to be doing wha...FreeBSD's BIND config suggests caching the root zone locally by AXFR'ing from ICANN (https://svnweb.freebsd.org/ports/head/dns/bind916/files/named.conf.in?revision=526548&view=markup#l101) but this doesn't actually appear to be doing what they expect. With the same snippet in my config (tested on both 9.16.3-Debian and 9.11.5-P4-5.1+deb10u1-Debian), I see delays querying for roots.
```
root@sfo-router:/etc/bind# rndc flush
root@sfo-router:/etc/bind# dig @localhost mx. ns
; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> @localhost mx. ns
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37308
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
; COOKIE: 17a4fb0d408598d6010000005eec09496e5246607410e24e (good)
;; QUESTION SECTION:
;mx. IN NS
;; ANSWER SECTION:
mx. 86400 IN NS i.mx-ns.mx.
mx. 86400 IN NS e.mx-ns.mx.
mx. 86400 IN NS o.mx-ns.mx.
mx. 86400 IN NS x.mx-ns.mx.
mx. 86400 IN NS c.mx-ns.mx.
mx. 86400 IN NS m.mx-ns.mx.
;; Query time: 235 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Jun 18 17:39:37 PDT 2020
;; MSG SIZE rcvd: 163
root@sfo-router:/etc/bind# dig @localhost mx. ns
; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> @localhost mx. ns
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43887
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
; COOKIE: 968a02a271ff4861010000005eec094aaea36118ea3c1275 (good)
;; QUESTION SECTION:
;mx. IN NS
;; ANSWER SECTION:
mx. 86399 IN NS i.mx-ns.mx.
mx. 86399 IN NS e.mx-ns.mx.
mx. 86399 IN NS o.mx-ns.mx.
mx. 86399 IN NS x.mx-ns.mx.
mx. 86399 IN NS c.mx-ns.mx.
mx. 86399 IN NS m.mx-ns.mx.
;; Query time: 1 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Jun 18 17:39:38 PDT 2020
;; MSG SIZE rcvd: 163
```https://gitlab.isc.org/isc-projects/bind9/-/issues/1955${LMDB_CFLAGS} missing from DNS_INCLUDES in make/includes.in2020-06-29T13:19:54ZMark Andrews${LMDB_CFLAGS} missing from DNS_INCLUDES in make/includes.inIn 9.16.4 named doesn't compile as lmdb.h is not found when lmdb is installed in a non standard place.In 9.16.4 named doesn't compile as lmdb.h is not found when lmdb is installed in a non standard place.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/19569.16.3 segmentation fault2020-07-22T15:40:41Znanwn147929@alibaba-inc.com9.16.3 segmentation fault<!--
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-9.16.3 terminated with signal 11, Segmentation fault.
### BIND version used
```
BIND 9.16.3-RedHat-9.16.3-20200604153203.alios6 (Stable Release) <id:5ea41c1>
running on Linux x86_64 2.6.32-220.23.2.ali878.el6.x86_64 #1 SMP Mon Jan 28 17:12:52 CST 2013
built by make with '--build=x86_64-unknown-linux-gnu' '--host=x86_64-unknown-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-epoll' '--with-tuning=large' '--with-pic' '--with-python=/home/tops/bin/python2.7' '--with-python-install-dir=/home/tops' '--disable-geoip' '--enable-auto-validation=no' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--disable-shared' 'LIBUV_CFLAGS=-I/home/admin/145_20200603144849066_144601007_code/rpm_workspace/rpm/.dep_create/include' 'LIBUV_LIBS=-L/home/admin/145_20200603144849066_144601007_code/rpm_workspace/rpm/.dep_create/lib -luv -lrt -lpthread -lnsl -ldl' 'build_alias=x86_64-unknown-linux-gnu' 'host_alias=x86_64-unknown-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS= -DDIG_SIGCHASE' 'PKG_CONFIG_PATH=/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 4.4.6 20110731 (Red Hat 4.4.6-3)
compiled with OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
linked to OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
compiled with libxml2 version: 2.7.6
linked to libxml2 version: 20706
compiled with zlib version: 1.2.3
linked to zlib version: 1.2.3
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Not sure, some TCP flows cause the issue.
### What is the current *bug* behavior?
BIND crashes.
### What is the expected *correct* behavior?
Not crash.
### 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
```
Core was generated by `/usr/sbin/named -u named -t /var/named/chroot'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000000000655f9d in isc__nm_tcpdns_send ()
Missing separate debuginfos, use: debuginfo-install bind911-9.16.3-20200604153203.alios6.x86_64
(gdb) bt
#0 0x0000000000655f9d in isc__nm_tcpdns_send ()
#1 0x00000000004788be in client_sendpkg ()
#2 0x000000000047a26d in ns_client_send ()
#3 0x000000000047a5cf in ns_client_error ()
#4 0x000000000048a0b1 in query_error ()
#5 0x000000000049286f in ns_query_done ()
#6 0x000000000049082b in query_gotanswer ()
#7 0x000000000049783d in fetch_callback ()
#8 0x0000000000662f81 in run ()
#9 0x00007f115cad4aa1 in start_thread () from /lib64/libpthread.so.0
#10 0x00007f115c40493d in clone () from /lib64/libc.so.6
```
### Possible fixes
```
t->region = (isc_region_t){ .base = isc_mem_get(t->mctx,
region->length + 2),
.length = region->length + 2 };
*(uint16_t *)t->region.base = htons(region->length);
memmove(t->region.base + 2, region->base, region->length);
```
I guess t->region needs overflow check?https://gitlab.isc.org/isc-projects/bind9/-/issues/1957nxdomain redirect test failed.2020-06-22T08:54:52ZMark Andrewsnxdomain redirect test failed.Job [#964155](https://gitlab.isc.org/isc-projects/bind9/-/jobs/964155) failed for 036cd40b8ca72074cbc0976e8d7db853aaa44e46:
NXDOMAIN redirect failed when zero TTL response arrived just before the second ended.
```
;; Got answer:
;; ->>...Job [#964155](https://gitlab.isc.org/isc-projects/bind9/-/jobs/964155) failed for 036cd40b8ca72074cbc0976e8d7db853aaa44e46:
NXDOMAIN redirect failed when zero TTL response arrived just before the second ended.
```
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42517
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: cab8af39465ee86a010000005eec24b41d4859412f564919 (good)
;; QUESTION SECTION:
;nonexist. IN TXT
;; AUTHORITY SECTION:
. 0 IN SOA a.root-servers.nil. marka.isc.org. 0 0 0 0 0
```
```
19-Jun-2020 02:36:35.996 query client=0x805789f78 thread=0x80140b500 (nonexist/TXT): qctx_init
...
19-Jun-2020 02:36:35.999 resquery 0x8052693d0 (fctx 0x8057f9010(nonexist.redirect/TXT)): response
19-Jun-2020 02:36:35.999 received packet from 10.53.0.3#10800
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24694
;; flags: qr aa; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 1eb8703f482cd718010000005eec24b3c2f6721d1c69fe02
;; QUESTION SECTION:
;nonexist.redirect. IN TXT
;; AUTHORITY SECTION:
;redirect. 0 IN SOA a.root-servers.nil. hostmaster.example.net. (
; 0 ; serial
; 0 ; refresh (0 seconds)
; 0 ; retry (0 seconds)
; 0 ; expire (0 seconds)
; 0 ; minimum (0 seconds)
; )
19-Jun-2020 02:36:35.999 fctx 0x8057f9010(nonexist.redirect/TXT): rctx_answer_none
19-Jun-2020 02:36:36.000 log_ns_ttl: fctx 0x8057f9010: rctx_answer_none: nonexist.redirect (in 'redirect'?): 1 300
19-Jun-2020 02:36:36.000 fctx 0x8057f9010(nonexist.redirect/TXT): ncache_message
19-Jun-2020 02:36:36.000 fctx 0x8057f9010(nonexist.redirect/TXT): clone_results
19-Jun-2020 02:36:36.000 fctx 0x8057f9010(nonexist.redirect/TXT): [result: success] query canceled in response(); responding
19-Jun-2020 02:36:36.000 fctx 0x8057f9010(nonexist.redirect/TXT): cancelquery
19-Jun-2020 02:36:36.000 dispatch 0x80278d600 response 0x804675a40 10.53.0.3#10800: detaching from task 0x8022d0da8
19-Jun-2020 02:36:36.000 dispatch 0x80278d600: detach: refcount 1
19-Jun-2020 02:36:36.000 fctx 0x8057f9010(nonexist.redirect/TXT): done
19-Jun-2020 02:36:36.000 fctx 0x8057f9010(nonexist.redirect/TXT): stopqueries
19-Jun-2020 02:36:36.000 fctx 0x8057f9010(nonexist.redirect/TXT): cancelqueries
19-Jun-2020 02:36:36.000 dispatch 0x80278d600: got packet: requests 0, buffers 1, recvs 0
19-Jun-2020 02:36:36.000 fctx 0x8057f9010(nonexist.redirect/TXT): sendevents
19-Jun-2020 02:36:36.000 sockmgr 0x801496ef0 thread 0: watcher got message -5 for socket 512
19-Jun-2020 02:36:36.000 sockmgr 0x801496ef0 thread 0: watcher got message -2 for socket -1
19-Jun-2020 02:36:36.000 query client=0x805789f78 thread=0x80140c900 (nonexist/TXT): fetch_callback
19-Jun-2020 02:36:36.000 query client=0x805789f78 thread=0x80140c900 (nonexist/TXT): qctx_init
19-Jun-2020 02:36:36.000 query client=0x805789f78 thread=0x80140c900 (nonexist/TXT): client attr:0x2303, query attr:0x23703, restarts:0, origqname:nonexist, timer:0, authdb:1, referral:0
19-Jun-2020 02:36:36.000 query client=0x805789f78 thread=0x80140c900 (nonexist/TXT): query_resume
19-Jun-2020 02:36:36.000 query client=0x805789f78 thread=0x80140c900 (nonexist/TXT): resume from redirect recursion
19-Jun-2020 02:36:36.000 query client=0x805789f78 thread=0x80140c900 (nonexist/TXT): redirect qctx->fname:nonexist, qtype:TXT, auth:0
19-Jun-2020 02:36:36.000 query client=0x805789f78 thread=0x80140c900 (nonexist/TXT): query_gotanswer
19-Jun-2020 02:36:36.000 client @0x805789f78 10.53.0.2#44061 (nonexist): rrl=0x0, HAVECOOKIE=0, result=DNS_R_NCACHENXDOMAIN, fname=0x805871f10(1), is_zone=0, RECURSIONOK=1, query.rpz_st=0x0(0), RRL_CHECKED=0
19-Jun-2020 02:36:36.000 query client=0x805789f78 thread=0x80140c900 (nonexist/TXT): query_checkrpz
19-Jun-2020 02:36:36.000 query client=0x805789f78 thread=0x80140c900 (nonexist/TXT): rpz_rewrite
19-Jun-2020 02:36:36.001 query client=0x805789f78 thread=0x80140c900 (nonexist/TXT): query_redirect
19-Jun-2020 02:36:36.001 query client=0x805789f78 thread=0x80140c900 (nonexist/TXT): redirect
19-Jun-2020 02:36:36.001 query client=0x805789f78 thread=0x80140c900 (nonexist/TXT): redirect2
19-Jun-2020 02:36:36.001 query client=0x805789f78 thread=0x80140c900 (nonexist/TXT): query_ncache
19-Jun-2020 02:36:36.001 query client=0x805789f78 thread=0x80140c900 (nonexist/TXT): query_nodata
19-Jun-2020 02:36:36.001 query client=0x805789f78 thread=0x80140c900 (nonexist/TXT): ns_query_done
19-Jun-2020 02:36:36.001 query client=0x805789f78 thread=0x80140c900 (nonexist/TXT): free_devent
```https://gitlab.isc.org/isc-projects/bind9/-/issues/1958support outgoing TCP connections2022-01-26T11:33:41ZEvan Huntsupport outgoing TCP connectionsThe adaptation of `rndc` and other tools to use the netmgr requires it to be able to establish outgoing TCP connections. This will be needed for multiple features in 9.17 and also 9.16 when DoT and DoH are backported.The adaptation of `rndc` and other tools to use the netmgr requires it to be able to establish outgoing TCP connections. This will be needed for multiple features in 9.17 and also 9.16 when DoT and DoH are backported.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1959Segmentation fault in nmsocket_maybe_destroy (sock=0xdededede) at netmgr/netm...2020-07-02T08:55:04ZMichal NowakSegmentation fault in nmsocket_maybe_destroy (sock=0xdededede) at netmgr/netmgr.c:801BIND `5238433f784935cb1c84a9f5dcb32d28f243fb0c` crashes on several system tests (e.g. dnssec, rootkeysentinel, statistics, synthfromdnssec) in `nmsocket_maybe_destroy (sock=0xdededede) at netmgr/netmgr.c:801` on Debian 9 (stretch) with k...BIND `5238433f784935cb1c84a9f5dcb32d28f243fb0c` crashes on several system tests (e.g. dnssec, rootkeysentinel, statistics, synthfromdnssec) in `nmsocket_maybe_destroy (sock=0xdededede) at netmgr/netmgr.c:801` on Debian 9 (stretch) with kernel 4.4.150 on ODROID HC1 single board computer (4x SAMSUNG EXYNOS ARMv7 Processor rev 3 (v7l) 32-bit, 2 GB RAM).
```
[New LWP 19119]
[New LWP 19124]
[New LWP 19117]
[New LWP 19098]
[New LWP 19102]
[New LWP 19123]
[New LWP 19019]
[New LWP 19093]
[New LWP 19105]
[New LWP 19109]
[New LWP 19127]
[New LWP 19129]
[New LWP 19128]
[New LWP 19121]
[New LWP 19122]
[New LWP 19134]
[New LWP 19135]
[New LWP 19138]
[New LWP 19090]
[New LWP 19137]
[New LWP 19131]
[New LWP 19133]
[New LWP 19126]
[New LWP 19112]
[New LWP 19120]
[New LWP 19130]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `/export/data/bind9/bin/named/.libs/lt-named -D dnssec-ns4 -X named.lock -m reco'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 nmsocket_maybe_destroy (sock=0xdededede) at netmgr/netmgr.c:801
801 if (sock->parent != NULL) {
[Current thread is 1 (Thread 0xafe9d380 (LWP 19119))]
Thread 26 (Thread 0xaae93380 (LWP 19130)):
#0 0xb68dabf2 in epoll_wait () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0xb6ebb604 in netthread (uap=0xb2d22eb8) at unix/socket.c:3408
thread = 0xb2d22eb8
manager = <optimized out>
done = false
cc = <optimized out>
strbuf = '\000' <repeats 127 times>
#2 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#3 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 25 (Thread 0xaf69c380 (LWP 19120)):
#0 0xb6942384 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#1 0xb693dcfc in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#2 0xb6eda8f8 in dispatch (threadid=<optimized out>, manager=0xb2d23018) at task.c:1057
No locals.
#3 run (queuep=<optimized out>) at task.c:1344
tq = <optimized out>
manager = 0xb2d23018
threadid = <optimized out>
#4 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#5 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 24 (Thread 0xb0fe0380 (LWP 19112)):
#0 0xb68d81c2 in syscall () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0xb681ef22 in ?? () from /usr/lib/arm-linux-gnueabihf/libuv.so.1
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 23 (Thread 0xace97380 (LWP 19126)):
#0 0xb6942384 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#1 0xb693dcfc in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#2 0xb6eda8f8 in dispatch (threadid=<optimized out>, manager=0xb2d23018) at task.c:1057
No locals.
#3 run (queuep=<optimized out>) at task.c:1344
tq = <optimized out>
manager = 0xb2d23018
threadid = <optimized out>
#4 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#5 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 22 (Thread 0xa9e91380 (LWP 19133)):
#0 0xb68dabf2 in epoll_wait () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0xb6ebb604 in netthread (uap=0xb2d22f18) at unix/socket.c:3408
thread = 0xb2d22f18
manager = <optimized out>
done = false
cc = <optimized out>
strbuf = '\000' <repeats 127 times>
#2 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#3 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 21 (Thread 0xaa692380 (LWP 19131)):
#0 0xb68dabf2 in epoll_wait () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0xb6ebb604 in netthread (uap=0xb2d22ee8) at unix/socket.c:3408
thread = 0xb2d22ee8
manager = <optimized out>
done = false
cc = <optimized out>
strbuf = '\000' <repeats 127 times>
#2 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#3 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 20 (Thread 0xa868e380 (LWP 19137)):
#0 0xb68dabf2 in epoll_wait () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0xb6ebb604 in netthread (uap=0xb2d22fa8) at unix/socket.c:3408
thread = 0xb2d22fa8
manager = <optimized out>
done = false
cc = <optimized out>
strbuf = '\000' <repeats 127 times>
#2 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#3 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 19 (Thread 0xb47ad380 (LWP 19090)):
#0 0xb68d81c2 in syscall () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0xb681ef22 in ?? () from /usr/lib/arm-linux-gnueabihf/libuv.so.1
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 18 (Thread 0xa7e8d380 (LWP 19138)):
#0 0xb68dabf2 in epoll_wait () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0xb6ebb604 in netthread (uap=0xb2d22fd8) at unix/socket.c:3408
thread = 0xb2d22fd8
manager = <optimized out>
done = false
cc = <optimized out>
strbuf = '\000' <repeats 127 times>
#2 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#3 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 17 (Thread 0xa8e8f380 (LWP 19135)):
#0 0xb68dabf2 in epoll_wait () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0xb6ebb604 in netthread (uap=0xb2d22f78) at unix/socket.c:3408
thread = 0xb2d22f78
manager = <optimized out>
done = false
cc = <optimized out>
strbuf = '\000' <repeats 127 times>
#2 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#3 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 16 (Thread 0xa9690380 (LWP 19134)):
#0 0xb68dabf2 in epoll_wait () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0xb6ebb604 in netthread (uap=0xb2d22f48) at unix/socket.c:3408
thread = 0xb2d22f48
manager = <optimized out>
done = false
cc = <optimized out>
strbuf = '\000' <repeats 127 times>
#2 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#3 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 15 (Thread 0xae69a380 (LWP 19122)):
#0 0xb6942384 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#1 0xb693dcfc in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#2 0xb6eda8f8 in dispatch (threadid=<optimized out>, manager=0xb2d23018) at task.c:1057
No locals.
#3 run (queuep=<optimized out>) at task.c:1344
tq = <optimized out>
manager = 0xb2d23018
threadid = <optimized out>
#4 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#5 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 14 (Thread 0xaee9b380 (LWP 19121)):
#0 0xb6942384 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#1 0xb693dcfc in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#2 0xb6eda8f8 in dispatch (threadid=<optimized out>, manager=0xb2d23018) at task.c:1057
No locals.
#3 run (queuep=<optimized out>) at task.c:1344
tq = <optimized out>
manager = 0xb2d23018
threadid = <optimized out>
#4 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#5 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 13 (Thread 0xabe95380 (LWP 19128)):
#0 0xb6942384 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#1 0xb693df86 in pthread_cond_timedwait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#2 0xb6ee0e06 in isc_condition_waituntil (c=c@entry=0xb2d25058, m=m@entry=0xb2d25024, t=t@entry=0xb2d2504c) at pthreads/condition.c:56
presult = <optimized out>
result = <optimized out>
ts = {tv_sec = 1592672884, tv_nsec = 101937582}
strbuf = "dH\257\246-\a춰L髨F\257\246\003\000\001\000\334F\257\246$PҲ{0\355\266\270 W\000<\000\000\000\310L\351\253\363\061\355\266LH\006\000\000\000\000\000|p궀S\351\253'\000\000\000\024\264\356\266RMIT\b\000\000\000\350L髭\356\355\266\360L髛\214\354\266pEP\247\350_\217\264\001\000\000\000أe\247\030M\351\253\000\000\000\000\000\000\000\000\334F\257\246"
#3 0xb6edf182 in run (uap=0xb2d25018) at timer.c:642
manager = 0xb2d25018
now = {seconds = 1592672883, nanoseconds = 301937582}
result = <optimized out>
#4 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#5 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 12 (Thread 0xab694380 (LWP 19129)):
#0 0xb68dabf2 in epoll_wait () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0xb6ebb604 in netthread (uap=0xb2d22e88) at unix/socket.c:3408
thread = 0xb2d22e88
manager = <optimized out>
done = false
cc = <optimized out>
strbuf = '\000' <repeats 127 times>
#2 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#3 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 11 (Thread 0xac696380 (LWP 19127)):
#0 0xb6942384 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#1 0xb693dcfc in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#2 0xb6eda8f8 in dispatch (threadid=<optimized out>, manager=0xb2d23018) at task.c:1057
No locals.
#3 run (queuep=<optimized out>) at task.c:1344
tq = <optimized out>
manager = 0xb2d23018
threadid = <optimized out>
#4 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#5 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 10 (Thread 0xb1922380 (LWP 19109)):
#0 0xb68d81c2 in syscall () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0xb681ef22 in ?? () from /usr/lib/arm-linux-gnueabihf/libuv.so.1
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 9 (Thread 0xb2264380 (LWP 19105)):
#0 0xb68d81c2 in syscall () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0xb681ef22 in ?? () from /usr/lib/arm-linux-gnueabihf/libuv.so.1
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 8 (Thread 0xb3e6b380 (LWP 19093)):
#0 0xb68d81c2 in syscall () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0xb681ef22 in ?? () from /usr/lib/arm-linux-gnueabihf/libuv.so.1
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 7 (Thread 0xb4932db0 (LWP 19019)):
#0 0xb6942386 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#1 0xb69412ae in do_sigwait () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#2 0xb694130a in sigwait () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#3 0xb6ec3806 in isc_app_ctxrun (ctx=ctx@entry=0xb6f062f8 <isc_g_appctx>) at app.c:312
sset = {__val = {16387, 0 <repeats 31 times>}}
sig = 1543
event = 0x0
next_event = <optimized out>
task = 0x0
#4 0xb6ec394e in isc_app_run () at app.c:365
result = <optimized out>
#5 0x00509ef0 in main (argc=<optimized out>, argv=0xbedb4ee4) at main.c:1524
result = <optimized out>
Thread 6 (Thread 0xade99380 (LWP 19123)):
#0 0xb6942384 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#1 0xb693dcfc in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#2 0xb6eda8f8 in dispatch (threadid=<optimized out>, manager=0xb2d23018) at task.c:1057
No locals.
#3 run (queuep=<optimized out>) at task.c:1344
tq = <optimized out>
manager = 0xb2d23018
threadid = <optimized out>
#4 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#5 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 5 (Thread 0xb2ba6380 (LWP 19102)):
#0 0xb68d81c2 in syscall () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0xb681ef22 in ?? () from /usr/lib/arm-linux-gnueabihf/libuv.so.1
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 4 (Thread 0xb3529380 (LWP 19098)):
#0 0xb68d81c2 in syscall () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0xb681ef22 in ?? () from /usr/lib/arm-linux-gnueabihf/libuv.so.1
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 3 (Thread 0xb069e380 (LWP 19117)):
#0 0xb68d81c2 in syscall () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
#1 0xb681ef22 in ?? () from /usr/lib/arm-linux-gnueabihf/libuv.so.1
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 2 (Thread 0xad698380 (LWP 19124)):
#0 0xb6942384 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#1 0xb693dcfc in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#2 0xb6eda8f8 in dispatch (threadid=<optimized out>, manager=0xb2d23018) at task.c:1057
No locals.
#3 run (queuep=<optimized out>) at task.c:1344
tq = <optimized out>
manager = 0xb2d23018
threadid = <optimized out>
#4 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#5 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 1 (Thread 0xafe9d380 (LWP 19119)):
#0 nmsocket_maybe_destroy (sock=0xdededede) at netmgr/netmgr.c:801
active_handles = <optimized out>
destroy = false
#1 0xb6eb1da4 in nmsocket_maybe_destroy (sock=sock@entry=0xa768ab58) at netmgr/netmgr.c:807
active_handles = <optimized out>
destroy = false
#2 0xb6eb1f6e in isc__nmsocket_prep_destroy (sock=0xa768ab58) at netmgr/netmgr.c:883
No locals.
#3 0xb6eb2032 in isc__nmsocket_detach (sockp=sockp@entry=0xafe9accc) at netmgr/netmgr.c:906
sock = <optimized out>
rsock = <optimized out>
#4 0xb6eb226a in isc_nmhandle_unref (handle=<optimized out>) at netmgr/netmgr.c:1212
sock = 0x0
#5 0xb6cfff44 in fetch_callback (task=<optimized out>, event=<optimized out>) at query.c:5742
devent = 0xa6961018
fetch = 0x0
client = 0xa5603420
fetch_canceled = <optimized out>
client_shuttingdown = <optimized out>
errorloglevel = <optimized out>
#6 0xb6edadbc in dispatch (threadid=<optimized out>, manager=0xb2d23018) at task.c:1152
dispatch_count = 2951336832
done = false
finished = false
requeue = false
event = 0xa6961018
#7 run (queuep=<optimized out>) at task.c:1344
tq = <optimized out>
manager = 0xb2d23018
threadid = <optimized out>
#8 0xb69395d8 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
No symbol table info available.
#9 0xb68da6fa in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
```July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/1960named crashed in isc__nm_tcp_send() on OpenIndiana2020-06-22T08:55:41ZMichal Nowaknamed crashed in isc__nm_tcp_send() on OpenIndianaBIND 9.16.4 crashed during recursive stress test on [OpenIndiana](https://en.wikipedia.org/wiki/OpenIndiana) 2020.04 (`illumos-6682e4c38c`) after 6 hours.
MDB backtrace:
```
> ::status
debugging core file of named (64-bit) from assam
fi...BIND 9.16.4 crashed during recursive stress test on [OpenIndiana](https://en.wikipedia.org/wiki/OpenIndiana) 2020.04 (`illumos-6682e4c38c`) after 6 hours.
MDB backtrace:
```
> ::status
debugging core file of named (64-bit) from assam
file: /usr/sbin/named
initial argv: /usr/sbin/named -g -c ./recursive.conf
threading model: native threads
status: process terminated by SIGSEGV (Segmentation Fault), addr=8
> $C
fffffc7fed9f43b0 libisc.so.1603.1.0`isc__nm_tcp_send+0x15()
fffffc7fed9f43d0 libns.so.1603.0.1`client_sendpkg.isra.0+0x2b()
fffffc7fed9f5410 libns.so.1603.0.1`ns_client_send+0x598()
fffffc7fed9f5970 libns.so.1603.0.1`ns_client_error+0x1a8()
fffffc7fed9f59a0 libns.so.1603.0.1`query_error+0xd1()
fffffc7fed9f5f30 libns.so.1603.0.1`fetch_callback+0x3b5()
fffffc7fed9f5fb0 libisc.so.1603.1.0`run+0x6c6()
fffffc7fed9f5fe0 libc.so.1`_thrp_setup+0x6c(fffffc7fee803a80)
fffffc7fed9f5ff0 libc.so.1`_lwp_start()
```
GDB backtrace: [named_recursive_8h_core_GDB.txt](/uploads/6fe89546b05ee5202e0cdf27cd3afc0a/named_recursive_8h_core_GDB.txt).
There seems to be a slight spike in RSS usage before the crash:
```
VSZ RSS
2020-06-22:04:28:36 2082616 2057748
2020-06-22:04:29:08 2082616 2063540
```
![named-memory-use-graph_OpenIndiana_9.16.4_recursive_8h](/uploads/0e82a998715893cba5601b61393739da/named-memory-use-graph_OpenIndiana_9.16.4_recursive_8h.png)
`named` log: [named.run.gz](/uploads/0d1bd42f7ab243f35c828ba243fd7245/named.run.gz)BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1613Signal DS submitting via rndc2020-08-31T12:08:46ZMatthijs Mekkingmatthijs@isc.orgSignal DS submitting via rndcWe need a way, via rndc or some other command, to signal that we have submitted the DS.We need a way, via rndc or some other command, to signal that we have submitted the DS.September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1962Integrate GitHub's super-linter image with CI2021-10-18T07:48:19ZMichal NowakIntegrate GitHub's super-linter image with CIRecently GitHub [introduced](https://github.blog/2020-06-18-introducing-github-super-linter-one-linter-to-rule-them-all/) [Super Linter](https://github.com/github/super-linter), a Docker image which provides an easy way to lint various s...Recently GitHub [introduced](https://github.blog/2020-06-18-introducing-github-super-linter-one-linter-to-rule-them-all/) [Super Linter](https://github.com/github/super-linter), a Docker image which provides an easy way to lint various source files.
`sudo docker run -e RUN_LOCAL=true -v $PWD:/tmp/lint github/super-linter`:
```
The script has completed
ERRORS FOUND in MARKDOWN:[16]
ERRORS FOUND in BASH:[373]
ERRORS FOUND in PERL:[44]
ERRORS FOUND in PYTHON:[12]
Exiting with errors found!
```
Given that how easy is to use it in GitHub Action it may become very popular for upstream projects and sideline linter versions distributed with the OS.
On the pro side it would help us not to care about updating our linters and go with whatever Super Linter provides.
On the con side it may not be ideal for outside GitHub use.BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1963journal file corrupt: expected serial N, got M2021-03-16T23:18:39ZTony Finchjournal file corrupt: expected serial N, got MOn my R&D box, running latest main (9.17.2 plus patches) I'm seeing several cases of this error message, for a number of different kinds of zone:
```
2020-06-22.02:29:17.494 general: error: auth.mkeys.jnl: journal file corrupt: expected...On my R&D box, running latest main (9.17.2 plus patches) I'm seeing several cases of this error message, for a number of different kinds of zone:
```
2020-06-22.02:29:17.494 general: error: auth.mkeys.jnl: journal file corrupt: expected serial 859, got 860
2020-06-22.02:34:21.396 general: error: ../u/z/dotat.at.jnl: journal file corrupt: expected serial 26317, got 26318
2020-06-22.02:37:46.170 general: error: ../zone/__catz__auth_catz.arpa.cam.ac.uk_in-addr.arpa.cam.ac.uk.db.jnl: journal file corrupt: expected serial 1592610406, got 1592614189
```
i.e. for the trust anchors, for primary zones, and secondary zones (most secondaries on this box are configured with catz). Multiple primary and secondary zones are affected. This started after I (belatedly) upgraded from 9.17.0 to 9.17.2 yesterday.
The delta is 1 for all the mkeys and primary zones, usually (but not always) larger for secondary zones.
edited to add: also the primary zones have `auto-dnssec maintain` but are not inline-signed.https://gitlab.isc.org/isc-projects/bind9/-/issues/1965bin/named/unix/os.c warning: '%s' directive output may be truncated on OpenIn...2020-06-29T13:40:19ZMichal Nowakbin/named/unix/os.c warning: '%s' directive output may be truncated on OpenIndianaBIND 9.16.4 compilation with GCC 7.5 on OpenIndiana 2020.04 (`illumos-6682e4c38c`) emitted warning in `bin/named/unix/os.c`:
```
libtool: compile: /usr/gcc/7/bin/gcc -include /export/home/newman/oi-userland/components/network/bind/build...BIND 9.16.4 compilation with GCC 7.5 on OpenIndiana 2020.04 (`illumos-6682e4c38c`) emitted warning in `bin/named/unix/os.c`:
```
libtool: compile: /usr/gcc/7/bin/gcc -include /export/home/newman/oi-userland/components/network/bind/build/amd64/config.h -I/export/home/newman/oi-userland/components/network/bind/build/amd64 -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4 -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/bin/named/unix/include -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/bin/named/unix/../include -I/export/home/newman/oi-userland/components/network/bind/build/amd64/lib/isccfg/include -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/lib/isccfg/include -I/export/home/newman/oi-userland/components/network/bind/build/amd64/lib/isccc/include -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/lib/isccc/include -I/export/home/newman/oi-userland/components/network/bind/build/amd64/lib/dns/include -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/lib/dns/include -I/export/home/newman/oi-userland/components/network/bind/build/amd64/lib/isc/include -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/lib/isc -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/lib/isc/include -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/lib/isc/unix/include -I/export/home/newman/oi-userland/components/network/bind/bind-9.16.4/lib/isc/pthreads/include -m64 -O3 -D_XOPEN_SOURCE=600 -D__EXTENSIONS__=1 -D_XPG6 -D_POSIX_PTHREAD_SEMANTICS -pthread -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers -fno-strict-aliasing -c os.c -fPIC -DPIC -o .libs/os.o
os.c: In function 'getuname':
os.c:920:49: warning: '%s' directive output may be truncated writing up to 256 bytes into a region of size between 253 and 1021 [-Wformat-truncation=]
snprintf(unamebuf, sizeof(unamebuf), "%s %s %s %s", uts.sysname,
^~
uts.machine, uts.release, uts.version);
~~~
os.c:920:2: note: 'snprintf' output between 4 and 1028 bytes into a destination of size 1024
snprintf(unamebuf, sizeof(unamebuf), "%s %s %s %s", uts.sysname,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
uts.machine, uts.release, uts.version);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
illumos [snprintf(3c)](https://illumos.org/man/3c/snprintf).July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/1966BIND-9.16.3 name.c:1738: INSIST(nlabels == name->labels) failed2020-06-23T05:19:55Znanwn147929@alibaba-inc.comBIND-9.16.3 name.c:1738: INSIST(nlabels == name->labels) failed### Summary
BIND assertion failed and quit.
### BIND version used
```
BIND 9.16.3-RedHat-9.16.3-20200604153203.alios7 (Stable Release) <id:5ea41c1>
running on Linux x86_64 3.10.0-327.ali2012.alios7.x86_64 #1 SMP Mon Oct 9 14:09:14 CS...### Summary
BIND assertion failed and quit.
### BIND version used
```
BIND 9.16.3-RedHat-9.16.3-20200604153203.alios7 (Stable Release) <id:5ea41c1>
running on Linux x86_64 3.10.0-327.ali2012.alios7.x86_64 #1 SMP Mon Oct 9 14:09:14 CST 2017
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-epoll' '--with-tuning=large' '--with-pic' '--with-python=/home/tops/bin/python2.7' '--with-python-install-dir=/home/tops' '--disable-geoip' '--enable-auto-validation=no' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--disable-shared' 'LIBUV_CFLAGS=-I/home/admin/162_20200603144848514_144601008_code/rpm_workspace/rpm/.dep_create/include' 'LIBUV_LIBS=-L/home/admin/162_20200603144848514_144601008_code/rpm_workspace/rpm/.dep_create/lib -luv -lrt -lpthread -lnsl -ldl' '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 ' 'CPPFLAGS= -DDIG_SIGCHASE' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-4)
compiled with OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
linked to OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
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: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Unknown
### What is the current *bug* behavior?
BIND quit due to assertion failed.
### What is the expected *correct* behavior?
Not quit.
### 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
```
23-Jun-2020 10:02:34.155 general: name.c:1738: INSIST(nlabels == name->labels) failed
23-Jun-2020 10:02:34.155 general: exiting (due to assertion failure)
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/bind9/-/issues/1967named may generate broken glueless referrals when reaching UDP packet size limit2022-09-22T12:24:31ZMichał Kępieńnamed may generate broken glueless referrals when reaching UDP packet size limit`named` unconditionally [ignores][1] the `ISC_R_NOSPACE` result code
when rendering the ADDITIONAL section of a response message. This is
usually fine, but there is an edge case which breaks with this
behavior: for delegations which onl...`named` unconditionally [ignores][1] the `ISC_R_NOSPACE` result code
when rendering the ADDITIONAL section of a response message. This is
usually fine, but there is an edge case which breaks with this
behavior: for delegations which only have in-bailiwick name servers
defined for the child zone, a referral must include glue records;
meanwhile, `named` may not include any glue records in a referral if its
size is close to the UDP packet size limit.
While I have not proved this in practice, I believe BIND has been
behaving this way since version 9.0.0. The issue affects all referrals,
both signed and unsigned, including those served by root servers: I came
across this problem by analyzing traffic patterns on my home resolver.
I believe that in extreme cases, this issue may cause resolution
failures for the delegated domain.
Given enough retries (due to load balancing), it should be possible to
reproduce this problem with:
```
$ dig @k.root-servers.net. _.dk. A +norec +dnssec +bufsize=512 +ignore +nsid
; <<>> DiG 9.17.2 <<>> @k.root-servers.net. _.dk. A +norec +dnssec +bufsize=512 +ignore +nsid
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10102
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; NSID: 6e 73 31 2e 64 65 2d 66 72 61 2e 6b 2e 72 69 70 65 2e 6e 65 74 ("ns1.de-fra.k.ripe.net")
;; QUESTION SECTION:
;_.dk. IN A
;; AUTHORITY SECTION:
dk. 172800 IN NS b.nic.dk.
dk. 172800 IN NS l.nic.dk.
dk. 172800 IN NS p.nic.dk.
dk. 172800 IN NS s.nic.dk.
dk. 172800 IN NS a.nic.dk.
dk. 172800 IN NS d.nic.dk.
dk. 172800 IN NS c.nic.dk.
dk. 86400 IN DS 9280 13 2 3A93091A1A8A850E72A86DDAD3C79B2E3D426CC275BC11980E85C0AC 2854612B
dk. 86400 IN RRSIG DS 8 1 86400 20200706050000 20200623040000 48903 . AKrl/m0EtfPo4IbY0oJLNkCh/H0ZzFeEEl7SrgQOoKQ7uxj1rYsb5vy7 w7J+kRjq0Ll4LTt92DtkJS6OqcXZguv0sQFnEOw5tkmTvjNXJZSsjk6u c/jPrfDlVaT9glKeGGjcFpSnDfSkUv7gsR5S91Ovk6RX1ZfKKzlydebC /ci+qAcaxnJtFDiSa7RR7jReoGkeR8FFo0onjsO/RRcUKxvBjO7aRWNh k/1dD8VSGBro/8LEaPuTYMxRnbTSvBxqO+IY1JhcbCoZYRMRCvFqPm1j 3zh025e+vDjQsA86YeahM/lr2mSgNXkNO87BEYPPVo73eA+9ANoPEcle vnhEtA==
;; Query time: 23 msec
;; SERVER: 2001:7fd::1#53(2001:7fd::1)
;; WHEN: Tue Jun 23 11:19:28 CEST 2020
;; MSG SIZE rcvd: 511
```
This issue is similar in spirit to the [F-Root incident][2] which
happened earlier this year.
If my findings are correct, I think the fix for this bug needs a release
note.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/e8fa9986bd3bc6fdb7d40b60ecebfdcafbabea4c/lib/ns/client.c#L541-543
[2]: https://www.isc.org/docs/f-root/incident-2020-01.pdfOctober 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1968Again: BIND | rbtdb.c:2162: INSIST with bind with 9.11.20 (see #1718)2020-07-02T09:33:14ZHolger WirtzAgain: BIND | rbtdb.c:2162: INSIST with bind with 9.11.20 (see #1718)<!--
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
Same problem as #1718, but this time after several hours on two of our three slave servers at the same time:
Sudden crash of the named process.
### BIND version used
```
BIND 9.11.20 (Extended Support Version) <id:f3d1d66>
running on Linux x86_64 3.16.0-10-amd64 #1 SMP Debian 3.16.81-1 (2020-01-17)
built by make with '--prefix=/usr' '--mandir=/usr/share/man' '--libdir=/usr/lib/x86_64-linux-gnu' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--enable-ipv6' '--enable-filter-aaaa' '--with-make-clean'
compiled by GCC 4.9.2
compiled with OpenSSL version: OpenSSL 1.0.1t 3 May 2016
linked to OpenSSL version: OpenSSL 1.0.1t 3 May 2016
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with libjson-c version: 0.11.99
linked to libjson-c version: 0.11.99
compiled with zlib version: 1.2.8
linked to zlib version: 1.2.8
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
```
### Steps to reproduce
```
# Created bind as usual:
VERSION=9.11.20
wget -O bind-$(VERSION).tar.gz https://downloads.isc.org/isc/bind9/$(VERSION)/bind-$(VERSION).tar.gz
wget -O bind-$(VERSION).tar.gz.sha512.asc https://downloads.isc.org/isc/bind9/$(VERSION) /bind-$(VERSION).tar.gz.sha512.asc
gpg --verify bind-$(VERSION).tar.gz.sha512.asc bind-$(VERSION).tar.gz
tar -zxf bind-$(VERSION).tar.gz
bind-$(VERSION)
./configure --prefix=/usr \
--mandir=\$${prefix}/share/man \
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
--infodir=\$${prefix}/share/info \
--sysconfdir=/etc/bind \
--with-python=python3 \
--localstatedir=/ \
--enable-threads \
--enable-largefile \
--with-libtool \
--enable-shared \
--enable-static \
--with-openssl=/usr \
--with-gssapi=/usr \
--with-gnu-ld \
--enable-ipv6 \
--enable-filter-aaaa
make && make install
```
### What is the current *bug* behavior?
After several hours, bind crashes with the following message in general.log:
```
23-Jun-2020 14:25:01.251 general: rbtdb.c:2162: INSIST(((unsigned int)(isc_atomic_xadd(&(&(node)->references)->refs, 0))) == 0 && node->data == ((void *)0)) failed, back trace
23-Jun-2020 14:25:01.251 general: #0 0x43fe6d in ??
23-Jun-2020 14:25:01.251 general: #1 0x7f382e8ffcfa in ??
23-Jun-2020 14:25:01.251 general: #2 0x7f382fbc73ed in ??
23-Jun-2020 14:25:01.251 general: #3 0x7f382fbc776c in ??
23-Jun-2020 14:25:01.251 general: #4 0x7f382e929a17 in ??
23-Jun-2020 14:25:01.251 general: #5 0x7f382daaa064 in ??
23-Jun-2020 14:25:01.251 general: #6 0x7f382d47862d in ??
23-Jun-2020 14:25:01.251 general: exiting (due to assertion failure)
```
The same (at the same time!) happens on the other dns-slave server:
```
23-Jun-2020 14:25:01.594 general: rbtdb.c:2162: INSIST(((unsigned int)(isc_atomic_xadd(&(&(node)->references)->refs, 0))) == 0 && node->data == ((void *)0)) failed, back trace
23-Jun-2020 14:25:01.594 general: #0 0x43fe6d in ??
23-Jun-2020 14:25:01.594 general: #1 0x7f19743eacfa in ??
23-Jun-2020 14:25:01.594 general: #2 0x7f19756b23ed in ??
23-Jun-2020 14:25:01.594 general: #3 0x7f19756b276c in ??
23-Jun-2020 14:25:01.594 general: #4 0x7f1974414a17 in ??
23-Jun-2020 14:25:01.594 general: #5 0x7f1973595064 in ??
23-Jun-2020 14:25:01.594 general: #6 0x7f1972f6362d in ??
23-Jun-2020 14:25:01.594 general: exiting (due to assertion failure)
```
### What is the expected *correct* behavior?
No crash.
### Relevant configuration files
named.conf:
```
include "/etc/bind/named.conf.local"; // only ACLs, logging and statistic channels
include "/etc/bind/named.conf.options"; // look down
include "/etc/bind/bind.keys";
include "/etc/bind/named.conf.namedboot";
include "/etc/bind/tsig.key";
```
named.options:
```
options {
directory "/var/cache/bind";
pid-file "/var/run/named/named.pid";
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { ::1; ********; };
listen-on { 127.0.0.1; *********; };
allow-query { any; };
allow-transfer { ******; };
recursion no;
version "0";
dnssec-enable yes;
dnssec-validation yes;
tcp-clients 1500;
rate-limit {
responses-per-second 50;
};
};
controls {
inet 127.0.0.1 allow { 127.0.0.1; ::1; };
};
```
### Relevant logs and/or screenshots
general.log:
```
23-Jun-2020 14:25:01.251 general: rbtdb.c:2162: INSIST(((unsigned int)(isc_atomic_xadd(&(&(node)->references)->refs, 0))) == 0 && node->data == ((void *)0)) failed, back trace
23-Jun-2020 14:25:01.251 general: #0 0x43fe6d in ??
23-Jun-2020 14:25:01.251 general: #1 0x7f382e8ffcfa in ??
23-Jun-2020 14:25:01.251 general: #2 0x7f382fbc73ed in ??
23-Jun-2020 14:25:01.251 general: #3 0x7f382fbc776c in ??
23-Jun-2020 14:25:01.251 general: #4 0x7f382e929a17 in ??
23-Jun-2020 14:25:01.251 general: #5 0x7f382daaa064 in ??
23-Jun-2020 14:25:01.251 general: #6 0x7f382d47862d in ??
23-Jun-2020 14:25:01.251 general: exiting (due to assertion failure)
```
### Possible fixes
-July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1969Silence CPPCHECK warnings2020-12-17T13:20:36ZMark AndrewsSilence CPPCHECK warningsJob [#972939](https://gitlab.isc.org/isc-projects/bind9/-/jobs/972939) failed for e82527727c42f9bb3e3a6c4f5b2dfd7a13a67c4c:
https://isc-projects.isc-pag.es/-/bind9/-/jobs/972939/artifacts/cppcheck_html/index.html
These appear to be fal...Job [#972939](https://gitlab.isc.org/isc-projects/bind9/-/jobs/972939) failed for e82527727c42f9bb3e3a6c4f5b2dfd7a13a67c4c:
https://isc-projects.isc-pag.es/-/bind9/-/jobs/972939/artifacts/cppcheck_html/index.html
These appear to be false positives with the exception of a now redundant NULL check in update.cJuly 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1970configure REQUIRES --enable-static=no to be SPECIFIED on the command line.2020-06-29T13:39:00ZMark Andrewsconfigure REQUIRES --enable-static=no to be SPECIFIED on the command line.You can't just type ./configure and have it work.You can't just type ./configure and have it work.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/19719.16.3 segmentation fault2020-07-22T15:40:10Znanwn147929@alibaba-inc.com9.16.3 segmentation fault### Summary
BIND-9.16.3 terminated with signal 11, Segmentation fault. It is similar to \#1947 but not sure whether it is duplicated.
### BIND version used
```
BIND 9.16.3-RedHat-9.16.3-20200604153203.alios6 (Stable Release) <id:5ea41c...### Summary
BIND-9.16.3 terminated with signal 11, Segmentation fault. It is similar to \#1947 but not sure whether it is duplicated.
### BIND version used
```
BIND 9.16.3-RedHat-9.16.3-20200604153203.alios6 (Stable Release) <id:5ea41c1>
running on Linux x86_64 2.6.32-220.23.2.ali878.el6.x86_64 #1 SMP Mon Jan 28 17:12:52 CST 2013
built by make with '--build=x86_64-unknown-linux-gnu' '--host=x86_64-unknown-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-epoll' '--with-tuning=large' '--with-pic' '--with-python=/home/tops/bin/python2.7' '--with-python-install-dir=/home/tops' '--disable-geoip' '--enable-auto-validation=no' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--disable-shared' 'LIBUV_CFLAGS=-I/home/admin/145_20200603144849066_144601007_code/rpm_workspace/rpm/.dep_create/include' 'LIBUV_LIBS=-L/home/admin/145_20200603144849066_144601007_code/rpm_workspace/rpm/.dep_create/lib -luv -lrt -lpthread -lnsl -ldl' 'build_alias=x86_64-unknown-linux-gnu' 'host_alias=x86_64-unknown-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS= -DDIG_SIGCHASE' 'PKG_CONFIG_PATH=/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 4.4.6 20110731 (Red Hat 4.4.6-3)
compiled with OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
linked to OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
compiled with libxml2 version: 2.7.6
linked to libxml2 version: 20706
compiled with zlib version: 1.2.3
linked to zlib version: 1.2.3
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Unkonw
### What is the current *bug* behavior?
Named crash.
### What is the expected *correct* behavior?
Not crash.
### 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
Named is compiled with -O2 flag, can't have detailed backtrace information with debuginfo package installed.
```
Core was generated by `/usr/sbin/named -u named -t /var/named/chroot'.
Program terminated with signal 11, Segmentation fault.
#0 0x000000000064fec5 in isc_nm_send ()
Missing separate debuginfos, use: debuginfo-install bind911-9.16.3-20200604153203.alios6.x86_64
(gdb) bt
#0 0x000000000064fec5 in isc_nm_send ()
#1 0x00000000004788be in client_sendpkg ()
#2 0x000000000047a26d in ns_client_send ()
#3 0x000000000047a5cf in ns_client_error ()
#4 0x000000000048a0b1 in query_error ()
#5 0x000000000049286f in ns_query_done ()
#6 0x000000000049082b in query_gotanswer ()
#7 0x000000000049783d in fetch_callback ()
#8 0x0000000000662f81 in run ()
#9 0x00007f283a32daa1 in start_thread () from /lib64/libpthread.so.0
#10 0x00007f2839c5d93d in clone () from /lib64/libc.so.6
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/bind9/-/issues/1972named aborted in __GI_sigismember at sigismem.c when SoftHSM not setup2021-10-05T12:42:28ZMichal Nowaknamed aborted in __GI_sigismember at sigismem.c when SoftHSM not setupI work on adding [stress test](https://gitlab.isc.org/isc-private/bind-qa/-/tree/master/bind9/stress) to the CI and I forgot to add [`*setup_softhsm`](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/.gitlab-ci.yml#L247), which setu...I work on adding [stress test](https://gitlab.isc.org/isc-private/bind-qa/-/tree/master/bind9/stress) to the CI and I forgot to add [`*setup_softhsm`](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/.gitlab-ci.yml#L247), which setups SoftHSM slot in the job:
```
.setup_softhsm: &setup_softhsm |
export SLOT=$(sh -x bin/tests/prepare-softhsm2.sh)
test -n "${SLOT}" && test "${SLOT}" -gt 0
```
`named` (`1844b47eb37ea20dd6365db6f7f6e8e1ac7d32e7`) started [crashing](https://gitlab.isc.org/mnowak/bind9/-/jobs/975274) on Fedora 31 with `Aborted (core dumped) $NAMED $COMMAND_SWITCHES -f -c ./named.conf > ./named.run 2>&1` immediately after start, the backtrace is:
```
(gdb) bt
#0 0x00007faeb8f0a625 in __GI_sigismember (set=<optimized out>, set=<optimized out>, signo=-2143708960) at sigismem.c:32
#1 __GI_sigismember (set=0x2, signo=-2143708960) at sigismem.c:24
#2 0x0000000000004003 in ?? ()
#3 0x0000000000000000 in ?? ()
```
Full backtrace: [gdb-full.txt](/uploads/406b6749d970e9323cf3df6168843cf9/gdb-full.txt).
Core: [core.128.gz](/uploads/12ff887f8d33cb015462e3e892d5d121/core.128.gz).
named.conf: [named.conf](/uploads/cc100953547112b2360fa985ad929a56/named.conf)
When I added `*setup_softhsm` `named` stopped crashing.BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1974ThreadSanitizer: data race in dup2020-09-17T07:53:56ZOndřej SurýThreadSanitizer: data race in dup```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 dup <null>
#1 isc_uv_export netmgr/uv-compat.c:162
#2 accept_connection netmgr/tcp.c:882
#3 tcp_connection_cb netmgr/tcp.c:392
...```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 dup <null>
#1 isc_uv_export netmgr/uv-compat.c:162
#2 accept_connection netmgr/tcp.c:882
#3 tcp_connection_cb netmgr/tcp.c:392
#4 uv__server_io <null>
#5 <null> <null>
Previous read of size 8 at 0x000000000001 by thread T2:
#0 epoll_ctl <null>
#1 uv__platform_invalidate_fd <null>
#2 uv_run <null>
#3 <null> <null>
Location is file descriptor 87 created by thread T1 at:
#0 dup <null>
#1 isc_uv_export netmgr/uv-compat.c:162
#2 accept_connection netmgr/tcp.c:882
#3 tcp_connection_cb netmgr/tcp.c:392
#4 uv__server_io <null>
#5 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_nm_start netmgr/netmgr.c:215
#3 create_managers bin/named/main.c:903
#4 setup bin/named/main.c:1217
#5 main bin/named/main.c:1517
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create pthreads/thread.c:73
#2 isc_nm_start netmgr/netmgr.c:215
#3 create_managers bin/named/main.c:903
#4 setup bin/named/main.c:1217
#5 main bin/named/main.c:1517
SUMMARY: ThreadSanitizer: data race in dup
```October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1975host does not report missing records on default lookups2020-12-15T12:38:43ZPetr Menšíkhost does not report missing records on default lookups<!--
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
host does not report missing records, when no type was gived and name does exist, but no queried records exist.
### BIND version used
```
BIND 9.16.4-RedHat-9.16.4-2.fc32 (Stable Release) <id:0849b42>
running on Linux x86_64 5.6.19-300.fc32.x86_64 #1 SMP Wed Jun 17 16:10:48 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-python=/usr/bin/python3' '--with-libtool' '--localstatedir=/var' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--with-maxminddb' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-lmdb=yes' '--without-libjson' '--with-json-c' '--enable-dnstap' '--with-cmocka' '--enable-fixed-rrset' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' 'LT_SYS_LIBRARY_PATH=/usr/lib64:' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 10.1.1 20200507 (Red Hat 10.1.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
compiled with protobuf-c version: 1.3.2
linked to protobuf-c version: 1.3.2
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
host 1.0.0.127.in-addr.arpa
### What is the current *bug* behavior?
Nothing is printed at all. No error, no missing type.
### What is the expected *correct* behavior?
Host should print similar message when type is explicitly given.
1.0.0.127.in-addr.arpa has no A, AAAA nor MX record
### Relevant configuration files
none
### Relevant logs and/or screenshots
```
host 1.0.0.127.in-addr.arpa
host -t mx 1.0.0.127.in-addr.arpa
1.0.0.127.in-addr.arpa has no MX record
```
### Possible fixes
Some counter for summary for one name, when all of them got responses of NOERROR
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bin/dig/host.c#L568
Reported originally on Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1850685January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/1976LMDB 0.9.26 will break "rndc reconfig" (+ other LMDB issues)2020-08-20T19:36:01ZMichał KępieńLMDB 0.9.26 will break "rndc reconfig" (+ other LMDB issues)The way BIND uses LMDB is at odds with what the authors of that library
expect and intend. ~~While I cannot find any mention of that
recommendation in the [docs][1], the LMDB author himself [says][2] that
"you should only ever open an e...The way BIND uses LMDB is at odds with what the authors of that library
expect and intend. ~~While I cannot find any mention of that
recommendation in the [docs][1], the LMDB author himself [says][2] that
"you should only ever open an environment once in any particular
process".~~[^1] BIND calls `mdb_env_open()` and `mdb_env_close()`
[multiple][3] [times][4] within the lifetime of a single process, but
AFAICT, doing that in an "open → close → open → close → ..." type of
sequence works just fine. Unfortunately, BIND does something worse and
it is related to what happens during an `rndc reconfig`: new views are
configured first and only after that happens, the old views get torn
down. For LMDB, this means that we call `mdb_env_open()` for a
previously `mdb_env_open()`ed LMDB environment *from the same process*
and then close the old "instance" of the environment. I am not sure we
ever cared about this a lot because it seemed to Just Work™. It did
[bite us][5] once (see 40a90fbf89738c1aa867a5f09ef7243ef3ae52e4), but we
worked around the problem and moved on.
Still, the [docs][6] clearly state:
> Do not have open an LMDB database twice in the same process at the
> same time.
We are not getting away with it as easily this time around.
In December 2019, the FreeBSD port for LMDB [started using robust
mutexes][7], which FreeBSD started supporting in the 11.0 release. This
broke LMDB-related BIND system tests on FreeBSD. I investigated it and
my conclusion was that the problem was likely caused by some low-level
FreeBSD issue that was over my head. I [reported it][8] and it was
ultimately determined to be an [undefined-behavior-type issue][9] with
what the FreeBSD threading library does when a mutex is unmapped from
memory without being destroyed first. This prompted LMDB maintainers to
merge a [fix][10] which causes LMDB to destroy locktable mutexes when
`mdb_env_close()` is called and the process calling that function is the
only remaining user of the LMDB environment. This change has been
already [applied][11] as a patch to the FreeBSD port of LMDB 0.9.24 and
I fully expect it to be a part of the next LMDB release, i.e. version
0.9.26, as it has also been [merged][12] into the LMDB 0.9 release
branch.
The problem is that the aforementioned fix breaks `rndc reconfig` on
*all* platforms we test on because it breaks the kludge we have been
effectively relying on so far. This is what we do (note that all calls
are for the same LMDB environment on disk, even though the pointers used
below - `envA` and `envB` - are different!):
1. `mdb_env_open(envA)`
2. (`rndc reconfig` is invoked)
3. `mdb_env_open(envB)`
4. `mdb_env_close(envA)`
Since all of this happens within a single process, the `mdb_env_close()`
call from step 4 destroys the locktable mutexes (because it correctly
observes that the current process is the only remaining user of the LMDB
environment at hand), which prevents any subsequent `mdb_txn_begin()`
calls from succeeding. Here is an example system test job which
triggers the problem:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/975003
This problem affects all maintained BIND branches.
The only way I can see to work around the problem yet again without
redesigning the whole thing from the ground up is to employ `MDB_NOLOCK`
and use a mutex for controlling concurrent access to the LMDB database
ourselves. What saves us here is that we already [have][13] a mutex
handy and we can just broaden its scope without bumping the API versions
for our libraries in 9.11. I will submit a merge request implementing
this workaround shortly.
Honestly, though, I am afraid that this will just be another bandaid.
Call me an Eastern European grumbler, but I am not happy with the way
LMDB support has been implemented in BIND. We seem to have [chosen][14]
LMDB because it was apparently performing slightly better than SQLite 3.
The thing is, I do not think our use case needs fast *concurrent* access
to the database; we need something that allows us to add, remove, and
query zone configuration *faster than scanning a flat file sequentially*
(which is what pretty much any sane database should be capable of).
LMDB lives up to its promises about speed, but it comes with a set of
caveats that we need to cater for, which complicates our code given how
BIND works. To make things worse, our implementation of LMDB uses
`#ifdef` guards, which means it shares *some* of the code with the
non-LMDB variant (NZF, a text file), but not *all* of it, which makes
the code harder to follow than it has to be.
Here are some ideas for what we can do in the future to improve the
state of things:
- Rework the LMDB implementation in BIND so that it matches the
intended use of that library. This could be achieved by keeping a
global list of reference-counted LMDB environment objects, each of
which would be associated with a specific view name (not view
instance!). This approach should allow `rndc reconfig` to do
without calling `mdb_env_open()` or `mdb_env_close()`. I think such
a change would be too severe to go into 9.16, though.
- Use a different database that will likely be slower than LMDB, but
might be simpler to use.
- Move LMDB support to a module (easier said than done).
- Drop LMDB support altogether :-)
[1]: http://www.lmdb.tech/doc/group__mdb.html
[2]: https://bugs.openldap.org/show_bug.cgi?id=9278#c4
[3]: https://gitlab.isc.org/isc-projects/bind9/-/blob/bcbc7e2b10f85451466a3cc098f15cddd019ae0f/bin/named/server.c#L12796
[4]: https://gitlab.isc.org/isc-projects/bind9/-/blob/bcbc7e2b10f85451466a3cc098f15cddd019ae0f/lib/dns/view.c#L2135
[5]: https://bugs.isc.org/Ticket/Display.html?id=46556#txn-508940
[6]: http://www.lmdb.tech/doc/index.html
[7]: https://svnweb.freebsd.org/ports?view=revision&revision=519246
[8]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244493
[9]: https://bugs.openldap.org/show_bug.cgi?id=9278#c3
[10]: https://git.openldap.org/openldap/openldap/-/commit/2fd44e325195ae81664eb5dc36e7d265927c5ebc
[11]: https://svnweb.freebsd.org/ports?view=revision&revision=539380
[12]: https://git.openldap.org/openldap/openldap/-/commit/f683ffdc81d0edb20437cb7d655cf15a60e31249
[13]: https://gitlab.isc.org/isc-projects/bind9/-/blob/d35101e4338c3254113b8f51d178ac44170d412f/lib/dns/include/dns/view.h#L227
[14]: https://bugs.isc.org/Ticket/Display.html?id=39837#txn-430786
[^1]: The docs *do* in fact state the same thing, see below.
August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/1977BIND 9.16 triggers build warnings on FreeBSD 11.42020-06-30T10:19:31ZMichał KępieńBIND 9.16 triggers build warnings on FreeBSD 11.4With Clang 10.0.0 on FreeBSD 11.4, compiling `lib/dns/spnego.c` triggers
the following warnings:
spnego.c:361:11: error: converting the result of '<<' to a boolean always evaluates to true [-Werror,-Wtautological-constant-compare]
...With Clang 10.0.0 on FreeBSD 11.4, compiling `lib/dns/spnego.c` triggers
the following warnings:
spnego.c:361:11: error: converting the result of '<<' to a boolean always evaluates to true [-Werror,-Wtautological-constant-compare]
return (GSS_S_DEFECTIVE_TOKEN);
^
/usr/include/gssapi/gssapi.h:423:41: note: expanded from macro 'GSS_S_DEFECTIVE_TOKEN'
#define GSS_S_DEFECTIVE_TOKEN (9ul << GSS_C_ROUTINE_ERROR_OFFSET)
^
spnego.c:366:11: error: converting the result of '<<' to a boolean always evaluates to true [-Werror,-Wtautological-constant-compare]
return (GSS_S_DEFECTIVE_TOKEN);
^
/usr/include/gssapi/gssapi.h:423:41: note: expanded from macro 'GSS_S_DEFECTIVE_TOKEN'
#define GSS_S_DEFECTIVE_TOKEN (9ul << GSS_C_ROUTINE_ERROR_OFFSET)
^
spnego.c:371:12: error: converting the result of '<<' to a boolean always evaluates to true [-Werror,-Wtautological-constant-compare]
return (GSS_S_DEFECTIVE_TOKEN);
^
/usr/include/gssapi/gssapi.h:423:41: note: expanded from macro 'GSS_S_DEFECTIVE_TOKEN'
#define GSS_S_DEFECTIVE_TOKEN (9ul << GSS_C_ROUTINE_ERROR_OFFSET)
^
spnego.c:376:11: error: converting the result of '<<' to a boolean always evaluates to true [-Werror,-Wtautological-constant-compare]
return (GSS_S_DEFECTIVE_TOKEN);
^
/usr/include/gssapi/gssapi.h:423:41: note: expanded from macro 'GSS_S_DEFECTIVE_TOKEN'
#define GSS_S_DEFECTIVE_TOKEN (9ul << GSS_C_ROUTINE_ERROR_OFFSET)
^
spnego.c:380:11: error: converting the result of '<<' to a boolean always evaluates to true [-Werror,-Wtautological-constant-compare]
return (GSS_S_DEFECTIVE_TOKEN);
^
/usr/include/gssapi/gssapi.h:423:41: note: expanded from macro 'GSS_S_DEFECTIVE_TOKEN'
#define GSS_S_DEFECTIVE_TOKEN (9ul << GSS_C_ROUTINE_ERROR_OFFSET)
^
5 errors generated.
For some reason, the `buster` build (which uses Clang 10.0.1) is happy
with this code as it is :shrug:
The prototype of `lib/dns/spnego.c:cmp_gss_type()` was changed back in
b105ccee68ccc3c18e6ea530063b3c8e5a42571c. `v9_11` is not affected
because !546 was not backported. `main` is not affected, either,
because 978c7b2e89aa37a7ddfe2f6b6ba12ce73dd04528 dropped
`lib/dns/spnego.c` altogether.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/1978Cross-compilation doesn’t work in 9.172021-01-07T02:49:43ZOndřej SurýCross-compilation doesn’t work in 9.17The `gen` and `cfg_gen` miss the `BUILD` specification, it’s build with `HOST` cc.The `gen` and `cfg_gen` miss the `BUILD` specification, it’s build with `HOST` cc.January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1979rndc-confgen2020-06-27T18:43:52ZPasan Jayarathnarndc-confgenHI,
I tried to install bind-9.10.1-P2 in Centos7 and when i try to run command "rndc-confgen -b 512", it says "bash: rndc-confgen: command not found"
But when i try install "rndc-confgen" , it says no packages, please help me to fix this...HI,
I tried to install bind-9.10.1-P2 in Centos7 and when i try to run command "rndc-confgen -b 512", it says "bash: rndc-confgen: command not found"
But when i try install "rndc-confgen" , it says no packages, please help me to fix this issue.
Thanks.https://gitlab.isc.org/isc-projects/bind9/-/issues/1980Follow-up from "Fix assertion failure when server is under load and root zone...2021-10-05T12:42:59ZWitold KrecickiFollow-up from "Fix assertion failure when server is under load and root zone is not yet loaded."The following discussion from !3572 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3572#note_135264): (+1 comment)
> I think this might not be the best place to...The following discussion from !3572 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3572#note_135264): (+1 comment)
> I think this might not be the best place to fix this, as we don't know here that the queried zone is a mirror zone. Can't we change the result code in a better place where we know that we hit the mirror zone and thus it's safe to alter the return code?https://gitlab.isc.org/isc-projects/bind9/-/issues/1981Require assertion failure in netmgr.c - REQUIRE((__builtin_expect(!!((handle)...2020-07-03T07:20:19ZMichael McNallyRequire assertion failure in netmgr.c - REQUIRE((__builtin_expect(!!((handle) != ((void*)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H') << 8 | ('D')))), 1)))Submitted to security-officer@isc.org by "Hoyt <xxxxxx>"
Michał thinks it may be a duplicate, but please evaluate (and close with a reference to whatever existing ticket it matches if it *is*.
```
Crash Report Detail: Logging
Mac OS X...Submitted to security-officer@isc.org by "Hoyt <xxxxxx>"
Michał thinks it may be a duplicate, but please evaluate (and close with a reference to whatever existing ticket it matches if it *is*.
```
Crash Report Detail: Logging
Mac OS X 10.15.5 (19F101)
named -v = BIND 9.16.4 (Stable Release) <id:0849b42>
….
DEFAULT.LOG
25-Jun-2020 19:35:40.058 config: info: none:98: 'max-cache-size 90%' - setting to 7372MB (out of 8192MB)
25-Jun-2020 19:35:40.071 general: info: reloading configuration succeeded
25-Jun-2020 19:35:40.076 general: info: reloading zones succeeded
25-Jun-2020 19:35:40.094 general: notice: all zones loaded
25-Jun-2020 19:35:40.094 general: notice: running
25-Jun-2020 19:39:02.188 query-errors: info: client @0x7fc44f8e2568 192.168.1.1#40515 (library-service.live.use1a.on.epicgames.com): query failed (SERVFAIL) for library-service.live.use1a.on.epicgames.com/IN/A at query.c:6896
25-Jun-2020 19:39:17.793 query-errors: info: client @0x7fc44f8e2568 192.168.1.1#30406 (na.api.amazonvideo.com): query failed (SERVFAIL) for na.api.amazonvideo.com/IN/A at query.c:6896
25-Jun-2020 19:40:30.942 network: info: listening on IPv6 interface utun4, fe80::53b4:e342:cbf4:b11d%20#53
25-Jun-2020 19:40:33.693 network: info: listening on IPv6 interface utun5, fe80::3356:1827:5bae:c32b%21#53
25-Jun-2020 20:07:11.971 query-errors: info: client @0x7fc451b4d968 192.168.1.1#18718 (4.0.41.198.in-addr.arpa): query failed (failure) for 4.0.41.198.in-addr.arpa/IN/PTR at query.c:6896
25-Jun-2020 20:14:17.072 general: critical: netmgr.c:1306: REQUIRE((__builtin_expect(!!((handle) != ((void*)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H') << 8 | ('D')))), 1))) failed, back trace
25-Jun-2020 20:14:17.091 general: critical: #0 0x100268c7d in isc_thread_setaffinity()+0x4995d
25-Jun-2020 20:14:17.093 general: critical: #1 0x1004448ca in isc_thread_setaffinity()+0x2255aa
25-Jun-2020 20:14:17.094 general: critical: #2 0x10045b000 in isc_thread_setaffinity()+0x23bce0
25-Jun-2020 20:14:17.094 general: critical: #3 0x10029e00b in isc_thread_setaffinity()+0x7eceb
25-Jun-2020 20:14:17.096 general: critical: #4 0x1002ab4d6 in isc_thread_setaffinity()+0x8c1b6
25-Jun-2020 20:14:17.098 general: critical: #5 0x1002a8ac1 in isc_thread_setaffinity()+0x897a1
25-Jun-2020 20:14:17.099 general: critical: #6 0x1002b18df in isc_thread_setaffinity()+0x925bf
25-Jun-2020 20:14:17.100 general: critical: #7 0x1002acefe in isc_thread_setaffinity()+0x8dbde
25-Jun-2020 20:14:17.101 general: critical: #8 0x1002aa9d2 in isc_thread_setaffinity()+0x8b6b2
25-Jun-2020 20:14:17.101 general: critical: #9 0x100469e6e in isc_thread_setaffinity()+0x24ab4e
25-Jun-2020 20:14:17.102 general: critical: #10 0x7fff6b52b109 in isc_thread_setaffinity()+0x7ffe6b30bde9
25-Jun-2020 20:14:17.103 general: critical: #11 0x7fff6b526b8b in isc_thread_setaffinity()+0x7ffe6b30786b
25-Jun-2020 20:14:17.104 general: critical: exiting (due to assertion failure)
25-Jun-2020 20:19:18.608 zoneload: info: managed-keys-zone: loaded serial 154
25-Jun-2020 20:19:18.636 zoneload: info: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
25-Jun-2020 20:19:18.636 general: warning: stoweaccesscom.zone:1: no TTL specified; using SOA MINTTL instead
…
25-Jun-2020 20:14:01.850 rpz: info: client @0x7fc451b4d968 192.168.1.1#55541 (www.belkin.com): rpz QNAME NXDOMAIN rewrite www.belkin.com/AAAA/IN via www.belkin.com.urlhaus.zone
25-Jun-2020 20:14:01.905 rpz: info: client @0x7fc451b4d968 192.168.1.1#51903 (www.belkin.com): rpz QNAME NXDOMAIN rewrite www.belkin.com/A/IN via www.belkin.com.urlhaus.zone
25-Jun-2020 20:14:02.010 lame-servers: info: host unreachable resolving 'ns-1722.awsdns-23.co.uk/A/IN': 2600:9000:5301:5700::1#53
25-Jun-2020 20:14:02.011 lame-servers: info: host unreachable resolving 'ns-1722.awsdns-23.co.uk/AAAA/IN': 2600:9000:5301:5700::1#53
25-Jun-2020 20:14:02.011 lame-servers: info: host unreachable resolving 'ns-1722.awsdns-23.co.uk/A/IN': 2600:9000:5305:da00::1#53
25-Jun-2020 20:14:02.012 lame-servers: info: host unreachable resolving 'ns-1722.awsdns-23.co.uk/AAAA/IN': 2600:9000:5305:da00::1#53
25-Jun-2020 20:14:02.013 lame-servers: info: host unreachable resolving 'ns-1722.awsdns-23.co.uk/A/IN': 2600:9000:5307:1b00::1#53
25-Jun-2020 20:14:02.013 lame-servers: info: host unreachable resolving 'ns-1722.awsdns-23.co.uk/AAAA/IN': 2600:9000:5307:1b00::1#53
25-Jun-2020 20:14:02.014 lame-servers: info: host unreachable resolving 'ns-1722.awsdns-23.co.uk/A/IN': 2600:9000:5303:9700::1#53
25-Jun-2020 20:14:02.015 lame-servers: info: host unreachable resolving 'ns-1722.awsdns-23.co.uk/AAAA/IN': 2600:9000:5303:9700::1#53
25-Jun-2020 20:14:02.094 lame-servers: info: host unreachable resolving '_.prod.browse.bestbuy.com/A/IN': 2600:9000:5306:ba00::1#53
25-Jun-2020 20:14:02.160 lame-servers: info: host unreachable resolving 'pe-osn-osh-fel-api-elb-xa-967714635.us-east-1.elb.amazonaws.com/AAAA/IN': 2600:9000:5307:100::1#53
25-Jun-2020 20:14:06.858 rpz: info: client @0x7fc44f8c2f68 192.168.1.1#41731 (www.belkin.com): rpz QNAME NXDOMAIN rewrite www.belkin.com/AAAA/IN via www.belkin.com.urlhaus.zone
25-Jun-2020 20:14:06.978 rpz: info: client @0x7fc44f8c2f68 192.168.1.1#8847 (www.belkin.com): rpz QNAME NXDOMAIN rewrite www.belkin.com/A/IN via www.belkin.com.urlhaus.zone
25-Jun-2020 20:14:17.072 general: critical: netmgr.c:1306: REQUIRE((__builtin_expect(!!((handle) != ((void*)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H') << 8 | ('D')))), 1))) failed, back trace
25-Jun-2020 20:14:17.091 general: critical: #0 0x100268c7d in isc_thread_setaffinity()+0x4995d
25-Jun-2020 20:14:17.093 general: critical: #1 0x1004448ca in isc_thread_setaffinity()+0x2255aa
25-Jun-2020 20:14:17.094 general: critical: #2 0x10045b000 in isc_thread_setaffinity()+0x23bce0
25-Jun-2020 20:14:17.094 general: critical: #3 0x10029e00b in isc_thread_setaffinity()+0x7eceb
25-Jun-2020 20:14:17.096 general: critical: #4 0x1002ab4d6 in isc_thread_setaffinity()+0x8c1b6
25-Jun-2020 20:14:17.098 general: critical: #5 0x1002a8ac1 in isc_thread_setaffinity()+0x897a1
25-Jun-2020 20:14:17.099 general: critical: #6 0x1002b18df in isc_thread_setaffinity()+0x925bf
25-Jun-2020 20:14:17.100 general: critical: #7 0x1002acefe in isc_thread_setaffinity()+0x8dbde
25-Jun-2020 20:14:17.101 general: critical: #8 0x1002aa9d2 in isc_thread_setaffinity()+0x8b6b2
25-Jun-2020 20:14:17.101 general: critical: #9 0x100469e6e in isc_thread_setaffinity()+0x24ab4e
25-Jun-2020 20:14:17.102 general: critical: #10 0x7fff6b52b109 in isc_thread_setaffinity()+0x7ffe6b30bde9
25-Jun-2020 20:14:17.103 general: critical: #11 0x7fff6b526b8b in isc_thread_setaffinity()+0x7ffe6b30786b
25-Jun-2020 20:14:17.104 general: critical: exiting (due to assertion failure)
25-Jun-2020 20:19:18.608 zoneload: info: managed-keys-zone: loaded serial 154
25-Jun-2020 20:19:18.636 zoneload: info: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
25-Jun-2020 20:19:18.636 general: warning: stoweaccesscom.zone:1: no TTL specified; using SOA MINTTL instead
25-Jun-2020 20:19:18.637 zoneload: info: zone localhost/IN: loaded serial 42
…
Queries
25-Jun-2020 20:14:15.073 queries: info: client @0x7fc44f8c2f68 192.168.1.1#57371 (cdn-0.nflximg.com): query: cdn-0.nflximg.com IN A + (192.168.1.114)
25-Jun-2020 20:14:15.280 queries: info: client @0x7fc451ace768 127.0.0.1#57158 (gum.criteo.com): query: gum.criteo.com IN A + (127.0.0.1)
25-Jun-2020 20:14:15.281 queries: info: client @0x7fc451ace768 127.0.0.1#56467 (gum.criteo.com): query: gum.criteo.com IN AAAA + (127.0.0.1)
25-Jun-2020 20:14:16.011 queries: info: client @0x7fc44f866f68 127.0.0.1#60819 (ag.gbc.criteo.com): query: ag.gbc.criteo.com IN A + (127.0.0.1)
25-Jun-2020 20:14:16.013 queries: info: client @0x7fc450a82368 127.0.0.1#59821 (ag.gbc.criteo.com): query: ag.gbc.criteo.com IN AAAA + (127.0.0.1)
25-Jun-2020 20:14:16.015 queries: info: client @0x7fc451ace768 127.0.0.1#62751 (gem.gbc.criteo.com): query: gem.gbc.criteo.com IN A + (127.0.0.1)
25-Jun-2020 20:14:16.018 queries: info: client @0x7fc450a89d68 127.0.0.1#63515 (gem.gbc.criteo.com): query: gem.gbc.criteo.com IN AAAA + (127.0.0.1)
25-Jun-2020 20:14:16.706 queries: info: client @0x7fc450a82368 127.0.0.1#60819 (gbc2.va.us.criteo.com): query: gbc2.va.us.criteo.com IN A + (127.0.0.1)
25-Jun-2020 20:14:16.707 queries: info: client @0x7fc45032bb68 127.0.0.1#59821 (gbc2.va.us.criteo.com): query: gbc2.va.us.criteo.com IN AAAA + (127.0.0.1)
25-Jun-2020 20:14:16.721 queries: info: client @0x7fc450a89d68 127.0.0.1#62751 (gbc6.va.us.criteo.com): query: gbc6.va.us.criteo.com IN A + (127.0.0.1)
25-Jun-2020 20:14:16.721 queries: info: client @0x7fc451ace768 127.0.0.1#63515 (gbc6.va.us.criteo.com): query: gbc6.va.us.criteo.com IN AAAA + (127.0.0.1)
25-Jun-2020 20:14:16.737 queries: info: client @0x7fc451b64b68 127.0.0.1#55419 (gbc2.va.us.criteo.com): query: gbc2.va.us.criteo.com IN A +T (127.0.0.1)
25-Jun-2020 20:19:19.615 queries: info: client @0x7f86bfbdc968 127.0.0.1#56230 (cdn.cvws.apple-dns.net): query: cdn.cvws.apple-dns.net IN AAAA + (127.0.0.1)
25-Jun-2020 20:19:19.617 queries: info: client @0x7f86bfbe2768 127.0.0.1#55876 (cdn.cvws.apple-dns.net): query: cdn.cvws.apple-dns.net IN A + (127.0.0.1)
25-Jun-2020 20:19:19.990 queries: info: client @0x7f86bfbe7368 127.0.0.1#59565 (iadsdk.apple.com): query: iadsdk.apple.com IN AAAA + (127.0.0.1)
…
Crash Log
Process: named [873]
Path: /usr/local/sbin/named
Identifier: named
Version: 0
Code Type: X86-64 (Native)
Parent Process: launchd [1]
Responsible: Terminal [477]
User ID: 0
Date/Time: 2020-06-25 20:14:19.518 -0400
OS Version: Mac OS X 10.15.5 (19F101)
Report Version: 12
Bridge OS Version: 4.5 (17P5300)
Anonymous UUID: 82507E35-4749-9A32-F6BB-A39F4951B0B0
Time Awake Since Boot: 100000 seconds
System Integrity Protection: enabled
Crashed Thread: 7
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
crashed on child side of fork pre-exec
Thread 0:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff6b470912 __sigwait + 10
1 libsystem_pthread.dylib 0x00007fff6b52b5e8 sigwait + 52
2 named 0x00000001004440a4 isc_app_ctxrun + 420
3 named 0x000000010044428e isc_app_run + 30
4 named 0x0000000100268551 main + 5697
5 libdyld.dylib 0x00007fff6b326cc9 start + 1
Thread 1:
0 libsystem_kernel.dylib 0x00007fff6b46c766 kevent + 10
1 libuv.1.dylib 0x00000001008256e6 uv__io_poll + 859
2 libuv.1.dylib 0x0000000100816946 uv_run + 359
3 named 0x0000000100458839 nm_thread + 153
4 libsystem_pthread.dylib 0x00007fff6b52b109 _pthread_start + 148
5 libsystem_pthread.dylib 0x00007fff6b526b8b thread_start + 15
Thread 2:
0 libsystem_kernel.dylib 0x00007fff6b46c766 kevent + 10
1 libuv.1.dylib 0x00000001008256e6 uv__io_poll + 859
2 libuv.1.dylib 0x0000000100816946 uv_run + 359
3 named 0x0000000100458839 nm_thread + 153
4 libsystem_pthread.dylib 0x00007fff6b52b109 _pthread_start + 148
5 libsystem_pthread.dylib 0x00007fff6b526b8b thread_start + 15
Thread 3:
0 libsystem_kernel.dylib 0x00007fff6b46c766 kevent + 10
1 libuv.1.dylib 0x00000001008256e6 uv__io_poll + 859
2 libuv.1.dylib 0x0000000100816946 uv_run + 359
3 named 0x0000000100458839 nm_thread + 153
4 libsystem_pthread.dylib 0x00007fff6b52b109 _pthread_start + 148
5 libsystem_pthread.dylib 0x00007fff6b526b8b thread_start + 15
Thread 4:
0 libsystem_kernel.dylib 0x00007fff6b46c766 kevent + 10
1 libuv.1.dylib 0x00000001008256e6 uv__io_poll + 859
2 libuv.1.dylib 0x0000000100816946 uv_run + 359
3 named 0x0000000100458839 nm_thread + 153
4 libsystem_pthread.dylib 0x00007fff6b52b109 _pthread_start + 148
5 libsystem_pthread.dylib 0x00007fff6b526b8b thread_start + 15
Thread 5:
0 libsystem_kernel.dylib 0x00007fff6b46a882 __psynch_cvwait + 10
1 libsystem_pthread.dylib 0x00007fff6b52b425 _pthread_cond_wait + 698
2 named 0x0000000100469a91 run + 225
3 libsystem_pthread.dylib 0x00007fff6b52b109 _pthread_start + 148
4 libsystem_pthread.dylib 0x00007fff6b526b8b thread_start + 15
Thread 6:
0 libsystem_kernel.dylib 0x00007fff6b46a882 __psynch_cvwait + 10
1 libsystem_pthread.dylib 0x00007fff6b52b425 _pthread_cond_wait + 698
2 named 0x0000000100469a91 run + 225
3 libsystem_pthread.dylib 0x00007fff6b52b109 _pthread_start + 148
4 libsystem_pthread.dylib 0x00007fff6b526b8b thread_start + 15
Thread 7 Crashed:
0 libsystem_kernel.dylib 0x00007fff6b46e33a __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff6b52ae60 pthread_kill + 430
2 libsystem_c.dylib 0x00007fff6b3f5808 abort + 120
3 named 0x0000000100268e20 assertion_failed + 496
4 named 0x00000001004448ca isc_assertion_failed + 10
5 named 0x000000010045b000 isc_nm_send + 80
6 named 0x000000010029e00b ns_client_send + 1115
7 named 0x00000001002ab4d6 query_send + 310
8 named 0x00000001002a8ac1 ns_query_done + 993
9 named 0x00000001002b18df query_prepresponse + 5695
10 named 0x00000001002acefe query_gotanswer + 2990
11 named 0x00000001002aa9d2 fetch_callback + 2786
12 named 0x0000000100469e6e run + 1214
13 libsystem_pthread.dylib 0x00007fff6b52b109 _pthread_start + 148
14 libsystem_pthread.dylib 0x00007fff6b526b8b thread_start + 15
Thread 8:
0 libsystem_kernel.dylib 0x00007fff6b46a882 __psynch_cvwait + 10
1 libsystem_pthread.dylib 0x00007fff6b52b425 _pthread_cond_wait + 698
2 named 0x0000000100469a91 run + 225
3 libsystem_pthread.dylib 0x00007fff6b52b109 _pthread_start + 148
4 libsystem_pthread.dylib 0x00007fff6b526b8b thread_start + 15
Thread 9:
0 libsystem_kernel.dylib 0x00007fff6b46a882 __psynch_cvwait + 10
1 libsystem_pthread.dylib 0x00007fff6b52b425 _pthread_cond_wait + 698
2 named 0x000000010047d01e isc_condition_waituntil + 158
3 named 0x000000010046f2e3 run + 707
4 libsystem_pthread.dylib 0x00007fff6b52b109 _pthread_start + 148
5 libsystem_pthread.dylib 0x00007fff6b526b8b thread_start + 15
Thread 10:
0 libsystem_kernel.dylib 0x00007fff6b46c766 kevent + 10
1 named 0x0000000100474aa8 netthread + 152
2 libsystem_pthread.dylib 0x00007fff6b52b109 _pthread_start + 148
3 libsystem_pthread.dylib 0x00007fff6b526b8b thread_start + 15
Thread 11:
0 libsystem_kernel.dylib 0x00007fff6b46c766 kevent + 10
1 named 0x0000000100474aa8 netthread + 152
2 libsystem_pthread.dylib 0x00007fff6b52b109 _pthread_start + 148
3 libsystem_pthread.dylib 0x00007fff6b526b8b thread_start + 15
Thread 12:
0 libsystem_kernel.dylib 0x00007fff6b46c766 kevent + 10
1 named 0x0000000100474aa8 netthread + 152
2 libsystem_pthread.dylib 0x00007fff6b52b109 _pthread_start + 148
3 libsystem_pthread.dylib 0x00007fff6b526b8b thread_start + 15
Thread 13:
0 libsystem_kernel.dylib 0x00007fff6b46c766 kevent + 10
1 named 0x0000000100474aa8 netthread + 152
2 libsystem_pthread.dylib 0x00007fff6b52b109 _pthread_start + 148
3 libsystem_pthread.dylib 0x00007fff6b526b8b thread_start + 15
Thread 7 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x000070000b7dd000 rcx: 0x000070000b7da148 rdx: 0x0000000000000000
rdi: 0x0000000000001803 rsi: 0x0000000000000006 rbp: 0x000070000b7da170 rsp: 0x000070000b7da148
r8: 0x0000000000001732 r9: 0x0000000000000143 r10: 0x000070000b7dd000 r11: 0x0000000000000246
r12: 0x0000000000001803 r13: 0x00000001005120f0 r14: 0x0000000000000006 r15: 0x0000000000000016
rip: 0x00007fff6b46e33a rfl: 0x0000000000000246 cr2: 0x000000076a6ea000
Logical CPU: 0
Error Code: 0x02000148
Trap Number: 133
Binary Images:
0x10025e000 - 0x1004e9fff +named (0) <839CAA3E-66F9-3AB2-BF19-132A662C88A3> /usr/local/sbin/named
0x1005cc000 - 0x100766c2f +libcrypto.1.1.dylib (0) <9D836867-F469-3417-97DC-31B074FCB6F4> /usr/local/opt/openssl@1.1/lib/libcrypto.1.1.dylib
0x1007fc000 - 0x100803ffb +libjson-c.4.dylib (0) <CD1D4F80-33A4-38DF-8CCC-1337D6BB1027> /usr/local/opt/json-c/lib/libjson-c.4.dylib
0x100810000 - 0x10082afff +libuv.1.dylib (0) <C40FAF3B-16DD-3C66-A7C4-3AAB443ACC94> /usr/local/opt/libuv/lib/libuv.1.dylib
0x1051b7000 - 0x105248eff dyld (750.5) <E4698FBD-806A-3396-B279-E685BA37430B> /usr/lib/dyld
0x7fff2cf33000 - 0x7fff2cf33fff com.apple.Accelerate (1.11 - Accelerate 1.11) <56DFF715-6A4E-3231-BDCC-A348BCB05047> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
0x7fff2cf4b000 - 0x7fff2d5a1fff com.apple.vImage (8.1 - 524.2.1) <17C93AB9-1625-3FDB-9851-C5E77BBE3428> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x7fff2d5a2000 - 0x7fff2d809ff7 libBLAS.dylib (1303.60.1) <CBC28BE4-3C78-3AED-9565-0D625251D121> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
0x7fff2d80a000 - 0x7fff2dcddfef libBNNS.dylib (144.100.2) <8D653678-1F9B-3670-AAE2-46DFB8D37643> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib
0x7fff2dcde000 - 0x7fff2e079fff libLAPACK.dylib (1303.60.1) <F8E9D081-7C60-32EC-A47D-2D30CAD73C5F> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
0x7fff2e07a000 - 0x7fff2e08ffec libLinearAlgebra.dylib (1303.60.1) <D2C1ACEA-2B6A-339A-9EEB-62A76CC92CBE> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib
0x7fff2e090000 - 0x7fff2e095ff3 libQuadrature.dylib (7) <3112C977-8306-3190-8313-01A952B7F3CF> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libQuadrature.dylib
0x7fff2e096000 - 0x7fff2e106fff libSparse.dylib (103) <40510BF9-99A7-3155-A81D-6DE5A0C73EDC> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparse.dylib
0x7fff2e107000 - 0x7fff2e119fef libSparseBLAS.dylib (1303.60.1) <3C1066AB-20D5-38D2-B1F2-70A03DE76D0B> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparseBLAS.dylib
0x7fff2e11a000 - 0x7fff2e2f1fd7 libvDSP.dylib (735.121.1) <74702E2E-ED05-3765-B18C-64BEFF62B517> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
0x7fff2e2f2000 - 0x7fff2e3b4fef libvMisc.dylib (735.121.1) <137558BF-503D-3A6E-96DC-A181E3FB31FF> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x7fff2e3b5000 - 0x7fff2e3b5fff com.apple.Accelerate.vecLib (3.11 - vecLib 3.11) <D7E8E400-35C8-3174-9956-8D1B483620DA> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x7fff2fb1a000 - 0x7fff2fea8ffd com.apple.CFNetwork (1126 - 1126) <BB8F4C63-10B8-3ACD-84CF-D4DCFA9245DD> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
0x7fff312a8000 - 0x7fff31727ffb com.apple.CoreFoundation (6.9 - 1676.105) <6AF8B3CC-BC3F-3869-B9FB-1D881422364E> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x7fff3268f000 - 0x7fff3268ffff com.apple.CoreServices (1069.24 - 1069.24) <D9F6AB40-10EC-3682-A969-85560E2E4768> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x7fff32690000 - 0x7fff32715fff com.apple.AE (838.1 - 838.1) <5F26DA9B-FB2E-3AF8-964B-63BD6671CF12> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x7fff32716000 - 0x7fff329f7ff7 com.apple.CoreServices.CarbonCore (1217 - 1217) <8022AF47-AA99-3786-B086-141D84F00387> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x7fff329f8000 - 0x7fff32a45ffd com.apple.DictionaryServices (1.2 - 323.6) <C0F3830C-A4C6-3046-9A6A-DE1B5D448C2C> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
0x7fff32a46000 - 0x7fff32a4eff7 com.apple.CoreServices.FSEvents (1268.100.1 - 1268.100.1) <E4B2CAF2-1203-335F-9971-1278CB6E2AE0> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents
0x7fff32a4f000 - 0x7fff32c89ff6 com.apple.LaunchServices (1069.24 - 1069.24) <2E0AD228-B1CC-3645-91EE-EB7F46F2147B> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x7fff32c8a000 - 0x7fff32d22ff1 com.apple.Metadata (10.7.0 - 2076.6) <C8034E84-7DD4-34B9-9CDF-16A05032FF39> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x7fff32d23000 - 0x7fff32d50fff com.apple.CoreServices.OSServices (1069.24 - 1069.24) <72FDEA52-7607-3745-AC43-630D80962099> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x7fff32d51000 - 0x7fff32db8fff com.apple.SearchKit (1.4.1 - 1.4.1) <086EB5DF-A2EC-3342-8028-CA7996BE5CB2> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
0x7fff32db9000 - 0x7fff32dddff5 com.apple.coreservices.SharedFileList (131.4 - 131.4) <AE333DA2-C279-3751-8C15-B963E58EE61E> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList
0x7fff33623000 - 0x7fff33629fff com.apple.DiskArbitration (2.7 - 2.7) <52E7D181-2A18-37CD-B24F-AA32E93F7A69> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x7fff33962000 - 0x7fff33d27fff com.apple.Foundation (6.9 - 1676.105) <1FA28BAB-7296-3A09-8E1E-E62A7D233DB8> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x7fff33d94000 - 0x7fff33de4ff7 com.apple.GSS (4.0 - 2.0) <4E241C00-42A5-3572-9430-D950FBB7A4A0> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
0x7fff3409b000 - 0x7fff3413fff3 com.apple.framework.IOKit (2.0.2 - 1726.121.1) <A0F54725-036F-3279-A46E-C2ABDBFD479B> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x7fff35c53000 - 0x7fff35c65ff3 com.apple.Kerberos (3.0 - 1) <AE0E56CA-D924-3CC8-BBAA-8C6EEC3038BE> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
0x7fff35c66000 - 0x7fff35c66fff libHeimdalProxy.dylib (77) <A970C7A8-7CCD-3701-A459-078BD5E8FE4E> /System/Library/Frameworks/Kerberos.framework/Versions/A/Libraries/libHeimdalProxy.dylib
0x7fff37c40000 - 0x7fff37c4cffe com.apple.NetFS (6.0 - 4.0) <AC74E6A4-6E9B-3AB1-9577-8277F8A3EDE0> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
0x7fff3a82e000 - 0x7fff3a84afff com.apple.CFOpenDirectory (10.15 - 220.40.1) <BFC32EBE-D95C-3267-B95C-5CEEFD189EA6> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
0x7fff3a84b000 - 0x7fff3a856ffd com.apple.OpenDirectory (10.15 - 220.40.1) <76A20BBA-775F-3E17-AB0F-FEDFCDCE0716> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
0x7fff3dbf0000 - 0x7fff3df39ff1 com.apple.security (7.0 - 59306.120.7) <AEA33464-1507-36F1-8CAE-A86EB787F9B5> /System/Library/Frameworks/Security.framework/Versions/A/Security
0x7fff3df3a000 - 0x7fff3dfc2ffb com.apple.securityfoundation (6.0 - 55236.60.1) <79289FE1-CB5F-3BEF-A33F-11A29A93A681> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
0x7fff3dff1000 - 0x7fff3dff5ff8 com.apple.xpc.ServiceManagement (1.0 - 1) <4194D29D-F0D4-33F8-839A-D03C6C62D8DB> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
0x7fff3eca1000 - 0x7fff3ed0fff7 com.apple.SystemConfiguration (1.19 - 1.19) <0CF8726A-BE41-3E07-B895-FBC44B75450E> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x7fff42c70000 - 0x7fff42d35ff7 com.apple.APFS (1412.120.2 - 1412.120.2) <1E8FD511-FDC4-31A2-ACDE-EB5192032BC6> /System/Library/PrivateFrameworks/APFS.framework/Versions/A/APFS
0x7fff44bbd000 - 0x7fff44bccfd7 com.apple.AppleFSCompression (119.100.1 - 1.0) <2E75CF51-B693-3275-9A4F-40571D48745E> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
0x7fff4638c000 - 0x7fff46395ff7 com.apple.coreservices.BackgroundTaskManagement (1.0 - 104) <F070F440-27AB-3FCF-9602-F278C332CA01> /System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/BackgroundTaskManagement
0x7fff48077000 - 0x7fff48087ffb com.apple.CommonAuth (4.0 - 2.0) <91EC83B5-857D-3D4F-93B1-AAD7E0E029D8> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
0x7fff49192000 - 0x7fff491a2ff3 com.apple.CoreEmoji (1.0 - 107.1) <CDCCB4B0-B98F-38E8-9568-C81320E756EB> /System/Library/PrivateFrameworks/CoreEmoji.framework/Versions/A/CoreEmoji
0x7fff497e2000 - 0x7fff4984cff0 com.apple.CoreNLP (1.0 - 213) <40FC46D2-844C-3282-A8E4-69DD827F05C5> /System/Library/PrivateFrameworks/CoreNLP.framework/Versions/A/CoreNLP
0x7fff4a6c7000 - 0x7fff4a6f5ffd com.apple.CSStore (1069.24 - 1069.24) <C96E5CE8-D604-3F13-B079-B2BA33B90081> /System/Library/PrivateFrameworks/CoreServicesStore.framework/Versions/A/CoreServicesStore
0x7fff53d6e000 - 0x7fff53e2cff4 com.apple.Heimdal (4.0 - 2.0) <F2C504F6-E211-3AB0-9754-D96D2F96634B> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
0x7fff56955000 - 0x7fff56a23ffd com.apple.LanguageModeling (1.0 - 215.1) <A6FAA215-9A01-3EE1-B304-2238801C5883> /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling
0x7fff56a24000 - 0x7fff56a6cfff com.apple.Lexicon-framework (1.0 - 72) <6AE1872C-0352-36FE-90CC-7303F13A5BEF> /System/Library/PrivateFrameworks/Lexicon.framework/Versions/A/Lexicon
0x7fff56a73000 - 0x7fff56a78ff3 com.apple.LinguisticData (1.0 - 353.18) <686E7B7C-640F-3D7B-A9C1-31E2DFACD457> /System/Library/PrivateFrameworks/LinguisticData.framework/Versions/A/LinguisticData
0x7fff57ddf000 - 0x7fff57e2bfff com.apple.spotlight.metadata.utilities (1.0 - 2076.6) <C3AEA22D-1FEB-3E38-9821-1FA447C8AF9D> /System/Library/PrivateFrameworks/MetadataUtilities.framework/Versions/A/MetadataUtilities
0x7fff588e2000 - 0x7fff588ecfff com.apple.NetAuth (6.2 - 6.2) <D660F2CB-5A49-3DD0-9DB3-86EF0797828C> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
0x7fff61b67000 - 0x7fff61b77ff3 com.apple.TCC (1.0 - 1) <FD146B21-6DC0-3B66-BB95-57A5016B1365> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
0x7fff65249000 - 0x7fff6524bff3 com.apple.loginsupport (1.0 - 1) <31F02734-1ECF-37D9-9DF6-7C3BC3A324FE> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport
0x7fff67d69000 - 0x7fff67d9dfff libCRFSuite.dylib (48) <02C52318-C537-3FD8-BBC4-E5BD25430652> /usr/lib/libCRFSuite.dylib
0x7fff67da0000 - 0x7fff67daafff libChineseTokenizer.dylib (34) <04A7CB5A-FD68-398A-A206-33A510C115E7> /usr/lib/libChineseTokenizer.dylib
0x7fff67e36000 - 0x7fff67e38ff7 libDiagnosticMessagesClient.dylib (112) <27220E98-6CE2-33E3-BD48-3CC3CE4AA036> /usr/lib/libDiagnosticMessagesClient.dylib
0x7fff6830c000 - 0x7fff6830dfff libSystem.B.dylib (1281.100.1) <B6FDA8A9-3D2B-3BD5-B5B0-57D311C0FF3D> /usr/lib/libSystem.B.dylib
0x7fff6839a000 - 0x7fff6839bfff libThaiTokenizer.dylib (3) <97DC10ED-3C11-3C89-B366-299A644035E7> /usr/lib/libThaiTokenizer.dylib
0x7fff683b3000 - 0x7fff683c9fff libapple_nghttp2.dylib (1.39.2) <B99D7150-D4E2-31A2-A594-36DA4B90D558> /usr/lib/libapple_nghttp2.dylib
0x7fff683fe000 - 0x7fff68470ff7 libarchive.2.dylib (72.100.1) <20B70252-0C4B-3AFD-8C8D-F51921E9D324> /usr/lib/libarchive.2.dylib
0x7fff6850e000 - 0x7fff6850eff3 libauto.dylib (187) <85383E24-1592-36BC-BB39-308B7F1C826E> /usr/lib/libauto.dylib
0x7fff685d4000 - 0x7fff685e4ffb libbsm.0.dylib (60.100.1) <B2331E11-3CBB-3BCF-93A6-12627AE444D0> /usr/lib/libbsm.0.dylib
0x7fff685e5000 - 0x7fff685f1fff libbz2.1.0.dylib (44) <BF40E193-8856-39B7-98F8-7A17B328B1E9> /usr/lib/libbz2.1.0.dylib
0x7fff685f2000 - 0x7fff68644fff libc++.1.dylib (902.1) <AD0805FE-F98B-3E2F-B072-83782B22DAC9> /usr/lib/libc++.1.dylib
0x7fff68645000 - 0x7fff6865affb libc++abi.dylib (902) <771E9263-E832-3985-9477-8F1B2D73B771> /usr/lib/libc++abi.dylib
0x7fff6865b000 - 0x7fff6865bfff libcharset.1.dylib (59) <FF23D4ED-A5AD-3592-9574-48486C7DF85B> /usr/lib/libcharset.1.dylib
0x7fff6865c000 - 0x7fff6866dfff libcmph.dylib (8) <296A51E6-9661-3AC2-A1C9-F1E3510F91AA> /usr/lib/libcmph.dylib
0x7fff6866e000 - 0x7fff68685fd7 libcompression.dylib (87) <21F37C2E-B9AA-38CE-9023-B763C8828AC6> /usr/lib/libcompression.dylib
0x7fff6895f000 - 0x7fff68975ff7 libcoretls.dylib (167) <9E5D1E0C-03F8-37B6-82A1-0D0597021CB8> /usr/lib/libcoretls.dylib
0x7fff68976000 - 0x7fff68977fff libcoretls_cfhelpers.dylib (167) <C23BE09B-85D1-3744-9E7B-E2B11ACD5442> /usr/lib/libcoretls_cfhelpers.dylib
0x7fff6909d000 - 0x7fff6909dfff libenergytrace.dylib (21) <DBF8BDEE-7229-3F06-AC10-A28DCC4243C0> /usr/lib/libenergytrace.dylib
0x7fff690c4000 - 0x7fff690c6fff libfakelink.dylib (149.1) <122F530F-F10E-3DD5-BBEA-91796BE583F3> /usr/lib/libfakelink.dylib
0x7fff690d5000 - 0x7fff690dafff libgermantok.dylib (24) <DD279BF6-E906-30D3-A69E-DC797E95F147> /usr/lib/libgermantok.dylib
0x7fff690db000 - 0x7fff690e4ff7 libheimdal-asn1.dylib (564.100.1) <68FA1BE5-8FFC-3345-8980-8D8629EBA451> /usr/lib/libheimdal-asn1.dylib
0x7fff690e5000 - 0x7fff691d5fff libiconv.2.dylib (59) <F58FED71-6CCA-30E8-9A51-13E9B46E568D> /usr/lib/libiconv.2.dylib
0x7fff691d6000 - 0x7fff6942dfff libicucore.A.dylib (64260.0.1) <7B9204AC-EA14-3FF3-B6B9-4C85B37EED79> /usr/lib/libicucore.A.dylib
0x7fff69447000 - 0x7fff69448fff liblangid.dylib (133) <36581D30-1C7B-3A58-AA07-36237BD75E0E> /usr/lib/liblangid.dylib
0x7fff69449000 - 0x7fff69461ff3 liblzma.5.dylib (16) <4DB30730-DBD1-3503-957A-D604049B98F9> /usr/lib/liblzma.5.dylib
0x7fff69479000 - 0x7fff69520ff7 libmecab.dylib (883.11) <66AD729B-2BCC-3347-B9B3-FD88570E884D> /usr/lib/libmecab.dylib
0x7fff69521000 - 0x7fff69783ff1 libmecabra.dylib (883.11) <2AE744D2-AC95-3720-8E66-4F9C7A79384C> /usr/lib/libmecabra.dylib
0x7fff69c4f000 - 0x7fff6a0cbff5 libnetwork.dylib (1880.120.4) <715FB943-BA01-351C-BEA6-121970472985> /usr/lib/libnetwork.dylib
0x7fff6a16c000 - 0x7fff6a19ffde libobjc.A.dylib (787.1) <CA836D3E-4595-33F1-B70C-7E39A3FBBE16> /usr/lib/libobjc.A.dylib
0x7fff6a1b2000 - 0x7fff6a1b6fff libpam.2.dylib (25.100.1) <732E8D8E-C630-3EC2-B6C3-A1564E3B68B8> /usr/lib/libpam.2.dylib
0x7fff6a1b9000 - 0x7fff6a1efff7 libpcap.A.dylib (89.120.1) <CF2ADF15-2D44-3A35-94B4-DD24052F9B23> /usr/lib/libpcap.A.dylib
0x7fff6a273000 - 0x7fff6a28bfff libresolv.9.dylib (67.40.1) <B0F5D204-7EF2-3B0B-90EF-BB4D196FCC62> /usr/lib/libresolv.9.dylib
0x7fff6a2e7000 - 0x7fff6a4d1ff7 libsqlite3.dylib (308.5) <AF518115-4AD1-39F2-9B82-E2640E2221E1> /usr/lib/libsqlite3.dylib
0x7fff6a722000 - 0x7fff6a725ffb libutil.dylib (57) <D33B63D2-ADC2-38BD-B8F2-24056C41E07B> /usr/lib/libutil.dylib
0x7fff6a726000 - 0x7fff6a733ff7 libxar.1.dylib (425.2) <943A4CBB-331B-3A04-A11F-A2301189D40B> /usr/lib/libxar.1.dylib
0x7fff6a739000 - 0x7fff6a81bff7 libxml2.2.dylib (33.3) <262EF7C6-7D83-3C01-863F-36E97F5ACD34> /usr/lib/libxml2.2.dylib
0x7fff6a81f000 - 0x7fff6a847fff libxslt.1.dylib (16.9) <86FE4382-BD77-3C19-A678-11EBCD70685A> /usr/lib/libxslt.1.dylib
0x7fff6a848000 - 0x7fff6a85aff3 libz.1.dylib (76) <DB120508-3BED-37A8-B439-5235EAB4618A> /usr/lib/libz.1.dylib
0x7fff6b108000 - 0x7fff6b10dff3 libcache.dylib (83) <A5ECC751-A681-30D8-B33C-D192C15D25C8> /usr/lib/system/libcache.dylib
0x7fff6b10e000 - 0x7fff6b119fff libcommonCrypto.dylib (60165.120.1) <C321A74A-AA91-3785-BEBF-BEDC6975026C> /usr/lib/system/libcommonCrypto.dylib
0x7fff6b11a000 - 0x7fff6b121fff libcompiler_rt.dylib (101.2) <652A6012-7E5C-3F4F-9438-86BC094526F3> /usr/lib/system/libcompiler_rt.dylib
0x7fff6b122000 - 0x7fff6b12bff7 libcopyfile.dylib (166.40.1) <40113A69-A81C-3397-ADC6-1D16B9A22C3E> /usr/lib/system/libcopyfile.dylib
0x7fff6b12c000 - 0x7fff6b1befe3 libcorecrypto.dylib (866.120.3) <5E4B0E50-24DD-3E04-9374-EDA9FFD6257B> /usr/lib/system/libcorecrypto.dylib
0x7fff6b2cb000 - 0x7fff6b30bff0 libdispatch.dylib (1173.100.2) <201EDBF3-0B36-31BA-A7CB-443CE35C05D4> /usr/lib/system/libdispatch.dylib
0x7fff6b30c000 - 0x7fff6b342fff libdyld.dylib (750.5) <7E711A46-5E4D-393C-AEA6-440E2A5CCD0C> /usr/lib/system/libdyld.dylib
0x7fff6b343000 - 0x7fff6b343ffb libkeymgr.dylib (30) <52662CAA-DB1F-30A3-BE13-D6274B1A6D7B> /usr/lib/system/libkeymgr.dylib
0x7fff6b344000 - 0x7fff6b350ff3 libkxld.dylib (6153.121.2) <5EBB4886-C7B6-31D6-AA63-D861B2D58FCE> /usr/lib/system/libkxld.dylib
0x7fff6b351000 - 0x7fff6b351ff7 liblaunch.dylib (1738.120.8) <07CF647B-F9DC-3907-AD98-2F85FCB34A72> /usr/lib/system/liblaunch.dylib
0x7fff6b352000 - 0x7fff6b357ff7 libmacho.dylib (959.0.1) <D91DFF00-E22F-3796-8A1C-4C1F5F8FA03C> /usr/lib/system/libmacho.dylib
0x7fff6b358000 - 0x7fff6b35aff3 libquarantine.dylib (110.40.3) <D3B7D02C-7646-3FB4-8529-B36DCC2419EA> /usr/lib/system/libquarantine.dylib
0x7fff6b35b000 - 0x7fff6b35cff7 libremovefile.dylib (48) <B5E88D9B-C2BE-3496-BBB2-C996317E18A3> /usr/lib/system/libremovefile.dylib
0x7fff6b35d000 - 0x7fff6b374ff3 libsystem_asl.dylib (377.60.2) <1170348D-2491-33F1-AA79-E2A05B4A287C> /usr/lib/system/libsystem_asl.dylib
0x7fff6b375000 - 0x7fff6b375ff7 libsystem_blocks.dylib (74) <7AFBCAA6-81BE-36C3-8DB0-AAE0A4ACE4C5> /usr/lib/system/libsystem_blocks.dylib
0x7fff6b376000 - 0x7fff6b3fdfff libsystem_c.dylib (1353.100.2) <935DDCE9-4ED0-3F79-A05A-A123DDE399CC> /usr/lib/system/libsystem_c.dylib
0x7fff6b3fe000 - 0x7fff6b401ffb libsystem_configuration.dylib (1061.120.2) <EA9BC2B1-5001-3463-9FAF-39FF61CAC87C> /usr/lib/system/libsystem_configuration.dylib
0x7fff6b402000 - 0x7fff6b405fff libsystem_coreservices.dylib (114) <3D0A3AA8-8415-37B2-AAE3-66C03BCE8B55> /usr/lib/system/libsystem_coreservices.dylib
0x7fff6b406000 - 0x7fff6b40efff libsystem_darwin.dylib (1353.100.2) <6EEC9975-EE3B-3C95-AA5B-030FD10587BC> /usr/lib/system/libsystem_darwin.dylib
0x7fff6b40f000 - 0x7fff6b416fff libsystem_dnssd.dylib (1096.100.3) <0115092A-E61B-317D-8670-41C7C34B1A82> /usr/lib/system/libsystem_dnssd.dylib
0x7fff6b417000 - 0x7fff6b418ffb libsystem_featureflags.dylib (17) <AFDB5095-0472-34AC-BA7E-497921BF030A> /usr/lib/system/libsystem_featureflags.dylib
0x7fff6b419000 - 0x7fff6b466ff7 libsystem_info.dylib (538) <851693E9-C079-3547-AD41-353F8C248BE8> /usr/lib/system/libsystem_info.dylib
0x7fff6b467000 - 0x7fff6b493ff7 libsystem_kernel.dylib (6153.121.2) <9F9902C9-A46F-3CA9-B7F9-5CCFE98FBF75> /usr/lib/system/libsystem_kernel.dylib
0x7fff6b494000 - 0x7fff6b4dbfff libsystem_m.dylib (3178) <436CFF76-6A99-36F2-A3B6-8D017396A050> /usr/lib/system/libsystem_m.dylib
0x7fff6b4dc000 - 0x7fff6b503fff libsystem_malloc.dylib (283.100.6) <D4BA7DF2-57AC-33B0-B948-A688EE43C799> /usr/lib/system/libsystem_malloc.dylib
0x7fff6b504000 - 0x7fff6b511ffb libsystem_networkextension.dylib (1095.120.6) <6DE86DB0-8CD2-361E-BD6A-A34282B47847> /usr/lib/system/libsystem_networkextension.dylib
0x7fff6b512000 - 0x7fff6b51bff7 libsystem_notify.dylib (241.100.2) <7E9E2FC8-DF26-340C-B196-B81B11850C46> /usr/lib/system/libsystem_notify.dylib
0x7fff6b51c000 - 0x7fff6b524fef libsystem_platform.dylib (220.100.1) <736920EA-6AE0-3B1B-BBDA-7DCDF0C229DF> /usr/lib/system/libsystem_platform.dylib
0x7fff6b525000 - 0x7fff6b52ffff libsystem_pthread.dylib (416.100.3) <77488669-19A3-3993-AD65-CA5377E2475A> /usr/lib/system/libsystem_pthread.dylib
0x7fff6b530000 - 0x7fff6b534ff3 libsystem_sandbox.dylib (1217.120.7) <20C93D69-6452-3C82-9521-8AE54345C66F> /usr/lib/system/libsystem_sandbox.dylib
0x7fff6b535000 - 0x7fff6b537fff libsystem_secinit.dylib (62.100.2) <E851113D-D5B1-3FB0-9D29-9C7647A71961> /usr/lib/system/libsystem_secinit.dylib
0x7fff6b538000 - 0x7fff6b53fffb libsystem_symptoms.dylib (1238.120.1) <25C3866B-004E-3621-9CD3-B1E9C4D887EB> /usr/lib/system/libsystem_symptoms.dylib
0x7fff6b540000 - 0x7fff6b556ff2 libsystem_trace.dylib (1147.120) <A1ED1D3A-5FAD-3559-A1D6-1BE4E1C5756A> /usr/lib/system/libsystem_trace.dylib
0x7fff6b558000 - 0x7fff6b55dff7 libunwind.dylib (35.4) <253A12E2-F88F-3838-A666-C5306F833CB8> /usr/lib/system/libunwind.dylib
0x7fff6b55e000 - 0x7fff6b593ffe libxpc.dylib (1738.120.8) <68D433B6-DCFF-385D-8620-F847FB7D4A5A> /usr/lib/system/libxpc.dylib
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 187
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 66307
thread_create: 0
thread_set_state: 0
VM Region Summary:
ReadOnly portion of Libraries: Total=463.1M resident=0K(0%) swapped_out_or_unallocated=463.1M(100%)
Writable regions: Total=200.9M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=200.9M(100%)
VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
Activity Tracing 256K 1
Kernel Alloc Once 8K 1
MALLOC 123.3M 517
MALLOC guard page 16K 4
STACK GUARD 56K 14
Stack 77.1M 15
__DATA 6236K 131
__DATA_CONST 268K 5
__LINKEDIT 389.5M 6
__OBJC_RO 32.2M 1
__OBJC_RW 1892K 2
__TEXT 73.6M 130
__UNICODE 564K 1
shared memory 12K 3
=========== ======= =======
TOTAL 704.8M 831
```July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)https://gitlab.isc.org/isc-projects/bind9/-/issues/1982Follow-up from "WIP: Resolve "Get current state of DNSSEC keys (kasp) via rndc""2020-07-07T12:11:24ZOndřej SurýFollow-up from "WIP: Resolve "Get current state of DNSSEC keys (kasp) via rndc""The following discussion from !3717 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3717#note_143896):
> This is outside of this MR, but using strftime would all...The following discussion from !3717 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3717#note_143896):
> This is outside of this MR, but using strftime would allow us use same routing for all systems and get rid of `\n` in the same go...BIND 9.17 BackburnerMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1988bad output rndc dnssec -status on Windows2020-07-16T07:03:47ZMatthijs Mekkingmatthijs@isc.orgbad output rndc dnssec -status on WindowsThe following discussion from !3780 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3780#note_144605): (+1 comment)
> This looks fine to me, though I started a p...The following discussion from !3780 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3780#note_144605): (+1 comment)
> This looks fine to me, though I started a pipeline including Windows
> system tests that I would like to complete successfully before merging
> this MR:
>
> https://gitlab.isc.org/isc-projects/bind9/pipelines/45755August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1983Block all domains from being resolved except one domain2020-06-30T01:59:17ZmkhadherBlock all domains from being resolved except one domainHi everyone,
I have Bind9 installed which is working perfectly as a DNS forwarder. I know how to sinkhole/block certain domains from being resolved and now I want to block all domains and only allow one domain "MyDummyDomain.com" to be ...Hi everyone,
I have Bind9 installed which is working perfectly as a DNS forwarder. I know how to sinkhole/block certain domains from being resolved and now I want to block all domains and only allow one domain "MyDummyDomain.com" to be resolved.
Is that technically feasible with Bind9? If so, could you please share some examples?https://gitlab.isc.org/isc-projects/bind9/-/issues/1984"./configure --with-gperftools-profiler" can fail oddly with "error: libcap i...2023-11-02T16:57:55ZMichal Nowak"./configure --with-gperftools-profiler" can fail oddly with "error: libcap is required"On Fedora 32 when `gperftools-devel` and `gperftools-libs` packages are missing, `./configure --with-gperftools-profiler` fails oddly with `error: libcap is required`:
```
checking whether to use gperftools profiler... yes
...
checking f...On Fedora 32 when `gperftools-devel` and `gperftools-libs` packages are missing, `./configure --with-gperftools-profiler` fails oddly with `error: libcap is required`:
```
checking whether to use gperftools profiler... yes
...
checking for library containing cap_set_proc... no
configure: error: libcap is required for Linux capabilities support. Either install libcap or use --disable-linux-caps.
```
`config.log`:
```
| #ifdef __cplusplus
| extern "C"
| #endif
| char cap_set_proc ();
| int
| main ()
| {
| return cap_set_proc ();
| ;
| return 0;
| }
configure:18826: result: no
configure:18833: error: libcap is required for Linux capabilities support. Either install libcap or use --disable-linux-caps.
```September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)https://gitlab.isc.org/isc-projects/bind9/-/issues/1985bind Arm pdf formatting2020-08-12T22:42:20ZPeter Daviesbind Arm pdf formattingBind Arm pdf formatting:
Formatting error in Bind Arm for release 9.16.4 - contents - manual pages and frontispiece
at https://downloads.isc.org/isc/bind9/9.16.4/doc/arm/Bv9ARM.pdf
and https://bind9.readthedocs.io/en/v9_16_4/
and htt...Bind Arm pdf formatting:
Formatting error in Bind Arm for release 9.16.4 - contents - manual pages and frontispiece
at https://downloads.isc.org/isc/bind9/9.16.4/doc/arm/Bv9ARM.pdf
and https://bind9.readthedocs.io/en/v9_16_4/
and https://bind9.readthedocs.io/en/v9_17_2/
On the Frontispiece - Appendices - Manual Pages - no command names listed just "Synopsis", "Description", "example" ....
https://bind9.readthedocs.io/en/v9_16/ appears to be okhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1987Fix formatting error in man pages section of BIND ARM2020-07-01T21:47:50ZSuzanne GoldlustFix formatting error in man pages section of BIND ARMOne formatting error was missed the first time around.One formatting error was missed the first time around.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1989'rndc dnstap --roll' with too big a argument (>128) can cause a buffer overflow.2020-08-04T11:14:51ZMark Andrews'rndc dnstap --roll' with too big a argument (>128) can cause a buffer overflow.```
1158 if (versions > 0) {
1159 /*
1160 * First we fill 'to_keep' structure using insertion sort
1161 */
5. index_parm: Indexing array of size 2048 with versions minus an offse...```
1158 if (versions > 0) {
1159 /*
1160 * First we fill 'to_keep' structure using insertion sort
1161 */
5. index_parm: Indexing array of size 2048 with versions minus an offset in call to memset. [Note: The source code implementation of the function has been overridden by a builtin model.]
1162 memset(to_keep, 0, versions * sizeof(long long));
1163 while (isc_dir_read(&dir) == ISC_R_SUCCESS) {
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/1990Bad isc_mem_put size.2020-07-16T07:05:26ZMark AndrewsBad isc_mem_put size.```
331 result = dns_rdatatype_fromtext(&types[i++].type, &r);
332 if (result != ISC_R_SUCCESS) {
333 cfg_obj_log(identity, named_g_lctx,
334 ...```
331 result = dns_rdatatype_fromtext(&types[i++].type, &r);
332 if (result != ISC_R_SUCCESS) {
333 cfg_obj_log(identity, named_g_lctx,
334 ISC_LOG_ERROR,
335 "'%.*s' is not a valid type",
336 (int)r.length, str);
CID 302775 (#1 of 1): Sizeof not portable (SIZEOF_MISMATCH)
suspicious_sizeof: Passing argument types of type dns_ssuruletype_t * and argument n * 8UL /* sizeof (types) */ to function isc__mem_put is suspicious. In this case, sizeof (dns_ssuruletype_t *) is equal to sizeof (dns_ssuruletype_t), but this is not a portable assumption.
Did you intend to use sizeof (*types) instead of sizeof (types)?
337 isc_mem_put(mctx, types, n * sizeof(types));
338 goto cleanup;
339 }
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1991Cleanup redundant non-NULL check.2020-07-06T00:30:57ZMark AndrewsCleanup redundant non-NULL check.```
1407 if (sigrdataset != NULL) {
1408 putrdataset(client->mctx, &sigrdataset);
1409 }
CID 288001 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking rctx suggest...```
1407 if (sigrdataset != NULL) {
1408 putrdataset(client->mctx, &sigrdataset);
1409 }
CID 288001 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking rctx suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1410 if (rctx != NULL) {
1411 isc_mutex_destroy(&rctx->lock);
1412 isc_mem_put(mctx, rctx, sizeof(*rctx));
1413 }
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1992Backport primaries and documentation changes to v9.162021-06-28T09:15:09ZOndřej SurýBackport primaries and documentation changes to v9.16* [x] !3703
* [x] !3679
* [x] !3692
* [x] !3644
* [x] !3676
* [x] !3793
* [x] !3591
* [x] !3800* [x] !3703
* [x] !3679
* [x] !3692
* [x] !3644
* [x] !3676
* [x] !3793
* [x] !3591
* [x] !3800February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1993check.c:1576:37: error: expected identifier before numeric constant on illumos2020-07-13T22:52:29ZMichal Nowakcheck.c:1576:37: error: expected identifier before numeric constant on illumosOn OpenIndiana 2020.04 (an illumos distribution) compilation of BIND `v9_16` commit 38ca3fbcdc5c02e2f985d5ff8937d473b50d6aef fails in `lib/bind9/check.c` with:
```
libtool: compile: /usr/gcc/7/bin/gcc -include /export/home/newman/bind9/...On OpenIndiana 2020.04 (an illumos distribution) compilation of BIND `v9_16` commit 38ca3fbcdc5c02e2f985d5ff8937d473b50d6aef fails in `lib/bind9/check.c` with:
```
libtool: compile: /usr/gcc/7/bin/gcc -include /export/home/newman/bind9/config.h -I/export/home/newman/bind9 -I../.. -I. -I/export/home/newman/bind9/lib/bind9/include -I../../lib/bind9/include -I/export/home/newman/bind9/lib/dns/include -I../../lib/dns/include -I/export/home/newman/bind9/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I/export/home/newman/bind9/lib/isccfg/include -I../../lib/isccfg/include -I/export/home/newman/bind9/lib/ns/include -I../../lib/ns/include -DISC_MEM_DEFAULTFILL=1 -DISC_LIST_CHECKINIT=1 -m64 -O3 -D_XOPEN_SOURCE=600 -D__EXTENSIONS__=1 -D_XPG6 -D_POSIX_PTHREAD_SEMANTICS -pthread -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers -fno-strict-aliasing -Wshadow -Werror -c check.c -fPIC -DPIC -o .libs/check.o
In file included from /usr/include/sys/select.h:53:0,
from /usr/include/sys/types.h:640,
from /usr/include/sys/wait.h:37,
from /usr/include/stdlib.h:45,
from check.c:16:
check.c: In function 'check_options':
check.c:1576:37: error: expected identifier before numeric constant
enum { MAS = 1, PRI = 2, SLA = 4, SEC = 8 } values = 0;
^
gmake[2]: *** [Makefile:273: check.lo] Error 1
```
It turns out that `/usr/include/sys/time.h` has `SEC` [defined](https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/time.h#L242).
Renaming `SEC` to `SCN` in `lib/bind9/check.c` does the trick. The introduction of `SEC` was in dca3658720cfb7f40b75e418a87d85552fe2a09c.August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/1994netscope.c:23:50: error: unused parameter 'addr' when HAVE_IF_NAMETOINDEX und...2020-08-05T13:09:26ZMichal Nowaknetscope.c:23:50: error: unused parameter 'addr' when HAVE_IF_NAMETOINDEX undefined on illumosOn OpenIndiana 2020.04 (an illumos distribution) compilation of BIND `main` commit 78a4ed31322271ff324994ab058b8448ae4a2252 fails in `lib/isc/netscope.c` with:
```
netscope.c: In function 'isc_netscope_pton':
netscope.c:23:50: error: unu...On OpenIndiana 2020.04 (an illumos distribution) compilation of BIND `main` commit 78a4ed31322271ff324994ab058b8448ae4a2252 fails in `lib/isc/netscope.c` with:
```
netscope.c: In function 'isc_netscope_pton':
netscope.c:23:50: error: unused parameter 'addr' [-Werror=unused-parameter]
isc_netscope_pton(int af, char *scopename, void *addr, uint32_t *zoneid) {
^~~~
cc1: all warnings being treated as errors
```
It seems that `addr` is used only when `HAVE_IF_NAMETOINDEX` is defined.August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/1995gssapictx.c:681:10: error: implicit declaration of function 'gsskrb5_register...2020-07-16T07:31:53ZMichal Nowakgssapictx.c:681:10: error: implicit declaration of function 'gsskrb5_register_acceptor_identity' on illumosOn OpenIndiana 2020.04 (an illumos distribution) compilation of BIND `main` commit 78a4ed31322271ff324994ab058b8448ae4a2252 fails in `lib/dns/gssapictx.c` with:
```
gssapictx.c: In function 'dst_gssapi_acceptctx':
gssapictx.c:681:10: err...On OpenIndiana 2020.04 (an illumos distribution) compilation of BIND `main` commit 78a4ed31322271ff324994ab058b8448ae4a2252 fails in `lib/dns/gssapictx.c` with:
```
gssapictx.c: In function 'dst_gssapi_acceptctx':
gssapictx.c:681:10: error: implicit declaration of function 'gsskrb5_register_acceptor_identity' [-Werror=implicit-function-declaration]
gret = gsskrb5_register_acceptor_identity(gssapi_keytab);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Perhaps `#if defined(ISC_PLATFORM_GSSAPI_KRB5_HEADER)` around `gsskrb5_register_acceptor_identity()` is missing (like `v9_16` has)?
```patch
--- a/lib/dns/gssapictx.c
+++ b/lib/dns/gssapictx.c
@@ -678,6 +678,7 @@ dst_gssapi_acceptctx(gss_cred_id_t cred, const char *gssapi_keytab,
}
if (gssapi_keytab != NULL) {
+#if defined(ISC_PLATFORM_GSSAPI_KRB5_HEADER) || defined(WIN32)
gret = gsskrb5_register_acceptor_identity(gssapi_keytab);
if (gret != GSS_S_COMPLETE) {
gss_log(3,
@@ -687,6 +688,27 @@ dst_gssapi_acceptctx(gss_cred_id_t cred, const char *gssapi_keytab,
gss_error_tostring(gret, 0, buf, sizeof(buf)));
return (DNS_R_INVALIDTKEY);
}
+#else /* if defined(ISC_PLATFORM_GSSAPI_KRB5_HEADER) || defined(WIN32) */
+ /*
+ * Minimize memory leakage by only setting KRB5_KTNAME
+ * if it needs to change.
+ */
+ const char *old = getenv("KRB5_KTNAME");
+ if (old == NULL || strcmp(old, gssapi_keytab) != 0) {
+ size_t size;
+ char *kt;
+
+ size = strlen(gssapi_keytab) + 13;
+ kt = malloc(size);
+ if (kt == NULL) {
+ return (ISC_R_NOMEMORY);
+ }
+ snprintf(kt, size, "KRB5_KTNAME=%s", gssapi_keytab);
+ if (putenv(kt) != 0) {
+ return (ISC_R_NOMEMORY);
+ }
+ }
+#endif /* if defined(ISC_PLATFORM_GSSAPI_KRB5_HEADER) || defined(WIN32) */
}
log_cred(cred);
```August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/1996[CVE-2020-8620]: A specially crafted large TCP payload can trigger an asserti...2023-03-21T13:42:51ZOndřej Surý[CVE-2020-8620]: A specially crafted large TCP payload can trigger an assertion failure in tcpdns.cNone (published patch date)
TALOS-2020-1100
CVE-2020-8620
Internet Systems Consortium's BIND TCP Receive Buffer Length Assertion Check Denial of Service Vulnerability
### Summary
An assertion failure exists within the Internet Sy...None (published patch date)
TALOS-2020-1100
CVE-2020-8620
Internet Systems Consortium's BIND TCP Receive Buffer Length Assertion Check Denial of Service Vulnerability
### Summary
An assertion failure exists within the Internet Systems Consortium's BIND server versions 9.16.1 through 9.17.1 when processing TCP traffic via the libuv library. Due to a length specified within a callback for the library, flooding the server's TCP port used for larger DNS requests (AXFR) can cause the libuv library to pass a length to the server which will violate an assertion check in the server's verifications. This assertion check will terminate the service resulting in a denial of service condition. An attacker can flood the port with unauthenticated packets in order to trigger this vulnerability.
### Tested Versions
Internet Systems Consortium BIND 9.16.1
Internet Systems Consortium BIND 9.16.2
Internet Systems Consortium BIND 9.16.3
Internet Systems Consortium BIND 9.17.0
Internet Systems Consortium BIND 9.17.1
### Product URLs
[https://www.isc.org/bind](https://www.isc.org/bind)
### CVSSv3 Score
7.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
### CWE
CWE-617 - Reachable Assertion
### Details
The BIND nameserver is considered the reference implementation of the Domain Name System of the Internet. It is capable of being an authoritative name server as well as a recursive cache for domain name queries on a network.
The BIND nameserver is based on a custom event queueing system that wraps around the `libuv` library (http://libuv.org) for performing asynchronous I/O as needed by the server. The `libuv` library was introduced as a new network manager during the release of version 9.16 in order to allow the server to be used on both the Posix and Windows environments and to simplify the management of processing network I/O distributed amongst a configurable number of threads within the server.
The BIND nameserver combines its own queue for scheduling with the `libuv` library in order to process requests and queries asynchronously for both the UDP and TCP protocols. In order to accomplish this, the server must first initialize the `libuv` library by allocating and initializing the `uv_loop_t` which is a handle directly used by the library to manage the event loop used by the server. After the server has initialized its core memory handling functions in the setup phase of the daemon, the `isc_nm_start` function will be used to construct a `uv_loop_t` for a number of workers using the `uv_loop_init` function at [1]. After initializing the loop that is to be used for each worker, the server will then allocate space for a receive buffer at [2] and then assign it into the context of the worker. This loop is then used to bind to the configured UDP and TCP ports as used by the server.
```
lib/isc/netmgr/netmgr.c:142
isc_nm_t *
isc_nm_start(isc_mem_t *mctx, uint32_t workers) {
isc_nm_t *mgr = NULL;
char name[32];
mgr = isc_mem_get(mctx, sizeof(*mgr));
*mgr = (isc_nm_t){ .nworkers = workers };
isc_mem_attach(mctx, &mgr->mctx);
...
r = uv_loop_init(&worker->loop); // [1] Initialize a uv_loop_t for each worker
RUNTIME_CHECK(r == 0);
...
r = uv_async_init(&worker->loop, &worker->async, async_cb);
RUNTIME_CHECK(r == 0);
...
worker->ievents = isc_queue_new(mgr->mctx, 128);
worker->ievents_prio = isc_queue_new(mgr->mctx, 128);
worker->recvbuf = isc_mem_get(mctx, ISC_NETMGR_RECVBUF_SIZE); // [2] Allocate a receive buffer of the size ISC_NETMGR_RECVBUF_SIZE
...
```
After the server has initialized each worker and bound to the configured ports, the server must use `libuv` to assign a callback to dispatch to when receiving a connection on a port. The callback that is used for processing TCP is the following `dnslisten_acceptcb` function. After performing a few validations, at [3] the function will call the `isc_nm_read` function with a callback, `dnslisten_readcb`, as its second parameter. This callback will be stored into a structure and then later passed to `libuv` in order to inform the library what to call when the server needs to read data from a connected TCP client.
```
lib/isc/netmgr/tcpdns.c:98
/*
* Accept callback for TCP-DNS connection.
*/
static void
dnslisten_acceptcb(isc_nmhandle_t *handle, isc_result_t result, void *cbarg) {
isc_nmsocket_t *dnslistensock = (isc_nmsocket_t *)cbarg;
isc_nmsocket_t *dnssock = NULL;
REQUIRE(VALID_NMSOCK(dnslistensock));
REQUIRE(dnslistensock->type == isc_nm_tcpdnslistener);
/* If accept() was unnsuccessful we can't do anything */
if (result != ISC_R_SUCCESS) {
return;
}
...
isc_nm_read(handle, dnslisten_readcb, dnssock); // [3] Pass the dnslisten_readcb callback for reading as a parameter
```
Inside the `isc_nm_read` function, the server will then assign the `dnslisten_readcb` callback that was passed as its second parameter into a `isc_nmsocket_t` structure at [4] as `sock->rcb.recv`. After preparing the `isc_nmsocket_t` structure, the server will fetch a new event and then assign the `isc_nmsocket_t` into it. Eventually at [5], the function will pass the event as the second parameter to the `isc__nm_async_startread` function. The `isc__nm_async_startread` function is directly responsible for calling into the `libuv` library with the necessary callbacks in order for the server to process any received DNS packets.
```
lib/isc/netmgr/tcp.c:521
isc_result_t
isc_nm_read(isc_nmhandle_t *handle, isc_nm_recv_cb_t cb, void *cbarg) {
isc_nmsocket_t *sock = NULL;
isc__netievent_startread_t *ievent = NULL;
...
sock = handle->sock;
sock->rcb.recv = cb; // [4] Store callback into sock
sock->rcbarg = cbarg;
...
ievent = isc__nm_get_ievent(sock->mgr, netievent_tcpstartread);
ievent->sock = sock; // Assign sock into the event
if (sock->tid == isc_nm_tid()) {
isc__nm_async_startread(&sock->mgr->workers[sock->tid], // [5] Pass the event containing the callback as the second parameter
(isc__netievent_t *)ievent);
isc__nm_put_ievent(sock->mgr, ievent);
} else {
...
return (ISC_R_SUCCESS);
}
```
Once inside the `isc__nm_async_startread` function, the `isc_nmsocket_t` will then be extracted from a field belonging to the event. After starting a timer with `libuv` in order to determine when to timeout the connection, the server will execute the `uv_read_start` function at [6]. The `uv_read_start` function belongs to `libuv` and is used in order to inform the library which callbacks to use when allocating space for the receive buffer during processing of a TCP stream and which callback to actually use for processing the data from the buffer that was received. The vulnerability referred to by this document is specifically due to the way these two callbacks are implemented by the server.
```
lib/isc/netmgr/tcp.c:548
void
isc__nm_async_startread(isc__networker_t *worker, isc__netievent_t *ev0) {
isc__netievent_startread_t *ievent = (isc__netievent_startread_t *)ev0;
isc_nmsocket_t *sock = ievent->sock;
int r;
...
r = uv_read_start(&sock->uv_handle.stream, isc__nm_alloc_cb, read_cb); // [6] Use libuv to assign callbacks for reading
...
}
```
When the `libuv` library needs the server to allocate a buffer to receive packet data into, it will call the following function. This function's responsibility is to allocate a buffer to receive packet data into, and then write the buffer along with its length into one of the function's parameters. The `libuv` library provides the `uv_buf_t` object to modify and a suggested size in its arguments. The implementation chosen by the server was to preallocate the read buffer for each worker during the setup process of the worker. Therefore in this function, the server will only need to assign the preallocated buffer and its size at [7] which prevents needing to allocate during the receiving of a packet.
```
lib/isc/netmgr/netmgr.c:972
void
isc__nm_alloc_cb(uv_handle_t *handle, size_t size, uv_buf_t *buf) {
isc_nmsocket_t *sock = uv_handle_get_data(handle);
isc__networker_t *worker = NULL;
REQUIRE(VALID_NMSOCK(sock));
REQUIRE(isc__nm_in_netthread());
REQUIRE(size <= ISC_NETMGR_RECVBUF_SIZE);
worker = &sock->mgr->workers[sock->tid];
INSIST(!worker->recvbuf_inuse);
buf->base = worker->recvbuf; // [7] Assign worker's receive buffer into buf->base
worker->recvbuf_inuse = true;
buf->len = ISC_NETMGR_RECVBUF_SIZE; // [7] Assign the length for the worker's receive buffer.
}
```
The size that was used for the allocation of the receive buffer and is assigned to the buffer length for `libuv` to use is defined in the following file. As described in the comments, this length is taken from the `libuv` source and contains the maximum size of a message on Posix platforms. Due to a smaller buffer size being used for the Windows platforms, the vulnerability described by this document does not affect that class of particular platforms.
```
lib/isc/netmgr/netmgr-int.h:38
#if !defined(WIN32)
/*
* New versions of libuv support recvmmsg on unices.
* Since recvbuf is only allocated per worker allocating a bigger one is not
* that wasteful.
* 20 here is UV__MMSG_MAXWIDTH taken from the current libuv source, nothing
* will break if the original value changes.
*/
#define ISC_NETMGR_RECVBUF_SIZE (20 * 65536)
#else
#define ISC_NETMGR_RECVBUF_SIZE (65536)
#endif
```
After the `libuv` library has dispatched to the allocation callback in order to allocate a buffer to read packet data into, the library can now execute the callback that is responsible for processing the actual data from the packet. The server implements this with the following `read_cb` function. This function will simply take the `uv_buf_t` and length that is passed as parameters to assign them into an `isc_region_t` at [8]. After initializing the `isc_region_t`, the server will then dispatch to the `dnslisten_readcb` callback at [9] that was previously assigned in the `isc_nm_read` function.
```
lib/isc/netmgr/tcp.c:639
static void
read_cb(uv_stream_t *stream, ssize_t nread, const uv_buf_t *buf) {
isc_nmsocket_t *sock = uv_handle_get_data((uv_handle_t *)stream);
REQUIRE(VALID_NMSOCK(sock));
REQUIRE(buf != NULL);
if (nread >= 0) {
isc_region_t region = { .base = (unsigned char *)buf->base, // [8] Initialize the isc_region_t with the buffer and size from libuv
.length = nread };
if (sock->rcb.recv != NULL) {
sock->rcb.recv(sock->tcphandle, ®ion, sock->rcbarg); // [9] Pass the region to the worker's callback
}
...
```
The `dnslisten_readcb` function has the responsibility for taking the packet data that was dispatched as a parameter by `libuv`, and aggregating it into a buffer containing a full DNS packet packet confirming to RFC1035. This is done by taking the packet data and its length from the `region` parameter of the type `isc_region_t` which was initialized by the calling function and using it to grow a buffer that will later be processed. At [10], the packet data and its length are extracted from the `isc_region_t` and assigned into local variables. Once determining the length, it is then used to check if the current packet buffer size that the server will process is large enough to fit the newly read data from the TCP socket. If the sum of the current buffer length and the number of bytes read from the packet is larger than the buffer size, then at [11] the server will use the `alloc_dnsbuf` function to reallocate the buffer to fit the calculated size. After performing the resize, at [12] the server will copy the new packet data from the `isc_region_t` directly into the current packet buffer and then process it at [13].
```
lib/isc/netmgr/tcpdns.c:198
static void
dnslisten_readcb(isc_nmhandle_t *handle, isc_region_t *region, void *arg) {
isc_nmsocket_t *dnssock = (isc_nmsocket_t *)arg;
unsigned char *base = NULL;
bool done = false;
size_t len;
...
base = region->base; // [10] Extract the libuv buffer and its length from the region
len = region->length;
if (dnssock->buf_len + len > dnssock->buf_size) {
alloc_dnsbuf(dnssock, dnssock->buf_len + len); // [11] Allocate the DNS buffer if it is too small
}
memmove(dnssock->buf + dnssock->buf_len, base, len); // [12] Copy new packet data to the end of the current packet buffer
dnssock->buf_len += len;
...
do {
isc_result_t result;
isc_nmhandle_t *dnshandle = NULL;
result = processbuffer(dnssock, &dnshandle); // [13] Process the contents off the packet data
...
```
When reallocating the packet buffer, the following `alloc_dnsbuf` function is used. The comment in front of this function indicates that the buffer size being defined for `NM_BIG_BUF` is for two full DNS packet lengths as this should be enough. However, due to the way that `libuv` works the length that was allocated for the worker receive buffer that was assigned in `isc__nm_alloc_cb` is used instead. This length is `20 * 64k` and is passed to the `read` system call by the `libuv` library. This results in the value of the `len` field that was passed to this function capable of being up to 0x140000 bytes. At [14], an assertion is used to validate that the length is less than the `NM_BIG_BUF` definition. If the length does not validate, then the assertion will log itself and follow up by calling the `abort` library function. This will directly terminate the server resulting in a denial of service condition.
```
lib/isc/netmgr/tcpdns.c:58
/*
* Two full DNS packets with lengths.
* netmgr receives 64k at most so there's no risk
* of overrun.
*/
#define NM_BIG_BUF (65535 + 2) * 2
static inline void
alloc_dnsbuf(isc_nmsocket_t *sock, size_t len) {
REQUIRE(len <= NM_BIG_BUF); // [14] Assertion
if (sock->buf == NULL) {
/* We don't have the buffer at all */
size_t alloc_len = len < NM_REG_BUF ? NM_REG_BUF : NM_BIG_BUF;
sock->buf = isc_mem_allocate(sock->mgr->mctx, alloc_len);
sock->buf_size = alloc_len;
} else {
/* We have the buffer but it's too small */
sock->buf = isc_mem_reallocate(sock->mgr->mctx, sock->buf,
NM_BIG_BUF);
sock->buf_size = NM_BIG_BUF;
}
}
```
### Crash Information
First we attach to the process, and then resume its execution.
```
$ gdb -p `pgrep named`
(gdb) c
Continuing.
```
After running the provided proof-of-concept, gdb will break due to the `SIGABRT` signal that was raised by the assertion.
```
(gdb)
Thread 5 "isc-net-0003" received signal SIGABRT, Aborted.
[Switching to Thread 0x7f95a443a700 (LWP 7)]
0x00007f95a822a18b in raise () from target:/lib/x86_64-linux-gnu/libc.so.6
```
The following backtrace is at the time of the signal being dispatched to the process.
```
(gdb) bt
#0 0x00007f95a822a18b in raise () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f95a8209859 in abort () from target:/lib/x86_64-linux-gnu/libc.so.6
#2 0x0000563409bc75c6 in assertion_failed (file=0x563409f56eff "tcpdns.c", line=66, type=isc_assertiontype_require,
cond=0x563409f56ee8 "len <= (65535 + 2) * 2") at ./main.c:260
#3 0x0000563409e83070 in isc_assertion_failed (file=0x563409f56eff "tcpdns.c", line=66, type=isc_assertiontype_require,
cond=0x563409f56ee8 "len <= (65535 + 2) * 2") at assertions.c:46
#4 0x0000563409ea9453 in alloc_dnsbuf (sock=0x7f9598ce6be0, len=1310749) at tcpdns.c:66
#5 0x0000563409ea9d2a in dnslisten_readcb (handle=0x7f957c003180, region=0x7f95a44369b0, arg=0x7f9598ce6be0) at tcpdns.c:223
#6 0x0000563409ea696a in read_cb (stream=0x7f9598ce6920, nread=1310720, buf=0x7f95a4436a20) at tcp.c:651
#7 0x00007f95a841bad1 in ?? () from target:/lib/x86_64-linux-gnu/libuv.so.1
#8 0x00007f95a841c608 in ?? () from target:/lib/x86_64-linux-gnu/libuv.so.1
#9 0x00007f95a8421ab0 in uv.io_poll () from target:/lib/x86_64-linux-gnu/libuv.so.1
#10 0x00007f95a84117ac in uv_run () from target:/lib/x86_64-linux-gnu/libuv.so.1
#11 0x0000563409ea0bc2 in nm_thread (worker0=0x56340b6dd048) at netmgr.c:481
#12 0x00007f95a83e5609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#13 0x00007f95a8306103 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
```
In frame 5 belonging to the `dnslisten_readcb` function, we can see that the region length corresponds directly to the value defined for `ISC_NETMGR_RECVBUF_SIZE`.
```
(gdb) frame 5
#5 0x0000563409ea9d2a in dnslisten_readcb (handle=0x7f957c003180, region=0x7f95a44369b0, arg=0x7f9598ce6be0) at tcpdns.c:223
223 alloc_dnsbuf(dnssock, dnssock->buf_len + len);
(gdb) p *regio
$3 = {base = 0x7f95a443b010 "l", length = 1310720}
The current buffer size that is to be grown is only 0x20002 bytes.
(gdb) p dnssock.buf_size
$7 = 131074
(gdb) p dnssock.buf_len
$8 = 29
```
### Exploit Proof of Concept
To use the provided proof-of-concept, it must first be modified. Change both the DST_IP and DST_PORT variables to point to the host the BIND daemon is listening on, and then run it with Python 2.x.
### Mitigation
Flood protection could mitigate this denial of service if configured properly.
### Credit
Discovered by Emanuel Almeida of Cisco Systems, Inc..
https://talosintelligence.com/vulnerability_reports/
### Timeline
None - Vendor Disclosure
None - Public ReleaseAugust 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/1997[CVE-2020-8621] Attempting QNAME minimization after forwarding can lead to an...2020-09-11T09:02:40ZOndřej Surý[CVE-2020-8621] Attempting QNAME minimization after forwarding can lead to an assertion failure in resolver.c### Summary
Similar to issue 1219, I am getting repeated periodic bind crashes. I am on Ubuntu Server 20.04 LTS, fully patched and up to date. This is installed from the ISC Bind9 PPA using the focal release.
### BIND version used
``...### Summary
Similar to issue 1219, I am getting repeated periodic bind crashes. I am on Ubuntu Server 20.04 LTS, fully patched and up to date. This is installed from the ISC Bind9 PPA using the focal release.
### BIND version used
```
BIND 9.16.4-Ubuntu (Stable Release) <id:0849b42>
running on Linux x86_64 5.4.0-33-generic #37-Ubuntu SMP Thu May 21 12:53:59 UTC 2020
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64
-linux-gnu' '--libexecdir=/usr/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads'
'--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-libjson-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=
no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-cWwckC/bind9-9.16.4=. -fstack-protector-strong -Wformat -
Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.3.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
Not sure, named is running fine and suddenly I will notice resolving slows on clients as DNS reverts to the secondary resolver, upon checking the service status it is "failed" in systemd. The service restarts but then crashes intermittently, approximately every 1-3 days.
### What is the current *bug* behavior?
Service fails and resolving stops.
### What is the expected *correct* behavior?
Service should not fail/stop
### Relevant configuration files
```
root@HOST:~# named-checkconf -px
...
```
[Sanitized by @mnowak.]
### Relevant logs and/or screenshots
Console output of /var/log/bind/bind.log
```
30-Jun-2020 00:00:02.536 general: notice: all zones loaded
30-Jun-2020 00:00:02.536 general: notice: running
30-Jun-2020 10:19:36.354 general: critical: resolver.c:5104: INSIST(dns_name_issubdomain(&fctx->name, &fctx->domain)) failed, back trace
30-Jun-2020 10:19:36.354 general: critical: #0 0x55b9b83ff083 in ??
30-Jun-2020 10:19:36.354 general: critical: #1 0x7f4ea095cac0 in ??
30-Jun-2020 10:19:36.354 general: critical: #2 0x7f4ea0b26675 in ??
30-Jun-2020 10:19:36.354 general: critical: #3 0x7f4ea0b29e90 in ??
30-Jun-2020 10:19:36.354 general: critical: #4 0x7f4ea0b2fdb8 in ??
30-Jun-2020 10:19:36.354 general: critical: #5 0x7f4ea0b348a1 in ??
30-Jun-2020 10:19:36.354 general: critical: #6 0x7f4ea0984d51 in ??
30-Jun-2020 10:19:36.354 general: critical: #7 0x7f4ea0425609 in ??
30-Jun-2020 10:19:36.354 general: critical: #8 0x7f4ea034c103 in ??
30-Jun-2020 10:19:36.354 general: critical: exiting (due to assertion failure)
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1998ddns-confgen should be an alias to tsig-keygen, not the other way around2021-02-03T11:26:17ZEvan Huntddns-confgen should be an alias to tsig-keygen, not the other way aroundSome releases back we modified `ddns-confgen` so that it would behave differently if called as `tsig-keygen`, and then deprecated the use of `dnssec-keygen` to generate TSIG keys. That's the primary use of that tool now, and it's what I ...Some releases back we modified `ddns-confgen` so that it would behave differently if called as `tsig-keygen`, and then deprecated the use of `dnssec-keygen` to generate TSIG keys. That's the primary use of that tool now, and it's what I think people are most likely to want to look up, but in a discussion with @sgoldlust I noticed that the manual page is still titled `ddns-confgen` and it's listed that way in the table of contents; `tsig-keygen` does not appear.
There doesn't seem to be any way to have the same man page listed twice when it documents two commands, but we should have it listed with the more useful name.
(Perhaps we could add a new man page for `ddns-confgen` that just links to the `tsig-keygen` man page, if we want them both to appear in the TOC.)August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1999Add a regular "make dist" job to CI2020-07-24T13:53:56ZMichal NowakAdd a regular "make dist" job to CIIt's easy to break `make dist` on `main`, we should test this scenario regularly, to prevent surprises like https://gitlab.isc.org/isc-private/bind9/-/jobs/1006996.It's easy to break `make dist` on `main`, we should test this scenario regularly, to prevent surprises like https://gitlab.isc.org/isc-private/bind9/-/jobs/1006996.August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2000[v9_17_2] autogen.sh has been removed2020-07-03T09:05:56ZJean-Christophe Manciot[v9_17_2] autogen.sh has been removed- what is the rationale behind this decision?
- is ```autoreconf -f -i``` still appropriate?- what is the rationale behind this decision?
- is ```autoreconf -f -i``` still appropriate?https://gitlab.isc.org/isc-projects/bind9/-/issues/2001kasp, statschannel and rpzextra tests fail2020-07-03T17:42:45ZJean-Christophe Manciotkasp, statschannel and rpzextra tests fail- Ubuntu 20.04
- tag: v9_17_2
The first failure is identical to [an already reported issue](https://gitlab.isc.org/isc-projects/bind9/-/issues/1939).
Building & testing bind9 with:
```
autoreconf -f -i
./configure --build=x86_64-pc-li...- Ubuntu 20.04
- tag: v9_17_2
The first failure is identical to [an already reported issue](https://gitlab.isc.org/isc-projects/bind9/-/issues/1939).
Building & testing bind9 with:
```
autoreconf -f -i
./configure --build=x86_64-pc-linux-gnu \
--prefix=/usr --sysconfdir=/etc/bind --localstatedir=/ \
--datarootdir=/usr/share --docdir=/usr/share/doc --mandir=/usr/share/man \
--disable-native-pkcs11 \
--disable-querytrace \
--enable-auto-validation \
--enable-developer \
--enable-dnstap \
--enable-fixed-rrset \
--enable-full-report \
--enable-largefile \
--enable-linux-caps \
--enable-shared=yes \
--enable-static=yes \
--with-cmocka=yes \
--with-gnu-ld=yes \
--with-gperftools-profiler=yes \
--with-gssapi=/usr/bin/krb5-config \
--with-json-c=yes \
--with-libidn2 \
--with-libxml2=yes \
--with-lmdb=auto \
--with-maxminddb=yes \
--with-openssl=/usr/lib/x86_64-linux-gnu \
--with-tuning=large \
--with-zlib=yes
make all
bin/tests/system/ifconfig.sh up
make check
```
leads to: [test-suite.log](/uploads/0a11a1ac6148bdf6fe5dfaf535c9324f/test-suite.log)
Full log: [bind9_9_17_2_amd64.build.log](/uploads/a294c51d3bebb59194477f33e29df50a/bind9_9_17_2_amd64.build.log)