BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-03-19T06:05:17Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4646CID 488065: Null pointer dereferences (REVERSE_INULL)2024-03-19T06:05:17ZMichal NowakCID 488065: Null pointer dereferences (REVERSE_INULL)Coverity Scan claims the following issue:
```c
/lib/dns/qpzone.c: 4805 in addrdataset()
4799 newheader->ttl = rdataset->ttl;
4800 if (rdataset->ttl == 0U) {
4801 DNS_SLABHEADER_SETATTR(newheader, DNS_SLABHEADERATTR_ZEROT...Coverity Scan claims the following issue:
```c
/lib/dns/qpzone.c: 4805 in addrdataset()
4799 newheader->ttl = rdataset->ttl;
4800 if (rdataset->ttl == 0U) {
4801 DNS_SLABHEADER_SETATTR(newheader, DNS_SLABHEADERATTR_ZEROTTL);
4802 }
4803 atomic_init(&newheader->count,
4804 atomic_fetch_add_relaxed(&init_count, 1));
>>> CID 488065: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "version" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
4805 if (version != NULL) {
4806 newheader->serial = version->serial;
4807
4808 if ((rdataset->attributes & DNS_RDATASETATTR_RESIGN) != 0) {
4809 DNS_SLABHEADER_SETATTR(newheader,
4810 DNS_SLABHEADERATTR_RESIGN);
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4645CID 488064: Passing null pointer "version" to "maybe_update_recordsandsize", ...2024-03-19T06:02:05ZMichal NowakCID 488064: Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences itCoverity Scan claims the following issues:
```
/lib/dns/qpzone.c: 1994 in add()
1988 newheader->down = topheader;
1989 topheader->next = newheader;
1990 node->dirty = 1;
1991 if (changed != NULL) {
1992 ...Coverity Scan claims the following issues:
```
/lib/dns/qpzone.c: 1994 in add()
1988 newheader->down = topheader;
1989 topheader->next = newheader;
1990 node->dirty = 1;
1991 if (changed != NULL) {
1992 changed->dirty = true;
1993 }
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences it.
1994 maybe_update_recordsandsize(false, version, header,
1995 nodename->length);
1996 }
1997 } else {
1998 /*
1999 * No non-IGNORED rdatasets of the given type exist at
/lib/dns/qpzone.c: 1972 in add()
1966 if (topheader_prev != NULL) {
1967 topheader_prev->next = newheader;
1968 } else {
1969 node->data = newheader;
1970 }
1971 newheader->next = topheader->next;
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences it.
1972 maybe_update_recordsandsize(false, version, header,
1973 nodename->length);
1974 dns_slabheader_destroy(&header);
1975 } else {
1976 idx = HEADERNODE(newheader)->locknum;
1977 if (RESIGN(newheader)) {
/lib/dns/qpzone.c: 1979 in add()
1973 nodename->length);
1974 dns_slabheader_destroy(&header);
1975 } else {
1976 idx = HEADERNODE(newheader)->locknum;
1977 if (RESIGN(newheader)) {
1978 resigninsert(qpdb, idx, newheader);
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "resigndelete", which dereferences it.
1979 resigndelete(qpdb, version,
1980 header DNS__DB_FLARG_PASS);
1981 }
1982 if (topheader_prev != NULL) {
1983 topheader_prev->next = newheader;
1984 } else {
/lib/dns/qpzone.c: 2061 in add()
2055 newheader->next = node->data;
2056 node->data = newheader;
2057 }
2058 }
2059 }
2060
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences it.
2061 maybe_update_recordsandsize(true, version, newheader, nodename->length);
2062
2063 /*
2064 * Check if the node now contains CNAME and other data.
2065 */
2066 if (version != NULL && cname_and_other(node, version->serial)) {
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4643Properly document how the IDN arguments work2024-03-16T06:52:25ZOndřej SurýProperly document how the IDN arguments workDocument how +idn, +idnin and +idnout interact when run interactively and non-interactively.
This has changed between the version.Document how +idn, +idnin and +idnout interact when run interactively and non-interactively.
This has changed between the version.https://gitlab.isc.org/isc-projects/bind9/-/issues/4640Checkzone in system test leaks queries2024-03-15T04:38:53ZMark AndrewsCheckzone in system test leaks queriesThe checkzone "checking with max ttl (text)" test leaks queries.The checkzone "checking with max ttl (text)" test leaks queries.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4636rndc.py got 'NotImplementedError: Wrong message version'2024-03-14T12:25:47Zbino oetomorndc.py got 'NotImplementedError: Wrong message version'dear All.
I'm trying to delete a zone in catalog zone using python.
the script is adopted (to Python 3.9.2) from catz-del.py of https://kb.isc.org/docs/aa-01401
here is the script.
```
import sys
import os
import isc
import dns.query
i...dear All.
I'm trying to delete a zone in catalog zone using python.
the script is adopted (to Python 3.9.2) from catz-del.py of https://kb.isc.org/docs/aa-01401
here is the script.
```
import sys
import os
import isc
import dns.query
import dns.update
import dns.name
import hashlib
ZONEPATH='/var/cache/bind/'
MASTERS=['192.168.1.101']
SERVER = '192.168.8.78'
DNSPORT=53
RNDCPORT=9953
RNDCALGO='sha256'
RNDCKEY='1234abcd8765'
CATZONE='catalog.example'
PTR_EXPIRE = 31622400
PRIMARIES = ';'.join(MASTERS)
def hashzones(domain):
hash = hashlib.sha1(dns.name.from_text(domain).to_wire()).hexdigest()
return f'{hash}.zones'
def del_zone(name):
# Update catalog zone
update = dns.update.Update(CATZONE)
update.delete(f'{hashzones(name)}','ptr')
response = dns.query.tcp(update, SERVER, port=DNSPORT)
if response.rcode() != 0:
raise Exception(f"Error updating catalog zone: {response.rcode()}" )
# Delete zone from primary using RNDC
r = isc.rndc((SERVER, DNSPORT), RNDCALGO, RNDCKEY)
response = r.call(f'delzone {name}')
if response['result'] != b'0':
raise Exception(f"Error deleting zone from primary: {response['err']}" )
del_zone(sys.argv[1])
```
I Got error when try to run it
```
(venv) debian@risetdns01:~/catzman$ python ./delzone.py domain20.bino
Traceback (most recent call last):
File "/home/debian/catzman/./delzone.py", line 40, in <module>
del_zone(sys.argv[1])
File "/home/debian/catzman/./delzone.py", line 35, in del_zone
r = isc.rndc((SERVER, DNSPORT), RNDCALGO, RNDCKEY)
File "/home/debian/catzman/isc/rndc.py", line 54, in __init__
self.__connect_login()
File "/home/debian/catzman/isc/rndc.py", line 158, in __connect_login
msg = self.__command(type="null")
File "/home/debian/catzman/isc/rndc.py", line 139, in __command
raise NotImplementedError("Wrong message version %d" % version)
NotImplementedError: Wrong message version 2147549184
```
while from my bind9 log file, I got
```
13-Mar-2024 22:35:29.991 update: info: client @0x7ff0a4030080 192.168.8.78#33920: updating zone 'catalog.example/IN': deleting rrset at '5858ea66ec75231963ecb03723e1ce3295e23349.zones.catalog.example' PTR
13-Mar-2024 22:35:29.991 client: debug 1: client @0x7ff0a40322c0 192.168.8.78#33926: message parsing failed: bad label type
```
my isc python module version '9.16.48-Debian'
Its /usr/lib/python3/dist-packages/isc/__init__.py since it cannot accessed directly when I use venv
My named details :
```
root@risetdns01:~# named -V
BIND 9.16.48-Debian (Extended Support Version) <id:0dab57e>
running on Linux x86_64 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31)
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-option-checking' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' '--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-json-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 -ffile-prefix-map=/build/reproducible-path/bind9-9.16.48=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 10.2.1 20210110
compiled with OpenSSL version: OpenSSL 1.1.1w 11 Sep 2023
linked to OpenSSL version: OpenSSL 1.1.1w 11 Sep 2023
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.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.5.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
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
```
Problem is not occur with 'add zone'
Kindly please tell me what to check or do to fix this problem.
sincerely
-bino-https://gitlab.isc.org/isc-projects/bind9/-/issues/4635Rbt zone database not being tested in main.2024-03-14T09:41:27ZMark AndrewsRbt zone database not being tested in main.Looking at the coverage data from !8854 the rbtdb zone instance isn't being tested anymore for signed zones.Looking at the coverage data from !8854 the rbtdb zone instance isn't being tested anymore for signed zones.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4634shutdown system test fails when machine is offline2024-03-15T15:04:16ZMark Andrewsshutdown system test fails when machine is offlineRunning the system tests when your machine is offline fails. In this case it was MacOS.
```
% more shutdown.log
============================= test session starts ==============================
platform darwin -- Python 3.10.13, pytest-...Running the system tests when your machine is offline fails. In this case it was MacOS.
```
% more shutdown.log
============================= test session starts ==============================
platform darwin -- Python 3.10.13, pytest-7.4.3, pluggy-1.3.0
rootdir: /Users/marka/git/bind9/bin/tests/system
configfile: pytest.ini
plugins: hypothesis-6.92.1
collected 2 items
tests_shutdown.py::test_named_shutdown[rndc]
-------------------------------- live log setup --------------------------------
2024-03-13 16:19:35 INFO:shutdown switching to tmpdir: /Users/marka/git/bind9/bin/tests/system/shutdown_tmp_n89rn3w9
2024-03-13 16:19:35 INFO:shutdown test started: shutdown/tests_shutdown.py
2024-03-13 16:19:35 INFO:shutdown using port range: <27538, 27557>
FAILED [ 50%]
tests_shutdown.py::test_named_shutdown[sigterm] FAILED [100%]
------------------------------ live log teardown -------------------------------
2024-03-13 16:19:41 INFO:shutdown test artifacts in: shutdown_shutdown
=================================== FAILURES ===================================
__________________________ test_named_shutdown[rndc] ___________________________
/Users/marka/git/bind9/bin/tests/system/shutdown/tests_shutdown.py:195: in test_named_shutdown
resolver = dns.resolver.Resolver()
/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/dns/resolver.py:944: in __init__
self.read_resolv_conf(filename)
/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/dns/resolver.py:1038: in read_resolv_conf
raise NoResolverConfiguration("no nameservers")
E dns.resolver.NoResolverConfiguration: no nameservers
------------------------------ Captured log setup ------------------------------
2024-03-13 16:19:35 INFO:shutdown switching to tmpdir: /Users/marka/git/bind9/bin/tests/system/shutdown_tmp_n89rn3w9
2024-03-13 16:19:35 INFO:shutdown test started: shutdown/tests_shutdown.py
2024-03-13 16:19:35 INFO:shutdown using port range: <27538, 27557>
_________________________ test_named_shutdown[sigterm] _________________________
/Users/marka/git/bind9/bin/tests/system/shutdown/tests_shutdown.py:195: in test_named_shutdown
resolver = dns.resolver.Resolver()
/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/dns/resolver.py:944: in __init__
self.read_resolv_conf(filename)
/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/dns/resolver.py:1038: in read_resolv_conf
raise NoResolverConfiguration("no nameservers")
E dns.resolver.NoResolverConfiguration: no nameservers
---------------------------- Captured log teardown -----------------------------
2024-03-13 16:19:41 INFO:shutdown test artifacts in: shutdown_shutdown
--- generated xml file: /Users/marka/git/bind9/bin/tests/system/shutdown.xml ---
=========================== short test summary info ============================
FAILED tests_shutdown.py::test_named_shutdown[rndc] - dns.resolver.NoResolver...
FAILED tests_shutdown.py::test_named_shutdown[sigterm] - dns.resolver.NoResol...
============================== 2 failed in 6.86s ===============================
FAIL shutdown (exit status: 1)
%
```Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4632Intermittent hang in dns__db_findnode() during RPZ-enabled "stress" test2024-03-12T10:34:30ZMichał KępieńIntermittent hang in dns__db_findnode() during RPZ-enabled "stress" test`named` seemingly hung during an RPZ-enabled "stress" test job:
https://gitlab.isc.org/isc-private/bind9/-/jobs/4115448
The same job passed fine in the scheduled pipeline that was run last
night (for the same code - only documentation ...`named` seemingly hung during an RPZ-enabled "stress" test job:
https://gitlab.isc.org/isc-private/bind9/-/jobs/4115448
The same job passed fine in the scheduled pipeline that was run last
night (for the same code - only documentation differs):
https://gitlab.isc.org/isc-projects/bind9/-/jobs/4114341
Artifacts were retained for the failed job.
```
2024-03-12:09:46:32 ERROR: Core dump file /builds/isc-private/bind9/output/ns4/core.24295 found
Core was generated by `/builds/isc-private/bind9/.local/usr/local/sbin/named -f -c ./named.conf'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007ff920ee4107 in read_indicator_wait_until_empty (rwl=rwl@entry=0x7ff91f859658) at rwlock.c:225
225 if (read_indicator_isempty(rwl)) {
[Current thread is 1 (Thread 0x7ff91fc75600 (LWP 24295))]
#0 0x00007ff920ee4107 in read_indicator_wait_until_empty (rwl=rwl@entry=0x7ff91f859658) at rwlock.c:225
#1 0x00007ff920ee4355 in isc_rwlock_wrlock (rwl=rwl@entry=0x7ff91f859658) at rwlock.c:246
#2 0x00007ff920cdf797 in findnode (db=0x7ff91f859500, name=0x7ff91edf0400, create=<optimized out>, nodep=0x7fffc0aa4f58) at qpcache.c:2901
#3 0x00007ff920c4e924 in dns__db_findnode (db=<optimized out>, name=name@entry=0x7ff91edf0400, create=create@entry=true, nodep=nodep@entry=0x7fffc0aa4f58) at db.c:439
#4 0x00007ff920d41d31 in cache_name (fctx=fctx@entry=0x7ff8fa5eec00, name=0x7ff91edf0400, message=message@entry=0x7ff8f9f13c80, addrinfo=addrinfo@entry=0x7ff8f9f067f0, now=now@entry=1710232927) at resolver.c:5803
#5 0x00007ff920d4283d in cache_message (fctx=fctx@entry=0x7ff8fa5eec00, message=0x7ff8f9f13c80, addrinfo=0x7ff8f9f067f0, now=1710232927) at resolver.c:6223
#6 0x00007ff920d4caa2 in resquery_response (eresult=<optimized out>, region=0x7fffc0aa5470, arg=0x7ff8fa2c1000) at resolver.c:7625
#7 0x00007ff920c55e6f in udp_recv (handle=0x7ff8f9d30000, eresult=<optimized out>, region=0x7fffc0aa5470, arg=<optimized out>) at dispatch.c:619
#8 0x00007ff920ea6349 in isc___nm_readcb (arg=<optimized out>) at netmgr/netmgr.c:1856
#9 0x00007ff920ea641b in isc__nm_readcb (sock=sock@entry=0x7ff8fa58e500, uvreq=uvreq@entry=0x7ff8fa539200, eresult=eresult@entry=ISC_R_SUCCESS, async=async@entry=false) at netmgr/netmgr.c:1871
#10 0x00007ff920eb7b40 in isc__nm_udp_read_cb (handle=<optimized out>, nrecv=244, buf=0x7fffc0aa5540, addr=0x7fffc0aa5590, flags=0) at netmgr/udp.c:589
#11 0x00007ff9205bb72a in uv__udp_recvmsg (handle=0x7ff8fa58e7c0) at /usr/src/libuv-v1.48.0/src/unix/udp.c:267
#12 0x00007ff9205bb022 in uv__udp_io (loop=0x7ff91f837020, w=0x7ff8fa58e840, revents=1) at /usr/src/libuv-v1.48.0/src/unix/udp.c:142
#13 0x00007ff9205c0e70 in uv__io_poll (loop=0x7ff91f837020, timeout=612) at /usr/src/libuv-v1.48.0/src/unix/linux.c:1528
#14 0x00007ff9205a5fa4 in uv_run (loop=0x7ff91f837020, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.48.0/src/unix/core.c:448
#15 0x00007ff920ecc52d in loop_thread (arg=arg@entry=0x7ff91f837000) at loop.c:284
#16 0x00007ff920edd775 in thread_body (wrap=0x7ff91f8d8380) at thread.c:85
#17 0x00007ff920edd7ef in isc_thread_main (func=func@entry=0x7ff920ecc4a2 <loop_thread>, arg=0x7ff91f837000) at thread.c:116
#18 0x00007ff920ecd204 in isc_loopmgr_run (loopmgr=0x7ff91f80ea80) at loop.c:456
#19 0x0000000000425250 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1574
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4626Repatedly hitting max-cache-size leads to all-SERVFAIL answers2024-03-08T17:59:30ZPetr Špačekpspacek@isc.orgRepatedly hitting max-cache-size leads to all-SERVFAIL answers### Summary
This needs proper investigation.
### BIND version affected
- v9.16.49-to-be
- v9.16.45 - even worse, response rate goes down
**Other versions were not tested** but I assume the same problem in other branches, too.
### Ste...### Summary
This needs proper investigation.
### BIND version affected
- v9.16.49-to-be
- v9.16.45 - even worse, response rate goes down
**Other versions were not tested** but I assume the same problem in other branches, too.
### Steps to reproduce
Run [resolver test pipeline](https://gitlab.isc.org/isc-projects/bind9-shotgun-ci/-/pipelines/new) with these settings:
1. SHOTGUN_SCENARIO = udp
2. SHOTGUN_TRAFFIC_MULTIPLIER = 10
3. SHOTGUN_DURATION = 600
4. CACHE_SIZE_MB = 64
This ridiculously overloads resolver with 64 MB cache and floods it with 100 k QPS.
### What is the current *bug* behavior?
Initially SERVFAIL rate spikes - that's okay, probably recursive clients limit - and then goes down - also expected. But then it goes up again to the point where the resolver only SERVFAILs (by the end of tenth minute).
![response-rate-rcodes.svg](/uploads/0f6cec19b3c2eba1d343803e1f1e4c23/response-rate-rcodes.svg)
Second problem is that response rate goes down from time to time. It should not drop answers. But that might be an artifact of the measurement - it uses 2 second timeout.
### What is the expected *correct* behavior?
Well, I would expect very roughly constant SERVFAIL rate.
### Relevant configuration files
Auto-generated by the pipeline. Recursive-clients = probably 10 000.
### Relevant logs
https://gitlab.isc.org/isc-projects/bind9-shotgun-ci/-/pipelines/166603 (artifacts retained for a while)
Have a look at charts v9.1*/results-shotgun/charts/response-rate-rcodes.svg in individual jobs.https://gitlab.isc.org/isc-projects/bind9/-/issues/4622BIND hangs in qp_makekey2024-03-19T10:01:54ZMichal NowakBIND hangs in qp_makekeyMy home resolver (`main` - 88a5befa2578bf9969652798ff0b3ede2d19e5c8) with QP got stuck after less than an hour of runtime:
```
Mar 06 17:53:17 dns.mnowak.cz named[81103]: client @0x7f11efb74c00 86.49.239.93#37346 (fedoraproject.org): que...My home resolver (`main` - 88a5befa2578bf9969652798ff0b3ede2d19e5c8) with QP got stuck after less than an hour of runtime:
```
Mar 06 17:53:17 dns.mnowak.cz named[81103]: client @0x7f11efb74c00 86.49.239.93#37346 (fedoraproject.org): query: fedoraproject.org IN AAAA +E(0)T (23.88.124.106)
Mar 06 17:53:17 dns.mnowak.cz named[81103]: client @0x7f11d913fc00 86.49.239.93#37388 (fedoraproject.org): query: fedoraproject.org IN AAAA +E(0)T (23.88.124.106)
Mar 06 17:53:18 dns.mnowak.cz named[81103]: client @0x7f11d905c400 86.49.239.93#37265 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:18 dns.mnowak.cz named[81103]: client @0x7f11ef80dc00 86.49.239.93#37366 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:20 dns.mnowak.cz named[81103]: client @0x7f11c5f93400 86.49.239.93#37217 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:20 dns.mnowak.cz named[81103]: client @0x7f11c5e70800 86.49.239.93#37210 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:21 dns.mnowak.cz named[81103]: client @0x7f11d913fc00 86.49.239.93#37346 (download.copr.fedorainfracloud.org): query: download.copr.fedorainfracloud.org IN A +E(0)T (23.88.124.106)
Mar 06 17:53:24 dns.mnowak.cz named[81103]: client @0x7f11c5f80c00 86.49.239.93#37347 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:24 dns.mnowak.cz named[81103]: client @0x7f11c5e6f000 86.49.239.93#37298 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:26 dns.mnowak.cz named[81103]: client @0x7f11c6408800 86.49.239.93#37257 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:31 dns.mnowak.cz named[81103]: client @0x7f11c5e57400 2a02:8308:a006:2b00::901f#56962 (download.copr.fedorainfracloud.org): query: download.copr.fedorainfracloud.org IN A +E(0)T (2a01:4f8:1c17:cdb0::1)
```
I `abort`ed the server to get a core file. Here's a backtrace:
```
#0 dns_qpkey_fromname (key=0x7ffdf559a200 "\002\"%\032\002\034&\026\002 \024''\030% \"&'\002\002", name=0x7f11c6260110) at qp.c:234
#1 0x00007f11f18dd88f in qp_makekey (key=<optimized out>, uctx=<optimized out>, pval=<optimized out>, ival=<optimized out>) at qpdb.c:201
#2 0x00007f11f18bf605 in leaf_qpkey (qpr=..., n=0x7f11f02ee048, key=0x7ffdf559a200 "\002\"%\032\002\034&\026\002 \024''\030% \"&'\002\002") at /home/newman/bind9/lib/dns/qp_p.h:883
#3 fix_iterator (qp=qp@entry=0x7f11f02d82c0, iter=iter@entry=0x7ffdf559c160, start=<optimized out>,
search=search@entry=0x7ffdf559bec0 "\002\"%\032\002\031\030\027\"%\024\034!\031%\024\026\037\"(\027\002\026\"#%\002\027\"*!\037\"\024\027\002\002", searchlen=searchlen@entry=36, bit=bit@entry=37 '%',
offset=9) at qp.c:2152
#4 0x00007f11f18bfeee in dns_qp_lookup (qpr=..., name=name@entry=0x7f11d9108380, foundname=foundname@entry=0x0, iter=iter@entry=0x7ffdf559c160, chain=0x7ffdf559b4a0, chain@entry=0x0,
pval_r=pval_r@entry=0x7ffdf559d178, ival_r=0x0) at qp.c:2284
#5 0x00007f11f18d62c0 in find_coveringnsec (search=search@entry=0x7ffdf559d6b0, name=name@entry=0x7f11d9108380, nodep=nodep@entry=0x7ffdf55a0080, now=now@entry=1709744001,
foundname=foundname@entry=0x7f11d9108100, rdataset=rdataset@entry=0x7f11d9129c00, sigrdataset=0x7f11d912b480) at qp-cachedb.c:636
#6 0x00007f11f18d69ee in cache_find (db=<optimized out>, name=0x7f11d9108380, version=<optimized out>, type=1, options=16, now=<optimized out>, nodep=0x7ffdf55a0080, foundname=0x7f11d9108100,
rdataset=0x7f11d9129c00, sigrdataset=0x7f11d912b480) at qp-cachedb.c:803
#7 0x00007f11f18538f7 in dns__db_findext (db=0x7f11f0259800, name=name@entry=0x7f11d9108380, version=0x0, type=1, options=options@entry=16, now=1709744001, nodep=0x7ffdf55a0080, foundname=0x7f11d9108100,
methods=0x7ffdf559f6f0, clientinfo=0x7ffdf559f660, rdataset=0x7f11d9129c00, sigrdataset=0x7f11d912b480) at db.c:535
#8 0x00007f11f1add5b1 in query_lookup (qctx=qctx@entry=0x7ffdf559fbe0) at query.c:5969
#9 0x00007f11f1ade2f7 in ns__query_start (qctx=qctx@entry=0x7ffdf559fbe0) at query.c:5817
#10 0x00007f11f1ae3b6e in query_setup (client=client@entry=0x7f11d913fc00, qtype=qtype@entry=1) at query.c:5529
#11 0x00007f11f1ae4667 in ns_query_start (client=client@entry=0x7f11d913fc00, handle=handle@entry=0x7f11d9180700) at query.c:12107
#12 0x00007f11f1ac66fe in ns_client_request (handle=0x7f11d9180700, eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at client.c:2231
#13 0x00007f11f1b2a968 in streamdns_on_complete_dnsmessage (dnsasm=<optimized out>, region=0x7ffdf55a0850, sock=0x7f11d9161300, transphandle=0x7f11ee98d500) at netmgr/streamdns.c:147
#14 streamdns_on_dnsmessage_data_cb (dnsasm=<optimized out>, result=<optimized out>, region=0x7ffdf55a0850, cbarg=0x7f11d9161300, userarg=0x7f11ee98d500) at netmgr/streamdns.c:206
#15 0x00007f11f1b2a1c8 in isc__dnsstream_assembler_callcb (dnsasm=0x7f11efb71300, result=ISC_R_SUCCESS, region=0x7ffdf55a0850, userarg=0x0) at ./include/isc/dnsstream.h:306
#16 isc__dnsstream_assembler_handle_message (dnsasm=dnsasm@entry=0x7f11efb71300, userarg=userarg@entry=0x7f11ee98d500) at ./include/isc/dnsstream.h:353
#17 0x00007f11f1b2ab7b in isc__dnsstream_assembler_processing (dnsasm=0x7f11efb71300, userarg=0x7f11ee98d500) at ./include/isc/dnsstream.h:370
#18 isc__dnsstream_assembler_incoming_direct (dnsasm=0x7f11efb71300, userarg=0x7f11ee98d500, buf=0x7ffdf55a0970, buf_size=65) at ./include/isc/dnsstream.h:396
#19 isc_dnsstream_assembler_incoming (dnsasm=0x7f11efb71300, userarg=0x7f11ee98d500, buf=0x7ffdf55a0970, buf_size=65) at ./include/isc/dnsstream.h:508
#20 streamdns_handle_incoming_data (sock=sock@entry=0x7f11d9161300, transphandle=transphandle@entry=0x7f11ee98d500, data=0x7ffdf55a0970, len=65) at netmgr/streamdns.c:242
#21 0x00007f11f1b2ad34 in streamdns_readcb (handle=0x7f11ee98d500, result=ISC_R_SUCCESS, region=0x7ffdf55a0960, cbarg=0x7f11d9161300) at netmgr/streamdns.c:557
#22 0x00007f11f1b30b73 in tls_do_bio (sock=sock@entry=0x7f11d9162200, received_data=received_data@entry=0x7ffdf55b09f0, send_data=send_data@entry=0x0, finish=finish@entry=false) at netmgr/tlsstream.c:679
#23 0x00007f11f1b30fb5 in tls_readcb (handle=0x7f11ee987400, result=ISC_R_SUCCESS, region=0x7ffdf55b09f0, cbarg=0x7f11d9162200) at netmgr/tlsstream.c:840
#24 0x00007f11f1b2314c in isc___nm_readcb (arg=<optimized out>) at netmgr/netmgr.c:1856
#25 0x00007f11f1b2321e in isc__nm_readcb (sock=sock@entry=0x7f11d9163b00, uvreq=<optimized out>, eresult=eresult@entry=ISC_R_SUCCESS, async=async@entry=false) at netmgr/netmgr.c:1871
#26 0x00007f11f1b2ee80 in isc__nm_tcp_read_cb (stream=<optimized out>, nread=174, buf=0x7ffdf55b0a90) at netmgr/tcp.c:772
#27 0x00007f11f131c6fb in uv.read () from /lib64/libuv.so.1
#28 0x00007f11f131ca78 in uv.stream_io () from /lib64/libuv.so.1
#29 0x00007f11f132262b in uv.io_poll () from /lib64/libuv.so.1
#30 0x00007f11f1309708 in uv_run () from /lib64/libuv.so.1
#31 0x00007f11f1b48255 in loop_thread (arg=arg@entry=0x7f11f0227000) at loop.c:284
#32 0x00007f11f1b5a02e in thread_body (wrap=0x7f11f0325480) at thread.c:85
#33 0x00007f11f1b5a0a7 in isc_thread_main (func=func@entry=0x7f11f1b481ca <loop_thread>, arg=0x7f11f0227000) at thread.c:116
#34 0x00007f11f1b491ea in isc_loopmgr_run (loopmgr=0x7f11f0209a80) at loop.c:456
#35 0x0000000000426ac0 in main (argc=4, argv=0x7ffdf55b4e08) at main.c:1574
```
[bt-full.txt](/uploads/e4d8eb5744a3ea1c45f09cc9bd521294/bt-full.txt)May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4620Cleanup: the characters from Regexp field are all unsigned and use unsigned c...2024-03-05T05:17:25ZMingshuai Renrenmingshuai@huawei.comCleanup: the characters from Regexp field are all unsigned and use unsigned char instead.```
From 0eac3b986972b2888ebf386642c1d281344aba91 Mon Sep 17 00:00:00 2001
From: renmingshuai <renmingshuai@huawei.com>
Date: Tue, 5 Mar 2024 09:49:01 +0800
Subject: [PATCH] Cleanup: the characters from Regexp field are all unsinged.
Us...```
From 0eac3b986972b2888ebf386642c1d281344aba91 Mon Sep 17 00:00:00 2001
From: renmingshuai <renmingshuai@huawei.com>
Date: Tue, 5 Mar 2024 09:49:01 +0800
Subject: [PATCH] Cleanup: the characters from Regexp field are all unsinged.
Use unsigned char instead.
Signed-off-by: renmingshuai <renmingshuai@huawei.com>
---
lib/dns/rdata/generic/naptr_35.c | 4 ++--
lib/isc/regex.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/dns/rdata/generic/naptr_35.c b/lib/dns/rdata/generic/naptr_35.c
index ecae2c0ca3..abc1e41101 100644
--- a/lib/dns/rdata/generic/naptr_35.c
+++ b/lib/dns/rdata/generic/naptr_35.c
@@ -25,8 +25,8 @@
static inline isc_result_t
txt_valid_regex(const unsigned char *txt) {
unsigned int nsub = 0;
- char regex[256];
- char *cp;
+ unsigned char regex[256];
+ unsigned char *cp;
bool flags = false;
bool replace = false;
unsigned char c;
diff --git a/lib/isc/regex.c b/lib/isc/regex.c
index 99809cc244..eb01c7d4d9 100644
--- a/lib/isc/regex.c
+++ b/lib/isc/regex.c
@@ -28,7 +28,7 @@
* Validate the regular expression 'C' locale.
*/
int
-isc_regex_validate(const char *c) {
+isc_regex_validate(const unsigned char *c) {
enum {
none, parse_bracket, parse_bound,
parse_ce, parse_ec, parse_cc
--
2.33.0
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4616Resolver cache redesign2024-03-01T12:29:31ZPetr Špačekpspacek@isc.orgResolver cache redesignThis is a meta issue to collect current problems & ideas what to do about it.
Current known problems:
- LRU cleaning can get state into a weird state: #2744
- Cache cleaning can block things, and is generally a mess: #3261, #4383
- Neg...This is a meta issue to collect current problems & ideas what to do about it.
Current known problems:
- LRU cleaning can get state into a weird state: #2744
- Cache cleaning can block things, and is generally a mess: #3261, #4383
- Negative answers from e.g. a random subdomain attack can push out useful things: #2495, #1831
- ADB vs. cache size is hardcoded and nobody knows if this is optimal or not: #2483, #2405
- Sizing is hard to get right: #614
- Cache is child-centric: #3311
- RRSIGs and not tightly bound to respective RR: #3396
- Data structures referenced by RBTDB are a mess: #4356, #3403, #3405Štěpán BalážikŠtěpán Balážikhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4615Improve dnssec-keygen warnings when unnecessary parameters are ignored2024-02-29T15:48:40ZCathy AlmondImprove dnssec-keygen warnings when unnecessary parameters are ignored### Summary
The specific instance that inspires this bug report is that these commands
> dnssec-keygen -b 2048 -a ECDSAP256SHA256 -f KSK example.com
> dnssec-keygen -b 2048 -a ECDSAP256SHA256 example.com
.. don't generate a warning th...### Summary
The specific instance that inspires this bug report is that these commands
> dnssec-keygen -b 2048 -a ECDSAP256SHA256 -f KSK example.com
> dnssec-keygen -b 2048 -a ECDSAP256SHA256 example.com
.. don't generate a warning that the -b 2048 is ignored because key algorithm ECDSAP256SHA256 has a predefined length
There may be other scenarios worth checking at the same time?
### BIND version affected
Noted against 9.16.28 (a long time ago), but the situation I don't think has changed.
### Steps to reproduce
See above - just do it?
### What is the current *bug* behavior?
No warning. dnssec-keygen goes its own sweet way and uses its built-in default length for this key
### What is the expected *correct* behavior?
It would have been really helpful to have known that the keys didn't have the requested length - this caused a bunch of other problems during migration to dnssec-policy using these keys!
What actually happened is that after restarting named and switching to dnssec-policy with these parameters:
> ksk lifetime unlimited algorithm ECDSAP256SHA256 2048;
> zsk lifetime unlimited algorithm ECDSAP256SHA256 2048;
named didn't recognise the existing keys as matching the policy and generated new ones for the zone, retiring the old keys - which is just what you don't want when migrating your existing zone's configuration and not intending to abruptly re-sign it with new keys (aargh!)
In fact, named-checkconf does fuss about the 2048:
> /etc/namedb/named.conf:54: dnssec-policy: key algorithm ECDSAP256SHA256 has predefined length; ignoring length value 2048
> /etc/namedb/named.conf:55: dnssec-policy: key algorithm ECDSAP256SHA256 has predefined length; ignoring length value 2048
So perhaps this is another small bug too - if the length is irrelevant and ignored - why did it not just recognise the existing keys?
It was perfectly happy with the same keys and with:
> ksk lifetime unlimited algorithm ECDSAP256SHA256;
> zsk lifetime unlimited algorithm ECDSAP256SHA256;May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4613Release Checklist for BIND 9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.222024-03-19T08:46:21ZPetr Špačekpspacek@isc.orgRelease Checklist for BIND 9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22## Release Schedule
**Code Freeze:** Wednesday, 6 March 2024
**Tagging Deadline:** Monday, 11 March 2024
**Public Release:** Wednesday, 20 March 2024
## Warning
This release uses non-standard process. It is based on February releas...## Release Schedule
**Code Freeze:** Wednesday, 6 March 2024
**Tagging Deadline:** Monday, 11 March 2024
**Public Release:** Wednesday, 20 March 2024
## Warning
This release uses non-standard process. It is based on February releases (9.16.48, 9.18.24, 9.19.21) and adds cherry-picked MRs on top.
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.16.49](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16)
- [9.16.49-S1](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16-S)
- [9.18.25](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18)
- [9.18.25-S1](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18-S)
- [9.19.22](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.19)
**Merge requests merged into the milestone without a release note:**
- [9.16.49](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.16)
- [9.16.49-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.16-sub)
- [9.18.25](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.18)
- [9.18.25-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.18-sub)
- [9.19.22](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=main)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.16.49](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.16)
- [9.16.49-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.16-sub)
- [9.18.25](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.18)
- [9.18.25-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.18-sub)
- [9.19.22](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29&label_name%5B%5D=No+CHANGES&target_branch=main)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Rebase -S editions on top of current open-source versions: `git checkout bind-9.18-sub && git rebase origin/bind-9.18`
- [x] ***(QA)*** [Inform](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/inform_supp_marketing.py) Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform. Check [public](https://gitlab.isc.org/isc-projects/bind9/-/pipelines?scope=all&source=schedule) and [private](https://gitlab.isc.org/isc-private/bind9/-/pipelines?scope=all&source=schedule) scheduled pipelines.
- [x] ***(QA)*** Check charts from `shotgun:*` jobs in the scheduled pipelines to verify there is no unexplained performance drop for any protocol.
- [x] ***(QA)*** Check [Perflab](https://perflab.isc.org/) 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](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/)[^1] (Subscription Edition only).
- [x] ***(QA)*** [Ensure](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/check_backports.py) all merge requests marked for backporting have been indeed backported.
- [x] ***(QA)*** ~~[Announce](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/inform_code_freeze.py) (on Mattermost) that the code freeze is in effect.~~
### Before the Tagging Deadline
- [x] ***(QA)*** Inspect the current output of the `cross-version-config-tests` job to verify that no unexpected backward-incompatible change was introduced in the current release cycle.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well. [Example](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/510)
- [x] ***(QA)*** Add a release marker to `CHANGES`. Examples: [9.18](https://gitlab.isc.org/isc-projects/bind9/-/commit/f14d8ad78c0506fd4247187f2177f8eceeb6b3b9), [9.16](https://gitlab.isc.org/isc-projects/bind9/-/commit/1bcdf21874f99a00da389d723e0ad07dfd70f9f1)
- [x] ***(QA)*** Add a release marker to `CHANGES.SE` (Subscription Edition only). [Example](https://gitlab.isc.org/isc-private/bind9/-/commit/0f03d5737bcbdaa1bf713c6db1887b14938c3421)
- [x] ***(QA)*** Update BIND 9 version in `configure.ac` ([9.18+](https://gitlab.isc.org/isc-projects/bind9/-/commit/3c85ab7f4c35e6d8acef1393606002a0a8730100)) or `version` ([9.16](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7692/diffs?commit_id=1bcdf21874f99a00da389d723e0ad07dfd70f9f1)).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org` (9.16).
- [x] ***(QA)*** ~~Update GitLab settings for all maintained branches to disallow merging to them: [public](https://gitlab.isc.org/isc-projects/bind9/-/settings/repository), [private](https://gitlab.isc.org/isc-private/bind9/-/settings/repository)~~
- [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)*** Check that the formatting is correct for the HTML version of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Verify GitLab CI results [for the tags](https://gitlab.isc.org/isc-private/bind9/-/pipelines?scope=tags) created and sign off on the releases to be published.
- [x] ***(QA)*** ~~Update GitLab settings for all maintained branches to allow merging to them again: [public](https://gitlab.isc.org/isc-projects/bind9/-/settings/repository), [private](https://gitlab.isc.org/isc-private/bind9/-/settings/repository)~~
- [x] ***(QA)*** Prepare (using [`version_bump.py`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/version_bump.py)) and merge MRs resetting the release notes and updating the version string for [each](!8856) [maintained](!8857) [branch](!8858).
- [x] ***(QA)*** Rebase the Subscription Edition branches (including recent release prep commits) on top of the open source branches with updated version strings.
- [x] ***(QA)*** [Announce (on Mattermost) that the code freeze is over.](https://mattermost.isc.org/isc/pl/8chqbcam7igq5nu8ryxtrjfq4r)
- [x] ***(QA)*** [Request signatures for the tarballs, providing their location and checksums. Ask signers on Mattermost.](https://mattermost.isc.org/isc/pl/ku6mfsqaktrq3ryz4iuth8183c)
- [x] ***(Signers)*** Ensure that the contents of tarballs and tags are identical.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again: Run `publish_bind.sh` on repo.isc.org to pre-publish.
- [x] ***(QA)*** ~~Prepare the `patches/` subdirectory for each security release (if applicable).~~
- [x] ***(QA)*** 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 (in [cloudsmith branch in private repo](https://gitlab.isc.org/isc-private/rpms/bind/-/tree/cloudsmith)). [Example](https://gitlab.isc.org/isc-private/rpms/bind/-/commit/e2512f4cfaf991827a635e374e7e93b27a5f38ba)
- [x] ***(Marketing)*** ~~Prepare and send out ASN emails (as outlined in the CVE checklist; if applicable).~~
### On the Day of Public Release
- [ ] ***(QA)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [ ] ***(QA)*** Place tarballs in public location on FTP site.
- [ ] ***(QA)*** Inform Marketing of the release, providing FTP links for the published tarballs.
- [ ] ***(QA)*** Use the [Printing Press project](https://gitlab.isc.org/isc-private/printing-press/-/wikis/home#adding-new-documents) to prepare a release announcement email.
- [ ] ***(Marketing)*** Publish links to downloads on ISC website. [Example](https://gitlab.isc.org/website/theme-staging-site/-/commit/1ac7b30b73cb03228df4cd5651fa4e774ac35625)
- [ ] ***(Marketing)*** Update the BIND -S information document in SF with download links to the new versions. (If this is a security release, this will have already been done as part of the ASN process.)
- [ ] ***(Marketing)*** Update the Current Software Versions document in the SF portal if any stable versions were released.
- [ ] ***(Marketing)*** Send the release announcement email to the *bind-announce* mailing list (and to *bind-users* if a major release - [example](https://lists.isc.org/pipermail/bind-users/2022-January/105624.html)).
- [ ] ***(Marketing)*** Announce release on social media sites.
- [ ] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [ ] ***(Support)*** Add the new releases to the [vulnerability matrix in the Knowledge Base](https://kb.isc.org/docs/aa-00913).
- [ ] ***(Support)*** Update tickets in case of waiting support customers.
- [ ] ***(QA)*** Build and test any outstanding private packages in [private repo](https://gitlab.isc.org/isc-private/rpms/bind/-/tree/cloudsmith). [Example](https://gitlab.isc.org/isc-private/rpms/bind/-/commit/2007d566db81dd9dfd79e571e2f600a3bc284da4)
- [ ] ***(QA)*** Build [public RPMs](https://gitlab.isc.org/isc-packages/rpms/bind). [Example commit](https://gitlab.isc.org/isc-packages/rpms/bind/-/commit/3b5e851ea7c4e3570371a4878b5461f02a44f8cc) which triggers [Copr builds](https://copr.fedorainfracloud.org/coprs/isc/) automatically
- [ ] ***(SwEng)*** Build Debian/Ubuntu packages.
- [ ] ***(SwEng)*** Update Docker files [here](https://gitlab.isc.org/isc-projects/bind9-docker/-/branches) and make sure push is synchronized to [GitHub](https://github.com/isc-projects/bind9-docker). [Docker Hub](https://hub.docker.com/r/internetsystemsconsortium/bind9) should pick it up automatically. [Example](https://gitlab.isc.org/isc-projects/bind9-docker/-/commit/cada7e10e9af951595c98bfffc4bd42512faac05)
- [ ] ***(QA)*** Ensure all new tags are annotated and signed. `git show --show-signature v9.19.12`
- [ ] ***(QA)*** Push tags for the published releases to the public repository.
- [ ] ***(QA)*** Using [`merge_tag.py`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/merge_tag.py), merge published release tags back into the their relevant development/maintenance branches.
- [ ] ***(QA)*** Ensure `allow_failure: true` is removed from the `cross-version-config-tests` job if it was set during the current release cycle.
- [ ] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [ ] ***(QA)*** Sanitize [confidential issues](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=milestone_due_desc&state=opened&confidential=yes) which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [ ] ***(QA)*** Update QA tools used in GitLab CI (e.g. Black, PyLint, Sphinx) by modifying the relevant [`Dockerfile`](https://gitlab.isc.org/isc-projects/images/-/merge_requests/228/diffs).
- [ ] ***(QA)*** Run a pipeline to rebuild all [images](https://gitlab.isc.org/isc-projects/images) used in GitLab CI.
- [ ] ***(QA)*** Update [`metadata.json`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/metadata.json) with the upcoming release information.
[^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.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4609ADB memory growth in 9.192024-02-28T06:53:58ZOndřej SurýADB memory growth in 9.19During the 25h test, it was discovered that ADB and main memory contextx grows suspiciously:
![bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-9.19](/uploads/5e5f039e83e4a892554001b6c7348e92/bindstats....During the 25h test, it was discovered that ADB and main memory contextx grows suspiciously:
![bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-9.19](/uploads/5e5f039e83e4a892554001b6c7348e92/bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-9.19.png)
![bindstats.memory.contexts.main._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-main-9.19](/uploads/bad7883a65948bfd2946b84fe6505cdf/bindstats.memory.contexts.main._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-main-9.19.png)
The growth is much slower in 9.18:
![bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1](/uploads/4cc202485a129130ecd978cf23ad452a/bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1.png)May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4607chain system test: mem.c:1311: INSIST(unreachable) failed2024-03-18T08:53:51ZMichal Nowakchain system test: mem.c:1311: INSIST(unreachable) failedJob [#4071483](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4071483) failed for f42a441b05408f4e816ea44a4780667a00c5fb86.
ns1 of the `chain` system test ended up in a bad place.
```
context: 0x7b3000001b00 (zonemgr-mctxpoo): 2 refe...Job [#4071483](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4071483) failed for f42a441b05408f4e816ea44a4780667a00c5fb86.
ns1 of the `chain` system test ended up in a bad place.
```
context: 0x7b3000001b00 (zonemgr-mctxpoo): 2 references
Dump of all outstanding memory allocations:
ptr 0x7b5000020200 size 496 file rbtdb.c line 3866
ptr 0x7b6000001000 size 1016 file rbt-zonedb.c line 2091
mem.c:1311: INSIST(unreachable) failed
```
```
2024-02-27 17:50:11 INFO:chain D:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D chain_tmp_qm1vyy5o-ns1 -m r'.
2024-02-27 17:50:11 INFO:chain D:Program terminated with signal SIGABRT, Aborted.
2024-02-27 17:50:11 INFO:chain D:#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
2024-02-27 17:50:11 INFO:chain D:Downloading source file /usr/src/debug/glibc-2.38-16.fc39.x86_64/nptl/pthread_kill.c...
2024-02-27 17:50:11 INFO:chain D:44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
2024-02-27 17:50:11 INFO:chain D:[Current thread is 1 (Thread 0x7f96faa8a380 (LWP 77097))]
2024-02-27 17:50:11 INFO:chain D:#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
2024-02-27 17:50:11 INFO:chain D:#1 0x00007f96fb0ed8a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
2024-02-27 17:50:11 INFO:chain D:#2 0x00007f96fb09b8ee in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
2024-02-27 17:50:11 INFO:chain D:#3 0x00007f96fb0838ff in __GI_abort () at abort.c:79
2024-02-27 17:50:11 INFO:chain D:#4 0x00007f96fc0bee3c in __interceptor_abort (fake=-89613312) at ../../../../libsanitizer/tsan/tsan_interceptors_posix.cpp:1875
2024-02-27 17:50:11 INFO:chain D:#5 0x0000000000427e49 in assertion_failed (file=<optimized out>, line=1311, type=<optimized out>, cond=0x7f96fc065ac3 "unreachable") at main.c:234
2024-02-27 17:50:11 INFO:chain D:#6 0x00007f96fc00b194 in isc_assertion_failed (file=file@entry=0x7f96fc0624cb "mem.c", line=line@entry=1311, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7f96fc065ac3 "unreachable") at assertions.c:48
2024-02-27 17:50:11 INFO:chain D:#7 0x00007f96fc02f45f in isc__mem_checkdestroyed () at mem.c:1311
2024-02-27 17:50:11 INFO:chain D:#8 0x00007f96fc02f54c in mem_shutdown () at mem.c:442
2024-02-27 17:50:11 INFO:chain D:#9 0x00007f96fc0da084 in __interceptor_pthread_once (o=o@entry=0x7f96fc07dec8 <shut_once>, f=f@entry=0x7f96fc02f533 <mem_shutdown>) at ../../../../libsanitizer/tsan/tsan_interceptors_posix.cpp:1551
2024-02-27 17:50:11 INFO:chain D:#10 0x00007f96fc02ce7e in isc__mem_shutdown () at mem.c:455
2024-02-27 17:50:11 INFO:chain D:#11 0x00007f96fc023088 in isc__shutdown () at lib.c:67
2024-02-27 17:50:11 INFO:chain D:#12 0x00007f96fd0ec0f2 in _dl_call_fini (closure_map=closure_map@entry=0x7f96fd0e98d0) at dl-call_fini.c:43
2024-02-27 17:50:11 INFO:chain D:#13 0x00007f96fd0f006e in _dl_fini () at dl-fini.c:114
2024-02-27 17:50:11 INFO:chain D:#14 0x00007f96fb09dfd6 in __run_exit_handlers (status=0, listp=<optimized out>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:111
2024-02-27 17:50:11 INFO:chain D:#15 0x00007f96fb09e11e in __GI_exit (status=<optimized out>) at exit.c:141
2024-02-27 17:50:11 INFO:chain D:#16 0x00007f96fb085151 in __libc_start_call_main (main=main@entry=0x429913 <main>, argc=argc@entry=12, argv=argv@entry=0x7ffe1fcbda88) at ../sysdeps/nptl/libc_start_call_main.h:74
2024-02-27 17:50:11 INFO:chain D:#17 0x00007f96fb08520b in __libc_start_main_impl (main=0x429913 <main>, argc=12, argv=0x7ffe1fcbda88, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe1fcbda78) at ../csu/libc-start.c:360
2024-02-27 17:50:11 INFO:chain D:#18 0x0000000000418d35 in _start ()
```
[core.77097-backtrace.txt](/uploads/dfe2e0c9ee3a48df96c87773f2674a12/core.77097-backtrace.txt)
[core.77097.gz](/uploads/6a868166ed706bec348e2930ddc5fa5c/core.77097.gz)
[named.run](/uploads/ef60bc0ac117defd99c6f3c831f99368/named.run)May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4606"dry-run" mode to help with dnssec-policy migration2024-02-28T10:46:36ZCarsten Strotmann"dry-run" mode to help with dnssec-policy migration### Description
For some users of BIND 9, esp. people are part time DNS admins only, migrating from manual DNSSEC key management with "auto-dnssec maintain;" towards "dnssec-policy" is difficult.
While the documentation provided by ISC...### Description
For some users of BIND 9, esp. people are part time DNS admins only, migrating from manual DNSSEC key management with "auto-dnssec maintain;" towards "dnssec-policy" is difficult.
While the documentation provided by ISC is good, there is currently no way to "verify" the new "dnssec-policy" configuration before enabling it. Experience has shown (in DNS training classes, but also in real world deployments) that there are many things that can go wrong:
- differences in the DNSSEC key configuration (old vs. new)
- file system permissions on the old key material
- file system location of the old key material
- issues with the time-events stored in the old key material
Going online with a slightly wrong configuration can cause an immediate key rollover, which might break the zone. Recovering from this situation is possible, but requires good knowledge of BIND 9 DNSSEC workings
### Request
Provide a "dnssec-policy dry-run" mode, where BIND 9 will log the next steps in the automatic DNSSEC management to the log files (e.g. category "DNSSEC"), but will not execute any changes to the DNSSEC signed zone or the key material. This will enable the user to test drive the new "dnssec-policy" to see if it will act as expected.
Admins can create a configuration with "dry-run" mode enabled, check the logfiles, and if the actions in the log-file match the expectations, the "dry-run" mode can be removed and the new configuration will become active.
### Links / referencesMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4605re-enable enginepkcs11 system test2024-03-06T14:48:23ZTom Krizekre-enable enginepkcs11 system testThe `enginepkcs11` test was accidentally disabled by a wrong `prereq.sh` condition in https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5924/diffs?commit_id=2e9fd6d0c11d0648589da5779baeefb5b98e855e#8b557d8387b0ad5e06dad7a7c2c6f6...The `enginepkcs11` test was accidentally disabled by a wrong `prereq.sh` condition in https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5924/diffs?commit_id=2e9fd6d0c11d0648589da5779baeefb5b98e855e#8b557d8387b0ad5e06dad7a7c2c6f6521febff5e_16_16.
Once [enabled](https://gitlab.isc.org/isc-projects/bind9/-/commit/f3d402d1aa2e359caa741ce2b4742795a4a37224), the test has a couple of [failures](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4068956) that need to be addressed:
```
2024-02-26 17:25:39 INFO:enginepkcs11.test_enginepkcs11 I:Test SOA is signed for ecdsap256sha256.same-policy.views in view1 (65)
2024-02-26 17:25:42 INFO:enginepkcs11.test_enginepkcs11 I:failed (SOA RRset not signed)
2024-02-26 17:25:42 INFO:enginepkcs11.test_enginepkcs11 I:Test DNSKEY is signed for ecdsap256sha256.same-policy.views in view1 (66)
2024-02-26 17:25:45 INFO:enginepkcs11.test_enginepkcs11 I:failed (DNSKEY RRset not signed)
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4603Comments to CVE-2023-56802024-02-26T16:05:08ZPeter DaviesComments to CVE-2023-5680Comments to CVE-2023-5680:
Description: When reviewing the fix for CVE-2023-5680 due to the crash we
reported separately, we've noticed many other suspicious points in its implemen
-tation. Though these are based on code inspect...Comments to CVE-2023-5680:
Description: When reviewing the fix for CVE-2023-5680 due to the crash we
reported separately, we've noticed many other suspicious points in its implemen
-tation. Though these are based on code inspection and we haven't checked whether
the issue is real or it can cause any practical problem like a crash, we're
deeply concerned about the overall quality of this implementation, and would
like to suggest ISC revisiting it, perhaps fundamentally.
The issues we've noticed are as follows (there may be more):
- it looks like a longer prefix match in ->old_ecs_root will not be found if
a shorter prefix match is found in ->ecs_root. When using two address prefix
trees, we ought to search both and use the longest prefix match, with ->ecs_root
in preference if both have equal prefix lengths.
- On a related note, it seems possible that copying (moving) data in old_ecs_root
to ecs_root can result in separate rdatasetheaders at the top level for the same record type.
- unlikely to be a big deal in practice, but this code in clean_iptree_nodedata()
probably doesn't do what it appears to intend; it results in cleaning up to 12
- as a meta issue, we're afraid the introduction of old_ecs_root and incremental
cleaning needs a lot more tests, especially low level unit tests, given its comp
-lexity. For example, if the last point is indeed an oversight, it could have
been caught by a unit test easily.
See also #4587https://gitlab.isc.org/isc-projects/bind9/-/issues/4601wrong filename looked when reading key files2024-02-23T20:10:41ZMichael Tokarevwrong filename looked when reading key files### Summary
When bind9 tools read a zone file with DNSKEY records, for which no .key file is provided but .private exists, a misleading error message is generated. For example:
```
$ dnssec-signzone 168.192.in-addr.arpa
dnssec-signzone...### Summary
When bind9 tools read a zone file with DNSKEY records, for which no .key file is provided but .private exists, a misleading error message is generated. For example:
```
$ dnssec-signzone 168.192.in-addr.arpa
dnssec-signzone: warning: dns_dnssec_keylistfromrdataset: error reading ./K168.192.in-addr.arpa.+007+13293.private: file not found
$ ls -l ./K168.192.in-addr.arpa.+007+13293.*
-rw------- 1 root root 1707 Oct 28 2011 ./K168.192.in-addr.arpa.+007+13293.private
```
So, it reports an existing file as "not found", while actually (according to strace) it looked for a .key file (which indeed does not exist, since it is inlined in the zone itself).
The end result is that this key is not processed at all, despite the tool has all the information, - the .key file contents is in the zone already (that's where dnssec-signzone found the `+007+13293` part, so it does have the DNSKEY record and don't actually need the .key file), and the .private file which it reported as missing (while not even trying to open it), is actually exists.
### BIND version affected
```
BIND 9.18.24-1-Debian (Extended Support Version) <id:>
running on Linux x86_64 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--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' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-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 -ffile-prefix-map=/build/reproducible-path/bind9-9.18.24=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 12.2.0
compiled with OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
linked to OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.52.0
linked to libnghttp2 version: 1.52.0
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
linked to maxminddb version: 1.7.1
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
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
```Not planned