BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-02-15T15:24:10Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4584Feature request: streamline the behavior of 'hostname' and 'server-id'2024-02-15T15:24:10ZMarco DavidsFeature request: streamline the behavior of 'hostname' and 'server-id'### Description
`hostname` default is the hostname of the machine hosting the name server, as found by the gethostname() function.
`server-id` default is `none`.
This may lead to confusion. Especially since other vendors (Unbound, Kno...### Description
`hostname` default is the hostname of the machine hosting the name server, as found by the gethostname() function.
`server-id` default is `none`.
This may lead to confusion. Especially since other vendors (Unbound, Knot) do it differently by combining the two (via the `identity` option).
### Request
To put both option-defaults more inline with each other. And perhaps even to consider to combine them, instead of treating them as separate entities. RFC4892 seams to suggest they are alternative ways of pointing to the same thing and this is also how Knot and Unbound interpret it.
Perhaps, while at it, also consider the usefulness of SOA and NS records in the reply (in the case of `CH ANY version.bind` and `CH ANY authors.bind`), because they are still shown, even if `server-id` is undefined, while their existence is not clear.
### Links / references
RFC4892 and RFC5001 may be relevant.https://gitlab.isc.org/isc-projects/bind9/-/issues/4572TLS forwarder lookup fails in resolver.c when TLS CA certificate not available2024-02-21T20:41:29ZTobias WolterTLS forwarder lookup fails in resolver.c when TLS CA certificate not available### Summary
When configuring a forwarder with a TLS configuration that specifies a CA file to verify the remote certificate, BIND dies at the RUNTIME_CHECK in resolver.c when it cannot read the CA file.
### BIND version affected
BIND ...### Summary
When configuring a forwarder with a TLS configuration that specifies a CA file to verify the remote certificate, BIND dies at the RUNTIME_CHECK in resolver.c when it cannot read the CA file.
### BIND version affected
BIND 9.19.19-1+0~20231220.107+debian12~1.gbpfc5ec0-Debian (Development Release) <id:>
### Steps to reproduce
1. Use the provided configuration snippet in any working configuration.
2. Do *not* have a `/certificates` directory.
3. Look up something from test.example.com.
### What is the current *bug* behavior?
BIND crashes in the resolver library due to the TLS context not being set up correctly.
### What is the expected *correct* behavior?
BIND complains about not being able to read about the CA certificate on startup.
### Relevant configuration files
* named.conf (excerpt):
```
tls auth1 {
ca-file "/certificates/ca.crt";
remote-hostname "auth1";
};
tls auth2 {
ca-file "/certificates/ca.crt";
remote-hostname "auth2";
};
zone test.example.com {
type forward;
forwarders port 853 { 172.23.23.11 tls auth1; 172.23.23.12 tls auth2; };
forward only;
};
```
### Relevant logs
```
recursive-2 | 12-Feb-2024 08:57:44.370 client @0x713184c1c000 172.23.23.23#45455 (foo.test.example.com): query: foo.test.example.com IN A +E(0)K (172.23.23.14)
recursive-2 | fetch: foo.test.example.com/A
recursive-2 | QNAME minimization - minimized, qmintype 2 qminname corp
recursive-2 | resolver.c:2175:fctx_query(): fatal error:
recursive-2 | RUNTIME_CHECK(result == ISC_R_SUCCESS) failed
recursive-2 | exiting (due to fatal error in library)
recursive-2 exited with code 139
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4532An option to not have bind9/dnssec-settime (possibly other tools) reset permi...2024-01-16T20:30:36ZDan MahoneyAn option to not have bind9/dnssec-settime (possibly other tools) reset permissions on a .private file.### Description
The `named` process and `dnssec-settime` (perhaps other tools) will take it upon themselves to change the permissions of a private key on certain changes.
However, we track our key-directory (and other configs) using gi...### Description
The `named` process and `dnssec-settime` (perhaps other tools) will take it upon themselves to change the permissions of a private key on certain changes.
However, we track our key-directory (and other configs) using git, with a group-shared repository.
Typical permissions on .private files are bind:bind with mode 660, but because a normal user (in the bind group) diffs/commits/pushes the repository, these keys can also be user:bind mode 660.
(Noting as well that our tooling is not more comfortable running git tasks as root, complaining of other permissions issues. Also, the less we can do as root, the better.)
With bind's usual permissions model, one cannot do a git diff/git log if the file is owned by bind. If the file is owned by user:bind, bind loses access to it on the permissions change.
Changing the umask under which the process runs doesn't seem to fix this, we tried.
Running a periodic cron job to fix this is a possible workaround, but feels like it shouldn't be necessary.
### Request
For command line tools, an option to not do this.
For `named, an `options` statement that lets us turn this off.
Both retaining the current behavior by default.
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4284CID 464884: Null pointer dereference in bin/tests/system/dyndb/driver/db.c2023-09-08T10:04:22ZMichal NowakCID 464884: Null pointer dereference in bin/tests/system/dyndb/driver/db.cCoverity Scan detected the following issue in `bin/tests/system/dyndb/driver/db.c`.
It's either something new, or Coverity Scan got interested in `bin/tests/system/dyndb/driver/db.c` because it was changed in 1d341096c1343e0a7df9888fb7c...Coverity Scan detected the following issue in `bin/tests/system/dyndb/driver/db.c`.
It's either something new, or Coverity Scan got interested in `bin/tests/system/dyndb/driver/db.c` because it was changed in 1d341096c1343e0a7df9888fb7c71483f1f14be2.
```
/bin/tests/system/dyndb/driver/db.c: 644 in create_db()
638
639 *dbp = (dns_db_t *)sampledb;
640
641 return (ISC_R_SUCCESS);
642
643 cleanup:
>>> CID 464884: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "sampledb" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
644 if (sampledb != NULL) {
645 if (dns_name_dynamic(&sampledb->common.origin)) {
646 dns_name_free(&sampledb->common.origin, mctx);
647 }
648
649 isc_mem_putanddetach(&sampledb->common.mctx, sampledb,
```September 2023 (9.16.44, 9.16.44-S1, 9.18.19, 9.18.19-S1, 9.19.17)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4087Follow-up from "fix handling of TCP timeouts"2023-11-02T16:30:30ZEvan HuntFollow-up from "fix handling of TCP timeouts"The following discussion from !7937 should be addressed:
- [ ] @aram started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7937#note_375087): (+2 comments)
> While you are addressing Ondřej's comments, ...The following discussion from !7937 should be addressed:
- [ ] @aram started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7937#note_375087): (+2 comments)
> While you are addressing Ondřej's comments, would you please also look at something not strictly related to this MR, which caught my eye (cc @ondrej):
>
> ```c
> void
> dns_dispatch_resume(dns_dispentry_t *resp, uint16_t timeout);
> /*%<
> * Reset the read timeout in the socket associated with 'resp' and
> * continue reading.
> *
> * Requires:
> *\li 'resp' is valid.
> */
> ```
>
> The function is supposed to reset the read timeout, but if I am reading the code correctly, both `udp_dispatch_getnext()` and `tcp_dispatch_getnext()` (called by `dns_dispatch_resume()`) potentially can ignore the timeout value if the read operation is already ongoing. Is that by design?
>
> I think it should at least update the `resp->timeout` value with the new one, and probably call `isc_nmhandle_settimeout()` even when already reading, in case if the new timeout is smaller than the remaining time of the current one.Not plannedEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/4061CID 454694: Code maintainability issue in lib/dns/request.c2023-05-16T12:54:45ZMichal NowakCID 454694: Code maintainability issue in lib/dns/request.cThe newly updated Coverity Scan claims "code maintainability issue" in `lib/dns/request.c` on ~"v9.16".
```
/lib/dns/request.c: 981 in dns_request_createvia()
975 /*
976 * Try again using TCP.
977 */
978 dns_me...The newly updated Coverity Scan claims "code maintainability issue" in `lib/dns/request.c` on ~"v9.16".
```
/lib/dns/request.c: 981 in dns_request_createvia()
975 /*
976 * Try again using TCP.
977 */
978 dns_message_renderreset(message);
979 dns_dispatch_removeresponse(&request->dispentry, NULL);
980 dns_dispatch_detach(&request->dispatch);
>>> CID 454694: Code maintainability issues (UNUSED_VALUE)
>>> Assigning value "NULL" to "sock" here, but that stored value is overwritten before it can be used.
981 sock = NULL;
982 options |= DNS_REQUESTOPT_TCP;
983 settsigkey = false;
984 goto use_tcp;
985 }
986 if (result != ISC_R_SUCCESS) {
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4019CID 452208: locking issue in tests/bench/qpmulti.c2023-05-12T20:43:31ZMichal NowakCID 452208: locking issue in tests/bench/qpmulti.cCoverity Scan claims a locking issue in a test code rooted in !7582.
```
/tests/bench/qpmulti.c: 296 in read_transactions()
290 if (result == ISC_R_SUCCESS) {
291 args->present++;
292 } else {
293 args->abs...Coverity Scan claims a locking issue in a test code rooted in !7582.
```
/tests/bench/qpmulti.c: 296 in read_transactions()
290 if (result == ISC_R_SUCCESS) {
291 args->present++;
292 } else {
293 args->absent++;
294 }
295 }
>>> CID 452208: API usage errors (LOCK)
>>> "dns_qpread_destroy" unlocks "args->multi->mutex" while it is unlocked.
296 dns_qpread_destroy(args->multi, &qp);
297 }
298 next_loop(args, start);
299 }
300
301 static void
```June 2023 (9.16.42, 9.16.42-S1, 9.18.16, 9.18.16-S1, 9.19.14)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4012remove win2k GSS-TSIG hacks2023-06-12T12:49:15ZEvan Huntremove win2k GSS-TSIG hacksOur GSSAPI implementation includes non-standard code to allow interoperation with Windows 2000. That OS reached its end of life 13 years ago, so it would probably be worthwhile to consider removing the extra code.
This would involve dep...Our GSSAPI implementation includes non-standard code to allow interoperation with Windows 2000. That OS reached its end of life 13 years ago, so it would probably be worthwhile to consider removing the extra code.
This would involve deprecating the `-o` option and the `oldgsstsig` command to `nsupdate`.
My suggestion is to remove the functionality now and make `-o` a synonym for `-g` and `oldgsstsig` a synonym for `gsstsig`. We can actually remove them in a later release.June 2023 (9.16.42, 9.16.42-S1, 9.18.16, 9.18.16-S1, 9.19.14)https://gitlab.isc.org/isc-projects/bind9/-/issues/3951TSIG-GSS keys should be deleted after use2023-11-02T16:30:30ZEvan HuntTSIG-GSS keys should be deleted after use@pspacek pointed out in !7629:
> Can we have test for key removal (coverage shows it's not tested)?
This is a problem. That code path was previously tested in the `tkey` system test, which negotiated the creation of DH keys and then del...@pspacek pointed out in !7629:
> Can we have test for key removal (coverage shows it's not tested)?
This is a problem. That code path was previously tested in the `tkey` system test, which negotiated the creation of DH keys and then deleted them, but that test has been removed now.
The `tsiggss` test runs `nsupdate`, which sets up GSS keys, but never deletes them.
RFC 3645 says:
```
When the client is not intended to continue using the established
security context, the client SHOULD delete an active context by
calling GSS_Delete_sec_context providing the associated
context_handle, AND client SHOULD delete the established context on
the DNS server by using TKEY RR with the Mode field set to 5, i.e.,
"key deletion" [RFC2930].
```
I take this to mean that `nsupdate` should be sending a delete message for negotiated keys when it's shutting down.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3912Updates to DoH +http and +https options for dig2023-03-14T16:16:02ZAlexey ChernyakUpdates to DoH +http and +https options for dig### Description
This is a request for updating DoH options in `dig` by:
1. Adding new options for specifying HTTP `:authority` pseudo-header and/or `Host:` header
2. Adding shorter alternatives to the existing HTTP/2 options.
### Reque...### Description
This is a request for updating DoH options in `dig` by:
1. Adding new options for specifying HTTP `:authority` pseudo-header and/or `Host:` header
2. Adding shorter alternatives to the existing HTTP/2 options.
### Request
**1. New DoH Options**
Add new `+http-authority=value` option to control the HTTP/2 (or HTTP/3) `:authority` pseudo-header within the DoH HTTP request, i.e.:
```
:method = GET
:scheme = https
:authority = dnsserver.example.net
```
Also add new `+http-host=value` option to control the HTTP/1.1 or HTTP/2 or HTTP/3 `Host:` header within the DoH HTTP request, i.e.:
```
:method = GET
:scheme = https
Host: dnsserver.example.net
```
These options are required for 2 use cases:
1. Bootstrapping a DoH query to a `@server` IP address without relying on any additional DNS resolution of the `@server` hostname.
2. Domain Fronting of DoH once issue #3896 implements SNI support in `dig`.
The expected future behaviour is:
* `@server` argument and `-p` option control what server IP address and port `dig` connects to.
* `+tls-sni` option controls what SNI hostname `dig` requests in `ClientHello` during TLS handshake.
* `+http-authority` and `-p` options control what `dig` requests within the HTTP `:authority` pseudo-header.
* `+http-host` and `-p` options control what `dig` requests within the HTTP `Host:` header.
* `+tls-hostname` option controls `dig` validation of certificate returned by `ServerHello` during TLS handshake.
HTTP `:authority` pseudo-header or HTTP `Host:` header should apply regardless of whether or not DoH connection is encapsulated in TLS.
Proposed logic is something along the lines of:
```
if request is DoH (either h2 or h2c)
if +http-authority option is specified
validate option input
HTTPauthority = option value
else if +http-host option is specified
validate option input
HTTPHost = option value
else if @server argument is a hostname
HTTPauthority = argument value
else if +tls-sni option is specified
HTTPauthority = option value
else if +tls-hostname option is specified
HTTPauthority = option value
else
HTTPauthority = server IP address
if +http-host option is specified
validate option input
HTTPHost = option value
if -p option is specified
if HTTPauthority is specified
if HTTPauthority doesn't include :port
HTTPauthority = HTTPauthority + ":" + port
if HTTPHost is specified
if HTTPHost doesn't include :port
HTTPHost = HTTPHost + ":" + port
if HTTPHost and HTTPauthority are specified
if HTTPHost differs from HTTPauthority
error
```
**2. Shorter Alternatives**
The DNSSEC option in `dig` currently has a number of shorter alternatives:
```
+dnssec, +do, +nodnssec, +nodo
```
This request is to add similar shorter standard HTTP/2 `h2` and `h2c` protocol identifier option alternatives to all existing `+http*` options in `dig`.
The proposed changes are outlined in the table below:
| Current | Proposed |
| --- | --- |
| `+https[=value], +nohttps` | `+https[=value], +h2[=value], +nohttps, +noh2 ` |
| `+https-get[=value], +nohttps-get` | `+https-get[=value], +h2-get[=value], +nohttps-get, +noh2-get` |
| `+https-post[=value], +nohttps-post` | `+https-post[=value], +h2-post[=value], +nohttps-post, +noh2-post` |
| `+http-plain[=value], +nohttp-plain` | `+http-plain[=value], +h2c[=value], +nohttp-plain, +noh2c` |
| `+http-plain-get[=value], +nohttp-plain-get` | `+http-plain-get[=value], +h2c-get[=value], +nohttp-plain-get, +noh2c-get` |
| `+http-plain-post[=value], +nohttp-plain-post` | `+http-plain-post[=value], +h2c-post[=value], +nohttp-plain-post, +noh2c-post` |
The use cases for this are:
* Reduction of some options length down to just 30% of the current.
* In the future ability to differentiate them from `+h3*` versions of these options when support for HTTP/3 DoH3 and DoQ is added (e.g. via nghttp3).
### Links / references
For HTTP `:authority` pseudo-header and `Host:` header request see:
* [Section 7.2 of RFC 9110: HTTP Semantics](https://datatracker.ietf.org/doc/html/rfc9110#section-7.2).
* [Section 8.3.1 of RFC 9113: HTTP/2](https://datatracker.ietf.org/doc/html/rfc9113#section-8.3.1).
* [Section 4.3.1 of RFC 9114: HTTP/3](https://datatracker.ietf.org/doc/html/rfc9114#section-4.3.1).
For standard definitions of `h2`, `h2c`, `h3`, `dot` and `doq` protocol identifiers see:
* [TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs](https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids)
* [Section 3.1 of RFC 9113: HTTP/2](https://datatracker.ietf.org/doc/html/rfc9113#section-3.1).
* [Section 11.1 of RFC 9114: HTTP/3](https://datatracker.ietf.org/doc/html/rfc9114#section-11.1).Not plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3872CID 436080: Calling "isc_timer_reset" without checking return value2023-02-15T11:16:24ZMichal NowakCID 436080: Calling "isc_timer_reset" without checking return valueCoverity Scan reports the following "issue" on `v9_18`, originating in 74bd205177794d1c14689eef84ae952c9826f678:
```
/lib/dns/rpz.c: 2088 in dns_rpz_zone_destroy()
2082 dns_db_updatenotify_unregister(rpz->db,
2083 d...Coverity Scan reports the following "issue" on `v9_18`, originating in 74bd205177794d1c14689eef84ae952c9826f678:
```
/lib/dns/rpz.c: 2088 in dns_rpz_zone_destroy()
2082 dns_db_updatenotify_unregister(rpz->db,
2083 dns_rpz_dbupdate_callback, rpz);
2084 dns_db_detach(&rpz->db);
2085 }
2086 INSIST(!rpz->updaterunning);
2087
>>> CID 436080: Error handling issues (CHECKED_RETURN)
>>> Calling "isc_timer_reset" without checking return value (as is done elsewhere 9 out of 10 times).
2088 isc_timer_reset(rpz->updatetimer, isc_timertype_inactive, NULL, NULL,
2089 true);
2090 isc_timer_destroy(&rpz->updatetimer);
2091
2092 isc_ht_destroy(&rpz->nodes);
2093
```March 2023 (9.16.39, 9.16.39-S1, 9.18.13, 9.18.13-S1, 9.19.11)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3820"distclean" target fails on FreeBSD2023-01-27T07:35:56ZMichal Nowak"distclean" target fails on FreeBSDThe `distclean` target fails on FreeBSD.
`autoreconf -fi && ./configure && make distclean`:
```
Making distclean in bench
make[2]: "/usr/home/newman/bind9/tests/bench/Makefile" line 565: Could not find ../../fuzz/.deps/old.Po
make[2]: ...The `distclean` target fails on FreeBSD.
`autoreconf -fi && ./configure && make distclean`:
```
Making distclean in bench
make[2]: "/usr/home/newman/bind9/tests/bench/Makefile" line 565: Could not find ../../fuzz/.deps/old.Po
make[2]: Fatal errors encountered -- cannot continue
make[2]: stopped in /usr/home/newman/bind9/tests/bench
```
Works with GNU make 4.3 from Ports.
It's there probably since 04f3000dfc4c1081c9e1e4752cf47c792e853d6fTony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3796Building BIND on newer versions of DragonFly BSD (at least 6.4) fails (w/ and...2023-02-03T14:24:47ZArtem BoldarievBuilding BIND on newer versions of DragonFly BSD (at least 6.4) fails (w/ and w/o Jemalloc)While doing some investigations for #3774, it was found that building BIND 9 is not possible on that platform as our memory management code fails to build on this platform when configuring with both `--with-jemalloc=yes` and `--with-jema...While doing some investigations for #3774, it was found that building BIND 9 is not possible on that platform as our memory management code fails to build on this platform when configuring with both `--with-jemalloc=yes` and `--with-jemalloc=no`. I think that it would be fair to make it work at least in the case when jemalloc-specific APIs are not available (like in the case of OpenBSD). BIND builds fine at least for DragonFly 6.2, according to @mnowak report in #3774. Obviously, that happens due to the changes to OS-specific headers.
## When Jemalloc is detected or when building with `--with-jemalloc=yes`
By default, `./configure` tries to detect presence of `<malloc_np.h>` and assumes that when it is available, Jemalloc specific API is availalbe (`mallocx()`, `sdallocx()`, `rallocx()`, etc). The header usually corresponds to `<jemalloc/jemalloc.h>` in upstream versions of Jemalloc. In this case `HAVE_MALLOC_NP_H` is defined in `config.h`.
That used to be the case for DragonFly BSD, but is not tanymore. On this platform `./configure` script works fine, but building BIND will fail as follows:
```
mem.c: In function 'mem_get':
mem.c:343:8: error: implicit declaration of function 'mallocx'; did you mean 'malloc'? [-Werror=implicit-function-declaration]
ret = mallocx(size, flags);
^~~~~~~
malloc
mem.c:343:6: warning: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
ret = mallocx(size, flags);
^
mem.c: In function 'mem_put':
mem.c:365:2: error: implicit declaration of function 'sdallocx'; did you mean 'reallocf'? [-Werror=implicit-function-declaration]
sdallocx(mem, size, flags);
^~~~~~~~
reallocf
mem.c: In function 'mem_realloc':
mem.c:375:12: error: implicit declaration of function 'rallocx'; did you mean 'reallocf'? [-Werror=implicit-function-declaration]
new_ptr = rallocx(old_ptr, new_size, flags);
^~~~~~~
reallocf
mem.c:375:10: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
new_ptr = rallocx(old_ptr, new_size, flags);
^
In file included from ./include/isc/hash.h:22,
from mem.c:26:
mem.c: In function 'mem_initialize':
mem.c:441:32: error: 'MALLOCX_ZERO' undeclared (first use in this function)
RUNTIME_CHECK(ISC_MEM_ZERO == MALLOCX_ZERO);
...
```
Keep in mind that `HAVE_MALLOC_NP_H` is defined in the case above, as the header is present. The case is that it does not provide the required API.
## When building without Jemalloc (`--with-jemalloc=yes`)
In such a case, `jemalloc_shim.h` is broken (the file is intended to provide a simple implementation of Jemalloc specific APIs using the available OS-specific capabilities). It fails as follows:
```
jemalloc_shim.h:44:10: fatal error: malloc.h: No such file or directory
#include <malloc.h>
^~~~~~~~~~
```
As memory allocator on DragonFly BSD does have `malloc_usable_size()`, we end up building with `HAVE_MALLOC_USABLE_SIZE` defined (which is not a surprise, as it is still a custom version of Jemalloc). In such a case, we attempt to include non-standard `<malloc.h>` ... which is not available on DragonFly BSD anymore. As far as I understand the matter, on newer versions of DragonFly BSD we should use `<sys/malloc.h>`. Doing so fixes the build. We can solve this by introducing `HAVE_SYS_MALLOC_H`, I guess.
To lessen maintenance pressure, I would suggest to assume that Jemalloc is not available on Dragon Fly BSD and use the generic code (the one used on OpenBSD)February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3780inconsistent use of "deprecated"2023-04-29T08:17:45ZEvan Huntinconsistent use of "deprecated"There's inconsistent usage of "deprecated" and "obsolete" in the man pages and ARM, it should be tidied up.There's inconsistent usage of "deprecated" and "obsolete" in the man pages and ARM, it should be tidied up.March 2023 (9.16.39, 9.16.39-S1, 9.18.13, 9.18.13-S1, 9.19.11)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3774TCP, DNS over TCP, and DNS over TLS unit tests fail or hang on Dragonfly BSD2023-05-29T13:13:36ZMichal NowakTCP, DNS over TCP, and DNS over TLS unit tests fail or hang on Dragonfly BSD`tcp_test`, `tcpdns_test`, `tls_test`, and `tlsdns_test` unit tests fail on Dragonfly BSD 6.2.1 in `*_noop` and `*_noresponse` tests like this:
```
[==========] Running 6 test(s).
[ RUN ] tlsdns_noop
Could not run test: 0x30 != 0
[ ...`tcp_test`, `tcpdns_test`, `tls_test`, and `tlsdns_test` unit tests fail on Dragonfly BSD 6.2.1 in `*_noop` and `*_noresponse` tests like this:
```
[==========] Running 6 test(s).
[ RUN ] tlsdns_noop
Could not run test: 0x30 != 0
[ LINE ] --- netmgr_common.c:621: error: Failure!0 != 0x1
[ LINE ] --- netmgr_common.c:650: error: Failure!Test teardown failed
[ ERROR ] tlsdns_noop
[ RUN ] tlsdns_noresponse
loop.c:343: REQUIRE(loopmgrp != ((void *)0) && *loopmgrp == ((void *)0)) failed, back trace
0x80068d0bc <isc_assertion_typetotext+0x6c> at /home/newman/bind9/lib/isc/.libs/libisc-9.19.9-dev.so
0x80068d02a <isc_assertion_failed+0xa> at /home/newman/bind9/lib/isc/.libs/libisc-9.19.9-dev.so
0x80069f1aa <isc_loopmgr_create+0x4ea> at /home/newman/bind9/lib/isc/.libs/libisc-9.19.9-dev.so
0x40627d <setup_loopmgr+0x4d> at /home/newman/bind9/tests/isc/.libs/tlsdns_test
0x404f75 <setup_netmgr_test+0x1e5> at /home/newman/bind9/tests/isc/.libs/tlsdns_test
0x405989 <stream_noresponse_setup+0x9> at /home/newman/bind9/tests/isc/.libs/tlsdns_test
0x80061cb95 <_test_realloc+0x485> at /usr/local/lib/libcmocka.so.0
0x80061d3b6 <_cmocka_run_group_tests+0x326> at /usr/local/lib/libcmocka.so.0
0x403a87 <main+0x47> at /home/newman/bind9/tests/isc/.libs/tlsdns_test
FAIL tlsdns_test (exit status: 134)
```
```
(gdb) bt
#0 0x00000008015cc79c in lwp_kill () from /lib/libc.so.8
#1 0x00000008013607f2 in _thr_send_sig () from /usr/lib/libpthread.so.0
#2 0x0000000801357ee5 in raise () from /usr/lib/libpthread.so.0
#3 0x0000000801666dff in abort () from /lib/libc.so.8
#4 0x000000080068d02f in isc_assertion_failed (file=file@entry=0x8006ce806 "loop.c", line=line@entry=343, type=type@entry=isc_assertiontype_require,
cond=cond@entry=0x8006c74b0 "loopmgrp != ((void *)0) && *loopmgrp == ((void *)0)") at assertions.c:50
#5 0x000000080069f1aa in isc_loopmgr_create (mctx=<optimized out>, nloops=<optimized out>, loopmgrp=loopmgrp@entry=0x408d60 <loopmgr>) at loop.c:219
#6 0x000000000040627d in setup_loopmgr (state=state@entry=0x802022500) at isc.c:73
#7 0x0000000000404f75 in setup_netmgr_test (state=0x802022500) at netmgr_common.c:161
#8 0x0000000000405989 in stream_noresponse_setup (state=<optimized out>) at netmgr_common.c:716
#9 0x000000080061cb95 in ?? () from /usr/local/lib/libcmocka.so.0
#10 0x000000080061d3b6 in _cmocka_run_group_tests () from /usr/local/lib/libcmocka.so.0
#11 0x0000000000403a87 in main () at tlsdns_test.c:162
```BIND 9.19.xArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3757named-checkconfig -px inserts extra blanks in output2022-12-31T08:40:56ZPhilip Prindevillenamed-checkconfig -px inserts extra blanks in output<!--
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
Certain multiline commands like `listen-on-v6` generate two spaces instead of one before the leading left curly bracket.
### BIND version used
```
BIND 9.18.10 (Stable Release) <id:aa8ab10>
running on Linux x86_64 5.15.85 #0 SMP Mon Dec 26 23:46:44 2022
built by make with '--target=x86_64-openwrt-linux' '--host=x86_64-openwrt-linux' '--build=x86_64-pc-linux-gnu' '--program-prefix=' '--program-suffix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--libexecdir=/usr/lib' '--sysconfdir=/etc' '--datadir=/usr/share' '--localstatedir=/var' '--mandir=/usr/man' '--infodir=/usr/info' '--with-openssl=/home/philipp/lede/staging_dir/target-x86_64_musl/usr' '--without-lmdb' '--enable-epoll' '--without-gssapi' '--without-readline' '--sysconfdir=/etc/bind' '--with-json-c=no' '--with-libxml2=no' '--enable-doh' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-openwrt-linux' 'target_alias=x86_64-openwrt-linux' 'CC=x86_64-openwrt-linux-musl-gcc' 'CFLAGS=-Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -fmacro-prefix-map=/home/philipp/lede/build_dir/target-x86_64_musl/bind-9.18.10=bind-9.18.10 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro ' 'LDFLAGS=-L/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-11.3.0_musl/usr/lib -L/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-11.3.0_musl/lib -znow -zrelro -Wl,--gc-sections,--as-needed ' 'CPPFLAGS=-I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-11.3.0_musl/usr/include -I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-11.3.0_musl/include/fortify -I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-11.3.0_musl/include ' 'PKG_CONFIG=/home/philipp/lede/staging_dir/host/bin/pkg-config' 'PKG_CONFIG_PATH=/home/philipp/lede/staging_dir/target-x86_64_musl/usr/lib/pkgconfig:/home/philipp/lede/staging_dir/target-x86_64_musl/usr/share/pkgconfig' 'PKG_CONFIG_LIBDIR=/home/philipp/lede/staging_dir/target-x86_64_musl/usr/lib/pkgconfig:/home/philipp/lede/staging_dir/target-x86_64_musl/usr/share/pkgconfig'
compiled by GCC 11.3.0
compiled with OpenSSL version: OpenSSL 1.1.1s 1 Nov 2022
linked to OpenSSL version: OpenSSL 1.1.1s 1 Nov 2022
compiled with libuv version: 1.44.1
linked to libuv version: 1.44.1
compiled with libnghttp2 version: 1.44.0
linked to libnghttp2 version: 1.44.0
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
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): no
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Create a `named.conf` with `listen-on-v6 { none; }` in the `options { ... };` section, and load it.
Then run:
```
named-checkconf -px \
| sed -r -ne '1N; N; /^\tlisten-on-v6 +\{\n\t\t"none";\n\t\};$/{ p; q; }; D'
```
and the output will be:
```
listen-on-v6 {
"none";
};
```
Note the extraneous space on the first line.
### What is the current *bug* behavior?
Two spaces before the `{`.
### What is the expected *correct* behavior?
A single space as for all other commands.
### Relevant configuration files
```
// This is the primary configuration file for the BIND DNS server named.
options {
directory "/tmp";
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
recursion yes;
// note that all subnets are visible to each other;
// if we wished to isolate them we could use "views".
allow-query {
localhost;
192.168.6.0/24;
192.168.7.0/24;
192.168.8.0/24;
};
auth-nxdomain no; # conform to RFC1035
// added by philipp
allow-transfer { none; };
// dnssec-validation no;
// dnssec-enabled yes;
dnssec-validation auto;
listen-on-v6 { none; };
};
include "/etc/bind/named-rndc.conf";
include "/tmp/bind/named.conf.local";
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
# added by philipp
zone "tiktok.com" {
type master;
file "/etc/bind/db.tiktok.com";
};
```
### Relevant logs and/or screenshots
```
listen-on-v6 {
"none";
};
```
### Possible fixes
UnknownNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3750"legacy" system test failure on "checking recursive lookup to drop edns serve...2023-01-03T10:16:42ZArаm Sаrgsyаn"legacy" system test failure on "checking recursive lookup to drop edns server fails"See https://gitlab.isc.org/isc-projects/bind9/-/jobs/3015722.
The `dig.out.test8` file's contents:
```
;; communications error to 10.53.0.1#11314: timed out
;; communications error to 10.53.0.1#11314: timed out
;; communications error ...See https://gitlab.isc.org/isc-projects/bind9/-/jobs/3015722.
The `dig.out.test8` file's contents:
```
;; communications error to 10.53.0.1#11314: timed out
;; communications error to 10.53.0.1#11314: timed out
;; communications error to 10.53.0.1#11314: timed out
; <<>> DiG 9.19.9-dev <<>> -p 11314 +tries +time +tcp +tries +time @10.53.0.1 dropedns. TXT
; (1 server found)
;; global options: +cmd
;; no servers could be reached
```
The code that checks for the expected failure:
```sh
resolution_fails() {
_servfail=0
_timeout=0
$DIG $DIGOPTS +tcp +tries=3 +time=5 @10.53.0.1 ${1} TXT > dig.out.test$n
grep "status: SERVFAIL" dig.out.test$n > /dev/null && _servfail=1
grep "connection timed out" dig.out.test$n > /dev/null && _timeout=1
if [ $_servfail -eq 1 ] || [ $_timeout -eq 1 ]; then
return 0
else
return 1
fi
}
```
So the test checks for "connection timed out", while current `dig` versions from ~"v9.18" and ~"v9.19" print only "timed out", without the word "connection".January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3748Follow-up from "Draft: Resolve "Forward queries via DoT""2023-01-03T10:20:56ZMark AndrewsFollow-up from "Draft: Resolve "Forward queries via DoT""The following discussion from !7199 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7199#note_338748):
> This needs to end up as a seperate issue. `isc_tlsctx_ca...The following discussion from !7199 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7199#note_338748):
> This needs to end up as a seperate issue. `isc_tlsctx_cache_new` really should be `isc_tlsctx_cache_create` and should take a pointer to a NULL pointer to prevent accidentally overwriting a non NULL `tlsctx_cache` and thereby leaking memory.January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3681Benign build issues in doc/man on OpenBSD2023-03-20T09:19:18ZMichal NowakBenign build issues in doc/man on OpenBSDOpenBSD often (but not always) [produces](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2907771) the following benign errors on `v9_16`:
```
making all in /builds/isc-projects/bind9/doc/man
: -b man -d "./_build"/.doctrees/arpaname.1i...OpenBSD often (but not always) [produces](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2907771) the following benign errors on `v9_16`:
```
making all in /builds/isc-projects/bind9/doc/man
: -b man -d "./_build"/.doctrees/arpaname.1in -W -a -v -c "/builds/isc-projects/bind9/doc/man" -D version="@""BIND9_VERSION""@" -D today="@""RELEASE_DATE""@" -D release="@""BIND9_VERSIONSTRING""@" . "./_build"/man
for man in arpaname.1in ddns-confgen.8in delv.1in dig.1in dnssec-cds.8in dnssec-checkds.8in dnssec-coverage.8in dnssec-dsfromkey.8in dnssec-importkey.8in dnssec-keyfromlabel.8in dnssec-keygen.8in dnssec-keymgr.8in dnssec-revoke.8in dnssec-settime.8in dnssec-signzone.8in dnssec-verify.8in dnstap-read.1in filter-aaaa.8in host.1in mdig.1in named-checkconf.8in named-checkzone.8in named-compilezone.8in named-journalprint.8in named-nzd2nzf.8in named-rrchecker.1in named.conf.5in named.8in nsec3hash.8in nslookup.1in nsupdate.1in rndc-confgen.8in rndc.conf.5in rndc.8in tsig-keygen.8in pkcs11-destroy.8in pkcs11-keygen.8in pkcs11-list.8in pkcs11-tokens.8in; do [ -e "./_build"/man/"$(basename $man in)" ] && cp -f "./_build"/man/"$(basename $man in)" "$man"; done
*** Error 1 in target 'arpaname.1in' (ignored)
```
The CI job otherwise passes.
The `:` on second line of the output is the (missing) `$(SPHINXBUILD)` from the `$(MANPAGES_IN)` target, which is OK as `sphinx-build` command is not in the image.
I tried to reproduce it locally with the CI image, but failed. Perhaps a race issue with another target?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3614Resolver prefetch issue with qtype ANY2022-11-07T10:49:44ZArаm SаrgsyаnResolver prefetch issue with qtype ANYIn `lib/ns/query.c:query_respond_any()`, when there are several datasets in the database node, only one of them has a chance to trigger a prefetch, because when one does, the `FETCH_RECTYPE_PREFETCH(client) != NULL` check (see below) doe...In `lib/ns/query.c:query_respond_any()`, when there are several datasets in the database node, only one of them has a chance to trigger a prefetch, because when one does, the `FETCH_RECTYPE_PREFETCH(client) != NULL` check (see below) does not pass for the rest of the datasets, even if they are eligible for a prefetch, as the client's fetch reserved for the prefetch operation is already in progress:
```c
static void
query_prefetch(ns_client_t *client, dns_name_t *qname,
dns_rdataset_t *rdataset) {
CTRACE(ISC_LOG_DEBUG(3), "query_prefetch");
if (FETCH_RECTYPE_PREFETCH(client) != NULL ||
client->view->prefetch_trigger == 0U ||
rdataset->ttl > client->view->prefetch_trigger ||
(rdataset->attributes & DNS_RDATASETATTR_PREFETCH) == 0)
{
return;
}
fetch_and_forget(client, qname, rdataset->type, RECTYPE_PREFETCH);
dns_rdataset_clearprefetch(rdataset);
ns_stats_increment(client->manager->sctx->nsstats,
ns_statscounter_prefetch);
}
```
I will use the `resolver` system test's `check prefetch qtype * (${n})` check to demonstrate it. Please note that if you want to reproduce it, you'll need to use the branch in !6937 which fixes another prefetch issue (unless it is already merged).
Run the test:
```
$ ./run.sh -n resolver
...
...
I:resolver:check prefetch qtype * (32)
...
PASS: resolver
```
Check the first answer, all records start with TTL value of 10:
```
$ cat resolver/dig.out.1.32
...
;; QUESTION SECTION:
;fetchall.tld. IN ANY
;; ANSWER SECTION:
fetchall.tld. 10 IN AAAA ::1
fetchall.tld. 10 IN A 1.2.3.4
fetchall.tld. 10 IN TXT "A" "short" "ttl"
...
```
Check the second answer (for a request after 7 seconds), this should had triggered a prefetch for all 3 records, because TTL value 3 is smaller than the configured trigger value 4:
```
$ cat resolver/dig.out.2.32
...
;; QUESTION SECTION:
;fetchall.tld. IN ANY
;; ANSWER SECTION:
fetchall.tld. 3 IN AAAA ::1
fetchall.tld. 3 IN A 1.2.3.4
fetchall.tld. 3 IN TXT "A" "short" "ttl"
...
```
Check the third answer (for a request after 1 second):
```
$ cat resolver/dig.out.3.32
...
;; QUESTION SECTION:
;fetchall.tld. IN ANY
;; ANSWER SECTION:
fetchall.tld. 9 IN AAAA ::1
fetchall.tld. 2 IN A 1.2.3.4
fetchall.tld. 2 IN TXT "A" "short" "ttl"
...
```
As you can see, only the first record was prefetched.
Here are the logs which confirm that, where you can see that `query_prefetch()` was called three times, but a prefetch was initiated only for the first call: [fetchall.tld-any.log.gz](/uploads/30a6656ecf98a5ca6c9b342f200969b7/fetchall.tld-any.log.gz).
I think, as suggest by @fanf in MM, ANY should not trigger prefetching at all. Or, otherwise, all records which are eligible for prefetch should be prefetched.Not planned