BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-08-02T15:41:17Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/229Forward to OpenDNS, with non-standard tags (aka Cisco Umbrella)2023-08-02T15:41:17ZVicky Riskvicky@isc.orgForward to OpenDNS, with non-standard tags (aka Cisco Umbrella)### Description
1) Customer would like to use BIND resolvers to resolve queries for internal zones and any that the Customer are authoritative for, and forward all queries for external addresses to the hosted OpenDNS resolver service (a...### Description
1) Customer would like to use BIND resolvers to resolve queries for internal zones and any that the Customer are authoritative for, and forward all queries for external addresses to the hosted OpenDNS resolver service (aka Cisco Umbrella). The object is to use OpenDNS to filter these external queries and control responses to the client.
### Request
2) ISC will develop an OpenDNS-filtering feature in BIND that will add three additional bit of information required by OpenDNS to queries forwarded to the OpenDNS system. These three fields are: Virtual ApplianceID (a numeric ID the Customer will statically configure into the BIND server used to identify the geographical site), an Organizational ID (also statically configured by the Customer, used to identify the Customer's resolvers), and a ClientIP address (IPv4 or IPv6 address, can be RFC 1918, which BIND will get from the DNS query and pass through to OpenDNS in the forwarded query).
3) The additional information sent to OpenDNS will be encoded in a ‘Protoss’ format EDNS option specified by OpenDNS.
4) ISC will minimize caching of responses from the OpenDNS resolver in BIND, although caching of approximately a second is unavoidable. In case of caching, ISC will cache responses per client.
5) ISC will perform interoperability testing with OpenDNS by accessing a test OpenDNS account provided by Cisco.
6) This new feature will be provided to the customer in a BIND 9.11.x-S subscriber-only release. These are stable releases supported by ISC for subscribers, but are not part of the public open source. There will be some minimal documentation provided about how to enable the feature and configure the two new options.
### Links / references
Evan has been in communication with the OpenDNS development staff about the format of the proprietary options.BIND-9.11.4-SEvan HuntEvan Hunt2018-06-13https://gitlab.isc.org/isc-projects/bind9/-/issues/230Add *.user to .gitignore2021-10-04T12:39:44ZGhost UserAdd *.user to .gitignoreThe .user extension is used by Visual Studio and those files are not required to build BIND on Windows.The .user extension is used by Visual Studio and those files are not required to build BIND on Windows.https://gitlab.isc.org/isc-projects/bind9/-/issues/232memory leak patch request for bind 9.11.32018-04-27T12:15:56ZGhost Usermemory leak patch request for bind 9.11.3<!--
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
Current stable version9.11.3 is experiencing significant memory leak. Release notes on your website indicate that this bug was identified as rndc memory leak and addressed in your early deployment version bind9.12.1
Installed 9.12.1 on my test environment and confirmed that memory leak issue is indeed addressed, however I am now experiencing a new bug with 9.12.1 which was reported in https://bugs.archlinux.org/task/57535
Requesting memory leak patch to be downstream to current stable version. Or if you can provide me with the patch to apply it to my system
### Steps to reproduce
Please install your current stable version 9.11.3 and load about 500k zones. To reproduce memory leak at faster rate please run a rndc config/reloads on a frequent rate
### What is the current *bug* behavior?
(What actually happens.)
memory leak
### What is the expected *correct* behavior?
(What you should see instead.)
no memory leak (see your early deployment-version or version 9.9.9)
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
same config file is used in 4 different versions and confirmed memory leak got introduced with your 9.10.x series and fixed in your early deployment version 9.12.1
bind9.9.9 - no memory leak
bind9.10.0 - memory leak
bind9.11.2 - memory leak
bind9.11.3 - memory leak
bind9.12.1 - no memory leak
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)
http://ftp.isc.org/isc/bind9/9.12.1/RELEASE-NOTES-bind-9.12.1.html
"
rndc reload could cause named to leak memory if it was invoked before the zone loading actions from a previous rndc reload command were completed. [RT #47076]
"https://gitlab.isc.org/isc-projects/bind9/-/issues/233Clarify documentation of update-policy tcp-self and 6to4-self2018-05-15T20:21:09ZBrian ConryClarify documentation of update-policy tcp-self and 6to4-selfThe ARM describes the tcp-self option for update-policy as (quoting from the HTML version):
```html
No signer is required for <em class="replaceable"><code>tcp-self</code></em>
or <em class="replaceable"><code...The ARM describes the tcp-self option for update-policy as (quoting from the HTML version):
```html
No signer is required for <em class="replaceable"><code>tcp-self</code></em>
or <em class="replaceable"><code>6to4-self</code></em> however the standard
reverse mapping / prefix conversion must match the identity
field.
```
This doesn't explicitly state that the update has to be received over TCP instead of UDP. While this might be thought to be strongly implied with ```tcp-self```, I don't know that it's implied at all with ```6to4-self``` (and I wonder if the rules might actually be different), such that it's probably worth explicitly stating the exact criteria looked for in the client identity (not to be confused with the ```identity field```, which is different).https://gitlab.isc.org/isc-projects/bind9/-/issues/234add prerequisite check to rootkeysentinel for dnssec support2018-05-03T14:51:03ZMark Andrewsadd prerequisite check to rootkeysentinel for dnssec supportMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/236silence cppcheck issues in lib/dns/dst_parse.c2018-05-03T15:18:02ZMark Andrewssilence cppcheck issues in lib/dns/dst_parse.c<pre>unchanged lib/dns/dst_parse.c 218 error arrayIndexOutOfBounds false Array 'have[11]' accessed at index 16, which is out of bounds.
unchanged lib/dns/dst_parse.c 222 error arrayIndexOutOfBounds false Array 'have[11]' accessed at inde...<pre>unchanged lib/dns/dst_parse.c 218 error arrayIndexOutOfBounds false Array 'have[11]' accessed at index 16, which is out of bounds.
unchanged lib/dns/dst_parse.c 222 error arrayIndexOutOfBounds false Array 'have[11]' accessed at index 16, which is out of bounds.<pre>Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/237dnssec-validation exception domains2022-01-26T07:43:51ZEvan Huntdnssec-validation exception domainsWe've had a feature request on the back burner list for a long while: The ability to permanently configure the equivalent of a negative trust anchor so that local fake TLDs like "corp" or "home" can be used without triggering validation ...We've had a feature request on the back burner list for a long while: The ability to permanently configure the equivalent of a negative trust anchor so that local fake TLDs like "corp" or "home" can be used without triggering validation failures due to their nonexistence at the root.
I implemented this over the weekend. No particular urgency about it, we might even decide it's not a good idea, but I'm opening an issue so I can push an associated MR for further discussion.BIND-9.13.3https://gitlab.isc.org/isc-projects/bind9/-/issues/238ISC_NET_RECVOVERFLOW support is broken.2018-05-18T06:20:15ZMark AndrewsISC_NET_RECVOVERFLOW support is broken.If ISC_NET_RECVOVERFLOW is defined BIND will not build.If ISC_NET_RECVOVERFLOW is defined BIND will not build.Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/239don't use NULL as a argument to a varargs function as it may not be promoted ...2018-05-11T06:33:43ZMark Andrewsdon't use NULL as a argument to a varargs function as it may not be promoted properly<pre>unchanged lib/isc/tests/buffer_test.c 271 portability varFuncNullUB false Passing NULL after the last typed argument to a variadic function leads to undefined behaviour.</pre><pre>unchanged lib/isc/tests/buffer_test.c 271 portability varFuncNullUB false Passing NULL after the last typed argument to a variadic function leads to undefined behaviour.</pre>Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/240Multiple RRSIGs on some records in signed zone even though only one key is ev...2018-07-02T13:05:08ZBrian ConryMultiple RRSIGs on some records in signed zone even though only one key is ever active at a time### Summary
named sometimes creates new RRSIGs for some records even though there are current, valid, RRSIGs already for those records from a now-inactive key that's still published.
### Steps to reproduce
This may require the signing...### Summary
named sometimes creates new RRSIGs for some records even though there are current, valid, RRSIGs already for those records from a now-inactive key that's still published.
### Steps to reproduce
This may require the signing of the zone to have never completed with one or more earlier keys.
1. create a KSK and at least four ZSKs
2. customize ```reset_keys.sh``` for the keys
3. use the attached ```named.conf``` and ```signing.test.db``` zone file
4. run ```reset_keys.sh``` immediately prior to starting ```named```. this schedules three key rolls: now+300s, now+600s, and now+660s, including key deletion
5. the result is observable before named is finished working through the scheduled keyevents
6. pipe the output of ```named-journalprint``` through ```check_journal.pl``` and it will report on changes to key status (as reflected in the TYPE65534 records) and when/if extra signatures are generated (I've attached the output from one of my test runs)
### What is the current *bug* behaviour?
Starting with the zone update in which the TYPE65534 RR for the original key (40278 in my test run) is removed (serial number 1996073706 in my file), named will sign RRsets with the currently-active key (20856 in my test run) even though they have current and valid signatures for the previous key (21894 in my test run) that is still published. This behaviour is not permanent, but it is unknown what triggers the end of it.
If no keys are given deletion times the bug will not manifest.
### What is the expected *correct* behaviour?
If there is always only ever one active ZSK at a time, there should never be current, valid, RRSIGs from multiple keys for any given RRset.
More specifically, given a sequence of successor keys ```A, B, C, D, E```, the signing behaviour during the transition from key ```D``` to key ```E``` doesn't seem like it should depend on whether or not it happens while key ```A``` is being deleted from the zone, but that is what has been observed.
It is not known whether or not there are "normal" configurations and/or keyroll policies that can trigger this bug.
The original reporter encountered it while testing their keyroll scripting by moving the system clock ahead by +30days relatively soon after a keyroll was performed. The test procedures here were created to reproduce the observed problem without having to modify the system clock.
### Relevant configuration files
[signing.test.db](/uploads/b6a41dbf811a147e4e7da95d181546f0/signing.test.db)
[named.conf](/uploads/69b38afa2fb14ed1750ebace33212678/named.conf)
### Relevant logs and/or screenshots
[reset_keys.sh](/uploads/fb8a0e2b85c8d8997b5003ed4a3d1bec/reset_keys.sh)
[check_journal.pl](/uploads/a31489fcb8ab85d4a1547b3fd837b992/check_journal.pl)
[signing.test.db.signed.jnl.txt](/uploads/5dd0a57b64fadfeb9a24ab48508072cd/signing.test.db.signed.jnl.txt)
This has been observed in both 9.9.4 and a recent master (commit 498491555e578626a37380e8baf3ee0d48dff815). I have ```rr``` recordings from both versions and can arrange to upload them if requested.Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/241dnssec system test fails consistently2021-10-04T12:41:32ZCurtis Blackburndnssec system test fails consistentlyon centos 7 and fedora 26 in jenkins, the dnssec system test fails at
```
I:dnssec:check dnskey-sig-validity sets longer expiry for DNSKEY (199)
I:dnssec:failed
```on centos 7 and fedora 26 in jenkins, the dnssec system test fails at
```
I:dnssec:check dnskey-sig-validity sets longer expiry for DNSKEY (199)
I:dnssec:failed
```https://gitlab.isc.org/isc-projects/bind9/-/issues/242Large amount of in-view zones, task pools and memory contexts2021-09-02T12:05:51ZGhost UserLarge amount of in-view zones, task pools and memory contextsWhen using in-view zones excessively bind seems to make no distinction between "actual" zones and zones just referenced elsewhere through "in-view".
This manifests, for example, when implementing GeoDNS via views and in-view. With only ...When using in-view zones excessively bind seems to make no distinction between "actual" zones and zones just referenced elsewhere through "in-view".
This manifests, for example, when implementing GeoDNS via views and in-view. With only 178 distinct zone files loaded, bind allocates task pools for 25690 zones in a setup I am administrating.
In this setup there is a baseline zone file in a "fallback" view for each zone, with additional zone files in country-specific views for GeoDNS targeting, where required.
If a zone does not carry any country-specific information, the country-specific view references the fallback via "in-view".
However, the basis for the calculation of required task pools and memory contexts is the number of zones in all views, regardless of the fact that a zone might be referenced via "in-view".
Correct me if I am wrong, but shouldn't bind only count distinct zones, factoring in when they are referenced via "in-view"?
Affected bind versions are 9.10.x up to at least 9.12.1, when having a look at bind/named/server.c (load_configuration) and the calculation of the number of zones via count_zones there.September 2021 (9.16.21, 9.16.21-S1, 9.17.18)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/243BIND 9.10.6-S3 Crash at rbtdb.c:22232020-01-30T15:57:39ZCathy AlmondBIND 9.10.6-S3 Crash at rbtdb.c:2223```
2018-04-01T14:12:51+00:00 facility="daemon" level="crit" program="named" header="named[35970]: " msg="rbtdb.c:2223: INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed, back trace"
```
Also seen intermittently from 9.1...```
2018-04-01T14:12:51+00:00 facility="daemon" level="crit" program="named" header="named[35970]: " msg="rbtdb.c:2223: INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed, back trace"
```
Also seen intermittently from 9.10.5-S4 as:
```
rbtdb.c:2226: INSIST(!((void *)((node)->deadlink.prev) != (void *)(-1))) failed, back
trace
```
----
Currently awaiting core dumps from non-stripped binaries.
* https://support.isc.org/Ticket/Display.html?id=12089
* https://support.isc.org/Ticket/Display.html?id=12631
* https://support.isc.org/Ticket/Display.html?id=13391https://gitlab.isc.org/isc-projects/bind9/-/issues/244Non-DNSSEC build fails to compile2018-05-14T02:27:34ZMark AndrewsNon-DNSSEC build fails to compile```
cc -g -O2 -I/usr/local/include/libxml2 -I/usr/include -I /usr/local/include -fPIC -Wl,-E -o acl_test acl_test.o dnstest.o ../libdns.a -lgssapi -lkrb5 -lgssapi_krb5 -lcrypt -lasn1 -lroken -lcom_err ../../isc/libisc.a -ljson-c -L/...```
cc -g -O2 -I/usr/local/include/libxml2 -I/usr/include -I /usr/local/include -fPIC -Wl,-E -o acl_test acl_test.o dnstest.o ../libdns.a -lgssapi -lkrb5 -lgssapi_krb5 -lcrypt -lasn1 -lroken -lcom_err ../../isc/libisc.a -ljson-c -L/usr/local/lib -lxml2 -lz -llzma -L/usr/lib -lm -L/usr/local/lib -L/usr/home/tbox/cvs/robie/builds/bind9.master.no-dnssec/bind9/unit/atf/lib -latf-c -lm
../libdns.a(dst_api.o): In function `dst__entropy_getdata':
/usr/home/tbox/cvs/robie/builds/bind9.master.no-dnssec/bind9/lib/dns/dst_api.c:1965: undefined reference to `dst_random_getdata'
```Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/245rpz test fails to launch ns2 on openbsd2018-05-25T20:02:27ZCurtis Blackburnrpz test fails to launch ns2 on openbsdon openbsd61-64 the rpz test emits errors when ran with `sh run.sh rpz`
tested on master, v9_12, and the 9.12.1-P1 tarball
```
---output---
$ sh run.sh rpz
tput: not enough arguments (3) for capability `setaf'
tput: not enough argu...on openbsd61-64 the rpz test emits errors when ran with `sh run.sh rpz`
tested on master, v9_12, and the 9.12.1-P1 tarball
```
---output---
$ sh run.sh rpz
tput: not enough arguments (3) for capability `setaf'
tput: not enough arguments (3) for capability `setaf'
tput: not enough arguments (3) for capability `setaf'
S:rpz:Thu May 3 20:05:18 PDT 2018
T:rpz:1:A
A:System test rpz
tput: not enough arguments (3) for capability `setaf'
tput: not enough arguments (3) for capability `setaf'
tput: not enough arguments (3) for capability `setaf'
tput: not enough arguments (3) for capability `setaf'
tput: not enough arguments (3) for capability `setaf'
tput: not enough arguments (3) for capability `setaf'
tput: not enough arguments (3) for capability `setaf'
I:Couldn't start server ns2 (pid=29602)
I:failed
kill: 29602: No such process
R:FAIL
E:rpz:Thu May 3 20:05:38 PDT 2018
---end output---
```
upon investigation, the setup.sh script is not successfully completing,
which leads to ns2 failing to launch.https://gitlab.isc.org/isc-projects/bind9/-/issues/246fails to build with libressl 2.7.22018-05-07T02:40:14ZGhost Userfails to build with libressl 2.7.2<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
Bind 9.11.3 fails to build with libressl 2.7.2
### What is the current *bug* behavior?
the following errors are generated:
`cc -pthread -I/wrkdirs/usr/ports/dns/bind911/work/bind-9.11.3 -I../.. -I. -I../../lib/dns -Iinclude -I/wrkdirs/usr/ports/dns/bind911/work/bind-9.11.3/lib/dns/include -I../../lib/dns/include -I/wrkdirs/usr/ports/dns/bind911/work/bind-9.11.3/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/pthreads/include -I../../lib/isc/x86_32/include -I/usr/local/include -I/usr/local/include -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_MD5 -DOPENSSL -DDIG_SIGCHASE=1 -D_THREAD_SAFE -O2 -pipe -DLIBICONV_PLUG -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/include -I/usr/local/include -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -c openssldh_link.c
openssldh_link.c:78:1: error: static declaration of 'DH_get0_key' follows non-static declaration
DH_get0_key(const DH *dh, const BIGNUM **pub_key, const BIGNUM **priv_key) {
^
/usr/local/include/openssl/dh.h:196:6: note: previous declaration is here
void DH_get0_key(const DH *dh, const BIGNUM **pub_key, const BIGNUM **priv_key);
^
openssldh_link.c:86:1: error: static declaration of 'DH_set0_key' follows non-static declaration
DH_set0_key(DH *dh, BIGNUM *pub_key, BIGNUM *priv_key) {
^
/usr/local/include/openssl/dh.h:197:5: note: previous declaration is here
int DH_set0_key(DH *dh, BIGNUM *pub_key, BIGNUM *priv_key);
^
openssldh_link.c:100:1: error: static declaration of 'DH_get0_pqg' follows non-static declaration
DH_get0_pqg(const DH *dh,
^
/usr/local/include/openssl/dh.h:193:6: note: previous declaration is here
void DH_get0_pqg(const DH *dh, const BIGNUM **p, const BIGNUM **q,
^
openssldh_link.c:112:1: error: static declaration of 'DH_set0_pqg' follows non-static declaration
DH_set0_pqg(DH *dh, BIGNUM *p, BIGNUM *q, BIGNUM *g) {
^
/usr/local/include/openssl/dh.h:195:5: note: previous declaration is here
int DH_set0_pqg(DH *dh, BIGNUM *p, BIGNUM *q, BIGNUM *g);
^
4 errors generated.
*** Error code 1`
`Stop.
make[3]: stopped in /wrkdirs/usr/ports/dns/bind911/work/bind-9.11.3/lib/dns`https://gitlab.isc.org/isc-projects/bind9/-/issues/247Log the remaining -V info at startup2018-06-25T22:28:22ZMark AndrewsLog the remaining -V info at startupMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/248named 9.12 uses too much memory with `--tuning=large` (regression vs. 9.11)2018-05-11T01:31:38ZGhost Usernamed 9.12 uses too much memory with `--tuning=large` (regression vs. 9.11)`named`, when run within the system tests such as `acl`, uses more than 1GB RSS per process soon after starting.`named`, when run within the system tests such as `acl`, uses more than 1GB RSS per process soon after starting.https://gitlab.isc.org/isc-projects/bind9/-/issues/249Address GCC 8 compilation warnings2018-05-10T08:56:10ZMichał KępieńAddress GCC 8 compilation warningsGCC 8.1.0 on Arch Linux emits some compilation warnings that were not triggered by GCC 7.3.1 on the same system:
* in `bin/named/server.c`:
```
./server.c: In function ‘named_server_zonestatus’:
./server.c:13990:11: warning: ‘%s’ direc...GCC 8.1.0 on Arch Linux emits some compilation warnings that were not triggered by GCC 7.3.1 on the same system:
* in `bin/named/server.c`:
```
./server.c: In function ‘named_server_zonestatus’:
./server.c:13990:11: warning: ‘%s’ directive output may be truncated writing up to 1023 bytes into a region of size 512 [-Wformat-truncation=]
"%s/%s", namebuf, typebuf);
^- -------
./server.c:13989:4: note: ‘snprintf’ output between 2 and 1035 bytes into a destination of size 512
snprintf(resignbuf, sizeof(resignbuf),
^-------------------------------------
"%s/%s", namebuf, typebuf);
--------------------------
```
* in `bin/tests/system/dlzexternal/driver.c`:
```
driver.c: In function ‘dlz_lookup’:
driver.c:424:3: warning: ‘strncpy’ output may be truncated copying 255 bytes from a string of length 255 [-Wstringop-truncation]
strncpy(last, full_name, 255);
^----------------------------
```
* in `lib/dns/dnssec.c`:
```
dnssec.c: In function ‘dns_dnssec_findzonekeys’:
dnssec.c:800:21: warning: ‘%s’ directive output may be truncated writing up to 1023 bytes into a region of size 242 [-Wformat-truncation=]
"key file for %s/%s/%d",
^-
namebuf, algbuf, dst_key_id(pubkey));
-------
dnssec.c:800:7: note: directive argument in the range [0, 65535]
"key file for %s/%s/%d",
^----------------------
dnssec.c:799:5: note: ‘snprintf’ output between 17 and 1063 bytes into a destination of size 255
snprintf(filename, sizeof(filename) - 1,
^---------------------------------------
"key file for %s/%s/%d",
------------------------
namebuf, algbuf, dst_key_id(pubkey));
------------------------------------
dnssec.c: In function ‘dns_dnssec_keylistfromrdataset’:
dnssec.c:1692:21: warning: ‘%s’ directive output may be truncated writing up to 1023 bytes into a region of size 242 [-Wformat-truncation=]
"key file for %s/%s/%d",
^-
namebuf, algbuf, dst_key_id(pubkey));
-------
dnssec.c:1692:7: note: directive argument in the range [0, 65535]
"key file for %s/%s/%d",
^----------------------
dnssec.c:1691:5: note: ‘snprintf’ output between 17 and 1063 bytes into a destination of size 255
snprintf(filename, sizeof(filename) - 1,
^---------------------------------------
"key file for %s/%s/%d",
------------------------
namebuf, algbuf, dst_key_id(pubkey));
------------------------------------
```
* in `lib/dns/rdata/generic/loc_29.c`:
```
In file included from code.h:56,
from rdata.c:560:
rdata/generic/loc_29.c: In function ‘totext_loc.isra.328’:
rdata/generic/loc_29.c:558:60: warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=]
"%d %d %d.%03d %s %d %d %d.%03d %s %s%lu.%02lum %s %s %s",
^
rdata/generic/loc_29.c:557:2: note: ‘snprintf’ output between 33 and 75 bytes into a destination of size 74
snprintf(buf, sizeof(buf),
^-------------------------
"%d %d %d.%03d %s %d %d %d.%03d %s %s%lu.%02lum %s %s %s",
----------------------------------------------------------
d1, m1, s1, fs1, north ? "N" : "S",
-----------------------------------
d2, m2, s2, fs2, east ? "E" : "W",
----------------------------------
below ? "-" : "", altitude/100, altitude % 100,
-----------------------------------------------
sbuf, hbuf, vbuf);
-----------------
```
* in `lib/isc/{unix,win32}/file.c`:
```
file.c: In function 'isc_file_sanitize':
file.c:742:36: error: '%s' directive output may be truncated writing up to 1 bytes into a region of size between 0 and 4096 [-Werror=format-truncation=]
snprintf(buf, sizeof(buf), "%s%s%s%s%s",
^-
file.c:742:2: note: 'snprintf' output 1 or more bytes (assuming 4098) into a destination of size 4096
snprintf(buf, sizeof(buf), "%s%s%s%s%s",
^---------------------------------------
dir != NULL ? dir : "", dir != NULL ? "/" : "",
-----------------------------------------------
hash, ext != NULL ? "." : "", ext != NULL ? ext : "");
-----------------------------------------------------
file.c:752:36: error: '%s' directive output may be truncated writing up to 1 bytes into a region of size between 0 and 4096 [-Werror=format-truncation=]
snprintf(buf, sizeof(buf), "%s%s%s%s%s",
^-
file.c:752:2: note: 'snprintf' output 1 or more bytes (assuming 4098) into a destination of size 4096
snprintf(buf, sizeof(buf), "%s%s%s%s%s",
^---------------------------------------
dir != NULL ? dir : "", dir != NULL ? "/" : "",
-----------------------------------------------
hash, ext != NULL ? "." : "", ext != NULL ? ext : "");
-----------------------------------------------------
```
* in `lib/ns/notify.c`:
```
notify.c: In function ‘ns_notify_start’:
notify.c:128:53: warning: ‘%s’ directive output may be truncated writing up to 1023 bytes into a region of size between 0 and 1023 [-Wformat-truncation=]
snprintf(tsigbuf, sizeof(tsigbuf), ": TSIG '%s' (%s)",
^-
namebuf, cnamebuf);
--------
notify.c:128:4: note: ‘snprintf’ output between 13 and 2059 bytes into a destination of size 1034
snprintf(tsigbuf, sizeof(tsigbuf), ": TSIG '%s' (%s)",
^-----------------------------------------------------
namebuf, cnamebuf);
------------------
```
None of these look serious to me. AFAICT, the worst case scenario is truncated output.BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/250Replace ATF+Kyua with something lighter2018-06-20T10:38:42ZOndřej SurýReplace ATF+Kyua with something lighterThe ATF suite is really heavyweight, and we are not really using it's full potential. Something simpler like [C-TAP Harness](https://www.eyrie.org/~eagle/software/c-tap-harness/) could be used instead.
Requirements:
* Support for all o...The ATF suite is really heavyweight, and we are not really using it's full potential. Something simpler like [C-TAP Harness](https://www.eyrie.org/~eagle/software/c-tap-harness/) could be used instead.
Requirements:
* Support for all our supported platforms (Linux, BSDs)
* Support for all our best-effort platforms (Windows, Solaris) (?)
* Support for mocking objects
* Support for catching assertions
* Output in Test Anything Protocol
* Output in xUnit/jUnit
* Active upstream developmentLong-termOndřej SurýOndřej Surý