BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-10-04T10:20:58Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2913Release checklist for BIND is missing a step for the official docker image2021-10-04T10:20:58ZHåkan LindqvistRelease checklist for BIND is missing a step for the official docker image<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
The release checklist used for BIND releases (see eg https://gitlab.isc.org/isc-projects/bind9/-/issues/2893) does not have a step for publishing the official docker image, and new versions of said docker image seems to generally not get released unless users voice complaints.
### BIND version used
N/A
### Steps to reproduce
* Observe that a new BIND version has been announced by ISC
* Try to redeploy your containers to get the new version
### What is the current *bug* behavior?
There is usually no new docker image available
### What is the expected *correct* behavior?
There should be a new docker image available as part of the release
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
N/A
### Possible fixes
My thinking is that if this step is added to the release checklist, whatever issues cause the docker image to not be published will be found internally by ISC and fixed.October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2924heap-use-after-free caused by checking for duplicate "http" configurations2021-10-04T10:15:31ZArtem Boldarievheap-use-after-free caused by checking for duplicate "http" configurationsChecking for duplicate `http` clauses in configuration files leads to heap use after free.
```
=================================================================
==1833==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300002b...Checking for duplicate `http` clauses in configuration files leads to heap use after free.
```
=================================================================
==1833==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300002b420 at pc 0x7fbcc0f4c4f2 bp 0x7ffdd9e9a170 sp 0x7ffdd9e99920
READ of size 1 at 0x60300002b420 thread T0
#0 0x7fbcc0f4c4f1 (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb64f1)
#1 0x7fbcc0b2dacd in isc_symtab_define /builds/isc-projects/bind9/lib/isc/symtab.c:221
#2 0x7fbcbe556dfc in bind9_check_httpserver /builds/isc-projects/bind9/lib/bind9/check.c:2046
#3 0x7fbcbe556dfc in bind9_check_httpservers /builds/isc-projects/bind9/lib/bind9/check.c:2111
#4 0x7fbcbe556dfc in bind9_check_namedconf /builds/isc-projects/bind9/lib/bind9/check.c:5692
#5 0x55798af6ceb7 in main /builds/isc-projects/bind9/bin/check/named-checkconf.c:726
#6 0x7fbcbd83e09a in __libc_start_main ../csu/libc-start.c:308
#7 0x55798af697c9 in _start (/builds/isc-projects/bind9/bin/check/.libs/named-checkconf+0xa7c9)
0x60300002b420 is located 0 bytes inside of 18-byte region [0x60300002b420,0x60300002b432)
freed by thread T0 here:
#0 0x7fbcc0f7efb0 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe8fb0)
#1 0x7fbcc0ac2ca6 in sdallocx /builds/isc-projects/bind9/lib/isc/jemalloc_shim.h:39
#2 0x7fbcc0ac2ca6 in mem_put /builds/isc-projects/bind9/lib/isc/mem.c:361
#3 0x7fbcc0ac2ca6 in isc__mem_free /builds/isc-projects/bind9/lib/isc/mem.c:977
#4 0x7fbcbe556e22 in bind9_check_httpserver /builds/isc-projects/bind9/lib/bind9/check.c:2066
#5 0x7fbcbe556e22 in bind9_check_httpservers /builds/isc-projects/bind9/lib/bind9/check.c:2111
#6 0x7fbcbe556e22 in bind9_check_namedconf /builds/isc-projects/bind9/lib/bind9/check.c:5692
#7 0x55798af6ceb7 in main /builds/isc-projects/bind9/bin/check/named-checkconf.c:726
#8 0x7fbcbd83e09a in __libc_start_main ../csu/libc-start.c:308
previously allocated by thread T0 here:
#0 0x7fbcc0f7f330 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
#1 0x7fbcc0ac1020 in mallocx /builds/isc-projects/bind9/lib/isc/jemalloc_shim.h:29
#2 0x7fbcc0ac1020 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:341
#3 0x7fbcc0ac1020 in isc__mem_allocate /builds/isc-projects/bind9/lib/isc/mem.c:886
#4 0x7fbcc0ac429b in isc__mem_strdup /builds/isc-projects/bind9/lib/isc/mem.c:996
#5 0x7fbcbe556d8b in bind9_check_httpserver /builds/isc-projects/bind9/lib/bind9/check.c:2039
#6 0x7fbcbe556d8b in bind9_check_httpservers /builds/isc-projects/bind9/lib/bind9/check.c:2111
#7 0x7fbcbe556d8b in bind9_check_namedconf /builds/isc-projects/bind9/lib/bind9/check.c:5692
#8 0x55798af6ceb7 in main /builds/isc-projects/bind9/bin/check/named-checkconf.c:726
#9 0x7fbcbd83e09a in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: heap-use-after-free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb64f1)
Shadow bytes around the buggy address:
0x0c067fffd630: 00 00 00 fa fa fa 00 00 02 fa fa fa 00 00 00 fa
0x0c067fffd640: fa fa 00 00 00 fa fa fa 00 00 00 00 fa fa 00 00
0x0c067fffd650: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 00 fa fa
0x0c067fffd660: 00 00 02 fa fa fa 00 00 00 fa fa fa 00 00 00 fa
0x0c067fffd670: fa fa 00 00 00 00 fa fa 00 00 02 fa fa fa 00 00
=>0x0c067fffd680: 00 fa fa fa[fd]fd fd fa fa fa 00 00 02 fa fa fa
0x0c067fffd690: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fffd6a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fffd6b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fffd6c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fffd6d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==1833==ABORTING
```
The problem was found by accident while working on a similar code in !5444October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2908rwlock with reader and writer both waiting2021-10-04T10:14:27ZMark Andrewsrwlock with reader and writer both waitingJob [#1982153](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1982153) failed for 495539142625d5007b638cc55bdfeecd610e8348:
```
Thread 3 (Thread 0x7f9a7f7ff700 (LWP 22482)):
#0 0x00007f9a82273a35 in pthread_cond_wait@@GLIBC_2.3.2 () f...Job [#1982153](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1982153) failed for 495539142625d5007b638cc55bdfeecd610e8348:
```
Thread 3 (Thread 0x7f9a7f7ff700 (LWP 22482)):
#0 0x00007f9a82273a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f9a8507e2c4 in isc__rwlock_lock (type=isc_rwlocktype_read, rwl=0x7f9a6ca50d48) at rwlock.c:327
No locals.
#2 isc_rwlock_lock (rwl=0x7f9a6ca50d48, type=type@entry=isc_rwlocktype_read) at rwlock.c:435
cnt = 101
spins = 8
max_cnt = 100
#3 0x00007f9a84ce2ab0 in zone_find (db=0x7f9a6ca50c00, name=0x7f9a7f7fa068, version=0x7f9a6ca5cb00, type=1, options=0, now=<optimized out>, nodep=0x0, foundname=0x7f9a7f7f8f30, rdataset=0x0, sigrdataset=0x0) at rbtdb.c:4043
node = 0x0
result = <optimized out>
search = {rbtdb = 0x7f9a6ca50c00, rbtversion = 0x7f9a6ca5cb00, serial = 2, options = 0, chain = {magic = 808267821, end = 0x0, levels = {0x0 <repeats 254 times>}, level_count = 0, level_matches = 0}, copy_name = false, need_cleanup = false, wild = false, zonecut = 0x0, zonecut_rdataset = 0x0, zonecut_sigrdataset = 0x7f9a84e01418, zonecut_name = {name = {magic = 1145983854, ndata = 0x0, length = 0, labels = 0, attributes = 0, offsets = 0x7f9a7f7f8c70 " validity", buffer = 0x7f9a7f7f8cf0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0, tail = 0x0}}, offsets = " validity", '\000' <repeats 16 times>, "\f\245l\232\177\000\000\370\220\177\177\232\177\000\000\000\f\245l\232\177\000\000\370\220\177\177\232\177\000\000\000\000\000\000\000\000\000\000\340\220\177\177\232\177\000\000>\315\315\204\232\177", '\000' <repeats 35 times>, "\215\177\177\232\177\000\000\032\300\307\204\232\177\000", buffer = {magic = 1114990113, base = 0x7f9a7f7f8d30, length = 255, used = 0, current = 0, active = 0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false}, data = "\000\000\000\000\000\000\000\000\200\220\177\177\232\177\000\000\270\233\177\177\232\177\000\000\300\215\177\177\232\177", '\000' <repeats 18 times>, "\005", '\000' <repeats 15 times>, "\320\216\177\177\232\177\000\000\314\\\313\204\232\177\000\000\300\355\263l\232\177\000\000", '\377' <repeats 12 times>, "\001\000\000\000\354\216\177\177\232\177\000\000\000\t", '\000' <repeats 22 times>, "p\216\177\177\232\177", '\000' <repeats 99 times>...}, now = 0}
cname_ok = true
close_version = true
maybe_zonecut = false
at_zonecut = false
wild = false
empty_node = <optimized out>
header = <optimized out>
header_next = <optimized out>
found = <optimized out>
nsecheader = <optimized out>
foundsig = <optimized out>
cnamesig = <optimized out>
nsecsig = <optimized out>
sigtype = <optimized out>
active = <optimized out>
lock = <optimized out>
tree = 0xd70
#4 0x00007f9a84c600cc in dns_db_find (db=db@entry=0x7f9a6ca50c00, name=name@entry=0x7f9a7f7fa068, version=version@entry=0x0, type=type@entry=1, options=options@entry=0, now=now@entry=0, nodep=nodep@entry=0x0, foundname=foundname@entry=0x7f9a7f7f8f30, rdataset=rdataset@entry=0x0, sigrdataset=sigrdataset@entry=0x0) at db.c:500
No locals.
#5 0x00007f9a84d8fda2 in zone_check_mx (zone=zone@entry=0x7f9a6ca1ba00, db=db@entry=0x7f9a6ca50c00, name=name@entry=0x7f9a7f7fa068, owner=owner@entry=0x7f9a7f7fa140) at zone.c:2826
result = <optimized out>
ownerbuf = '\000' <repeats 352 times>...
namebuf = '\000' <repeats 496 times>...
altbuf = '\000' <repeats 16 times>, "!fuB\232\177\000\000\220\221\177\177\232\177\000\000\377", '\000' <repeats 15 times>, '\377' <repeats 16 times>, "\000\000\000\000\000\000\000\000\000\233\177\177\232\177\000\000\000\313\245l\232\177\000\000\000\f\245l\232\177\000\000nSND\000\000\000\000\260\222\177\177\232\177\000\000\016\000\000\000\003\000\000\000\001\000\000\000\000\000\000\000\360\221\177\177\232\177\000\000p\222\177\177\232\177\000\000", '\377' <repeats 16 times>, '\000' <repeats 17 times>, "\004\r", '\000' <repeats 29 times>...
fixed = {name = {magic = 1145983854, ndata = 0x0, length = 0, labels = 0, attributes = 0, offsets = 0x7f9a7f7f8f80 '\377' <repeats 16 times>, buffer = 0x7f9a7f7f9000, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0, tail = 0x0}}, offsets = '\377' <repeats 16 times>, '\000' <repeats 17 times>, "\221\177\177\232\177\000\000\314\\\313\204\232\177\000\000 \234\177\177\232\177\000\000", '\377' <repeats 12 times>, "\001\000\000\000\034\221\177\177\232\177\000\000\000\t\177\177\232\177\000\000\256\240\320\204\232\177\000\000nSND\232\177\000\000\032?/l\232\177\000\000\016\000\000\000\003\000\000\000\001\000\000\000\232\177\000", buffer = {magic = 1114990113, base = 0x7f9a7f7f9040, length = 255, used = 0, current = 0, active = 0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false}, data = "\000\000\000\000\000\000\000\000\260\233\177\177\232\177\000\000\000\004\r\000\000\000\000\000 \234\177\177\232\177\000\000\000\000\000\000\232\177\000\000p\204\066l\232\177\000\000 \221\177\177\232\177\000\000\000\f\245l\232\177\000\000nSND", '\000' <repeats 28 times>, "\320\220\177\177\232\177\000\000P\221\177\177\232\177\000\000", '\377' <repeats 16 times>, '\000' <repeats 16 times>, "\224\263\177\177\232\177\000\000P\234\177\177\232\177\000\000\000\221\177\177\232\177\000\000\233\316\315\204\232\177\000\000P\234\177\177\232\177\000\000\000\000\000\000\000\000\000\000 \221\177\177\232\177\000\000"...}
foundname = 0x7f9a7f7f8f30
level = -4
#6 0x00007f9a84db5aaf in integrity_checks (db=0x7f9a6ca50c00, zone=0x7f9a6ca1ba00) at zone.c:3385
mx = {common = {rdclass = 1, rdtype = 15, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}}, mctx = 0x0, pref = 10, mx = {magic = 1145983854, ndata = 0x7f9a6c2f3c1c "\004mail\bmanykeys", length = 15, labels = 3, attributes = 1, offsets = 0x0, buffer = 0x0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0, tail = 0x0}}}
srv = {common = {rdclass = 41328, rdtype = 32639, link = {prev = 0x7f9a84cd8a6e <add32+3723>, next = 0x7f9a7f7fa6f0}}, mctx = 0x7f9a6c8be51a, priority = 41328, weight = 32639, port = 32666, target = {magic = 0, ndata = 0x7f9a6c85d840 '\336' <repeats 200 times>..., length = 0, labels = 0, attributes = 1821107340, offsets = 0x7f000101017a <Address 0x7f000101017a out of bounds>, buffer = 0x100000009, link = {prev = 0x800000001, next = 0x7f9a6c368550}, list = {head = 0x7f9a6ca5c080, tail = 0x7f9a6c328a60}}}
result = <optimized out>
node = 0x7f9a6c368550
bottom = 0x7f9a7f7fa350
ok = true
fixed = {name = {magic = 1145983854, ndata = 0x7f9a7f7fa250 "\001a\bmanykeys", length = 12, labels = 3, attributes = 1, offsets = 0x7f9a7f7fa190 "", buffer = 0x7f9a7f7fa210, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0, tail = 0x0}}, offsets = "\000\002\v\000\232\177\000\000g\265\360\201\232\177\000\000\200\344\213l\232\177\000\000\236\000\000\000\232\177\000\000\016\260\231l\232\177\000\000P\205\066l\232\177\000\000\000\260\231l\232\177\000\000\000\336\205l\232\177\000\000\360\246\177\177\232\177\000\000\000\017\245l\232\177\000\000`\264\177\177\232\177\000\000\340\262\177\177\232\177\000\000\220\247\177\177\232\177\000\000k\031\311\204\232\177\000\000\000\000\000\000\000\000\000\000`\264\177\177\232\177\000", buffer = {magic = 1114990113, base = 0x7f9a7f7fa250, length = 255, used = 12, current = 0, active = 0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false}, data = "\001a\bmanykeys\000", '\377' <repeats 12 times>, "\000\000\000\000\000\000\000\000\001\000\016\002,\001\000\000n\364Ba]\346Ba\333\331\000\000\000\000\000\000nSND\000\000\000\000\216\361\066l\232\177\000\000\n\000\000\000\002\000\000\000\001\000\000\000#\001\000\000(\247\177\177\232\177\000\000\b\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\000\247\177\177\232\177\000\000\210\221\006\205\232\177\000\000\000\000\000\000\000\000\000\000`\000\202\177\232\177\000\000\230\361\066l\232\177\000\000\001\000\000\000\000\000\000\000\220\243\177\177\232\177\000\000\200|\202\177\232\177\000\000\001\000\000\000\000\000\000\000\376\377\377\377\000\000\000\000@\243\177\177\232\177\000\000"...}
ns = {common = {rdclass = 58544, rdtype = 27787, link = {prev = 0x7f9a7f7f9f10, next = 0x7f9a7f7f9f50}}, mctx = 0x7f9a84d0060e <dns_rdata_compare+2390>, name = {magic = 1815539716, ndata = 0x7f9a0000011c <Address 0x7f9a0000011c out of bounds>, length = 1815540000, labels = 32666, attributes = 92, offsets = 0x0, buffer = 0x2, link = {prev = 0x7f9a42756621, next = 0x7f9a7f7f9f80}, list = {head = 0xff, tail = 0x0}}}
rdata = {data = 0x7f9a6c2f3c1a "", length = 17, rdclass = 1, type = 15, flags = 0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}}
name = 0x7f9a7f7fa140
have_txt = <optimized out>
dbiterator = 0x7f9a6c36d000
rdataset = {magic = 1145983826, methods = 0x7f9a8502e580 <rdataset_methods>, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, rdclass = 1, type = 15, ttl = 300, trust = 9, covers = 0, attributes = 0, count = 125, resign = 0, private1 = 0x7f9a6ca50c00, private2 = 0x7f9a6c368550, private3 = 0x7f9a6c2f3c10, privateuint4 = 0, private5 = 0x7f9a6c2f3c16, private6 = 0x0, private7 = 0x0}
fixedbottom = {name = {magic = 1145983854, ndata = 0x0, length = 0, labels = 0, attributes = 0, offsets = 0x7f9a7f7fa3a0 "\020", buffer = 0x7f9a7f7fa420, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0, tail = 0x0}}, offsets = "\020\000\000\000\232\177\000\000\270\243\177\177\333\331\000\000`\262\000\000#\001\000\000\001\000\000\000\000\000\000\000\340\244\177\177\232\177\000\000\001\000\000\000:\000\000\000+\000\000\000#\000\000\000\026\000\000\000\000\000\000\000\020\244\177\177\232\177\000\000\200|\202\177\232\177\000\000`\262\177\177\232\177\000\000\000\000\000\000\000\000\000\000 \324\205l\232\177\000\000\026\000\000\000\000\000\000\000\060\245\177\177\232\177\000\000\066\065\322\204\232\177\000", buffer = {magic = 1114990113, base = 0x7f9a7f7fa460, length = 255, used = 0, current = 0, active = 0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false}, data = "\260\232\240l\232\177\000\000\200|\202\177\232\177\000\000\060\245\177\177\232\177\000\000\250\366\006\205\232\177\000\000\270\232\240l\232\177\000\000\330\244\177\177\232\177\000\000\340\244\177\177\232\177", '\000' <repeats 27 times>, "\260\231l\232\177\000\000\000 \000\000\000\000\000\000\000\000\000\000#\001\000\000\060\247\177\177\232\177\000\000\377\377\377\377\004\000\000\000\003\000\000\000/\000\000\002\001\000\000\000\232\177\000\000\000\260\231l\232\177\000\000\t\000\000\000\000\000\000\000\337\211\305\204\232\177\000\000\060\245\177\177\232\177\000\000\000\000\000\000\000\000\000\000\200|\202\177\232\177\000\000=\000\000\000\000\000\000\000\240\251\207l\232\177\000\000"...}
have_spf = <optimized out>
#7 zone_postload (zone=zone@entry=0x7f9a6ca1ba00, db=0x7f9a6ca50c00, loadtime=..., result=<optimized out>, result@entry=0) at zone.c:5026
soacount = 1
nscount = 1
errors = 0
serial = 5
oldserial = 32666
refresh = 20
retry = 20
expire = 1814400
minimum = 3600
soattl = 300
now = {seconds = 1631777918, nanoseconds = 192228013}
needdump = true
fixjournal = false
hasinclude = false
nomaster = <optimized out>
had_db = false
inc = <optimized out>
is_dynamic = <optimized out>
#8 0x00007f9a84db85f1 in zone_load (zone=0x7f9a6ca1ba00, flags=0, locked=locked@entry=true) at zone.c:2347
result = 0
now = {seconds = 1631777918, nanoseconds = 192228013}
loadtime = {seconds = 1631777901, nanoseconds = 856299706}
db = 0x7f9a6ca50c00
rbt = <optimized out>
is_dynamic = <optimized out>
#9 0x00007f9a84db87f3 in zone_asyncload (task=0x7f9a753755c0, event=0x0) at zone.c:2380
asl = 0x7f9a6c87aa20
zone = 0x7f9a6ca1ba00
result = <optimized out>
#10 0x00007f9a8508c9ad in task_run (task=0x7f9a753755c0) at task.c:827
dispatch_count = 0
finished = false
event = 0x7f9a6c368160
result = 0
#11 isc_task_run (task=0x7f9a753755c0) at task.c:907
No locals.
#12 0x00007f9a8504def0 in isc__nm_async_task (worker=worker@entry=0x7f9a7f829000, ev0=ev0@entry=0x7f9a6c240f00) at netmgr/netmgr.c:827
ievent = 0x7f9a6c240f00
result = <optimized out>
#13 0x00007f9a85053a51 in process_netievent (worker=worker@entry=0x7f9a7f829000, ievent=0x7f9a6c240f00) at netmgr/netmgr.c:906
No locals.
#14 0x00007f9a850542d5 in process_queue (worker=worker@entry=0x7f9a7f829000, type=type@entry=NETIEVENT_TASK) at netmgr/netmgr.c:998
stop = <optimized out>
waiting = 0
ievent = <optimized out>
#15 0x00007f9a850549d7 in process_all_queues (worker=0x7f9a7f829000) at netmgr/netmgr.c:746
result = <optimized out>
type = 2
reschedule = false
#16 async_cb (handle=0x7f9a7f829360) at netmgr/netmgr.c:775
worker = 0x7f9a7f829000
#17 0x00007f9a8304ba33 in uv__async_io () from /lib64/libuv.so.1
No symbol table info available.
#18 0x00007f9a8305ccb3 in uv__io_poll () from /lib64/libuv.so.1
No symbol table info available.
#19 0x00007f9a8304c260 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#20 0x00007f9a850543ac in nm_thread (worker0=0x7f9a7f829000) at netmgr/netmgr.c:681
r = <optimized out>
worker = 0x7f9a7f829000
mgr = 0x7f9a7f823180
#21 0x00007f9a85093076 in isc__trampoline_run (arg=0x1ea5ad0) at trampoline.c:185
trampoline = 0x1ea5ad0
result = <optimized out>
#22 0x00007f9a8226fea5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#23 0x00007f9a81f989fd in clone () from /lib64/libc.so.6
No symbol table info available.
```
```
Thread 9 (Thread 0x7f9a7d7ff700 (LWP 22484)):
#0 0x00007f9a82273a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f9a8507e4c6 in isc__rwlock_lock (type=isc_rwlocktype_write, rwl=0x7f9a6ca50d48) at rwlock.c:409
prev_writer = <optimized out>
#2 isc_rwlock_lock (rwl=rwl@entry=0x7f9a6ca50d48, type=type@entry=isc_rwlocktype_write) at rwlock.c:435
cnt = 101
spins = 8
max_cnt = 100
#3 0x00007f9a84ce06b8 in cleanup_dead_nodes_callback (task=0x7f9a75374fc0, event=0x7f9a6c368630) at rbtdb.c:2461
rbtdb = 0x7f9a6ca50c00
again = false
locknum = <optimized out>
#4 0x00007f9a8508c9ad in task_run (task=0x7f9a75374fc0) at task.c:827
dispatch_count = 0
finished = false
event = 0x7f9a6c368630
result = 0
#5 isc_task_run (task=0x7f9a75374fc0) at task.c:907
No locals.
#6 0x00007f9a8504def0 in isc__nm_async_task (worker=worker@entry=0x7f9a7f829960, ev0=ev0@entry=0x7f9a7f827c80) at netmgr/netmgr.c:827
ievent = 0x7f9a7f827c80
result = <optimized out>
#7 0x00007f9a85053a51 in process_netievent (worker=worker@entry=0x7f9a7f829960, ievent=0x7f9a7f827c80) at netmgr/netmgr.c:906
No locals.
#8 0x00007f9a850542d5 in process_queue (worker=worker@entry=0x7f9a7f829960, type=type@entry=NETIEVENT_TASK) at netmgr/netmgr.c:998
stop = <optimized out>
waiting = 1
ievent = <optimized out>
#9 0x00007f9a850549d7 in process_all_queues (worker=0x7f9a7f829960) at netmgr/netmgr.c:746
result = <optimized out>
type = 2
reschedule = false
#10 async_cb (handle=0x7f9a7f829cc0) at netmgr/netmgr.c:775
worker = 0x7f9a7f829960
#11 0x00007f9a8304ba33 in uv__async_io () from /lib64/libuv.so.1
No symbol table info available.
#12 0x00007f9a8305ccb3 in uv__io_poll () from /lib64/libuv.so.1
No symbol table info available.
#13 0x00007f9a8304c260 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#14 0x00007f9a850543ac in nm_thread (worker0=0x7f9a7f829960) at netmgr/netmgr.c:681
r = <optimized out>
worker = 0x7f9a7f829960
mgr = 0x7f9a7f823180
#15 0x00007f9a85093076 in isc__trampoline_run (arg=0x1ea2050) at trampoline.c:185
trampoline = 0x1ea2050
result = <optimized out>
#16 0x00007f9a8226fea5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#17 0x00007f9a81f989fd in clone () from /lib64/libc.so.6
No symbol table info available.
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/2910"unknown" system test doesn't leave forensics2021-10-04T10:09:09ZMark Andrews"unknown" system test doesn't leave forensicsJob [#1984661](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1984661) failed for dff1b270e552947936eda07821fcd08ba9716f9a:Job [#1984661](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1984661) failed for dff1b270e552947936eda07821fcd08ba9716f9a:October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/2902wrong default is used for HTTP port2021-10-04T09:33:00ZEvan Huntwrong default is used for HTTP portNoticed while looking at code, if the HTTP (non-encrypted) listening port is specified on the command line, the wrong value is used for the listener.
```
} else if (http && !do_tls) {
if (named_g_ht...Noticed while looking at code, if the HTTP (non-encrypted) listening port is specified on the command line, the wrong value is used for the listener.
```
} else if (http && !do_tls) {
if (named_g_httpport != 0) {
port = named_g_port;
```
This means if you ran `named -p http=N`, it would try to listen for HTTP connections on port 53.October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/28666b0b0c6aba2488f8db5d6cdbc44162b98ffa5ed4 breaks using with MIT Kerberos2021-10-04T09:27:12ZMichael Osipov6b0b0c6aba2488f8db5d6cdbc44162b98ffa5ed4 breaks using with MIT Kerberos### Summary
Change in 6b0b0c6aba2488f8db5d6cdbc44162b98ffa5ed4 passes incorrect args to `krb5-config`.
### BIND version used
bind-9.16.19
### Steps to reproduce
Try compile with Kerberos 5 release 1.19.2 and pass to `./configure` `-...### Summary
Change in 6b0b0c6aba2488f8db5d6cdbc44162b98ffa5ed4 passes incorrect args to `krb5-config`.
### BIND version used
bind-9.16.19
### Steps to reproduce
Try compile with Kerberos 5 release 1.19.2 and pass to `./configure` `--with-gssapi=$PREFIX/bin/krb5-config`.
### What is the current *bug* behavior?
The linker test fails:
```
configure:17572: checking krb5-config linking as -L/opt/ports/lib/hpux32 -L/opt/ports/lib/hpux32 -lkrb5 -lk5crypto -lcom_err
configure:17585: /opt/aCC/bin/aCC -Ae -o conftest -g -mt -I/opt/ports/include -L/opt/ports/lib/hpux32 conftest.c -L/opt/ports/lib/hpux32 -L/opt/ports/lib/hpux32 -lkrb5 -lk5crypto -lcom_err >&5
"conftest.c", line 112: warning #2223-D: function "gss_acquire_cred" declared implicitly
gss_acquire_cred();krb5_init_context()
^
"conftest.c", line 112: warning #2223-D: function "krb5_init_context" declared implicitly
gss_acquire_cred();krb5_init_context()
^
ld: Unsatisfied symbol "gss_acquire_cred" in file conftest.o
1 error.
configure:17585: $? = 1
```
### What is the expected *correct* behavior?
Linker test to pass
### Possible fixes
The problem is incorrect understanding of `krb5-config`. It does *not* accept more than one `library` request and if more than one is passed, the latter always overrides the former:
```
# krb5-config --libs gssapi krb5
-L/opt/ports/lib/hpux32 -Wl,+b,/opt/ports/lib/hpux32 -L/opt/ports/lib/hpux32 -lkrb5 -lk5crypto -lcom_err
# # extracted test
# /opt/aCC/bin/aCC -Ae -o conftest -g -mt -I/opt/ports/include -L/opt/ports/lib/hpux32 conftest.c -L/opt/ports/lib/hpux32 -L/opt/ports/lib/hpux32 -lkrb5 -lk5crypto -lcom_err
"conftest.c", line 4: warning #2223-D: function "gss_acquire_cred" declared
implicitly
gss_acquire_cred();krb5_init_context()
^
"conftest.c", line 4: warning #2223-D: function "krb5_init_context" declared
implicitly
gss_acquire_cred();krb5_init_context()
^
ld: Unsatisfied symbol "gss_acquire_cred" in file conftest.o
1 error.
```
Correct is to pass `gssapi` *only*, it internally depends on `krb5` and will add all required libraries, name for GSS-API `gss_` AND KRB5 `krb5_`:
```
# krb5-config --libs gssapi
-L/opt/ports/lib/hpux32 -Wl,+b,/opt/ports/lib/hpux32 -L/opt/ports/lib/hpux32 -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err
```
thus
```
/opt/aCC/bin/aCC -Ae -o conftest -g -mt -I/opt/ports/include -L/opt/ports/lib/hpux32 conftest.c -L/opt/ports/lib/hpux32 -L/opt/ports/lib/hpux32 -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err
"conftest.c", line 4: warning #2223-D: function "gss_acquire_cred" declared
implicitly
gss_acquire_cred();krb5_init_context()
^
"conftest.c", line 4: warning #2223-D: function "krb5_init_context" declared
implicitly
gss_acquire_cred();krb5_init_context()
# file ./conftest
./conftest: ELF-32 executable object file - IA64
# ldd ./conftest
./conftest:
libgssapi_krb5.2 => /opt/ports/lib/hpux32/libgssapi_krb5.2
libkrb5.3 => /opt/ports/lib/hpux32/libkrb5.3
libk5crypto.3 => /opt/ports/lib/hpux32/libk5crypto.3
libcom_err.3 => /opt/ports/lib/hpux32/libcom_err.3
libpthread.so.1 => /usr/lib/hpux32/libpthread.so.1
libc.so.1 => /usr/lib/hpux32/libc.so.1
libkrb5support.0 => /opt/ports/lib/hpux32/libkrb5support.0
libintl.so.10 => /opt/ports/lib/hpux32/libintl.so.10
libdl.so.1 => /usr/lib/hpux32/libdl.so.1
libiconv.so.8 => /opt/ports/lib/hpux32/libiconv.so.8
libc.so.1 => /usr/lib/hpux32/libc.so.1
libc.so.1 => /usr/lib/hpux32/libc.so.1
```
fix:
```
# sed -i"" "s#--libs gssapi krb5#--libs gssapi#g" configure
....
checking for GSSAPI library... trying /opt/ports/bin/krb5-config
checking gssapi.h usability... yes
checking gssapi.h presence... yes
checking for gssapi.h... yes
checking gssapi/gssapi.h usability... yes
checking gssapi/gssapi.h presence... yes
checking for gssapi/gssapi.h... yes
checking krb5/krb5.h usability... yes
checking krb5/krb5.h presence... yes
checking for krb5/krb5.h... yes
checking krb5.h usability... yes
checking krb5.h presence... yes
checking for krb5.h... yes
checking krb5-config linking as -L/opt/ports/lib/hpux32 -Wl,+b,/opt/ports/lib/hpux32 -L/opt/ports/lib/hpux32 -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err... krb5-config: linked
...
```October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2852BIND doesn't create server TCP sockets for new interfaces detected during nam...2021-10-04T09:19:36ZCathy AlmondBIND doesn't create server TCP sockets for new interfaces detected during named start-up processingMore detail noted in [Support ticket RT #18855](https://support.isc.org/Ticket/Display.html?id=18855)
The scenario is a recursive server that has a scripted start-up process. named is started first, without the server anycast IPs activ...More detail noted in [Support ticket RT #18855](https://support.isc.org/Ticket/Display.html?id=18855)
The scenario is a recursive server that has a scripted start-up process. named is started first, without the server anycast IPs active (this is to prevent client queries from reaching the server before it is ready to handle queries). The next step in the script is to add the anycast address to the lo interface.
It was observed (on both 9.11.33-S1 and 9.16.18) that named creates both UDP and TCP sockets for interfaces that are present when named is first starting up. These are logged as:
listening on IPv4 interface ... (interface IP address and port)
The interfaces that are missing the TCP server socket are logged as being added after named reports that the control channel socket has been created.
command channel listening on 127.0.0.1#953
And these newly added interfaces are logged thus:
additionally listening on IPv4 interface (interface, IP address and port)
This step takes place before named has finished its startup processing and has logged:
running
If a 5s delay is added to the start-up script, then the new interfaces, when added, have both TCP and UDP sockets created as expected.
Analysis of logs produced by named 9.11.33-S1 (options -g -d 255) show that named does not even attempt to create the second socket for the additional interfaces added at this point in its start up processing, whereas the ones that were already present and created earlier have two calls to open and bind to a socket.
Here's a snippet from the debug logs of named starting up and opening the server sockets on the 127.0.0.1 interface: (already present and detected at startup)
```
05-Aug-2021 09:49:13.322 listening on IPv4 interface lo, 127.0.0.1#53
05-Aug-2021 09:49:13.322 clientmgr @0x7f35b14f4010: create
05-Aug-2021 09:49:13.322 sendmsg: Invalid argument
05-Aug-2021 09:49:13.330 socket 0x7f35b15ca270: created
05-Aug-2021 09:49:13.330 socket 0x7f35b15ca270 127.0.0.1#53: bound << *** HERE ***
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: dns_dispatch_createudp: Created UDP dispatch for 127.0.0.1#53 with socket fd 512
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: created UDP dispatcher 0x7f35a402f7b0
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402f7b0: created task 0x7f35b14f28a8
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402f7b0: created socket 0x7f35b15ca270
05-Aug-2021 09:49:13.330 socket 0x7f35b15ca4d0: dupped
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: dns_dispatch_createudp: Created UDP dispatch for 127.0.0.1#53 with socket fd 513
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: created UDP dispatcher 0x7f35a402f1e0
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402f1e0: created task 0x7f35b14f2970
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402f1e0: created socket 0x7f35b15ca4d0
05-Aug-2021 09:49:13.330 socket 0x7f35b15ca730: dupped
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: dns_dispatch_createudp: Created UDP dispatch for 127.0.0.1#53 with socket fd 514
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: created UDP dispatcher 0x7f35a402ec10
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402ec10: created task 0x7f35b14f2a38
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402ec10: created socket 0x7f35b15ca730
05-Aug-2021 09:49:13.330 socket 0x7f35b15ca990: dupped
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: dns_dispatch_createudp: Created UDP dispatch for 127.0.0.1#53 with socket fd 515
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: created UDP dispatcher 0x7f35a402e640
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402e640: created task 0x7f35b14f2b00
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402e640: created socket 0x7f35b15ca990
05-Aug-2021 09:49:13.330 socket 0x7f35b15cabf0: dupped
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: dns_dispatch_createudp: Created UDP dispatch for 127.0.0.1#53 with socket fd 516
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: created UDP dispatcher 0x7f35a402e070
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402e070: created task 0x7f35b14f2bc8
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402e070: created socket 0x7f35b15cabf0
05-Aug-2021 09:49:13.330 socket 0x7f35b14f8010: dupped
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: dns_dispatch_createudp: Created UDP dispatch for 127.0.0.1#53 with socket fd 517
05-Aug-2021 09:49:13.330 dispatchmgr 0x7f35b15c9010: created UDP dispatcher 0x7f35a402daa0
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402daa0: created task 0x7f35b14f2c90
05-Aug-2021 09:49:13.330 dispatch 0x7f35a402daa0: created socket 0x7f35b14f8010
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: createclients
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: get client
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: create new
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: clientmctx
05-Aug-2021 09:49:13.330 client @0x7f35a403a9a0 (no-peer): create
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: get client
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: create new
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: clientmctx
05-Aug-2021 09:49:13.330 client @0x7f35a40408a0 (no-peer): create
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: get client
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: create new
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: clientmctx
05-Aug-2021 09:49:13.330 client @0x7f35a40a2230 (no-peer): create
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: get client
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: create new
05-Aug-2021 09:49:13.330 clientmgr @0x7f35b14f4010: clientmctx
05-Aug-2021 09:49:13.331 client @0x7f35a40b0ae0 (no-peer): create
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: get client
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: create new
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: clientmctx
05-Aug-2021 09:49:13.331 client @0x7f35a40bf390 (no-peer): create
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: get client
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: create new
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: clientmctx
05-Aug-2021 09:49:13.331 client @0x7f35a40cdc40 (no-peer): create
05-Aug-2021 09:49:13.331 socket 0x7f35b14f8270: created
05-Aug-2021 09:49:13.331 socket 0x7f35b14f8270 127.0.0.1#53: bound << *** AND HERE ***
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: createclients
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: get client
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: create new
05-Aug-2021 09:49:13.331 clientmgr @0x7f35b14f4010: clientmctx
05-Aug-2021 09:49:13.331 client @0x7f35a40dc660 (no-peer): create
```
(named is started with -U 6)
The same logging for the additional interfaces is completely missing the second 'socket ... created' and 'socket ... bound' pair from the logs.
There are no obvious errors being logged - named simply doesn't create the second socket (that I assume is the TCP listener that we didn't get).
The same symptoms are present both in 9.11-S and 9.16, but it's not possible to obtain useful debug logging from 9.16 - likely because the libuv-based server socket code no longer has the logging that was available from the named-based server socket code.October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/2921Unhandled NULL returns from jemalloc's mallocx()2021-10-01T04:19:29ZMichał KępieńUnhandled NULL returns from jemalloc's mallocx()As [documented][1], jemalloc's `mallocx()` function can return `NULL`:
> The mallocx() and rallocx() functions return a pointer to the
> allocated memory if successful; otherwise a NULL pointer is returned
> to indicate insufficient con...As [documented][1], jemalloc's `mallocx()` function can return `NULL`:
> The mallocx() and rallocx() functions return a pointer to the
> allocated memory if successful; otherwise a NULL pointer is returned
> to indicate insufficient contiguous memory was available to service
> the allocation request.
However, `mem_get()` [does not account for that possibility][2] as
commit fcc6814776c285cb64608f5ac18281fdf8a063fe (!5012) removed a `NULL`
check which was previously there. This raises several issues:
1. Segmentation faults may now happen instead of `abort()`s. This was
[proven][3] to be possible by GitLab CI (see GDB output below).
2. Behavior is inconsistent between jemalloc-enabled and non-jemalloc
builds. The latter [checks][4] whether each pointer returned by the
system `malloc()` function is `NULL` and `abort()`s if it is. The
former does not (see GDB output below).
<details>
<summary>Click here to fold/expand GDB output</summary>
```
Core was generated by `/builds/isc-projects/bind9/lib/isc/tests/.libs/mem_test'.
Program terminated with signal SIGABRT, Aborted.
#0 0xf7f29069 in __kernel_vsyscall ()
[Current thread is 1 (Thread 0xe13f8b40 (LWP 7031))]
(gdb) bt
#0 0xf7f29069 in __kernel_vsyscall ()
#1 0xf7cae382 in raise () from /lib/i386-linux-gnu/libc.so.6
#2 0xf7c982b6 in abort () from /lib/i386-linux-gnu/libc.so.6
#3 0xf7e80cf7 in ?? () from /usr/lib/i386-linux-gnu/libcmocka.so.0
#4 0xf7e80d40 in ?? () from /usr/lib/i386-linux-gnu/libcmocka.so.0
#5 <signal handler called>
#6 0xf7dc06ca in ?? () from /lib/i386-linux-gnu/libc.so.6
#7 0xf7ed108a in memset (__len=<optimized out>, __ch=190, __dest=0x0) at /usr/i686-linux-gnu/include/bits/string_fortified.h:71
#8 mem_get (size=<optimized out>, ctx=0xf5437000) at mem.c:344
#9 isc__mem_get (ctx=0xf5437000, size=65534, file=0x565c4008 "mem_test.c", line=439) at mem.c:752
#10 0x565c164e in mem_thread (arg=0xf5437000) at mem_test.c:439
#11 0xf7ef1996 in isc__trampoline_run (arg=0x57bb1d00) at trampoline.c:185
#12 0xf7e63fd2 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#13 0xf7d796d6 in clone () from /lib/i386-linux-gnu/libc.so.6
(gdb) frame 8
#8 mem_get (size=<optimized out>, ctx=0xf5437000) at mem.c:344
344 memset(ret, 0xbe, size); /* Mnemonic for "beef". */
(gdb) print ret
$1 = 0x0
```
</details>
[1]: http://jemalloc.net/jemalloc.3.html
[2]: https://gitlab.isc.org/isc-projects/bind9/-/blob/eeec53eb5da5c0968e099f01c6236127f9813a97/lib/isc/mem.c#L341-345
[3]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2004301
[4]: https://gitlab.isc.org/isc-projects/bind9/-/blob/eeec53eb5da5c0968e099f01c6236127f9813a97/lib/isc/jemalloc_shim.h#L30October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2909Pointers used before validation2021-09-29T01:43:48ZArаm SаrgsyаnPointers used before validationAfter analyzing and filtering out the false positives from a static analyzer's report, there are three places left where a pointer is being used/dereferenced before being checked against NULL:
1. lib/isc/netmgr/netmgr.c - `uvreq` in `is...After analyzing and filtering out the false positives from a static analyzer's report, there are three places left where a pointer is being used/dereferenced before being checked against NULL:
1. lib/isc/netmgr/netmgr.c - `uvreq` in `isc__nm_async_readcb()`
2. lib/isc/netmgr/tcpdns.c - `ievent->sock` in `isc__nm_async_tcpdnssend()`
3. lib/isccfg/parser.c - `obj` in `cfg_print_spacelist()`October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/2893Release Checklist for BIND 9.16.21, BIND 9.16.21-S1, 9.17.182021-09-20T16:11:26ZMichał KępieńRelease Checklist for BIND 9.16.21, BIND 9.16.21-S1, 9.17.18## Notes
- BIND releases 9.11.36 & 9.11.36-S1, which were originally planned for September, are currently not expected to happen due to lack of code changes since 9.11.35(-S1).
## Release Schedule
**Code Freeze:** Wednesday, Septemb...## Notes
- BIND releases 9.11.36 & 9.11.36-S1, which were originally planned for September, are currently not expected to happen due to lack of code changes since 9.11.35(-S1).
## Release Schedule
**Code Freeze:** Wednesday, September 1st, 2021
**Tagging Deadline:** Monday, September 6th, 2021
**Public Release:** Wednesday, September 15th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.17.18](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
- [9.16.21](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
**Merge requests merged into the milestone without a release note:**
- [9.17.18](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)¬[label_name][]=Release%20Notes&target_branch=main)
- [9.16.21](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)¬[label_name][]=Release%20Notes&target_branch=v9_16)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.17.18](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)&label_name[]=No%20CHANGES&target_branch=main)
- [9.16.21](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=September%202021%20(9.11.36%2C%209.11.36-S1%2C%209.16.21%2C%209.16.21-S1%2C%209.17.18)&label_name[]=No%20CHANGES&target_branch=v9_16)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is in effect.
### Before the Tagging Deadline
- [x] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Update API files for libraries with new version information.
- [x] ***(QA)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(QA)*** Update `CHANGES`.
- [x] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update `README.md`.
- [x] ***(QA)*** Update `version`.
- [x] ***(QA)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is over.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription Edition (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public packages (`*.deb`, RPMs).
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Merge the automatically prepared `prep 9.x.y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_x`).
- [x] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Michał KępieńMichał Kępień2021-09-15https://gitlab.isc.org/isc-projects/bind9/-/issues/2912Explicit support for conservative DNSSEC algorithm rollover (RFC 6781 4.1.4)2021-09-20T07:42:43ZEtienne DechampsExplicit support for conservative DNSSEC algorithm rollover (RFC 6781 4.1.4)I couldn't find an explicitly documented way to use `dnssec-settime` and `dnssec-signzone -S` (smart signing) to perform a "conservative" DNSSEC algorithm rollover as described in [RFC 6781 section 4.1.4](https://datatracker.ietf.org/doc...I couldn't find an explicitly documented way to use `dnssec-settime` and `dnssec-signzone -S` (smart signing) to perform a "conservative" DNSSEC algorithm rollover as described in [RFC 6781 section 4.1.4](https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.4).
That RFC describes a procedure that involves publishing additional RRSIGs with the algorithm *first*, wait until old RRSIG RRsets have expired, and only then add the new DNSKEY. The reason why algorithm rollovers have to be done in this precise order is because an RRSIG RRset must contain at least one key for each algorithm that is used in the DNSKEY RRset. (See [RFC 4035 2.2](https://datatracker.ietf.org/doc/html/rfc4035#section-2.2) and [RFC 6840 5.11](https://datatracker.ietf.org/doc/html/rfc6840#section-5.11).) If that order is not followed, a cache could end up with a new DNSKEY using the new algorithm, alongside RRSIGs that are missing the new algorithm, which is not standard-conformant.
The same applies in reverse when removing an algorithm: the DNSKEY should be removed *first*, and RRSIGs should only be removed after the DNSKEY removal has propagated.
The [Algorithm rollover](https://bind9.readthedocs.io/en/latest/dnssec-guide.html#algorithm-rollovers) section of the bind DNSSEC guide seems to describe a procedure where the DNSKEY and RRSIG records are added/removed at the same time, which violates RFC 6781 section 4.1.4.
Digging a little deeper, I noticed that `dnssec-settime` and `dnssec-signzone` (from bind 9.16.15-debian) can, in fact, be coerced into rolling out the `RRSIG`s before the `DNSKEY`:
```
$ echo '@ 300 IN SOA example. example. (123 5m 5m 5m 5m)' > example
$ dnssec-keygen -f KSK -a 8 example.
$ dnssec-keygen -f KSK -a 13 example.
$ dnssec-settime -A -1w -P +1w Kexample.+013+*.key
$ dnssec-signzone -z -S example
```
The resulting `example.signed` file will contain `RRSIG`s for algorithms 8 and 13, but only the `DNSKEY` for algorithm 8. This is great and can be used for RFC 6781-compliant algorithm rollover, but let's note that this behaviour seems somewhat unintended and is completely undocumented - in fact, it directly contradicts `dnssec-settime(8)`, which states that after the activation date the "key is included in the zone".
A more serious problem is that it doesn't seem possible to do this in reverse for algorithm removal:
```
$ dnssec-settime -D -1w -I +1w Kexample.+008+*.key
dnssec-settime: warning: Key is scheduled to be deleted before it is
scheduled to be inactive.
$ dnssec-signzone -z -S example
```
The resulting `example.signed` is missing both `RRSIG`s and the `DNSKEY` for algorithm 8. In order to be RFC 6781-compliant, we need to remove the `DNSKEY` before the `RRSIG`s but it doesn't look like that's possible with the current implementation of smart signing.
It looks like the following changes are required for bind9 smart signing to support conservative algorithm rollover as described in RFC 6781 4.1.4:
- `dnssec-signzone -S` should output `RRSIG`s (but not the `DNSKEY`) if the key deletion date is in the past but the key inactivation date is in the future. The `dnssec-settime` warning shown above should be removed. The `dnssec-settime` manpage should be updated accordingly.
- The "Algorithm rollovers" section of the DNSSEC guide should be updated to explain how to do a RFC 6781 conservative rollover using `dnssec-settime`, i.e. using reversed activation/publication and deletion/inactivation dates.https://gitlab.isc.org/isc-projects/bind9/-/issues/2768named locked up in statschannel system test2021-09-17T05:46:20ZMark Andrewsnamed locked up in statschannel system testJob [#1789000](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1789000) failed for 33d991f1cd5b20d024d953f6f780e3873199aeb8:
[Backtrace](https://isc-projects.isc-pag.es/-/bind9/-/jobs/1789000/artifacts/bin/tests/system/statschannel/ns2...Job [#1789000](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1789000) failed for 33d991f1cd5b20d024d953f6f780e3873199aeb8:
[Backtrace](https://isc-projects.isc-pag.es/-/bind9/-/jobs/1789000/artifacts/bin/tests/system/statschannel/ns2/core.17139-backtrace.txt)
Possibly also 9.11October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/2834statschannel system test core dump2021-09-17T05:43:33ZMark Andrewsstatschannel system test core dumpJob [#1884662](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1884662) failed for 10d3a48e2f9c5d47d22ef1e1a843d9eb9fd855d5:Job [#1884662](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1884662) failed for 10d3a48e2f9c5d47d22ef1e1a843d9eb9fd855d5:https://gitlab.isc.org/isc-projects/bind9/-/issues/2449AddressSanitizer: odr-violation: global 'dns_lctx' at log.c:69:332021-09-16T13:29:11ZMichal NowakAddressSanitizer: odr-violation: global 'dns_lctx' at log.c:69:33On Fedora 33 with gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) with ASAN, but not Debian 10 with gcc 8.3.0 we have in the CI, I get following error when running the `dyndb` system test:
```
29-Jan-2021 11:25:04.597 loading DynDB instan...On Fedora 33 with gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) with ASAN, but not Debian 10 with gcc 8.3.0 we have in the CI, I get following error when running the `dyndb` system test:
```
29-Jan-2021 11:25:04.597 loading DynDB instance 'sample' driver '../driver/lib/sample.so'
=================================================================
==2511090==ERROR: AddressSanitizer: odr-violation (0x7f9e15d78d00):
[1] size=8 'dns_lctx' log.c:69:33
[2] size=8 'dns_lctx' log.c:69:33
These globals were registered at these points:
[1]:
#0 0x7f9e324a7328 (/lib64/libasan.so.6+0x37328)
#1 0x7f9e14913fb2 in _sub_I_00099_1 (../driver/lib/sample.so+0xaa8fb2)
#2 0x7f9e32e6f8dd in call_init.part.0 (/lib64/ld-linux-x86-64.so.2+0x108dd)
[2]:
#0 0x7f9e324a7328 (/lib64/libasan.so.6+0x37328)
#1 0x737dad in _sub_I_00099_1 (/home/newman/isc/ws/bind9/bin/named/named+0x737dad)
#2 0xe634bc in __libc_csu_init (/home/newman/isc/ws/bind9/bin/named/named+0xe634bc)
==2511090==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0
SUMMARY: AddressSanitizer: odr-violation: global 'dns_lctx' at log.c:69:33
Thread T13 created by T0 here:
#0 0x7f9e324c5f46 in __interceptor_pthread_create (/lib64/libasan.so.6+0x55f46)
#1 0xe5ecfa in isc_thread_create /home/newman/isc/ws/bind9/lib/isc/pthreads/thread.c:73
#2 0xe08c5a in isc_taskmgr_create /home/newman/isc/ws/bind9/lib/isc/task.c:1434
#3 0x45a841 in create_managers main.c:924
#4 0x45a841 in setup main.c:1265
#5 0x45a841 in main main.c:1568
#6 0x7f9e312541e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)
==2511090==ABORTING
```
This problem does not manifest on `main`.October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/2906sig-signing-type breaks `named-checkconf -p` pretty output2021-09-16T08:41:28ZEgbertsig-signing-type breaks `named-checkconf -p` pretty output### Summary
When using the “sig-signing-type” keyword found inside a zone clause, it causes the named.conf file checker to silently exit with error code 1.
### BIND version used
named v9.16.15
### Steps to reproduce
The named.conf ...### Summary
When using the “sig-signing-type” keyword found inside a zone clause, it causes the named.conf file checker to silently exit with error code 1.
### BIND version used
named v9.16.15
### Steps to reproduce
The named.conf file simply has the following excerpt:
```
zone “public” {
# . . .
sig-signing-type 65243
# . . .
};
```
Running
```
named-checkconf -t . -p named.conf
```
will no longer output any content of the file.
### What is the current *bug* behavior?
No longer outputs any file content
Exit code 1
### What is the expected *correct* behavior?
Expected the original (but nicely rearranged) output of named.conf.
### Relevant configuration files
### Relevant logs and/or screenshots
No error output, no output output, just silent exit with an error code of 1.
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2907Address PyLint 2.10.2 warnings2021-09-16T06:56:44ZMichał KępieńAddress PyLint 2.10.2 warningsPyLint 2.10.2 reports some new warnings for various Python bits in the repository:
- `unspecified-encoding`
- `redundant-u-string-prefix`
Example report for `main`:
```
************* Module tests-checkds
bin/tests/system/checkds/t...PyLint 2.10.2 reports some new warnings for various Python bits in the repository:
- `unspecified-encoding`
- `redundant-u-string-prefix`
Example report for `main`:
```
************* Module tests-checkds
bin/tests/system/checkds/tests-checkds.py:70:9: W1514: Using open without explicitly specifying an encoding (unspecified-encoding)
bin/tests/system/checkds/tests-checkds.py:120:13: W1514: Using open without explicitly specifying an encoding (unspecified-encoding)
bin/tests/system/checkds/tests-checkds.py:206:17: W1514: Using open without explicitly specifying an encoding (unspecified-encoding)
************* Module yamlget
bin/tests/system/digdelv/yamlget.py:22:5: W1514: Using open without explicitly specifying an encoding (unspecified-encoding)
************* Module stress_http_quota
bin/tests/system/doth/stress_http_quota.py:131:13: W1514: Using open without explicitly specifying an encoding (unspecified-encoding)
************* Module tests-rpz-passthru-logging
bin/tests/system/rpzextra/tests-rpz-passthru-logging.py:40:9: W1514: Using open without explicitly specifying an encoding (unspecified-encoding)
bin/tests/system/rpzextra/tests-rpz-passthru-logging.py:44:9: W1514: Using open without explicitly specifying an encoding (unspecified-encoding)
************* Module helper
bin/tests/system/statschannel/helper.py:82:9: W1514: Using open without explicitly specifying an encoding (unspecified-encoding)
************* Module conf
doc/arm/conf.py:90:10: W1406: The u prefix for strings is no longer necessary in Python >=3.0 (redundant-u-string-prefix)
doc/arm/conf.py:92:12: W1406: The u prefix for strings is no longer necessary in Python >=3.0 (redundant-u-string-prefix)
doc/arm/conf.py:93:9: W1406: The u prefix for strings is no longer necessary in Python >=3.0 (redundant-u-string-prefix)
doc/arm/conf.py:143:31: W1406: The u prefix for strings is no longer necessary in Python >=3.0 (redundant-u-string-prefix)
doc/man/conf.py:33:10: W1406: The u prefix for strings is no longer necessary in Python >=3.0 (redundant-u-string-prefix)
doc/man/conf.py:38:12: W1406: The u prefix for strings is no longer necessary in Python >=3.0 (redundant-u-string-prefix)
doc/man/conf.py:39:9: W1406: The u prefix for strings is no longer necessary in Python >=3.0 (redundant-u-string-prefix)
```
These should be easy to fix.
Blocks #2893October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2837BIND 9 doesn't run on Windows when then number of workers in 8 or 122021-09-15T21:06:34Zlegacy1BIND 9 doesn't run on Windows when then number of workers in 8 or 12So this is simple to test with bind 9.16.19 and a CPU with more then 7 cores/threads bind will not start older version like 9.16.15 or 9.17.12 works beyond 7 cores/threads.
Please fix thanksSo this is simple to test with bind 9.16.19 and a CPU with more then 7 cores/threads bind will not start older version like 9.16.15 or 9.17.12 works beyond 7 cores/threads.
Please fix thanksSeptember 2021 (9.16.21, 9.16.21-S1, 9.17.18)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2844`rndc freeze` command always fails, perhaps due to `in-view`2021-09-15T21:06:34ZAndrej Podzimek`rndc freeze` command always fails, perhaps due to `in-view`### Summary
`rndc freeze` always fails:
```
rndc: 'freeze' failed: already frozen
```
### BIND version used
```
BIND 9.17.16 (Development Release) <id:b33f621>
running on Linux x86_64 5.12.15-arch1-1-zen2 #1 SMP PREEMPT Sun, 11 Jul 2...### Summary
`rndc freeze` always fails:
```
rndc: 'freeze' failed: already frozen
```
### BIND version used
```
BIND 9.17.16 (Development Release) <id:b33f621>
running on Linux x86_64 5.12.15-arch1-1-zen2 #1 SMP PREEMPT Sun, 11 Jul 2021 10:50:03 +0000
built by make with '--prefix=/usr' '--sysconfdir=/etc' '--sbindir=/usr/bin' '--localstatedir=/var' '--disable-static' '--enable-fixed-rrset' '--enable-full-report' '--with-python=/usr/bin/python' '--with-maxminddb' '--with-openssl' '--with-libidn2' '--with-json-c' '--with-libxml2' '--with-lmdb' '--with-libtool' 'CFLAGS=-march=native -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -DDIG_SIGCHASE -fcommon' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
compiled by GCC 11.1.0
compiled with OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
compiled with libuv version: 1.41.0
linked to libuv version: 1.42.0
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.44.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.6.0
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
Set up a server with a few zones and views. (In particular, the `in-view` feature is used a lot. Could it be causing wrong zone freeze retries?) Then call `rndc freeze`.
### What is the current *bug* behavior?
`rndc freeze` always fails. (But then `thaw` always succeeds.)
### What is the expected *correct* behavior?
`rndc freeze` should succeed, definitely at least after a successful `rndc thaw`.
### Relevant configuration files
There are lots of them. Not sure which ones are relevant. Please feel free to ask for details.
The server has a number of views, `dnssec-policy`, zones shared among views with `in-view` as well as zones that differ between views (signed with `dnssec-policy` in only one view while other views reuse the same DNSSEC keys (but not the same zone file/data) via `auto-dnssec maintain; inline-signing yes;`).
### Relevant logs and/or screenshots
For `rndc freeze`, [the logs look like](/uploads/ffc2209077b1788a185702240779be0f/freeze.txt) repetitive attempts to freeze the same zones (all of which are defined in the `loopback` view mentioned in the log and reused in numerous views using `in-view`).
Thawing seems to work fine. Uneventful.
```
Aug 02 10:48:10 named[450242]: received control channel command 'thaw'
Aug 02 10:48:10 named[450242]: thawing all zones: success
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2878zonefiles in map format larger than 2 GiB cannot be read but can be written (...2021-09-15T21:06:34ZPetr Špačekpspacek@isc.orgzonefiles in map format larger than 2 GiB cannot be read but can be written (data loss)### Summary
Large zones written in `masterfile-format map;` with files larger than 2 GiB cannot be read.
### BIND version used
It affects latest commits on all supported branches:
- main 042d206bf499119dd16efc452718cb03a728d960
- v9_1...### Summary
Large zones written in `masterfile-format map;` with files larger than 2 GiB cannot be read.
### BIND version used
It affects latest commits on all supported branches:
- main 042d206bf499119dd16efc452718cb03a728d960
- v9_16 713ded2cc37037a5c63b61c00cc41b7de0328996
- v9_11 0480e212bf4b70f52e5a24e8ef3849a94c627a84
### Steps to reproduce
1. Generate a zone file which results in map file larger than 2 GiB:
```bash
perl bin/tests/startperf/mkzonefile.pl test 8000000 > /tmp/text
```
2. Convert text zone file into `map` format:
```bash
named-compilezone -i none -k ignore -m ignore -M ignore -n ignore -r ignore -S ignore -T ignore -W ignore -f text -F map -o /tmp/map test /tmp/text
```
3. Attempt to read the zone:
```bash
named-checkzone -i none -k ignore -m ignore -M ignore -n ignore -r ignore -S ignore -T ignore -W ignore -f map test /tmp/map
```
### What is the current *bug* behavior?
```
zone test/IN: loading from master file /tmp/map failed: invalid file
zone test/IN: not loaded due to errors.
```
### What is the expected *correct* behavior?
Zone can be read and the data are intact, obviously.
### Possible fixes
The main question is how much we want to invest into the `map` format. If we decide to remove RBTDB map format in favor of a different data structure, we might consider a low-cost option: Limit file size to make it "safe" and remove the format a bit later.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://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 Hunt