BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-10-20T16:51:28Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3602udp_test fails with atomic_load(&sreads) >= expected_creads2022-10-20T16:51:28ZOndřej Surýudp_test fails with atomic_load(&sreads) >= expected_creadsReproduced under `rr record -h`:
```
[==========] Running 18 test(s).
[ RUN ] mock_listenudp_uv_udp_open
[ OK ] mock_listenudp_uv_udp_open
[ RUN ] mock_listenudp_uv_udp_bind
[ OK ] mock_listenudp_uv_udp_bind
[ RUN ...Reproduced under `rr record -h`:
```
[==========] Running 18 test(s).
[ RUN ] mock_listenudp_uv_udp_open
[ OK ] mock_listenudp_uv_udp_open
[ RUN ] mock_listenudp_uv_udp_bind
[ OK ] mock_listenudp_uv_udp_bind
[ RUN ] mock_listenudp_uv_udp_recv_start
[ OK ] mock_listenudp_uv_udp_recv_start
[ RUN ] mock_udpconnect_uv_udp_open
[ OK ] mock_udpconnect_uv_udp_open
[ RUN ] mock_udpconnect_uv_udp_bind
[ OK ] mock_udpconnect_uv_udp_bind
[ RUN ] mock_udpconnect_uv_udp_connect
[ OK ] mock_udpconnect_uv_udp_connect
[ RUN ] mock_udpconnect_uv_recv_buffer_size
[ OK ] mock_udpconnect_uv_recv_buffer_size
[ RUN ] mock_udpconnect_uv_send_buffer_size
[ OK ] mock_udpconnect_uv_send_buffer_size
[ RUN ] udp_noop
[ OK ] udp_noop
[ RUN ] udp_noresponse
[ OK ] udp_noresponse
[ RUN ] udp_shutdown_connect
[ OK ] udp_shutdown_connect
[ RUN ] udp_shutdown_read
[ OK ] udp_shutdown_read
[ RUN ] udp_cancel_read
[ OK ] udp_cancel_read
[ RUN ] udp_timeout_recovery
[ OK ] udp_timeout_recovery
[ RUN ] udp_double_read
[ OK ] udp_double_read
[ RUN ] udp_recv_one
[ OK ] udp_recv_one
[ RUN ] udp_recv_two
[ OK ] udp_recv_two
[ RUN ] udp_recv_send
atomic_load(&sreads) >= expected_creads
[ LINE ] --- udp_test.c:947: error: Failure!Aborted
```Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3609dual-stack-servers are not being used2023-11-02T17:05:05ZMark Andrewsdual-stack-servers are not being usedThe current code for deciding when to add a dual stack server doesn't always cause the server to be added as it is looking for a NXRRSET indication for the server's address (A for IPv4 and AAAA for IPv6) as well as no dispatch for that t...The current code for deciding when to add a dual stack server doesn't always cause the server to be added as it is looking for a NXRRSET indication for the server's address (A for IPv4 and AAAA for IPv6) as well as no dispatch for that transport. When the server is within the zone we can't get the NXRRSET indication. Additionally no dispatch is contingent on -4 or -6 being used on the command line.
- We need a solution to the bootstrap problem or to relax the requirement.
- We need a better solution for how to determine we are effectively running single stack other the -4 and -6.
- We need to add tests for dual-stack-servers as there are currently none.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 plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3616empty zones slow down loading lots of zones2023-11-02T17:05:05ZPetr Špačekpspacek@isc.orgempty zones slow down loading lots of zones### Summary
Loading 1 M zones from textual named.conf & minimal zone file is much slower if `empty-zones-enable yes` (default) is in effect.
### BIND version used
BIND 9.19.7-dev (Development Release) 64287e4
### Steps to reproduce
1...### Summary
Loading 1 M zones from textual named.conf & minimal zone file is much slower if `empty-zones-enable yes` (default) is in effect.
### BIND version used
BIND 9.19.7-dev (Development Release) 64287e4
### Steps to reproduce
1. Generate config
```
for I in $(seq 1 1000000); do echo "zone z$I.example. { type primary; file \"db\"; };" >> named.conf; done
echo 'options { notify no; };' >> named.conf
```
2. Use minimal zone file:
[db](/uploads/dc86b8dc10f481b4d9b2f9718a7efd2a/db)
3. Run BIND:
```
named -g -c named.conf &> log
```
4. Observe CPU utilization going through the roof. Startup time is over 60 seconds on my laptop.
### What is the expected *correct* behavior?
It could be faster :-)
### Relevant logs and/or screenshots
Notice the timestamps - it takes quite long to process a single zone:
```
20-Oct-2022 15:55:37.781 automatic empty zone: 10.IN-ADDR.ARPA
20-Oct-2022 15:55:37.971 automatic empty zone: 16.172.IN-ADDR.ARPA
20-Oct-2022 15:55:38.148 automatic empty zone: 17.172.IN-ADDR.ARPA
20-Oct-2022 15:55:38.325 automatic empty zone: 18.172.IN-ADDR.ARPA
20-Oct-2022 15:55:38.505 automatic empty zone: 19.172.IN-ADDR.ARPA
```
Flamegraph, all threads combined:
![nothreads.svg](/uploads/30254da36ec0ee0be71ca1d86d0e2cde/nothreads.svg)
With
```
options { notify no; empty-zones-enable no; };
```
the load time decreases down to ~ 42 s, i.e. almost 1/3 decrease.
### Possible fixes
From a quick glance, it seems that `create_empty_zone()` is called in a cycle and it effectively walks the cfg-representation of zone list over and over, including conversion from text to wire format, and then compares zone names. This is done to detect forward zones with particular configuration.
Unless I'm missing something, we should be able to move empty zones creating to the very end of config processing and use forward table for way more efficient lookups which should lower the processing time for empty zones to almost zero.Not plannedTony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3618dynamic TTL shortening in auth after RR change2022-10-26T09:07:48ZPetr Špačekpspacek@isc.orgdynamic TTL shortening in auth after RR change### Description
TL;DR version: Withdrawing DS is a nightmare because TLDs have too long TTLs. COM with 1 day is a total nightmare and risk-averse bussinesses like google.com are not going to risk 1 day disruption of service => no prospe...### Description
TL;DR version: Withdrawing DS is a nightmare because TLDs have too long TTLs. COM with 1 day is a total nightmare and risk-averse bussinesses like google.com are not going to risk 1 day disruption of service => no prospect of deploying DNSSEC.
Long version:
https://indico.dns-oarc.net/event/44/contributions/962/
### Request
I'm considering an _experiment_, not a production-ready feature. Auth DNS is not a good place for what I'm going to propose, but I still think it is a nice experiment:
Add magic which shortens TTLs sent out in answers after RR modification. Say, in the first hour after modification shorten TTL of modified DS RR to 60 seconds. After that use the original TTL. (Of course we can invent any other schema, this is just a simple example.)
Obviously this requires knowing when RR was modified - and this is a nightmare by itself. For an experiment I think it would be good enough to look at RRSIG inception time to detect the initial window. Obviously this will have false positives after resigning, but for an experiment I think we don't need to care.
An experiment would allow us to detect if something breaks when TTL on RR and it's RRSIG do not match when sent as an answer from auth. (It should work, but you know how it is ...)
### Links / references
- https://indico.dns-oarc.net/event/44/contributions/962/
- https://chat.dns-oarc.net/community/pl/u36txi1cw3ykzx7iaos4rqo95c
- https://www.ripe.net/ripe/mail/archives/dns-wg/2021-December/003935.htmlhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3623A combination of an RPZ with NSIP triggers & unusually (but not entirely) bro...2022-10-27T11:36:42ZGraham ClinchA combination of an RPZ with NSIP triggers & unusually (but not entirely) broken delegation gives SERVFAIL & "rpz NSIP rewrite X via Y NS address rewrite rrset failed: failure"<!--
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
When a configured response policy zone contains rpz-nsip triggers **and** NS record resolution does not complete successfully (but in an apparently unusual way), SERVFAIL is returned to queries that would otherwise succeed.
### BIND version used
```
BIND 9.18.8 (Stable Release) <id:35f5d35>
running on Darwin arm64 21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:19:52 PDT 2022; root:xnu-8020.140.49~2/RELEASE_ARM64_T6000
built by make with '--prefix=/opt/homebrew/Cellar/bind/9.18.8' '--sysconfdir=/opt/homebrew/etc/bind' '--localstatedir=/opt/homebrew/var' '--with-json-c' '--with-libidn2=/opt/homebrew/opt/libidn2' '--with-openssl=/opt/homebrew/opt/openssl@3' '--without-lmdb' 'CC=clang' 'PKG_CONFIG_PATH=/opt/homebrew/opt/json-c/lib/pkgconfig:/opt/homebrew/opt/libidn2/lib/pkgconfig:/opt/homebrew/opt/libnghttp2/lib/pkgconfig:/opt/homebrew/opt/libuv/lib/pkgconfig:/opt/homebrew/opt/openssl@3/lib/pkgconfig' 'PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/opt/homebrew/Library/Homebrew/os/mac/pkgconfig/12'
compiled by CLANG Apple LLVM 14.0.0 (clang-1400.0.29.202)
compiled with OpenSSL version: OpenSSL 3.0.5 5 Jul 2022
linked to OpenSSL version: OpenSSL 3.0.5 5 Jul 2022
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.50.0
linked to libnghttp2 version: 1.50.0
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
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: /opt/homebrew/etc/bind/named.conf
rndc configuration: /opt/homebrew/etc/bind/rndc.conf
DNSSEC root key: /opt/homebrew/etc/bind/bind.keys
nsupdate session key: /opt/homebrew/var/run/named/session.key
named PID file: /opt/homebrew/var/run/named/named.pid
named lock file: /opt/homebrew/var/run/named/named.lock
```
### Steps to reproduce
Configure a minimal BIND 9 recursive resolver with a response policy zone that includes an rpz-nsip match, and then attempt to resolve www.britishairways.com (which appears to have an unusually broken partially lame delegation).
### What is the current *bug* behavior?
DNS resolution of "www.britishways.com" fails with SERVFAIL:
```
$ delv www.britishairways.com @::1
;; resolution failed: SERVFAIL
```
named (at -d 1) logs:
```
25-Oct-2022 22:53:35.007 client @0x1439ad560 ::1#53833 (www.britishairways.com): rpz NSIP rewrite www.britishairways.com via dnssec1-win.server.ntli.net NS address rewrite rrset failed: failure
25-Oct-2022 22:53:35.007 client @0x1439ad560 ::1#53833 (www.britishairways.com): query failed (SERVFAIL) for www.britishairways.com/IN/A at query.c:7232
```
### What is the expected *correct* behavior?
DNS resolution of "www.britishairways.com" should succeed:
```
$ delv www.britishairways.com @::1
; unsigned answer
www.britishairways.com. 60 IN CNAME www.ba.com.edgekey.net.
www.ba.com.edgekey.net. 21600 IN CNAME e8308.b.akamaiedge.net.
e8308.b.akamaiedge.net. 20 IN A 104.117.169.173
```
### Relevant configuration files
named.conf:
```
options {
response-policy {
zone "test.example.net" policy given;
};
};
zone "test.example.net" {
type primary;
file "test.example.net";
};
```
test.example.net zone file:
```
@ SOA ns1 hostmaster. (
2003080800 ; serial number
12h ; refresh
15m ; update retry
3w ; expiry
2h ; minimum
)
@ NS ns1
ns1 A 127.0.0.1
foo.com CNAME .
32.99.99.168.192.rpz-nsip CNAME .
```
Note that simply commenting out the final line in the zone file causes the problem to go away.
### Relevant logs and/or screenshots
named -d 2 -g output:
```
[...]
25-Oct-2022 22:57:14.370 fetch: www.britishairways.com/A
25-Oct-2022 22:57:14.371 fetch: _.com/A
25-Oct-2022 22:57:14.393 fetch: _.britishairways.com/A
25-Oct-2022 22:57:14.419 fetch: ns1.britishairways.com/AAAA
25-Oct-2022 22:57:14.419 fetch: ns2.britishairways.com/AAAA
25-Oct-2022 22:57:14.419 fetch: dnssec1-win.server.ntli.net/A
25-Oct-2022 22:57:14.419 fetch: dnssec1-win.server.ntli.net/AAAA
25-Oct-2022 22:57:14.419 fetch: dnssec2-win.server.ntli.net/A
25-Oct-2022 22:57:14.419 fetch: dnssec2-win.server.ntli.net/AAAA
25-Oct-2022 22:57:14.439 delete_node(): 0x600002c8edf0 www.britishairways.com (bucket 15)
25-Oct-2022 22:57:14.440 fetch: britishairways.com/DS
25-Oct-2022 22:57:14.456 fetch: com/DNSKEY
25-Oct-2022 22:57:14.477 fetch: dnssec1-win.server.ntli.net/A
25-Oct-2022 22:57:14.494 lame server resolving 'dnssec2-win.server.ntli.net' (in 'server.ntli.net'?): 194.168.4.237#53
25-Oct-2022 22:57:14.495 lame server resolving 'dnssec1-win.server.ntli.net' (in 'server.ntli.net'?): 194.168.4.237#53
25-Oct-2022 22:57:14.495 lame server resolving 'dnssec1-win.server.ntli.net' (in 'server.ntli.net'?): 194.168.4.237#53
25-Oct-2022 22:57:14.497 lame server resolving 'dnssec2-win.server.ntli.net' (in 'server.ntli.net'?): 194.168.4.237#53
25-Oct-2022 22:57:14.497 lame server resolving 'dnssec1-win.server.ntli.net' (in 'server.ntli.net'?): 194.168.4.237#53
25-Oct-2022 22:57:14.522 lame server resolving 'dnssec2-win.server.ntli.net' (in 'server.ntli.net'?): 62.253.162.237#53
25-Oct-2022 22:57:14.522 fetch: dns1.ntli.net/AAAA
25-Oct-2022 22:57:14.522 fetch: dns2.ntli.net/AAAA
25-Oct-2022 22:57:14.522 lame server resolving 'dnssec1-win.server.ntli.net' (in 'server.ntli.net'?): 62.253.162.237#53
25-Oct-2022 22:57:14.522 lame server resolving 'dnssec1-win.server.ntli.net' (in 'server.ntli.net'?): 62.253.162.237#53
25-Oct-2022 22:57:14.522 lame server resolving 'dnssec2-win.server.ntli.net' (in 'server.ntli.net'?): 62.253.162.237#53
25-Oct-2022 22:57:14.523 lame server resolving 'dnssec1-win.server.ntli.net' (in 'server.ntli.net'?): 62.253.162.237#53
25-Oct-2022 22:57:14.523 client @0x11a870560 ::1#52973 (www.britishairways.com): rpz NSIP rewrite www.britishairways.com via dnssec1-win.server.ntli.net NS address rewrite rrset failed: failure
25-Oct-2022 22:57:14.523 client @0x11a870560 ::1#52973 (www.britishairways.com): query failed (SERVFAIL) for www.britishairways.com/IN/A at query.c:7232
25-Oct-2022 22:57:14.523 fetch completed at resolver.c:4140 for dnssec1-win.server.ntli.net/A in 0.045906: failure/success [domain:server.ntli.net,referral:0,restart:2,qrysent:2,timeout:0,lame:2,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
```
### Possible fixes
Unclear, but appears to be a fault in the rpz-nsip processing when an "unusually unknown" NS IP is processed.https://gitlab.isc.org/isc-projects/bind9/-/issues/3629Slow retries after timeouts2022-11-16T16:07:31Zgrzchr15Slow retries after timeoutsMeasurements from Neustar/UltraDNS for some DNS servers including BIND9,They think there is weird behavior:
https://ripe85.ripe.net/wp-content/uploads/presentations/96-dknight-fewnsmanyips-ripe85-dnswg.pdf
Page 8
Video: https://ripe85....Measurements from Neustar/UltraDNS for some DNS servers including BIND9,They think there is weird behavior:
https://ripe85.ripe.net/wp-content/uploads/presentations/96-dknight-fewnsmanyips-ripe85-dnswg.pdf
Page 8
Video: https://ripe85.ripe.net/archive/video/dave-knight_fewer-name-servers-more-addresses_main-20221027-112204.mp4 time 7:17 onwards
Measurements from Neustar/UltraDNS for some DNS servers including BIND9
- Bind Strongly prefers IPv6 - they think there is weird behavior.
- If one address is broken, penalize all higher numbered addresses until piling onto the last one?
- Slow to get an answer when retryingŠtěpán BalážikŠtěpán Balážikhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3635Implement support for DNS over QUIC2023-02-15T19:00:14ZJeremy SakladImplement support for DNS over QUIC### Description
DNS-over-QUIC, specified in [RFC 9250][RFC 9250], has considerable advantages over the already-implemented options.
* With the debatable exception of DoH and HTTP/3, it is the only standardized encrypted DNS protocol to...### Description
DNS-over-QUIC, specified in [RFC 9250][RFC 9250], has considerable advantages over the already-implemented options.
* With the debatable exception of DoH and HTTP/3, it is the only standardized encrypted DNS protocol to operate over UDP.
* It avoids issues such as head-of-line blocking and potential for amplification attacks.
* It avoids the overhead of DNS-over-HTTPS.
### Request
DNS-over-QUIC should be offered wherever DNS-over-HTTPS or DNS-over-TLS is, at minimum. Its use should be encouraged over the others where applicable.
[RFC 9250][RFC 9250] emphasizes the following scopes of usage:
> * the "stub to recursive resolver" scenario (also called the "stub to recursive" scenario in this document)
> * the "recursive resolver to authoritative nameserver" scenario (also called the "recursive to authoritative" scenario in this document), and
> * the "nameserver to nameserver" scenario (mainly used for zone transfers (XFR) [RFC1995][RFC 1995] [RFC5936][RFC 5936]).
I believe that covers every function of BIND.
---
While not specific to DNS-over-QUIC, the implementation should be designed with future support for non-standard ports and SVBC records in mind. 53/udp is explicitly banned for use with this protocol, but it should eventually be possible to use any other non-standard port rather than 853/udp.
[RFC 1995]: https://www.rfc-editor.org/info/rfc1995
[RFC 5936]: https://www.rfc-editor.org/info/rfc5936
[RFC 9250]: https://www.rfc-editor.org/info/rfc9250Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3642tcpdns_recv_send failure in mem.c:7722023-01-10T14:16:34ZMichal Nowaktcpdns_recv_send failure in mem.c:772Job [#2874890](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2874890) failed for 395a5576b40eb7f4d34ee0606200947b4698173e with:
```
[ RUN ] tcpdns_recv_send
mem.c:772: REQUIRE(((ctx) != ((void *)0) && ((const isc__magic_t *)(ctx)...Job [#2874890](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2874890) failed for 395a5576b40eb7f4d34ee0606200947b4698173e with:
```
[ RUN ] tcpdns_recv_send
mem.c:772: REQUIRE(((ctx) != ((void *)0) && ((const isc__magic_t *)(ctx))->magic == ((('M') << 24 | ('e') << 16 | ('m') << 8 | ('C'))))) failed, back trace
```
<details><summary>tcpdns_recv_send failure</summary>
```
[==========] Running 6 test(s).
[ RUN ] tcpdns_noop
[ OK ] tcpdns_noop
[ RUN ] tcpdns_noresponse
[ OK ] tcpdns_noresponse
[ RUN ] tcpdns_timeout_recovery
[ OK ] tcpdns_timeout_recovery
[ RUN ] tcpdns_recv_one
[ OK ] tcpdns_recv_one
[ RUN ] tcpdns_recv_two
[ OK ] tcpdns_recv_two
[ RUN ] tcpdns_recv_send
mem.c:772: REQUIRE(((ctx) != ((void *)0) && ((const isc__magic_t *)(ctx))->magic == ((('M') << 24 | ('e') << 16 | ('m') << 8 | ('C'))))) failed, back trace
mem.c:772: REQUIRE(((ctx) != ((void *)0) && ((const isc__magic_t *)(ctx))->magic == ((('M') << 24 | ('e') << 16 | ('m') << 8 | ('C'))))) failed, back trace
mem.c:772: REQUIRE(((ctx) != ((void *)0) && ((const isc__magic_t *)(ctx))->magic == ((('M') << 24 | ('e') << 16 | ('m') << 8 | ('C'))))) failed, back trace
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(+0x3119d)[0x7efd91df119d]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(+0x3119d)[0x7efd91df119d]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(+0x3119d)[0x7efd91df119d]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(isc_assertion_failed+0xa)[0x7efd91df1118]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(isc_assertion_failed+0xa)[0x7efd91df1118]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(isc_assertion_failed+0xa)[0x7efd91df1118]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(isc__mem_get+0x9f)[0x7efd91e04800]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(isc__mem_get+0x9f)[0x7efd91e04800]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(isc__mem_get+0x9f)[0x7efd91e04800]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(isc_nm_tcpdnsconnect+0x8b)[0x7efd91de92af]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(isc_nm_tcpdnsconnect+0x8b)[0x7efd91de92af]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(isc_nm_tcpdnsconnect+0x8b)[0x7efd91de92af]
/builds/isc-projects/bind9/tests/isc/.libs/lt-tcpdns_test[0x403b0d]
/builds/isc-projects/bind9/tests/isc/.libs/lt-tcpdns_test(stream_recv_send_connect+0x5a)[0x4040ec]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(+0x3b536)[0x7efd91dfb536]
/builds/isc-projects/bind9/tests/isc/.libs/lt-tcpdns_test[0x403b0d]
/builds/isc-projects/bind9/tests/isc/.libs/lt-tcpdns_test[0x403b0d]
/lib64/libuv.so.1(uv__run_idle+0x99)[0x7efd91ba7a49]
/builds/isc-projects/bind9/tests/isc/.libs/lt-tcpdns_test(stream_recv_send_connect+0x5a)[0x4040ec]
/builds/isc-projects/bind9/tests/isc/.libs/lt-tcpdns_test(stream_recv_send_connect+0x5a)[0x4040ec]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(+0x3b536)[0x7efd91dfb536]
/lib64/libuv.so.1(uv_run+0x298)[0x7efd91ba0bf8]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(+0x3b536)[0x7efd91dfb536]
/lib64/libuv.so.1(uv__run_idle+0x99)[0x7efd91ba7a49]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(+0x41b44)[0x7efd91e01b44]
/lib64/libuv.so.1(uv__run_idle+0x99)[0x7efd91ba7a49]
/lib64/libuv.so.1(uv_run+0x298)[0x7efd91ba0bf8]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(isc__trampoline_run+0x16)[0x7efd91e1b87f]
/lib64/libuv.so.1(uv_run+0x298)[0x7efd91ba0bf8]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(+0x41b44)[0x7efd91e01b44]
/lib64/libpthread.so.0(+0x81df)[0x7efd90de91df]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(+0x41b44)[0x7efd91e01b44]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(isc__trampoline_run+0x16)[0x7efd91e1b87f]
/lib64/libc.so.6(clone+0x43)[0x7efd90a55dd3]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.7-dev.so(isc__trampoline_run+0x16)[0x7efd91e1b87f]
/lib64/libpthread.so.0(+0x81df)[0x7efd90de91df]
../../tests/unit-test-driver.sh: line 36: 7887 Aborted (core dumped) "${TEST_PROGRAM}"
I:tcpdns_test:Core dump found: ./core.7887
D:tcpdns_test:backtrace from ./core.7887 start
[New LWP 7975]
[New LWP 7970]
[New LWP 7973]
[New LWP 7887]
[New LWP 7971]
[New LWP 7976]
[New LWP 7972]
[New LWP 7977]
[New LWP 7974]
[New LWP 7968]
[New LWP 7967]
[New LWP 7969]
[New LWP 7978]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/builds/isc-projects/bind9/tests/isc/.libs/lt-tcpdns_test'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007efd90a6aa9f in raise () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7efd89efb700 (LWP 7975))]
Thread 13 (Thread 0x7efd83fff700 (LWP 7978)):
#0 0x00007efd90df282d in __lll_lock_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007efd90debba4 in pthread_mutex_lock () from /lib64/libpthread.so.0
No symbol table info available.
#2 0x00007efd90b84ff3 in dl_iterate_phdr () from /lib64/libc.so.6
No symbol table info available.
#3 0x00007efd8f0a1bf5 in _Unwind_Find_FDE () from /lib64/libgcc_s.so.1
No symbol table info available.
#4 0x00007efd8f09e193 in uw_frame_state_for () from /lib64/libgcc_s.so.1
No symbol table info available.
#5 0x00007efd8f0a01d8 in _Unwind_Backtrace () from /lib64/libgcc_s.so.1
No symbol table info available.
#6 0x00007efd90b57c46 in backtrace () from /lib64/libc.so.6
No symbol table info available.
#7 0x00007efd91df18f2 in isc_backtrace (addrs=addrs@entry=0x7efd83ffce20, maxaddrs=maxaddrs@entry=128) at backtrace.c:44
n = <optimized out>
#8 0x00007efd91df119d in default_callback (file=0x7efd91e2ff0b "mem.c", line=772, type=isc_assertiontype_require, cond=0x7efd91e304a0 "((ctx) != ((void *)0) && ((const isc__magic_t *)(ctx))->magic == ((('M') << 24 | ('e') << 16 | ('m') << 8 | ('C'))))") at assertions.c:100
tracebuf = {0x7efd91df18f2 <isc_backtrace+24>, 0x7efd91df119d <default_callback+49>, 0x7efd91df1118 <isc_assertion_failed+10>, 0x7efd80e008c0, 0x14, 0x7efd80e09218, 0x0, 0x7efd83ffe058, 0x7efd83ffcee8, 0xe6c048c994a92300, 0x7efd57200000, 0x400, 0x200, 0x7efd83ffde68, 0x7efd57200000, 0x7efd83ffd110, 0x7efd83ffdc78, 0x7efd9037de0b <je_arena_ralloc+459>, 0x0, 0x7efd57201000, 0x7efd83ffd118, 0x0, 0x7efd80e008c0, 0x0, 0x0, 0x201, 0x0, 0x0, 0x0, 0x3c3000, 0x7efd903b134a <extents_remove_locked.isra+170>, 0xe6c048c994a92300, 0x23, 0x7efd8ec03268, 0x7efd8ec03268, 0x7efd8ec0f200, 0x7efd8e660cc8, 0x7efd907fdec0, 0xd50dcc13, 0x7efd83ffdc78, 0x7efd8ec0f100, 0x7efd903aca72 <extent_lock_from_addr+434>, 0x0, 0x100000000000000, 0x7efd83ffdc78, 0x0, 0x7efd83ffdc78, 0xd50dcc13, 0x7efd8ec03268, 0x7efd8ec0f200, 0x7efd8ec0f580, 0x7efd903b1877 <extent_try_coalesce_impl+839>, 0x7efd83ffdca8, 0x7efd8ec00980, 0x7efd83ffd250, 0x7efd00000001, 0x0, 0x7efd83ffd108, 0x0, 0x183ffd250, 0x7efd83ffdca8, 0x1, 0x8, 0x7efd83ffd108, 0x0, 0x54, 0x7efd83ffd0f0, 0x7efd91df6247 <isc_hash64+87>, 0x7efd83ffd05f, 0x7efd92549c70 <isc_modules+80>, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7efd83ffd198, 0x0, 0x183ffdc78, 0x0, 0x7efd83ffd1b8, 0x0, 0x183ffd198, 0x0, 0x1, 0x8, 0x7efd83ffd1b8, 0x0, 0x2e2, 0x7efd83ffd1a0, 0x7efd91df6247 <isc_hash64+87>, 0x7efd83ffd1c0, 0x7efd91e03bc9 <delete_trace_entry+303>, 0x7efd91e2b585, 0x7efd5720f400, 0x0, 0x7efd57200000, 0x400, 0x0, 0x0, 0x7efd83ffd258, 0x0, 0x7efd83ffd268, 0x0, 0x7efd83ffd278, 0x0, 0x18ea13010, 0x168, 0x1, 0x8, 0x7efd83ffd278, 0x0, 0x201, 0x7efd83ffd260, 0x7efd91df6247 <isc_hash64+87>, 0x7efd91e27a1e, 0x7efd57204000, 0x7efd83ffd1f0, 0x7efd91e05a3c <isc__mem_putanddetach+114>, 0x7efd5720f400, 0x0, 0x0, 0x0, 0x7efd83ffd2a0, 0x7efd91df15d7 <isc_astack_destroy+125>, 0x7efd83ffdc78, 0x7efd83ffd328, 0x0, 0x10027ffff}
nframes = <optimized out>
#9 0x00007efd91df1118 in isc_assertion_failed (file=file@entry=0x7efd91e2ff0b "mem.c", line=line@entry=772, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7efd91e304a0 "((ctx) != ((void *)0) && ((const isc__magic_t *)(ctx))->magic == ((('M') << 24 | ('e') << 16 | ('m') << 8 | ('C'))))") at assertions.c:49
No locals.
#10 0x00007efd91e04800 in isc__mem_get (ctx=<optimized out>, size=size@entry=2208, flags=flags@entry=0, file=file@entry=0x7efd91e2a6f2 "netmgr/tcpdns.c", line=line@entry=269) at mem.c:781
ptr = 0x0
#11 0x00007efd91de92af in isc_nm_tcpdnsconnect (mgr=<optimized out>, local=0x6084e0 <tcp_connect_addr>, peer=0x608580 <tcp_listen_addr>, cb=0x40529c <connect_connect_cb>, cbarg=cbarg@entry=0x403ae9 <tcpdns_connect>, timeout=timeout@entry=30000) at netmgr/tcpdns.c:269
result = ISC_R_SUCCESS
sock = 0x0
ievent = 0x0
req = 0x0
sa_family = 10
worker = 0x7efd8ead4680
__func__ = "isc_nm_tcpdnsconnect"
#12 0x0000000000403b0d in tcpdns_connect (nm=<optimized out>) at tcpdns_test.c:63
No locals.
#13 0x00000000004040ec in stream_recv_send_connect (arg=0x403ae9 <tcpdns_connect>) at netmgr_common.c:516
connect = 0x403ae9 <tcpdns_connect>
connect_addr = {type = {sa = {sa_family = 10, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 10, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 10, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, "\001", __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 256}, __u6_addr32 = {0, 0, 0, 16777216}}}, sin6_scope_id = 0}, ss = {ss_family = 10, __ss_padding = '\000' <repeats 21 times>, "\001", '\000' <repeats 95 times>, __ss_align = 0}, sunix = {sun_family = 10, sun_path = '\000' <repeats 21 times>, "\001", '\000' <repeats 85 times>}}, length = 28, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}}
#14 0x00007efd91dfb536 in isc__job_cb (idle=0x7efd8ebf0808) at job.c:75
job = 0x7efd8ebf0800
r = <optimized out>
__func__ = "isc__job_cb"
#15 0x00007efd91ba7a49 in uv.run_idle () from /lib64/libuv.so.1
No symbol table info available.
#16 0x00007efd91ba0bf8 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#17 0x00007efd91e01b44 in loop_run (loop=0x7efd8eaa5b80) at loop.c:267
r = <optimized out>
job = <optimized out>
r = <optimized out>
job = <optimized out>
__func__ = "loop_run"
next = <optimized out>
#18 loop_thread (arg=0x7efd8eaa5b80) at loop.c:294
loop = 0x7efd8eaa5b80
#19 0x00007efd91e1b87f in isc__trampoline_run (arg=0x18486b0) at trampoline.c:198
trampoline = 0x18486b0
result = <optimized out>
#20 0x00007efd90de91df in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#21 0x00007efd90a55dd3 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 12 (Thread 0x7efd82ffd700 (LWP 7969)):
#0 0x00007efd90df05be in pthread_barrier_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007efd91bada7d in uv_barrier_wait () from /lib64/libuv.so.1
No symbol table info available.
#2 0x00007efd91de8154 in isc__nm_async_tcpdnsstop (worker=worker@entry=0x7efd8ead40c0, ev0=ev0@entry=0x7efd8ea8bd00) at netmgr/tcpdns.c:670
ievent = 0x7efd8ea8bd00
sock = 0x7efd8e3196e0
__func__ = "isc__nm_async_tcpdnsstop"
#3 0x00007efd91de27d2 in process_netievent (arg=0x7efd8ea8bd00) at netmgr/netmgr.c:463
ievent = 0x7efd8ea8bd00
worker = 0x7efd8ead40c0
#4 0x00007efd91dfb536 in isc__job_cb (idle=0x7efd8ebf0a48) at job.c:75
job = 0x7efd8ebf0a40
r = <optimized out>
__func__ = "isc__job_cb"
#5 0x00007efd91ba7a49 in uv.run_idle () from /lib64/libuv.so.1
No symbol table info available.
#6 0x00007efd91ba0bf8 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#7 0x00007efd91e01b44 in loop_run (loop=0x7efd8eaa26a0) at loop.c:267
r = <optimized out>
job = <optimized out>
r = <optimized out>
job = <optimized out>
__func__ = "loop_run"
next = <optimized out>
#8 loop_thread (arg=0x7efd8eaa26a0) at loop.c:294
loop = 0x7efd8eaa26a0
#9 0x00007efd91e1b87f in isc__trampoline_run (arg=0x1845fc0) at trampoline.c:198
trampoline = 0x1845fc0
result = <optimized out>
#10 0x00007efd90de91df in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#11 0x00007efd90a55dd3 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 11 (Thread 0x7efd81ffb700 (LWP 7967)):
#0 0x00007efd90df05be in pthread_barrier_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007efd91bada7d in uv_barrier_wait () from /lib64/libuv.so.1
No symbol table info available.
#2 0x00007efd91de8154 in isc__nm_async_tcpdnsstop (worker=worker@entry=0x7efd8ead4040, ev0=ev0@entry=0x7efd8ea8bb80) at netmgr/tcpdns.c:670
ievent = 0x7efd8ea8bb80
sock = 0x7efd8e3185a0
__func__ = "isc__nm_async_tcpdnsstop"
#3 0x00007efd91de27d2 in process_netievent (arg=0x7efd8ea8bb80) at netmgr/netmgr.c:463
ievent = 0x7efd8ea8bb80
worker = 0x7efd8ead4040
#4 0x00007efd91dfb536 in isc__job_cb (idle=0x7efd8ea24508) at job.c:75
job = 0x7efd8ea24500
r = <optimized out>
__func__ = "isc__job_cb"
#5 0x00007efd91ba7a49 in uv.run_idle () from /lib64/libuv.so.1
No symbol table info available.
#6 0x00007efd91ba0bf8 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#7 0x00007efd91e01b44 in loop_run (loop=0x7efd8eaa1ae0) at loop.c:267
r = <optimized out>
job = <optimized out>
r = <optimized out>
job = <optimized out>
__func__ = "loop_run"
next = <optimized out>
#8 loop_thread (arg=0x7efd8eaa1ae0) at loop.c:294
loop = 0x7efd8eaa1ae0
#9 0x00007efd91e1b87f in isc__trampoline_run (arg=0x1848200) at trampoline.c:198
trampoline = 0x1848200
result = <optimized out>
#10 0x00007efd90de91df in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#11 0x00007efd90a55dd3 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 10 (Thread 0x7efd827fc700 (LWP 7968)):
#0 0x00007efd90df05be in pthread_barrier_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007efd91bada7d in uv_barrier_wait () from /lib64/libuv.so.1
No symbol table info available.
#2 0x00007efd91de8154 in isc__nm_async_tcpdnsstop (worker=worker@entry=0x7efd8ead4080, ev0=ev0@entry=0x7efd8ea8a800) at netmgr/tcpdns.c:670
ievent = 0x7efd8ea8a800
sock = 0x7efd8e318e40
__func__ = "isc__nm_async_tcpdnsstop"
#3 0x00007efd91de27d2 in process_netievent (arg=0x7efd8ea8a800) at netmgr/netmgr.c:463
ievent = 0x7efd8ea8a800
worker = 0x7efd8ead4080
#4 0x00007efd91dfb536 in isc__job_cb (idle=0x7efd8ea23848) at job.c:75
job = 0x7efd8ea23840
r = <optimized out>
__func__ = "isc__job_cb"
#5 0x00007efd91ba7a49 in uv.run_idle () from /lib64/libuv.so.1
No symbol table info available.
#6 0x00007efd91ba0bf8 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#7 0x00007efd91e01b44 in loop_run (loop=0x7efd8eaa20c0) at loop.c:267
r = <optimized out>
job = <optimized out>
r = <optimized out>
job = <optimized out>
__func__ = "loop_run"
next = <optimized out>
#8 loop_thread (arg=0x7efd8eaa20c0) at loop.c:294
loop = 0x7efd8eaa20c0
#9 0x00007efd91e1b87f in isc__trampoline_run (arg=0x1845e20) at trampoline.c:198
trampoline = 0x1845e20
result = <optimized out>
#10 0x00007efd90de91df in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#11 0x00007efd90a55dd3 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 9 (Thread 0x7efd8a6fc700 (LWP 7974)):
#0 0x00007efd90df05be in pthread_barrier_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007efd91bada7d in uv_barrier_wait () from /lib64/libuv.so.1
No symbol table info available.
#2 0x00007efd91de8154 in isc__nm_async_tcpdnsstop (worker=worker@entry=0x7efd8ead4200, ev0=ev0@entry=0x7efd8ea8af80) at netmgr/tcpdns.c:670
ievent = 0x7efd8ea8af80
sock = 0x7efd8e31c200
__func__ = "isc__nm_async_tcpdnsstop"
#3 0x00007efd91de27d2 in process_netievent (arg=0x7efd8ea8af80) at netmgr/netmgr.c:463
ievent = 0x7efd8ea8af80
worker = 0x7efd8ead4200
#4 0x00007efd91dfb536 in isc__job_cb (idle=0x7efd8ebf0d48) at job.c:75
job = 0x7efd8ebf0d40
r = <optimized out>
__func__ = "isc__job_cb"
#5 0x00007efd91ba7a49 in uv.run_idle () from /lib64/libuv.so.1
No symbol table info available.
#6 0x00007efd91ba0bf8 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#7 0x00007efd91e01b44 in loop_run (loop=0x7efd8eaa4400) at loop.c:267
r = <optimized out>
job = <optimized out>
r = <optimized out>
job = <optimized out>
__func__ = "loop_run"
next = <optimized out>
#8 loop_thread (arg=0x7efd8eaa4400) at loop.c:294
loop = 0x7efd8eaa4400
#9 0x00007efd91e1b87f in isc__trampoline_run (arg=0x1847ef0) at trampoline.c:198
trampoline = 0x1847ef0
result = <optimized out>
#10 0x00007efd90de91df in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#11 0x00007efd90a55dd3 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 8 (Thread 0x7efd88ef9700 (LWP 7977)):
#0 0x00007efd90b85317 in _dl_addr () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007efd90b58296 in backtrace_symbols_fd () from /lib64/libc.so.6
No symbol table info available.
#2 0x00007efd91df193a in isc_backtrace_symbols_fd (buffer=buffer@entry=0x7efd88ef6e20, size=size@entry=13, fd=<optimized out>) at backtrace.c:61
No locals.
#3 0x00007efd91df11f6 in default_callback (file=0x7efd91e2ff0b "mem.c", line=772, type=<optimized out>, cond=0x7efd91e304a0 "((ctx) != ((void *)0) && ((const isc__magic_t *)(ctx))->magic == ((('M') << 24 | ('e') << 16 | ('m') << 8 | ('C'))))") at assertions.c:107
tracebuf = {0x7efd91df119d <default_callback+49>, 0x7efd91df1118 <isc_assertion_failed+10>, 0x7efd91e04800 <isc__mem_get+159>, 0x7efd91de92af <isc_nm_tcpdnsconnect+139>, 0x403b0d <tcpdns_connect+36>, 0x4040ec <stream_recv_send_connect+90>, 0x7efd91dfb536 <isc__job_cb+59>, 0x7efd91ba7a49 <uv.run_idle+153>, 0x7efd91ba0bf8 <uv_run+664>, 0x7efd91e01b44 <loop_thread+433>, 0x7efd91e1b87f <isc__trampoline_run+22>, 0x7efd90de91df <start_thread+239>, 0x7efd90a55dd3 <clone+67>, 0x7efd90a55dd3 <clone+67>, 0x0, 0x7efd9037ae61 <arena_bin_malloc_hard+1201>, 0x7efd806086e8, 0x3, 0x7efd88ef6f2f, 0xa, 0x7efd905f9d90, 0x7efd9037ad6e <arena_bin_malloc_hard+958>, 0x7efd806008c0, 0x7efd88ef7c78, 0x7efd8060a880, 0x7efd80608760, 0x7efd80608728, 0x7efd905f9d90, 0x7efd88ef6f2c, 0x7efd88ef7038, 0x0, 0x188ef6f2d, 0x0, 0x1, 0x8, 0x7efd88ef7038, 0x7efd8e6620d8, 0x7efd907ff200, 0xd50dcc13, 0x7efd88ef7c78, 0x7efd8ec0f300, 0x7efd903aca72 <extent_lock_from_addr+434>, 0x0, 0x1007efd9037bd7f, 0x4000000000, 0x0, 0x7efd88ef7c78, 0xd50dcc13, 0x7efd8ec03268, 0x7efd8ec0f400, 0x7efd8ec0f500, 0x7efd903b1877 <extent_try_coalesce_impl+839>, 0x7efd88ef7ca8, 0x7efd8ec00980, 0x7efd88ef7250, 0x48c900000001, 0x0, 0x7efd88ef7108, 0x0, 0x188ef7250, 0x7efd88ef7ca8, 0x1, 0x8, 0x7efd88ef7108, 0x0, 0x54, 0x7efd88ef70f0, 0x7efd91df6247 <isc_hash64+87>, 0x7efd88ef705f, 0x7efd92549c70 <isc_modules+80>, 0x0, 0x0, 0x0, 0x100000000000000, 0x0, 0xe6c048c994a92300, 0x0, 0xe6c048c994a92300, 0x7efd88ef7190, 0x7efd88ef71b8, 0x0, 0x1000000a8, 0x0, 0x1, 0x8, 0x7efd88ef71b8, 0x0, 0x2e2, 0x7efd88ef71a0, 0x7efd91df6247 <isc_hash64+87>, 0x7efd88ef71c0, 0x7efd91e03bc9 <delete_trace_entry+303>, 0x7efd91e2b585, 0x7efd5660e400, 0x7efd88ef7130, 0x8, 0x7efd8eaa5928, 0x34, 0x7efd91bb52a8, 0x7efd88ef7258, 0x0, 0x7efd88ef7268, 0x0, 0x7efd88ef7278, 0x0, 0x100000001, 0x8, 0x1, 0x8, 0x7efd88ef7278, 0x0, 0x201, 0x7efd88ef7260, 0x7efd91df6247 <isc_hash64+87>, 0x7efd91e27a1e, 0x7efd56603000, 0x7efd88ef71f0, 0x7efd91e05a3c <isc__mem_putanddetach+114>, 0x7efd5660e400, 0x0, 0x0, 0x0, 0x7efd88ef72a0, 0x7efd91df15d7 <isc_astack_destroy+125>, 0x7efd88ef7c78, 0x7efd88ef7328, 0x0, 0x10027ffff}
nframes = 13
#4 0x00007efd91df1118 in isc_assertion_failed (file=file@entry=0x7efd91e2ff0b "mem.c", line=line@entry=772, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7efd91e304a0 "((ctx) != ((void *)0) && ((const isc__magic_t *)(ctx))->magic == ((('M') << 24 | ('e') << 16 | ('m') << 8 | ('C'))))") at assertions.c:49
No locals.
#5 0x00007efd91e04800 in isc__mem_get (ctx=<optimized out>, size=size@entry=2208, flags=flags@entry=0, file=file@entry=0x7efd91e2a6f2 "netmgr/tcpdns.c", line=line@entry=269) at mem.c:781
ptr = 0x0
#6 0x00007efd91de92af in isc_nm_tcpdnsconnect (mgr=<optimized out>, local=0x6084e0 <tcp_connect_addr>, peer=0x608580 <tcp_listen_addr>, cb=0x40529c <connect_connect_cb>, cbarg=cbarg@entry=0x403ae9 <tcpdns_connect>, timeout=timeout@entry=30000) at netmgr/tcpdns.c:269
result = ISC_R_SUCCESS
sock = 0x0
ievent = 0x0
req = 0x0
sa_family = 10
worker = 0x7efd8ead4640
__func__ = "isc_nm_tcpdnsconnect"
#7 0x0000000000403b0d in tcpdns_connect (nm=<optimized out>) at tcpdns_test.c:63
No locals.
#8 0x00000000004040ec in stream_recv_send_connect (arg=0x403ae9 <tcpdns_connect>) at netmgr_common.c:516
connect = 0x403ae9 <tcpdns_connect>
connect_addr = {type = {sa = {sa_family = 10, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 10, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 10, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, "\001", __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 256}, __u6_addr32 = {0, 0, 0, 16777216}}}, sin6_scope_id = 0}, ss = {ss_family = 10, __ss_padding = '\000' <repeats 21 times>, "\001", '\000' <repeats 95 times>, __ss_align = 0}, sunix = {sun_family = 10, sun_path = '\000' <repeats 21 times>, "\001", '\000' <repeats 85 times>}}, length = 28, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}}
#9 0x00007efd91dfb536 in isc__job_cb (idle=0x7efd8ebf0748) at job.c:75
job = 0x7efd8ebf0740
r = <optimized out>
__func__ = "isc__job_cb"
#10 0x00007efd91ba7a49 in uv.run_idle () from /lib64/libuv.so.1
No symbol table info available.
#11 0x00007efd91ba0bf8 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#12 0x00007efd91e01b44 in loop_run (loop=0x7efd8eaa55a0) at loop.c:267
r = <optimized out>
job = <optimized out>
r = <optimized out>
job = <optimized out>
__func__ = "loop_run"
next = <optimized out>
#13 loop_thread (arg=0x7efd8eaa55a0) at loop.c:294
loop = 0x7efd8eaa55a0
#14 0x00007efd91e1b87f in isc__trampoline_run (arg=0x1848510) at trampoline.c:198
trampoline = 0x1848510
result = <optimized out>
#15 0x00007efd90de91df in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#16 0x00007efd90a55dd3 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 7 (Thread 0x7efd8b6fe700 (LWP 7972)):
#0 0x00007efd90df05be in pthread_barrier_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007efd91bada7d in uv_barrier_wait () from /lib64/libuv.so.1
No symbol table info available.
#2 0x00007efd91de8154 in isc__nm_async_tcpdnsstop (worker=worker@entry=0x7efd8ead4180, ev0=ev0@entry=0x7efd8ea8ac80) at netmgr/tcpdns.c:670
ievent = 0x7efd8ea8ac80
sock = 0x7efd8e31b0c0
__func__ = "isc__nm_async_tcpdnsstop"
#3 0x00007efd91de27d2 in process_netievent (arg=0x7efd8ea8ac80) at netmgr/netmgr.c:463
ievent = 0x7efd8ea8ac80
worker = 0x7efd8ead4180
#4 0x00007efd91dfb536 in isc__job_cb (idle=0x7efd8ebf0bc8) at job.c:75
job = 0x7efd8ebf0bc0
r = <optimized out>
__func__ = "isc__job_cb"
#5 0x00007efd91ba7a49 in uv.run_idle () from /lib64/libuv.so.1
No symbol table info available.
#6 0x00007efd91ba0bf8 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#7 0x00007efd91e01b44 in loop_run (loop=0x7efd8eaa3840) at loop.c:267
r = <optimized out>
job = <optimized out>
r = <optimized out>
job = <optimized out>
__func__ = "loop_run"
next = <optimized out>
#8 loop_thread (arg=0x7efd8eaa3840) at loop.c:294
loop = 0x7efd8eaa3840
#9 0x00007efd91e1b87f in isc__trampoline_run (arg=0x1846050) at trampoline.c:198
trampoline = 0x1846050
result = <optimized out>
#10 0x00007efd90de91df in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#11 0x00007efd90a55dd3 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 6 (Thread 0x7efd896fa700 (LWP 7976)):
#0 0x00007efd90df282d in __lll_lock_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007efd90debba4 in pthread_mutex_lock () from /lib64/libpthread.so.0
No symbol table info available.
#2 0x00007efd90b851f7 in _dl_addr () from /lib64/libc.so.6
No symbol table info available.
#3 0x00007efd90b58296 in backtrace_symbols_fd () from /lib64/libc.so.6
No symbol table info available.
#4 0x00007efd91df193a in isc_backtrace_symbols_fd (buffer=buffer@entry=0x7efd896f7e20, size=size@entry=13, fd=<optimized out>) at backtrace.c:61
No locals.
#5 0x00007efd91df11f6 in default_callback (file=0x7efd91e2ff0b "mem.c", line=772, type=<optimized out>, cond=0x7efd91e304a0 "((ctx) != ((void *)0) && ((const isc__magic_t *)(ctx))->magic == ((('M') << 24 | ('e') << 16 | ('m') << 8 | ('C'))))") at assertions.c:107
tracebuf = {0x7efd91df119d <default_callback+49>, 0x7efd91df1118 <isc_assertion_failed+10>, 0x7efd91e04800 <isc__mem_get+159>, 0x7efd91de92af <isc_nm_tcpdnsconnect+139>, 0x403b0d <tcpdns_connect+36>, 0x4040ec <stream_recv_send_connect+90>, 0x7efd91dfb536 <isc__job_cb+59>, 0x7efd91ba7a49 <uv.run_idle+153>, 0x7efd91ba0bf8 <uv_run+664>, 0x7efd91e01b44 <loop_thread+433>, 0x7efd91e1b87f <isc__trampoline_run+22>, 0x7efd90de91df <start_thread+239>, 0x7efd90a55dd3 <clone+67>, 0x7efd90a55dd3 <clone+67>, 0x0, 0x7efd896f8110, 0x7efd896f8c78, 0x7efd9037de0b <je_arena_ralloc+459>, 0x0, 0x7efd56c00400, 0x7efd896f8118, 0x0, 0x7efd80a008c0, 0x0, 0x0, 0x201, 0x0, 0x0, 0x0, 0x141000, 0x7efd903b134a <extents_remove_locked.isra+170>, 0xe6c048c994a92300, 0x1d, 0x7efd8ec03268, 0x7efd8ec03268, 0x7efd8ec0f400, 0x7efd8e6616d0, 0x7efd907ff5f0, 0xd50dcc13, 0x7efd896f8c78, 0x7efd8ec0f200, 0x7efd903aca72 <extent_lock_from_addr+434>, 0x0, 0x100000000000001, 0x7efd896f8c78, 0x0, 0x7efd896f8c78, 0xd50dcc13, 0x7efd8ec03268, 0x7efd8ec0f300, 0x7efd8ec0f500, 0x7efd903b1877 <extent_try_coalesce_impl+839>, 0x7efd896f8ca8, 0x7efd8ec00980, 0x7efd896f8250, 0x7efd00000001, 0x0, 0x7efd896f8108, 0x0, 0x1896f8250, 0x7efd896f8ca8, 0x1, 0x8, 0x7efd896f8108, 0x0, 0x54, 0x7efd896f80f0, 0x7efd91df6247 <isc_hash64+87>, 0x7efd896f805f, 0x7efd92549c70 <isc_modules+80>, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7efd896f8198, 0x0, 0x1896f8c78, 0x0, 0x7efd896f81b8, 0x0, 0x1896f8198, 0x0, 0x1, 0x8, 0x7efd896f81b8, 0x0, 0x2e2, 0x7efd896f81a0, 0x7efd91df6247 <isc_hash64+87>, 0x7efd896f81c0, 0x7efd91e03bc9 <delete_trace_entry+303>, 0x7efd91e2b585, 0x7efd56c13400, 0x0, 0x7efd80000000, 0x7efd8df8c120, 0x7efd896f8c78, 0x7efd8ea32e30, 0x7efd896f8258, 0x0, 0x7efd896f8268, 0x0, 0x7efd896f8278, 0x0, 0x18ea18010, 0x168, 0x1, 0x8, 0x7efd896f8278, 0x0, 0x201, 0x7efd896f8260, 0x7efd91df6247 <isc_hash64+87>, 0x7efd91e27a1e, 0x7efd56c04400, 0x7efd896f81f0, 0x7efd91e05a3c <isc__mem_putanddetach+114>, 0x7efd56c13400, 0x0, 0x0, 0x0, 0x7efd896f82a0, 0x7efd91df15d7 <isc_astack_destroy+125>, 0x7efd896f8c78, 0x7efd896f8328, 0x0, 0x10027ffff}
nframes = 13
#6 0x00007efd91df1118 in isc_assertion_failed (file=file@entry=0x7efd91e2ff0b "mem.c", line=line@entry=772, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7efd91e304a0 "((ctx) != ((void *)0) && ((const isc__magic_t *)(ctx))->magic == ((('M') << 24 | ('e') << 16 | ('m') << 8 | ('C'))))") at assertions.c:49
No locals.
#7 0x00007efd91e04800 in isc__mem_get (ctx=<optimized out>, size=size@entry=2208, flags=flags@entry=0, file=file@entry=0x7efd91e2a6f2 "netmgr/tcpdns.c", line=line@entry=269) at mem.c:781
ptr = 0x0
#8 0x00007efd91de92af in isc_nm_tcpdnsconnect (mgr=<optimized out>, local=0x6084e0 <tcp_connect_addr>, peer=0x608580 <tcp_listen_addr>, cb=0x40529c <connect_connect_cb>, cbarg=cbarg@entry=0x403ae9 <tcpdns_connect>, timeout=timeout@entry=30000) at netmgr/tcpdns.c:269
result = ISC_R_SUCCESS
sock = 0x0
ievent = 0x0
req = 0x0
sa_family = 10
worker = 0x7efd8ead4600
__func__ = "isc_nm_tcpdnsconnect"
#9 0x0000000000403b0d in tcpdns_connect (nm=<optimized out>) at tcpdns_test.c:63
No locals.
#10 0x00000000004040ec in stream_recv_send_connect (arg=0x403ae9 <tcpdns_connect>) at netmgr_common.c:516
connect = 0x403ae9 <tcpdns_connect>
connect_addr = {type = {sa = {sa_family = 10, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 10, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 10, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, "\001", __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 256}, __u6_addr32 = {0, 0, 0, 16777216}}}, sin6_scope_id = 0}, ss = {ss_family = 10, __ss_padding = '\000' <repeats 21 times>, "\001", '\000' <repeats 95 times>, __ss_align = 0}, sunix = {sun_family = 10, sun_path = '\000' <repeats 21 times>, "\001", '\000' <repeats 85 times>}}, length = 28, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}}
#11 0x00007efd91dfb536 in isc__job_cb (idle=0x7efd8ebf0688) at job.c:75
job = 0x7efd8ebf0680
r = <optimized out>
__func__ = "isc__job_cb"
#12 0x00007efd91ba7a49 in uv.run_idle () from /lib64/libuv.so.1
No symbol table info available.
#13 0x00007efd91ba0bf8 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#14 0x00007efd91e01b44 in loop_run (loop=0x7efd8eaa4fc0) at loop.c:267
r = <optimized out>
job = <optimized out>
r = <optimized out>
job = <optimized out>
__func__ = "loop_run"
next = <optimized out>
#15 loop_thread (arg=0x7efd8eaa4fc0) at loop.c:294
loop = 0x7efd8eaa4fc0
#16 0x00007efd91e1b87f in isc__trampoline_run (arg=0x1847a10) at trampoline.c:198
trampoline = 0x1847a10
result = <optimized out>
#17 0x00007efd90de91df in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#18 0x00007efd90a55dd3 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 5 (Thread 0x7efd8beff700 (LWP 7971)):
#0 0x00007efd90df05be in pthread_barrier_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007efd91bada7d in uv_barrier_wait () from /lib64/libuv.so.1
No symbol table info available.
#2 0x00007efd91de8154 in isc__nm_async_tcpdnsstop (worker=worker@entry=0x7efd8ead4140, ev0=ev0@entry=0x7efd8ea89900) at netmgr/tcpdns.c:670
ievent = 0x7efd8ea89900
sock = 0x7efd8e31a820
__func__ = "isc__nm_async_tcpdnsstop"
#3 0x00007efd91de27d2 in process_netievent (arg=0x7efd8ea89900) at netmgr/netmgr.c:463
ievent = 0x7efd8ea89900
worker = 0x7efd8ead4140
#4 0x00007efd91dfb536 in isc__job_cb (idle=0x7efd8ebf0b08) at job.c:75
job = 0x7efd8ebf0b00
r = <optimized out>
__func__ = "isc__job_cb"
#5 0x00007efd91ba7a49 in uv.run_idle () from /lib64/libuv.so.1
No symbol table info available.
#6 0x00007efd91ba0bf8 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#7 0x00007efd91e01b44 in loop_run (loop=0x7efd8eaa3260) at loop.c:267
r = <optimized out>
job = <optimized out>
r = <optimized out>
job = <optimized out>
__func__ = "loop_run"
next = <optimized out>
#8 loop_thread (arg=0x7efd8eaa3260) at loop.c:294
loop = 0x7efd8eaa3260
#9 0x00007efd91e1b87f in isc__trampoline_run (arg=0x1846020) at trampoline.c:198
trampoline = 0x1846020
result = <optimized out>
#10 0x00007efd90de91df in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#11 0x00007efd90a55dd3 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 4 (Thread 0x7efd92768140 (LWP 7887)):
#0 0x00007efd90df05be in pthread_barrier_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007efd91bada7d in uv_barrier_wait () from /lib64/libuv.so.1
No symbol table info available.
#2 0x00007efd91de8154 in isc__nm_async_tcpdnsstop (worker=worker@entry=0x7efd8ead4000, ev0=ev0@entry=0x7efd8ea8b700) at netmgr/tcpdns.c:670
ievent = 0x7efd8ea8b700
sock = 0x7efd8e317d00
__func__ = "isc__nm_async_tcpdnsstop"
#3 0x00007efd91de27d2 in process_netievent (arg=0x7efd8ea8b700) at netmgr/netmgr.c:463
ievent = 0x7efd8ea8b700
worker = 0x7efd8ead4000
#4 0x00007efd91de2af3 in isc__nm_process_ievent (worker=<optimized out>, event=<optimized out>) at netmgr/netmgr.c:567
No locals.
#5 0x00007efd91de72c5 in stop_tcpdns_child (sock=sock@entry=0x7efd8e5d8c00, tid=tid@entry=0) at netmgr/tcpdns.c:605
csock = 0x7efd8e317d00
ievent = <optimized out>
#6 0x00007efd91de7c14 in isc__nm_tcpdns_stoplistening (sock=0x7efd8e5d8c00) at netmgr/tcpdns.c:632
__func__ = "isc__nm_tcpdns_stoplistening"
#7 0x00007efd91ddf096 in isc_nm_stoplistening (sock=<optimized out>) at netmgr/netmgr.c:2091
No locals.
#8 0x0000000000403c86 in stop_listening (arg=<optimized out>) at tcpdns_test.c:45
No locals.
#9 0x00007efd91dfb536 in isc__job_cb (idle=0x7efd8ebefe48) at job.c:75
job = 0x7efd8ebefe40
r = <optimized out>
__func__ = "isc__job_cb"
#10 0x00007efd91ba7a49 in uv.run_idle () from /lib64/libuv.so.1
No symbol table info available.
#11 0x00007efd91ba0bf8 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#12 0x00007efd91e01b44 in loop_run (loop=0x7efd8eaa1500) at loop.c:267
r = <optimized out>
job = <optimized out>
r = <optimized out>
job = <optimized out>
__func__ = "loop_run"
next = <optimized out>
#13 loop_thread (arg=0x7efd8eaa1500) at loop.c:294
loop = 0x7efd8eaa1500
#14 0x00007efd91e02b91 in isc_loopmgr_run (loopmgr=0x7efd8ea23540) at loop.c:474
__func__ = "isc_loopmgr_run"
#15 0x0000000000403ae7 in run_test_tcpdns_recv_send (state=<optimized out>) at tcpdns_test.c:121
No locals.
#16 0x00007efd91782f37 in cmocka_run_one_test_or_fixture () from /lib64/libcmocka.so.0
No symbol table info available.
#17 0x00007efd917838a1 in _cmocka_run_group_tests () from /lib64/libcmocka.so.0
No symbol table info available.
#18 0x000000000040405e in main () at tcpdns_test.c:153
r = <optimized out>
Thread 3 (Thread 0x7efd8aefd700 (LWP 7973)):
#0 0x00007efd90df05be in pthread_barrier_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007efd91bada7d in uv_barrier_wait () from /lib64/libuv.so.1
No symbol table info available.
#2 0x00007efd91de8154 in isc__nm_async_tcpdnsstop (worker=worker@entry=0x7efd8ead41c0, ev0=ev0@entry=0x7efd8ea8ae00) at netmgr/tcpdns.c:670
ievent = 0x7efd8ea8ae00
sock = 0x7efd8e31b960
__func__ = "isc__nm_async_tcpdnsstop"
#3 0x00007efd91de27d2 in process_netievent (arg=0x7efd8ea8ae00) at netmgr/netmgr.c:463
ievent = 0x7efd8ea8ae00
worker = 0x7efd8ead41c0
#4 0x00007efd91dfb536 in isc__job_cb (idle=0x7efd8ebf0c88) at job.c:75
job = 0x7efd8ebf0c80
r = <optimized out>
__func__ = "isc__job_cb"
#5 0x00007efd91ba7a49 in uv.run_idle () from /lib64/libuv.so.1
No symbol table info available.
#6 0x00007efd91ba0bf8 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#7 0x00007efd91e01b44 in loop_run (loop=0x7efd8eaa3e20) at loop.c:267
r = <optimized out>
job = <optimized out>
r = <optimized out>
job = <optimized out>
__func__ = "loop_run"
next = <optimized out>
#8 loop_thread (arg=0x7efd8eaa3e20) at loop.c:294
loop = 0x7efd8eaa3e20
#9 0x00007efd91e1b87f in isc__trampoline_run (arg=0x1846080) at trampoline.c:198
trampoline = 0x1846080
result = <optimized out>
#10 0x00007efd90de91df in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#11 0x00007efd90a55dd3 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 2 (Thread 0x7efd837fe700 (LWP 7970)):
#0 0x00007efd90df05be in pthread_barrier_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007efd91bada7d in uv_barrier_wait () from /lib64/libuv.so.1
No symbol table info available.
#2 0x00007efd91de8154 in isc__nm_async_tcpdnsstop (worker=worker@entry=0x7efd8ead4100, ev0=ev0@entry=0x7efd8ea8be80) at netmgr/tcpdns.c:670
ievent = 0x7efd8ea8be80
sock = 0x7efd8e319f80
__func__ = "isc__nm_async_tcpdnsstop"
#3 0x00007efd91de27d2 in process_netievent (arg=0x7efd8ea8be80) at netmgr/netmgr.c:463
ievent = 0x7efd8ea8be80
worker = 0x7efd8ead4100
#4 0x00007efd91dfb536 in isc__job_cb (idle=0x7efd8ebf08c8) at job.c:75
job = 0x7efd8ebf08c0
r = <optimized out>
__func__ = "isc__job_cb"
#5 0x00007efd91ba7a49 in uv.run_idle () from /lib64/libuv.so.1
No symbol table info available.
#6 0x00007efd91ba0bf8 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#7 0x00007efd91e01b44 in loop_run (loop=0x7efd8eaa2c80) at loop.c:267
r = <optimized out>
job = <optimized out>
r = <optimized out>
job = <optimized out>
__func__ = "loop_run"
next = <optimized out>
#8 loop_thread (arg=0x7efd8eaa2c80) at loop.c:294
loop = 0x7efd8eaa2c80
#9 0x00007efd91e1b87f in isc__trampoline_run (arg=0x1845ff0) at trampoline.c:198
trampoline = 0x1845ff0
result = <optimized out>
#10 0x00007efd90de91df in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#11 0x00007efd90a55dd3 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 1 (Thread 0x7efd89efb700 (LWP 7975)):
#0 0x00007efd90a6aa9f in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007efd90a3de05 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x00007efd91df111d in isc_assertion_failed (file=file@entry=0x7efd91e2ff0b "mem.c", line=line@entry=772, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7efd91e304a0 "((ctx) != ((void *)0) && ((const isc__magic_t *)(ctx))->magic == ((('M') << 24 | ('e') << 16 | ('m') << 8 | ('C'))))") at assertions.c:50
No locals.
#3 0x00007efd91e04800 in isc__mem_get (ctx=<optimized out>, size=size@entry=2208, flags=flags@entry=0, file=file@entry=0x7efd91e2a6f2 "netmgr/tcpdns.c", line=line@entry=269) at mem.c:781
ptr = 0x0
#4 0x00007efd91de92af in isc_nm_tcpdnsconnect (mgr=<optimized out>, local=0x6084e0 <tcp_connect_addr>, peer=0x608580 <tcp_listen_addr>, cb=0x40529c <connect_connect_cb>, cbarg=cbarg@entry=0x403ae9 <tcpdns_connect>, timeout=timeout@entry=30000) at netmgr/tcpdns.c:269
result = ISC_R_SUCCESS
sock = 0x0
ievent = 0x0
req = 0x0
sa_family = 10
worker = 0x7efd8ead45c0
__func__ = "isc_nm_tcpdnsconnect"
#5 0x0000000000403b0d in tcpdns_connect (nm=<optimized out>) at tcpdns_test.c:63
No locals.
#6 0x00000000004040ec in stream_recv_send_connect (arg=0x403ae9 <tcpdns_connect>) at netmgr_common.c:516
connect = 0x403ae9 <tcpdns_connect>
connect_addr = {type = {sa = {sa_family = 10, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 10, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 10, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, "\001", __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 256}, __u6_addr32 = {0, 0, 0, 16777216}}}, sin6_scope_id = 0}, ss = {ss_family = 10, __ss_padding = '\000' <repeats 21 times>, "\001", '\000' <repeats 95 times>, __ss_align = 0}, sunix = {sun_family = 10, sun_path = '\000' <repeats 21 times>, "\001", '\000' <repeats 85 times>}}, length = 28, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}}
#7 0x00007efd91dfb536 in isc__job_cb (idle=0x7efd8ebf05c8) at job.c:75
job = 0x7efd8ebf05c0
r = <optimized out>
__func__ = "isc__job_cb"
#8 0x00007efd91ba7a49 in uv.run_idle () from /lib64/libuv.so.1
No symbol table info available.
#9 0x00007efd91ba0bf8 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#10 0x00007efd91e01b44 in loop_run (loop=0x7efd8eaa49e0) at loop.c:267
r = <optimized out>
job = <optimized out>
r = <optimized out>
job = <optimized out>
__func__ = "loop_run"
next = <optimized out>
#11 loop_thread (arg=0x7efd8eaa49e0) at loop.c:294
loop = 0x7efd8eaa49e0
#12 0x00007efd91e1b87f in isc__trampoline_run (arg=0x1847870) at trampoline.c:198
trampoline = 0x1847870
result = <optimized out>
#13 0x00007efd90de91df in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#14 0x00007efd90a55dd3 in clone () from /lib64/libc.so.6
No symbol table info available.
D:tcpdns_test:backtrace from ./core.7887 end
FAIL tcpdns_test (exit status: 134)
```
</details>Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3644dupsigs system test is flaky for TYPE65534 on Windows2023-02-06T19:48:34ZMichal Nowakdupsigs system test is flaky for TYPE65534 on WindowsSuspiciously, the `dupsigs` system test only prints a variant of the following `check_journal.pl` failure several times over and [exits with a `PASS`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2876865):
```
unable to parse key sta...Suspiciously, the `dupsigs` system test only prints a variant of the following `check_journal.pl` failure several times over and [exits with a `PASS`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2876865):
```
unable to parse key status record at check_journal.pl line 87, <> line 13.
1008 26311
1 38032
```
More debugging for what happens for `TYPE65534` RRTYPE on Windows is needed.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3649Feature request: configurable TCP timeouts on zone refresh queries2023-06-15T13:22:31ZCathy AlmondFeature request: configurable TCP timeouts on zone refresh queriesThere is nothing that can be configured to reduce the timeout when failing to reach an authoritative server with a refresh query over TCP (BIND default is "try-tcp-refresh yes;")
Customer input is :
```
Basically, if my slave is trying ...There is nothing that can be configured to reduce the timeout when failing to reach an authoritative server with a refresh query over TCP (BIND default is "try-tcp-refresh yes;")
Customer input is :
```
Basically, if my slave is trying to reach out to a third-party master and doesn't get a response in 10-15 seconds, I want it to move on to the next listed master in hopes of better results versus waiting for 2 minutes
```
A 'sort of' workaround for this is to allow the UDP timeout to happen ("try-tcp-refresh no;") but that takes away the possibility of being able to reach servers and to pull a zone transfer in the situation where UDP doesn't work, but TCP does.
We have configurable TCP timeouts for other BIND functions, but not for this.
See [Support ticket #21044](https://support.isc.org/Ticket/Display.html?id=21044)https://gitlab.isc.org/isc-projects/bind9/-/issues/3650Support not crossing the XFR streams2023-11-09T21:01:32ZMark AndrewsSupport not crossing the XFR streams### Description
#### Goal
Make BIND in the role of **secondary** to play nicely with multi-master infrastructures.
In large topologies people want to avoid SPOF anywhere in the DNS infrastructure. Other people provide tools to accept D...### Description
#### Goal
Make BIND in the role of **secondary** to play nicely with multi-master infrastructures.
In large topologies people want to avoid SPOF anywhere in the DNS infrastructure. Other people provide tools to accept DNS UPDATE at multiple servers in parallel and then resynchronize databases using their own protocols, which is not consistent with monotonic and unique SOA SERIAL mapping to a single version of zone data.
Multi-master primaries can go up and down at any time - that's why people do want multi-master in the first place!
#### Problems in practice
- Replication between primaries (using proprietary protocols) takes non-zero time.
- SOA serials are generally not consistent/cannot be relied upon.
- IXFR is total mess when switching between primaries.
- AXFR and NOTIFY is unreliable - SOA serial might indicate there are no new data while there actually are.
- Primaries might do independent signing - RRSIGs inconsistent (IXFR trouble again).
### Request
Extend the primaries the syntax to support **sets** of primaries to which server the same zone contents, and switch between them when the current set is unreachable.
Sets are needed to support topologies where BIND secondary is not speaking directly to the primaries but is somewhere deeper down in the replication tree.
Proposal:
```
primaries [set #] ... { ... };
```
Record the set number in the raw file. "255 sets must be good enough for everyone."
#### Caveats
- Secondaries with sets configured now require `masterfile-format raw`.
- Config change might mess up mapping between primary sets and number recorded in the raw zone file.
### Links / references
Who is doing multi-master, for different purposes:
- Windows Active Directory DNS - very common, does not maintain SOA serial consistency across topology.
- Some TLDs do independent DNSSEC signers to avoid SPOF.
- FreeIPA - multi-master DNS - like Windows AD but for Unix, independent DNSSEC signers (different RRSIGs on each DNS server), does not maintain strict SOA serial consistency.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3653update-policy logic logging/debugging2022-11-04T07:04:22ZJorisupdate-policy logic logging/debugging### Description
Currently debugging update-policy rules is opaque, only the decision is available.
It would be beneficial if it was possible to trace the individual steps taken, eg which rule was expanded to what (wildcard expansion, k...### Description
Currently debugging update-policy rules is opaque, only the decision is available.
It would be beneficial if it was possible to trace the individual steps taken, eg which rule was expanded to what (wildcard expansion, key names vs fqdn names) to which result.
### Request
Logging at the right trace level could be something like below. Note I'm by far not an expert in the update policies, my example might way off.
```update-policy
grant wrong-key-name name example.com ANY;
=> identity key wrong-key-name not found, aborted
grant key-name name example.com NS;
=> update request does not match name example.com, aborted
grant key-name name example.com MX;
=> update request does not match type, aborted
grant updater-key.example.com name example.com ANY;
=> identity host updater-key.example.com not found, aborted [ a keyname that looks like a fqdn? ]
=> request denied```
Similarly key/kerberos failures could be logged too.
### Links / references
In #235 a similar request is made, this elaborates the scope and suggested solution.https://gitlab.isc.org/isc-projects/bind9/-/issues/3657Time and related disasters in software (y2k38)2023-03-31T15:51:56ZTony FinchTime and related disasters in software (y2k38)There are some opportunities to simplify:
* BIND now targets POSIX, which gives us much more useful guarantees about the behaviour of `time_t`, so we can replace most uses of `isc_stdtime_t`.
* ISO C has adopted `struct timespec` s...There are some opportunities to simplify:
* BIND now targets POSIX, which gives us much more useful guarantees about the behaviour of `time_t`, so we can replace most uses of `isc_stdtime_t`.
* ISO C has adopted `struct timespec` so we can use that instead of `isc_time_t`. It is used for C's timed mutex and thread sleep.
- This will need some care, though, because `isc_time_t` has unsigned members, whereas `struct timespec` is signed, for instance, `long tv_nsec`.
- On the other hand, 64 bit nanoseconds since the epoch is much easier to use than `struct timespec` or `isc_time_t`
* Most uses of time in BIND should probably be changed to use CLOCK_MONOTONIC instead of wall timeNot plannedTony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3658journal performance improvements - use asynchronous I/O2023-04-06T12:27:32ZPetr Špačekpspacek@isc.orgjournal performance improvements - use asynchronous I/OCurrently journal I/O is done synchronously, including fsync(). `fsync` is very slow (see #3556) and we probably cannot get rid of it completely, so I think we should use asynchronous I/O for journal processing. That would allow the serv...Currently journal I/O is done synchronously, including fsync(). `fsync` is very slow (see #3556) and we probably cannot get rid of it completely, so I think we should use asynchronous I/O for journal processing. That would allow the server to process normal queries while waiting for journal operations.
TODO: Test IXFR-in and querying the server in parallel.https://gitlab.isc.org/isc-projects/bind9/-/issues/3659Implement draft-ietf-dnsop-dns-error-reporting2023-11-02T17:05:06ZMark AndrewsImplement draft-ietf-dnsop-dns-error-reportingthe current draft is at https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/
Development inter-op testing is using 65023 as the EDNS option code point.the current draft is at https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/
Development inter-op testing is using 65023 as the EDNS option code point.Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3660CID 375800: Concurrent data access violations in lib/isc/rwlock.c2023-01-10T14:15:41ZMichal NowakCID 375800: Concurrent data access violations in lib/isc/rwlock.cCoverity Scan assumes that `rwl->readers_waiting` should be accessed with a lock held as is done elsewhere 4 out of 5 times.
The following recent commits might be of interest:
- 98b7a93772077c021c3ff8a8d763decb8dffeba1
- 6bd201ccec1d5a...Coverity Scan assumes that `rwl->readers_waiting` should be accessed with a lock held as is done elsewhere 4 out of 5 times.
The following recent commits might be of interest:
- 98b7a93772077c021c3ff8a8d763decb8dffeba1
- 6bd201ccec1d5a11a42890e8b94a6920fcda97bb
- 0492bbf590fa5c7e52f94d5a9220724e68052444
```
*** CID 375800: Concurrent data access violations (MISSING_LOCK)
/lib/isc/rwlock.c: 104 in isc__rwlock_init()
98 rwl->magic = 0;
99
100 atomic_init(&rwl->spins, 0);
101 atomic_init(&rwl->write_requests, 0);
102 atomic_init(&rwl->write_completions, 0);
103 atomic_init(&rwl->cnt_and_flag, 0);
>>> CID 375800: Concurrent data access violations (MISSING_LOCK)
>>> Accessing "rwl->readers_waiting" without holding lock "isc_rwlock.lock". Elsewhere, "isc_rwlock.readers_waiting" is accessed with "isc_rwlock.lock" held 4 out of 5 times.
104 rwl->readers_waiting = 0;
105 atomic_init(&rwl->write_granted, 0);
106 if (read_quota != 0) {
107 UNEXPECTED_ERROR("read quota is not supported");
108 }
109 if (write_quota == 0) {
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3669update-policy external is synchronous and blocking without timeouts2023-04-06T12:51:39ZPetr Špačekpspacek@isc.orgupdate-policy external is synchronous and blocking without timeouts### Summary
[update-policy](https://bind9.readthedocs.io/en/v9_19_6/reference.html#namedconf-statement-update-policy) `external` is using synchronous blocking I/O on a Unix socket.
### BIND version used
0744ebe2206fcb327ca0d33e0a72275...### Summary
[update-policy](https://bind9.readthedocs.io/en/v9_19_6/reference.html#namedconf-statement-update-policy) `external` is using synchronous blocking I/O on a Unix socket.
### BIND version used
0744ebe2206fcb327ca0d33e0a722757525e30f0, but as far as I can tell all versions after 9.8.0b1 are affected. (We did not have the `external` policy before that version.)
### Steps to reproduce
I've just looked at the code - function `dns_ssu_external_match()`.
### What is the current *bug* behavior?
Connect/write/read operations are done synchronously on an unix socket. If the external system takes non-zero time to process the query (say, because it's doing database lookups ... or because it just crashed) a named thread will be blocked while waiting for the answer.
### What is the expected *correct* behavior?
I would expect it to be asynchronous... Or that we don't have the policy :-0Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3679Fix stub zone operation when talking to minimal authoritative servers2023-04-17T10:16:31ZGreg ChoulesFix stub zone operation when talking to minimal authoritative servershttps://gitlab.isc.org/isc-projects/bind9/-/issues/1736 was created to fix the issue that when the authoritative server to which a stub zone is pointing is configured for "minimal-responses yes;" and the NS are in-zone, operation of the ...https://gitlab.isc.org/isc-projects/bind9/-/issues/1736 was created to fix the issue that when the authoritative server to which a stub zone is pointing is configured for "minimal-responses yes;" and the NS are in-zone, operation of the stub zone would fail because it did not receive address records for the zone's NS in the Additional section of the NS response.
I believe that the fix was applied at the wrong end of the conversation, by making the authoritative server's response to NS queries return Additional data even if "minimal-responses" is set to "yes".
A BIND recursive server (with stub zones configured) may be talking to a non-BIND authoritative server with a more strict minimal response configuration, in which case the problem would still exist.
I think the correct fix would be to modify the stub zone code so that, if it needs address records for the given NS, it queries for them. This should work without any extra user configuration because stub zones **must** be defined with at least one primary - a bit like root hints - which is used to send the initial SOA and NS queries. The same address(es) can be used for the address queries for the NS records, given that they are in the zone itself.https://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/3687Add the ability to specify TLS configuration at the zone level for catalog zones2023-03-29T07:57:03ZMark AndrewsAdd the ability to specify TLS configuration at the zone level for catalog zonesCurrently the only way to specify which TLS configuration to use with catalog member zones is to inherit it from the default-primaries settings.
One possible mechanism would be to support multiple fields in the TXT record that currently...Currently the only way to specify which TLS configuration to use with catalog member zones is to inherit it from the default-primaries settings.
One possible mechanism would be to support multiple fields in the TXT record that currently specifies the TSIG key with "" indicating that field is empty.
e.g.
- TXT keyname TLS-configuration
- TXT keyname
- TXT "" TLS-configuration
- TXT "" ""
- TXT keyname ""
Deploying such a change would require the servers involved to be upgraded prior to the use of the new record format.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3688rndc status "soa queries in progress" counter includes also AXFR in progress2023-11-02T17:05:06ZPetr Špačekpspacek@isc.orgrndc status "soa queries in progress" counter includes also AXFR in progress### Summary
rndc status "soa queries in progress" counter includes also AXFRs in progress, even transfers which made SOA query and received a valid answer with SOA before initiating transfer itself.
### BIND version used
- ~"Affects v...### Summary
rndc status "soa queries in progress" counter includes also AXFRs in progress, even transfers which made SOA query and received a valid answer with SOA before initiating transfer itself.
### BIND version used
- ~"Affects v9.19": 8272cc2
- ~"Affects v9.18": v9_18_9
- ~"Affects v9.16": v9_16_35
- ~"Affects v9.11 (EoL)": v9_11_37
### Steps to reproduce
1. Use following config to transfer (public) se. zone:
```
zone se {
type secondary;
primaries { 45.155.96.61; };
notify no;
};
```
2. Run `tcpdump` and watch SOA queries go by:
```
sudo tcpdump -i any 'udp and host 45.155.96.61'
```
3. Run BIND:
```
named -g -c secondary.conf
```
4. Observe output from `rndc status` before the transfer finishes.
### What is the current *bug* behavior?
tcpdump shows:
```
18:43:53.463606 enp0s13f0u1u2u3 Out IP p.50306 > zonedata.iis.se.domain: 21273 [1au] SOA? se. (35)
18:43:53.512928 enp0s13f0u1u2u3 In IP zonedata.iis.se.domain > p.50306: 21273*- 1/0/1 SOA (107)
```
`rndc status` at the same time shows:
```
xfers running: 1
xfers deferred: 0
soa queries in progress: 1
```
`named` log at the time:
```
21-Nov-2022 18:43:53.509 zone se/IN: Transfer started.
21-Nov-2022 18:43:53.556 transfer of 'se/IN' from 45.155.96.61#53: connected using 45.155.96.61#53
```
### What is the expected *correct* behavior?
I would expect "soa queries in progress" counter so be 0 at this point in time.Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3691stats channels and `rndc dumpstats` do not expose all counters from `rndc sta...2022-11-29T13:42:48ZPetr Špačekpspacek@isc.orgstats channels and `rndc dumpstats` do not expose all counters from `rndc status`### Summary
JSON and XML stat channels, and `rndc dumpstats` command, do not expose counters from `rndc status`. This forces users to scrape both channels to get complete picture.
### BIND version used
9.19.8-dev (Development Release)...### Summary
JSON and XML stat channels, and `rndc dumpstats` command, do not expose counters from `rndc status`. This forces users to scrape both channels to get complete picture.
### BIND version used
9.19.8-dev (Development Release) 9128e54 , but it certainly dates long way back.
### What is the current *bug* behavior?
Compare lines produced by `rndc status` with content of JSON stats channel:
| rndc status line | evaluation | JSON key |
|-------------------------------------------------------------|-------------------|-------------|
| version: BIND 9.19.8-dev (Development Release) <id:9128e54> | different format, just `9.19.8-dev` | version |
| running on p: Linux x86_64 6.0.8-arch1-1 #1 SMP … | missing | |
| boot time: Tue, 22 Nov 2022 08:43:49 GMT | different format | boot-time |
| last configured: Tue, 22 Nov 2022 09:34:20 GMT | different format | config-time |
| configuration file: /etc/named.conf | missing | |
| CPUs found: 8 | missing | |
| worker threads: 8 | missing | |
| UDP listeners per interface: 8 | missing | |
| number of zones: 103 (98 automatic) | missing | |
| debug level: 0 | missing | |
| xfers running: 0 | missing | |
| xfers deferred: 0 | missing | |
| soa queries in progress: 0 | missing | |
| query logging is OFF | missing | |
| recursive clients: 0/900/1000 | missing | |
| tcp clients: 0/150 | missing | |
| TCP high-water: 0 | missing | |
| server is up and running | missing | |
### What is the expected *correct* behavior?
All information from `rndc status` is also exposed in other stats channels.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3695Improvement: Including query time in dnstap CLIENT_RESPONSE messages2023-01-11T12:15:33ZBorja Marcos EA2EKHImprovement: Including query time in dnstap CLIENT_RESPONSE messages### Description
While the dnstap specification recommends including the query time for AUTH_RESPONSE, RESOLVER_RESPONSE and
CLIENT_RESPONSE dnstap messages, the latter is excluded.
Having the query time in CLIENT_RESPONSE dnstap messa...### Description
While the dnstap specification recommends including the query time for AUTH_RESPONSE, RESOLVER_RESPONSE and
CLIENT_RESPONSE dnstap messages, the latter is excluded.
Having the query time in CLIENT_RESPONSE dnstap messages would be very useful when using dnstap to keep track
of response times.
### Request
In lib/dns/dnstap.c (both for 9.16 and 9.18) the dns_dt_send function accepts the qtime and rtime parameters.
However, when building the dnstap message, CLIENT_RESPONSE messages are prevented from using the qtime parameter.
` dm.m.has_response_time_sec = 1;
dm.m.response_time_nsec = isc_time_nanoseconds(t);
dm.m.has_response_time_nsec = 1;
/*
* Types CR, RR, and FR can fall through and get the query
* time set as well. Any other response type, break.
*/
if (msgtype != DNS_DTTYPE_RR && msgtype != DNS_DTTYPE_FR
&& msgtype != DNS_DTTYPE_CR) { // << I HAVE ADDED THIS!
break;
}
FALLTHROUGH;
case DNS_DTTYPE_AQ:
case DNS_DTTYPE_CQ:
case DNS_DTTYPE_FQ:
case DNS_DTTYPE_RQ:
case DNS_DTTYPE_SQ:
case DNS_DTTYPE_TQ:
case DNS_DTTYPE_UQ:
if (qtime != NULL) {
t = qtime;
}
dm.m.query_time_sec = isc_time_seconds(t);
dm.m.has_query_time_sec = 1;
dm.m.query_time_nsec = isc_time_nanoseconds(t);
dm.m.has_query_time_nsec = 1;
break;
`
I have tried making the simple change shown above (so that qtime is considered for
CLIENT_RESPONSE messages as well) and it works both for 9.16.35 and 9.18.9.
The change looks safe enough (it won´t crash because if qtime is NULL t will contain a
timestamp obtained when dns_dt_send() is invoked) and at worst it would contain a false
qtime.
A more correct alternative would be to include it for CLIENT_RESPONSE messages only if qtime != NULL. But
I don´t know whether it can happen or all the calls to dns_dt_send() will contain qtime.
Also, is it possible for qtime to be missing for a CLIENT_RESPONSE but not for a RESOLVER_RESPONSE? Because for a RESOLVER_RESPONSE it would mean that query time in the dnstap message would contain the timestamp obtained in dns_dt_send() and, being probably
greater than the response time itself that would botch a time difference calculation.
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3698rndc can get very very slow if large number of requests is made over short pe...2023-01-12T11:25:12ZPetr Špačekpspacek@isc.orgrndc can get very very slow if large number of requests is made over short period of time### Summary
rndc can get very very slow if large number of requests is made over short period of time. Primary cause seems to be that packet deduplication goes O(n^2).
### BIND version used
- ~"Affects v9.19" : e2bbf38cdb42de70d504b2f...### Summary
rndc can get very very slow if large number of requests is made over short period of time. Primary cause seems to be that packet deduplication goes O(n^2).
### BIND version used
- ~"Affects v9.19" : e2bbf38cdb42de70d504b2ff281fb360cd0f27c0
- I assume that supported versions are affected
### Steps to reproduce
TL;DR call `rndc addzone` in a tight loop, and measure response time.
Helper scripts:
* [addconfprim.py](/uploads/129fa9ac79cd590c9172e6d61f28a59f/addconfprim.py) - run this
* [rndc.py](/uploads/23c2eba46244ac7decbe865d84a92052/rndc.py)
### What is the current *bug* behavior?
Adding zones slows down very quickly.
```
33000 zones present; adding last 1000 took 1.93 secs
...
65000 zones present; adding last 1000 took 4.42 secs
```
### What is the expected *correct* behavior?
No speed degradation.
### Relevant configuration files
```
key "key" {
algorithm hmac-sha256;
secret "ptCZS/77Xm2sIzCdO/oxEoer2BbDgCfvF0CrqrcdRWM=";
};
options {
max-cache-size 10M;
recursion no;
notify no;
allow-new-zones yes;
lmdb-mapsize 110M;
};
```
* [empty.db](/uploads/da7366d7d37edc16d43b7280f7cbaf6f/empty.db)
### Possible fixes
From a quick glance, the problem centers around `DUP_LIFETIME` defined in `lib/isccc/cc.c` and in the inefficiency of `isccc_cc_cleansymtab()` and it's use.https://gitlab.isc.org/isc-projects/bind9/-/issues/3699Hang on shutdown in the "tcp" system test2023-08-07T09:16:17ZMichał KępieńHang on shutdown in the "tcp" system testThe `tcp` system test fails fairly often as it puts quite a bit of
strain on the test host, so this [job][1] might not *have* to be a hang,
but the backtrace seems to be a match:
```
D:tcp:#0 0x00007f1ce8f765be in pthread_barrier_wait ...The `tcp` system test fails fairly often as it puts quite a bit of
strain on the test host, so this [job][1] might not *have* to be a hang,
but the backtrace seems to be a match:
```
D:tcp:#0 0x00007f1ce8f765be in pthread_barrier_wait () from /lib64/libpthread.so.0
D:tcp:[Current thread is 1 (Thread 0x7f1cecac22c0 (LWP 22507))]
D:tcp:#0 0x00007f1ce8f765be in pthread_barrier_wait () from /lib64/libpthread.so.0
D:tcp:#1 0x00007f1cea0aca7d in uv_barrier_wait () from /lib64/libuv.so.1
D:tcp:#2 0x00007f1cec14c414 in isc__nm_async_tcpdnsstop (worker=worker@entry=0x7f1ce5276000, ev0=ev0@entry=0x7f1ce4b7d800) at netmgr/tcpdns.c:670
D:tcp:#3 0x00007f1cec146a92 in process_netievent (arg=0x7f1ce4b7d800) at netmgr/netmgr.c:463
D:tcp:#4 0x00007f1cec146db3 in isc__nm_process_ievent (worker=<optimized out>, event=<optimized out>) at netmgr/netmgr.c:567
D:tcp:#5 0x00007f1cec14b585 in stop_tcpdns_child (sock=sock@entry=0x7f1ce53eac00, tid=tid@entry=0) at netmgr/tcpdns.c:605
D:tcp:#6 0x00007f1cec14bed4 in isc__nm_tcpdns_stoplistening (sock=0x7f1ce53eac00) at netmgr/tcpdns.c:632
D:tcp:#7 0x00007f1cec143356 in isc_nm_stoplistening (sock=<optimized out>) at netmgr/netmgr.c:2091
D:tcp:#8 0x00007f1cebae0559 in ns_interface_shutdown (ifp=ifp@entry=0x7f1ce528a500) at interfacemgr.c:742
D:tcp:#9 0x00007f1cebae08d9 in purge_old_interfaces (mgr=mgr@entry=0x7f1ce53d3460) at interfacemgr.c:828
D:tcp:#10 0x00007f1cebae0b8b in ns_interfacemgr_shutdown (mgr=0x7f1ce53d3460) at interfacemgr.c:447
D:tcp:#11 0x000000000044288a in shutdown_server (task=<optimized out>, event=<optimized out>) at server.c:10124
D:tcp:#12 0x00007f1cec178944 in task_run (task=<optimized out>, task@entry=0x7f1ce5225e80) at task.c:470
D:tcp:#13 0x00007f1cec178a85 in task__run (arg=0x7f1ce5225e80) at task.c:287
D:tcp:#14 0x00007f1cec160bf4 in isc__job_cb (idle=0x7f1ce52236c8) at job.c:75
D:tcp:#15 0x00007f1cea0a6a49 in uv.run_idle () from /lib64/libuv.so.1
D:tcp:#16 0x00007f1cea09fbf8 in uv_run () from /lib64/libuv.so.1
D:tcp:#17 0x00007f1cec166d31 in loop_run (loop=0x7f1ce52a1e40) at loop.c:270
D:tcp:#18 loop_thread (arg=0x7f1ce52a1e40) at loop.c:297
D:tcp:#19 0x00007f1cec167dd3 in isc_loopmgr_run (loopmgr=0x7f1ce5223540) at loop.c:477
D:tcp:#20 0x00000000004238e0 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1545
```
I do not recall seeing this particular backtrace before, so I assumed it
makes sense to at least retain job artifacts and have this problem
catalogued as a GitLab issue.
Perhaps a total red herring, but `isc__nm_async_tcpdnsstop()` is also
present in the backtrace for one of the threads in a failed unit test
job reported [elsewhere][2], which also happened on Oracle Linux 8.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2935216
[2]: https://gitlab.isc.org/isc-projects/bind9/-/issues/3642Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3704nsupdate prints confusing error message when answer has RCODE=REFUSED2022-11-29T09:25:03ZPetr Špačekpspacek@isc.orgnsupdate prints confusing error message when answer has RCODE=REFUSEDThis is follow-up from [discussion](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/442#note_328521):
`nsupdate` says `Communication with 10.53.0.1#5300 failed: REFUSED` rather than `status: REFUSED`. This is somewhat confusin...This is follow-up from [discussion](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/442#note_328521):
`nsupdate` says `Communication with 10.53.0.1#5300 failed: REFUSED` rather than `status: REFUSED`. This is somewhat confusing because the communication went okay (we have sent & received the answer from server) and the server indeed sent RCODE=REFUSED.https://gitlab.isc.org/isc-projects/bind9/-/issues/3705automated test for statistics channel versioning2022-11-29T13:34:00ZPetr Špačekpspacek@isc.orgautomated test for statistics channel versioningWe should have a test for statistics channel. I envision that the test should at least detect:
- [ ] new fields - minor version bump in in order
- [ ] removed fields
- [ ] value type changes? (e.g. int to float)
It would be much easier...We should have a test for statistics channel. I envision that the test should at least detect:
- [ ] new fields - minor version bump in in order
- [ ] removed fields
- [ ] value type changes? (e.g. int to float)
It would be much easier to do if we had a way to export ALL counters, including all zero-value counters, from stats channel. As far as I can tell from the main branch 532615baf868c2cef926f1494199fd9c0153064b it is not the case.https://gitlab.isc.org/isc-projects/bind9/-/issues/3729Drop RHEL/CentOS 7 support after 30. June 20242023-03-14T16:11:32ZOndřej SurýDrop RHEL/CentOS 7 support after 30. June 2024RHEL/CentOS 7 Maitentance Phase 2 ends on 30. June 2024. As BIND 9.20 will be released in Q.I 2024, there's little point in supporting RHEL/CentOS/Oracle/RockyLinux/... 7 in BIND 9.19 now. We should also drop the support for RHEL-and-c...RHEL/CentOS 7 Maitentance Phase 2 ends on 30. June 2024. As BIND 9.20 will be released in Q.I 2024, there's little point in supporting RHEL/CentOS/Oracle/RockyLinux/... 7 in BIND 9.19 now. We should also drop the support for RHEL-and-clones 7 support after 30. June 2024 in BIND 9.18.
- Phase I - drop EL7 support in 9.19+
- [x] Drop EL7 jobs from GitLab CI for `main` (https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7346)
- [x] Remove EL7 bind-dev RPM builds from Cloudsmith pipeline (https://gitlab.isc.org/isc-private/rpms/bind/-/merge_requests/19)
- [x] Remove EL7 buildroot from [isc/bind-dev](https://copr.fedorainfracloud.org/coprs/isc/bind-dev/) COPR
- [x] Update installation instructions on `isc/bind-dev` COPR so that they do not include EL7-specific bits
- [ ] [Remove](https://help.cloudsmith.io/docs/delete-a-package#bulk-package-delete) old 9.19 EL7 packages from bind-dev Cloudsmith repo (after a few months)
- Phase II - drop EL7 support in 9.18 (after EOL - 2024-06-30)
- [ ] Drop EL7 jobs from GitLab CI for `v9_18`
- [ ] Drop EL7-specific parts from all Packer image recipes
- [ ] Drop EL7 support from the `packager:rpm` Docker image
- [ ] Drop EL7-specific parts from BIND RPM build&test scripts
- [ ] Remove EL7 buildroots from COPR
- [ ] Update installation instructions on COPR so that they do not include EL7-specific bits
- [ ] Remove EL7 from CI images build scripts ([Docker](https://gitlab.isc.org/isc-projects/images/-/blob/main/docker/bind9/oraclelinux-template/Dockerfile), [Packer](https://gitlab.isc.org/isc-projects/images/-/tree/main/packer/oraclelinux), ...)
- [ ] Remove all EL7 packages from Cloudsmith (after a few months); update "Due date"Michał KępieńMichał Kępień2024-06-30https://gitlab.isc.org/isc-projects/bind9/-/issues/3730rndc and stats should respond while zones are loading2023-01-06T17:17:02ZPetr Špačekpspacek@isc.orgrndc and stats should respond while zones are loading### Description
Neither RNDC or statistics channels generate responses to requests while primary zones are being loaded after startup.
### Versions tested
* ~"Affects v9.16": It kind of works for RNDC (but not stats channel), assuming ...### Description
Neither RNDC or statistics channels generate responses to requests while primary zones are being loaded after startup.
### Versions tested
* ~"Affects v9.16": It kind of works for RNDC (but not stats channel), assuming there is enough threads. `rndc` blocks mainly when `named -n1` is used.
* ~"Affects v9.18" Same as v9.16.
* ~"Affects v9.19": It does not work at all during first startup. It looks to me like a regression/fallout in recent versions.
### Request
I would expect that RNDC and stats channel can be used to monitor progress - e.g. number of zones loaded (and ideally also configured, which would be a new counter).
### Reproducer
1. Configure a large zone, say `net.`, and start named.
2. Attempt to run `rndc status` or GET on statistics channels.
3. Answer is returned only after the zone is loaded (or fails to load).
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3738Many repeated log messages about managed-keys-zone2022-12-13T14:38:25ZPetr Špačekpspacek@isc.orgMany repeated log messages about managed-keys-zone### Summary
Authoritative server excessively logs
```
managed-keys-zone: Unable to fetch DNSKEY set '.': failure
```
or
```
managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
```
### BIND version used
-...### Summary
Authoritative server excessively logs
```
managed-keys-zone: Unable to fetch DNSKEY set '.': failure
```
or
```
managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
```
### BIND version used
- ~"Affects v9.19": Intermittently reproducible, BIND 9.19.8-dev 1b2ee33.
- Not sure about older versions.
### Steps to reproduce
1. Configure server with `options { recursion no; };`
2. Do bunch of restart or `rndc reconfig` s
### What is the current *bug* behavior?
Message
```
managed-keys-zone: Unable to fetch DNSKEY set '.': failure
```
is repeated many times within the same millisecond.
Largest observed repetition is 114.
### What is the expected *correct* behavior?
First, I dunno why the auth server should even bother fetching `. DNSKEY` ...
If it is legit I would not expect it going in circles.
### Relevant configuration files
(abbreviated)
```
options {
recursion no;
listen-on {
};
listen-on-v6 {
2600::0;
};
allow-query {
"any";
};
notify no;
};
zone "net." {
type primary;
file "/usr/etc/smallnet.db";
masterfile-format text;
};
```
`smallnet.db` is an empty zone.
If `net.` zone is configured with an empty zone it complains about inability to fetch keys.
If `net.` is not configured at all it repeats log line about key being trusted.
### Relevant logs and/or screenshots
[log](/uploads/c414c9ae327b4d726fb42773db4c8f75/log)https://gitlab.isc.org/isc-projects/bind9/-/issues/3741reuse TCP/TLS connections for XFR2022-12-19T15:49:41ZPetr Špačekpspacek@isc.orgreuse TCP/TLS connections for XFR### Description
Profiling confirms we thought before: Not reusing TCP connections is a real performance drag for secondary servers which have to transfer lots of zones.
This is a profile for secondary with 100 k small zones being trans...### Description
Profiling confirms we thought before: Not reusing TCP connections is a real performance drag for secondary servers which have to transfer lots of zones.
This is a profile for secondary with 100 k small zones being transferred from the same primary:
![catz.svg](/uploads/eb13335b4753ae32439ce28d44fdd579/catz.svg)
I.e. about 1/2 of CPU time spent by `net` threads in bind(), spinning on CPU and looking for a free source port - because there's a lot of connections going on. (I did tune the OS to use 1k-64k port range before doing this test.)
Measured on v9_18_10, zone list comes via CATZ from the same primary.
### Request
Reuse TCP/TLS connections when talking to the same primary.
Please note that reusing connections for ordinary queries is very intentionally out of scope for this ticket. It causes (or at least caused) all sorts of issues with broken implementations, and I hope that reusing it for zone transfers will be better.
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3751Extend 'allow-*' options to support extended syntax that includes 'transport'...2023-11-02T17:05:06ZArtem BoldarievExtend 'allow-*' options to support extended syntax that includes 'transport' and 'port' parameters (like 'allow-transfer')While working on XoT we extended `allow-transfer` option with `port` and `transport` parameters (see !5587). As in 9.19 we support update forwarding over TLS (see !6710) and soon will support queries forwarding over TLS (see !7199 which ...While working on XoT we extended `allow-transfer` option with `port` and `transport` parameters (see !5587). As in 9.19 we support update forwarding over TLS (see !6710) and soon will support queries forwarding over TLS (see !7199 which is being worked on by @aram ), it seems that it is time to update other related options to support the extended syntax. The low-level functionality is there, it is a matter of enabling the syntax and extending the `transport-acl` system test.
We should not forget to extend these as we are improving our support for DNS transports other than UDP and TCP, as was originally intended while adding the initial support for these extra parameters.
This might end up being a "meta" issue referencing other related issues/MRs.
We should improve the documentation on that too, but that is a different matter.Not plannedArtem 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/3758Revisit BIND features to prevent the scenario where a second BIND instance is...2023-01-02T14:18:27ZCathy AlmondRevisit BIND features to prevent the scenario where a second BIND instance is running accidentallyAs discussed with Engineering, but not relating to a specific customer issue, although Support team regularly encounter sites with unintentional multiple running instances of named, so I'm tagging this one as 'Customer'.
With newer BIND...As discussed with Engineering, but not relating to a specific customer issue, although Support team regularly encounter sites with unintentional multiple running instances of named, so I'm tagging this one as 'Customer'.
With newer BIND using SO_REUSEPORT (`reuseport yes;`) there is no longer anything to stop multiple instances of running named from listening on the same sockets - the kernel will distribute incoming queries to the listening threads/processes per however the kernel and NICs implement and support rx-flow-hash.
This could be seen as a 'feature' by some. But for others, it allows accidental launching of multiple instances of named, and then much confusion and pain troubleshooting ensuing problems, if, for example, the intent was to restart named with a different version or different configuration. Having different instances fielding different queries could produce different outcomes!
This new behaviour (mostly) negates this change, introduced in BIND 9.11.0:
4022. [func] Stop multiple spawns of named by limiting number of
processes to 1. This is done by using a lockfile and
checking whether we can listen on any configured
TCP interfaces. [RT #37908]
Of significance is that with the introduction of reuseport, the TCP listen check will now no longer work, and that lock-file is not enabled by default.
```
lock-file
This is the pathname of a file on which named attempts to acquire a file lock when starting for the first time; if
unsuccessful, the server terminates, under the assumption that another server is already running. If not specified,
the default is none.
Specifying lock-file none disables the use of a lock file. lock-file is ignored if named was run using the
-X option, which overrides it. Changes to lock-file are ignored if named is being reloaded or reconfigured;
it is only effective when the server is first started.
```
This is distinct from pid-file, whose purpose is to identify the pid of the running named instance, so that signals can be sent to it:
```
pid-file
This is the pathname of the file the server writes its process ID in. If not specified, the default is /var/run/
named/named.pid. The PID file is used by programs that send signals to the running name server. Specifying
pid-file none disables the use of a PID file; no file is written and any existing one is removed. Note that
none is a keyword, not a filename, and therefore is not enclosed in double quotes.
```
---
What to do? I'm not sure - I think this is a 'gotcha' rather than a bug at this point, but I think it's so subtle that it has the potential to derail the unwary who aren't aware that it could happen. Should we perhaps change the default for the existence of the lock-file?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3763rndc documentation misses a feature; rndc-confgen still uses md52023-01-05T21:28:34ZTimothe Littrndc documentation misses a feature; rndc-confgen still uses md5The code is (mostly) willing, but the documentation is weak :-(
I finally noticed that the rndc [documentation](https://bind9.readthedocs.io/en/v9_18_10/manpages.html#rndc-conf-rndc-configuration-file) describes rndc.conf as
> "has a si...The code is (mostly) willing, but the documentation is weak :-(
I finally noticed that the rndc [documentation](https://bind9.readthedocs.io/en/v9_18_10/manpages.html#rndc-conf-rndc-configuration-file) describes rndc.conf as
> "has a similar structure and syntax to `named.conf`".
This is true, but omits a valuable feature:
`include` works in `rndc.conf`.
It turns out that this is useful if you ever need (or want) to rotate keys, since a (suitably protected) .key file can be `include`d in `rndc.conf` and likewise `include`d in `named.conf`.
In any case, this structure avoids duplication of the secret key; makes updating the key simpler, and allows `rndc.conf` to have read permissions - thus making the `options` clause visible, which may be desirable. It also means that if you use unique keys for more than one `named` instance, you can simply move the key file to your management stations, but retain the default-server without editing each station's `rndc.conf`.
For example:
```sh
named.conf
# Define the rndc control key
include "rndc.key";
cat >/etc/named/rndc.conf
include "rndc.key";
options {
default-server: 2001:0db8::53;
default-port: 953;
};
# Now, updating and initial key creation becomes simply:
touch /etc/named/rndc.key
chmod 600 /etc/named/rndc.key
tsig-keygen -a sha256 rndc-key >/etc/named/rndc.key
rndc reconfig
```
No more copying the `key` clause into both files, or including in `named.conf` but copying into `rndc.conf`.
For extra credit - `rndc-confgen` should probably produce this structure, since it's better than the current suggestions.
`rndc-confgen` should definitely be updated to default to SHA256 rather than MD5, since MD5 is deprecated and the documentation says (under the `key` statment) that SHA256 is now the default...
Happy New Year.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3775update-policy documentation confuses2023-01-09T11:29:01ZTimothe Littupdate-policy documentation confusesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3776update-policy wildcard match limitations2023-01-09T11:30:12ZTimothe Littupdate-policy wildcard match limitations[The `wildcard` match documentation](https://bind9.readthedocs.io/en/v9_18_10/reference.html#dynamic-update-policies) reads
> The name field is subject to **DNS wildcard expansion**, and this rule matches when the name being updated is ...[The `wildcard` match documentation](https://bind9.readthedocs.io/en/v9_18_10/reference.html#dynamic-update-policies) reads
> The name field is subject to **DNS wildcard expansion**, and this rule matches when the name being updated is a valid expansion of the wildcard.
It would be useful to have a more flexible wildcard match for the update-policy's grant/deny wildcard names.
An example that would help many of us (who use Let's Encrypt) is
`_acme-challenge.*.example.net`, as in
```
grant "CERTIFICATE_ISSUE_BOT" name _acme-challenge.*.example.net. TXT ;
```
Since DNS wildcards only work for the leftmost label, this can't be expressed with the current syntax.
As a result, when a server is added, not only must the A/AAAA records be added (which can be done with UPDATE), but a `grant` clause must be added to the configuration (which can not).
Or allow the BOT to handle all TXT records in the domain. I'm pretty sure I don't want a bot to be able to mess up SPF, google console, and other TXT records...
There are other cases where a generic glob match would be helpful, but most of them can be worked-around by suitable naming and/or introducing a subdomain. Unfortunately, that's not the case for ACME, which requires this structure for the records it uses for `dns-01` validation.
This is NOT asking for changes to how queries are resolved. That ship sailed (to where there be dragons) long ago. Just how `update-policy` clauses are matched. `update-policy` is internal to bind, and the suggested change would be upward-compatible.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3779catalog zone grammar does not enforce default-primaries key / should we suppo...2023-03-16T08:59:16ZPetr Špačekpspacek@isc.orgcatalog zone grammar does not enforce default-primaries key / should we support primary zones in catalog?### Summary
Catalog zones grammar in named.conf does not enforce/require `default-primaries` key. This can be either bug, or an opportunity to extend the feature in an meaningful way.
### BIND version used
* ~"Affects v9.16": d14a22b3...### Summary
Catalog zones grammar in named.conf does not enforce/require `default-primaries` key. This can be either bug, or an opportunity to extend the feature in an meaningful way.
### BIND version used
* ~"Affects v9.16": d14a22b3d9fa8e8bb21dfe3bb0bca216a5b93910
* ~"Affects v9.18": f5e7192691568d4c089fbdd4ed4e93c7af785bae
* ~"Affects v9.19": 0e489b9ed4ba7821c50038dade014bf2b706bd12
### Steps to reproduce
1. Define catalog zone **without** `default-primaries` key. E.g.
```
catalog-zones {
zone "catalog.invalid"
//default-masters { 127.0.0.2; }
in-memory no
zone-directory "catzones"
min-update-interval 1;
};
```
2a. Start **with** matching files on disk
2b. Start **without** matching files on disk
### What is the current *bug* behavior?
The config is accepted by parser but causes surprising behavior later on.
Variant 2A:
The zone is on disk under correct name, and it loads just fine when the file is available in `catzones` directory. `rndc zonestatus` then reports:
```
name: .
type: secondary
files: catzones/__catz___default_catalog.invalid_..db
serial: 2023010600
nodes: 8438
last loaded: Fri, 06 Jan 2023 16:03:08 GMT
next refresh: Fri, 06 Jan 2023 16:12:19 GMT
expires: Fri, 13 Jan 2023 16:03:08 GMT
secure: yes
inline signing: no
key maintenance: none
dynamic: no
reconfigurable via modzone: yes
```
Next time refresh timer hits it errors out with
```
zone ./IN: cannot refresh: no primaries
```
but continues serving the zone until it expires. Kind of works, but not so much because it can never refresh and is bound to expire eventually.
Variant 2B:
File is not on disk. It fails to load as expected, and logs
```
zone ./IN: cannot refresh: no primaries
```
immediately.
### Possible fixes
I can see two options:
a) Require the `default-primaries` and error out if it is not present. That would be the same as for regular secondary zones, I believe.
b) Make this behavior "supported", probably by switching zone type to "primary" in case there is no `default-primaries` defined for the respective catalog. (In that case `in-memory` must be configured as `no`.)
Personally I think it makes sense to do b) because it eliminates need to have two different per-zone config management procedures for primaries.
I mean - with "strict" variant adding a new primary zone always requires `rndc addzone` + catalog zone modification on the primary side.
With less strict variant `rndc addzone` is not necessary and the whole state is in the catalog zone, which is has to be maintained for secondaries anyway.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3786DNS Broker - Refactor the outgoing DNS connection handling2023-11-02T17:05:06ZOndřej SurýDNS Broker - Refactor the outgoing DNS connection handlingThis is a meta-issue for refactoring the `dns_dispatch`, `dns_request` and `dns_resolver` to use hypothetical new unit `dns_broker` that will transparently handle the outgoing DNS connection handling including streaming DNS connection re...This is a meta-issue for refactoring the `dns_dispatch`, `dns_request` and `dns_resolver` to use hypothetical new unit `dns_broker` that will transparently handle the outgoing DNS connection handling including streaming DNS connection reuse.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3792incoming AXFR sometimes does not close TCP connection2024-02-24T07:53:11ZPetr Špačekpspacek@isc.orgincoming AXFR sometimes does not close TCP connection### Summary
I've noticed in PCAPs that sometimes BIND does not close TCP connection after successful incoming AXFR. This might cause source port depletion on a busy server.
### BIND version used
* ~"Affects v9.19": 9.19.9 56d7e01
* No...### Summary
I've noticed in PCAPs that sometimes BIND does not close TCP connection after successful incoming AXFR. This might cause source port depletion on a busy server.
### BIND version used
* ~"Affects v9.19": 9.19.9 56d7e01
* Not reproducible on ~"v9.18" (9.18.11 equivalent, b04ab06) - albeit closing the connection can take more than one second, it happens from the secondary side as expected
* ~"Affects v9.16": (9.16.37, b4a65aaea19762a3712932aa2270e8a833fbde22) - reproducible
Don't ask me how is that possible ...
### Steps to reproduce
1. Configure primary with 100k zones + catalog - can be BIND or Knot DNS (recommended to take BIND out of equation on one side)
2. Configure BIND as secondary for the catalog
3. Start secondary with clean state
### What is the current *bug* behavior?
PCAPs show that sometimes the primary closes hanging connection after primary-side timeout.
### What is the expected *correct* behavior?
Connections are closed as soon as possible.
### Relevant configuration files
#### Primary
* [named.conf](/uploads/863bf85788384d2e4893ea94cc606c89/named.conf)
* [catalog.db](/uploads/c515216922d648acf6065f7a50b36233/catalog.db)
* [empty.db](/uploads/5686c122ffb6fd4eb035bc1b88931e0f/empty.db)
Knot DNS version: [knotd.conf](/uploads/e59561f0b1f2047d348a51303d5a2119/knotd.conf)
#### Secondary
* [named.conf](/uploads/984a16e8322400cc6465b14ca45710ef/named.conf)
### Relevant logs and/or screenshots
* Primary: [primary.log.zst](/uploads/e50efe9e008cd762b3a671245e207b7d/primary.log.zst)
* Secondary: [secondary-for-knotd-conf3000.log.zst](/uploads/e8732553815f19ebf3b483629afd6279/secondary-for-knotd-conf3000.log.zst)
* search for `z19823.test` and look at timestamps
* PCAP: [bindconf3000.pcap.zst](/uploads/86b89c9ddc6d4e1c6066cfd1a997c25b/bindconf3000.pcap.zst)
* search for `tcp.stream eq 37322` in Wireshark to get `z19823.test` transfer
Suspicious conversation from the PCAP, times relative to the previous packet:
|No. | Time | Source | Source Port | Destination | Reply code | Info|
|--- | --- | --- | --- | --- | --- | ---|
|484345 | 0 | 192.0.2.2 | 40571 | 192.0.2.1 | | 40571 → 53 [SYN] Seq=0 Win=64660 Len=0 MSS=1220 SACK_PERM TSval=3661096036 TSecr=0 WS=128|
|484346 | 0,000027 | 192.0.2.1 | 53 | 192.0.2.2 | | 53 → 40571 [SYN, ACK] Seq=0 Ack=1 Win=65232 Len=0 MSS=1220 SACK_PERM TSval=1123290483 TSecr=3661096036 WS=128|
|484347 | 0,000008 | 192.0.2.2 | 40571 | 192.0.2.1 | | 40571 → 53 [ACK] Seq=1 Ack=1 Win=64768 Len=0 TSval=3661096036 TSecr=1123290483|
|511718 | 1,98078 | 192.0.2.2 | 40571 | 192.0.2.1 | | Standard query 0x47aa AXFR z19823.test|
|511719 | 0,000019 | 192.0.2.1 | 53 | 192.0.2.2 | | 53 → 40571 [ACK] Seq=1 Ack=32 Win=65280 Len=0 TSval=1123292464 TSecr=3661098017|
|511724 | 0,000107 | 192.0.2.1 | 53 | 192.0.2.2 | No error | Standard query response 0x47aa AXFR z19823.test SOA <Root> NS invalid SOA <Root>|
|511726 | 0,000009 | 192.0.2.2 | 40571 | 192.0.2.1 | | 40571 → 53 [ACK] Seq=32 Ack=121 Win=64768 Len=0 TSval=3661098017 TSecr=1123292464|
|601979 | 9,49634 | 192.0.2.1 | 53 | 192.0.2.2 | | 53 → 40571 [FIN, ACK] Seq=121 Ack=32 Win=65280 Len=0 TSval=1123301960 TSecr=3661098017|
|602469 | 0,040942 | 192.0.2.2 | 40571 | 192.0.2.1 | | 40571 → 53 [ACK] Seq=32 Ack=122 Win=64768 Len=0 TSval=3661107554 TSecr=1123301960|
|621475 | 1,959518 | 192.0.2.2 | 40571 | 192.0.2.1 | | 40571 → 53 [FIN, ACK] Seq=32 Ack=122 Win=64768 Len=0 TSval=3661109514 TSecr=1123301960|
|621476 | 0,000019 | 192.0.2.1 | 53 | 192.0.2.2 | | 53 → 40571 [ACK] Seq=122 Ack=33 Win=65280 Len=0 TSval=1123303961 TSecr=3661109514|
### Possible fixesMay 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/3794Dispatch code intermittently reports "response doesn't match" during the "rec...2023-02-23T10:23:56ZMichał KępieńDispatch code intermittently reports "response doesn't match" during the "reclimit" system testhttps://gitlab.isc.org/isc-private/bind9/-/jobs/3068391
```
S:reclimit:2023-01-13T13:29:59+0000
T:reclimit:1:A
A:reclimit:System test reclimit
I:reclimit:PORTS:12586,12587,12588,12589,12590,12591,12592,12593,12594,12595,12596,12597,1259...https://gitlab.isc.org/isc-private/bind9/-/jobs/3068391
```
S:reclimit:2023-01-13T13:29:59+0000
T:reclimit:1:A
A:reclimit:System test reclimit
I:reclimit:PORTS:12586,12587,12588,12589,12590,12591,12592,12593,12594,12595,12596,12597,12598
I:reclimit:starting servers
I:reclimit:set max-recursion-depth=12
I:reclimit:attempt excessive-depth lookup (1)
I:reclimit:attempt permissible lookup (2)
I:reclimit:set max-recursion-depth=5
I:reclimit:attempt excessive-depth lookup (3)
I:reclimit:attempt permissible lookup (4)
I:reclimit:set max-recursion-depth=100, max-recursion-queries=50
I:reclimit:attempt excessive-queries lookup (5)
I:reclimit:attempt permissible lookup (6)
I:reclimit:failed
I:reclimit:set max-recursion-depth=100, max-recursion-queries=40
I:reclimit:attempt excessive-queries lookup (7)
I:reclimit:attempt permissible lookup (8)
I:reclimit:attempting NS explosion (9)
I:reclimit:exit status: 1
I:reclimit:stopping servers
R:reclimit:FAIL
E:reclimit:2023-01-13T13:30:05+0000
```
The reason for the test failure is that one of the "intermediate"
queries sent by `ns3` to `ans4` (`ns1.1.example.org/A`) got a response
that the dispatch code did not like, necessitating a requery, which in
turn caused the `max-recursion-queries` limit to be exceeded for the
`indirect6.example.org/A` query, causing the test to fail.
The interesting part is *why* the dispatch code did not like the
response that the `ans4` "server" sent. Here are the relevant log
excerpts:
```
13-Jan-2023 13:30:02.298 sending packet to 10.53.0.4#12586
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57016
;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1.1.example.org. IN A
13-Jan-2023 13:30:02.298 dispatch 0x7f55202f6400: UDP response 0x7f5508de0800: sending
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: connected: success
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: attaching handle 0x7f5508a05980 to 0x7f5508ce4a18
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: reading
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: connect callback: success
13-Jan-2023 13:30:02.298 sending packet to 10.53.0.4#12586
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56518
;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1.1.example.org. IN AAAA
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: sending
13-Jan-2023 13:30:02.298 dispatch 0x7f55202f6400: UDP response 0x7f5508de0800: sent: success
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: sent: success
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: read callback:success, requests 1
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: got valid DNS message header, /QR 1, id 57016
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: response doesn't match
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: continue reading
```
The relevant piece of code is:
```c
594 /*
595 * The QID and the address must match the expected ones.
596 */
597 if (resp->id != id || !isc_sockaddr_equal(&peer, &resp->peer)) {
598 dispentry_log(resp, LVL(90), "response doesn't match");
599 inc_stats(disp->mgr, dns_resstatscounter_mismatch);
600 goto next;
601 }
```
Given the `got valid DNS message header` log message with the expected
ID, it seems that `isc_sockaddr_equal(&peer, &resp->peer)` must have
returned `false`. I do not know why that happened because I do not have
a PCAP file containing the traffic exchanged between the servers in
question.
This only happens intermittently, so for now I am merely opening this
issue to record it and make others aware of it. My gut feeling is that
there is no way to figure out what happened here without a PCAP file or
improved dispatch debugging, but I would love to be proved wrong :-)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3803Delayed zone deletion2023-01-17T07:51:26ZOndřej SurýDelayed zone deletionWhen zones are removed from the configuration, the process to release the memory held by the deleted zones could take even minute or more if the server is busy.
This has been (partially?) fixed in `main` which doesn't exhibit the behavi...When zones are removed from the configuration, the process to release the memory held by the deleted zones could take even minute or more if the server is busy.
This has been (partially?) fixed in `main` which doesn't exhibit the behaviour, but it's true for 9.16 and 9.18. This can be reproduced by doing something like this:
1. add zone <n+1> to `zones.conf`
2. del zone <n> to `zones.conf`
3. run `rndc reconfig`
4. repeat
It's now roughly at `dom170883.example` and the server consumes 3.2GB of memory.
This is not normal mode of operation, but in the environment that provides short-lived domains for containers, it's very much plausible.
I've had a `jeprof` output with symbols, but alas, I've deleted the binary, so you need to trust me that the 99% is all `dns_zone_create()`:
![Screenshot_2023-01-17_at_8.50.40](/uploads/afa578c916aceda4ae64e73a25466e2e/Screenshot_2023-01-17_at_8.50.40.png)https://gitlab.isc.org/isc-projects/bind9/-/issues/3809zones deleted during asyncload are never freed2023-01-18T16:02:17ZOndřej Surýzones deleted during asyncload are never freedZones that are deleted during the asyncload go into spiral:
```
dns_zone_create:::0:0x7f4c0b3c4e00->irefs = 0
zone_iattach:asyncload:zt.c:370:0x7f4c0b3c4e00->irefs = 2
dns_zone__idetach:zone_asyncload:zone.c:2423:0x7f4c0b3c4e00->irefs =...Zones that are deleted during the asyncload go into spiral:
```
dns_zone_create:::0:0x7f4c0b3c4e00->irefs = 0
zone_iattach:asyncload:zt.c:370:0x7f4c0b3c4e00->irefs = 2
dns_zone__idetach:zone_asyncload:zone.c:2423:0x7f4c0b3c4e00->irefs = 1
[...13k...]
zone_iattach:asyncload:zt.c:370:0x7f4c0b3c4e00->irefs = 2
dns_zone__idetach:zone_asyncload:zone.c:2423:0x7f4c0b3c4e00->irefs = 1
[...continues...]
```https://gitlab.isc.org/isc-projects/bind9/-/issues/3810Replace system test runner with pytest2024-02-29T15:26:01ZTom KrizekReplace system test runner with pytestThe legacy solution for running systems test has evolved over the course of years and is currently a mix of shell & perl scripts intermingled with the build system, while some of the system tests utilize pytest. Implementing a more consi...The legacy solution for running systems test has evolved over the course of years and is currently a mix of shell & perl scripts intermingled with the build system, while some of the system tests utilize pytest. Implementing a more consistent solution using just pytest as a runner could bring following benefits:
- better test run isolation (i.e. artifacts from previous run don't interfere with current test run)
- more precise control over test selection (running just a single test case)
- getting rid of perl+shell glue scripts
- a simpler and more standard way to run and parallelize test runs
- solid foundation for future extensions (e.g. wrapping test execution inside a network/pid namespace)
For a transitory period of time, the legacy test framework should be supported, since it'd be difficult to replace everything at once. The pytest runner should be available in 9.18+, it'd be prudent to keep the legacy runner support until 9.16 reaches EOL. By that time, we should have enough insight to determine whether pytest proves to be a suitable replacement and throw away the legacy runner from supported branches at that point.
Migration plan for moving to pytest runner and dropping the legacy runner support:
- Phase I - pytest runner development, legacy runner supported
- [x] initial implementation of the pytest runner (#3978, !6809)
- [x] support out-of-tree tests (#4246)
- [x] resolve support on CI systems with old pytest (OpenBSD, CentOS 7) (!8193)
- [x] implement any missing (and desired) features from legacy runner (#4252)
- [x] configure `make check` to invoke pytest (#4262)
- Phase II - deprecating legacy runner - 9.19-only
- [ ] remove legacy runner control script(s) - legacy.run.sh, get_ports.sh ...
- [ ] remove no longer needed scripts from system tests (e.g. clean.sh)
- [ ] remove conf.sh(.common) and declare variables in pytest only
- [ ] remove the Makefile entanglement
- [ ] declare python and pytest-xdist as required dependencies for tests + document
- [ ] address any `FUTURE` comments in the pytest runner code
- Phase III - cleanup after legacy runner
- [ ] rewrite start.pl/stop.pl to python (related https://gitlab.isc.org/isc-projects/bind9/-/issues/3198)
- [ ] rewrite remaining setup/teardown perl&shell scripts to python
- [ ] rewrite setup.sh/prereq.sh system tests scripts to pytest fixtures
- [ ] ensure system test documentation is up to dateBIND 9.19.xTom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3811Lock contention in the RBTDB2023-11-02T17:03:41ZOndřej SurýLock contention in the RBTDB@pspacek discovered a lock contention of the RBTDB nodelocks in the `rdataset_getownercase()` and `decrement_reference()` functions.@pspacek discovered a lock contention of the RBTDB nodelocks in the `rdataset_getownercase()` and `decrement_reference()` functions.Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3812You can't just destroy created managers2023-02-28T14:24:43ZMark AndrewsYou can't just destroy created managersThe following sequence fails which makes error handling difficult.
```
isc_managers_create(&mctx, isc_os_ncpus(), &loopmgr, &netmgr, &taskmgr);
isc_managers_destroy(&mctx, &loopmgr, &netmgr, &taskmgr);
```The following sequence fails which makes error handling difficult.
```
isc_managers_create(&mctx, isc_os_ncpus(), &loopmgr, &netmgr, &taskmgr);
isc_managers_destroy(&mctx, &loopmgr, &netmgr, &taskmgr);
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3813Duplicate key IDs across algorithms are not handled correctly.2023-09-11T16:19:33ZMark AndrewsDuplicate key IDs across algorithms are not handled correctly.Job [#3089156](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3089156) failed for e706fb81ca2f46f893bc96216544b73a16022884:
```
I:nsec3:check number of keys for zone nsec3-to-rsasha1.kasp in dir ns3 (103)
I:nsec3:check key id 08113
I:...Job [#3089156](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3089156) failed for e706fb81ca2f46f893bc96216544b73a16022884:
```
I:nsec3:check number of keys for zone nsec3-to-rsasha1.kasp in dir ns3 (103)
I:nsec3:check key id 08113
I:nsec3:check key id 08113
I:nsec3:KEY1 ID 8113
I:nsec3:KEY2 ID 8113
I:nsec3:error: bad DNSKEY RRset for zone nsec3-to-rsasha1.kasp
I:nsec3:failed
```
```
% ls ns3/*nsec3-to-rsasha1.kasp*
ns3/Knsec3-to-rsasha1.kasp.+005+08113.key ns3/Knsec3-to-rsasha1.kasp.+013+08113.private ns3/nsec3-to-rsasha1.kasp.db.signed
ns3/Knsec3-to-rsasha1.kasp.+005+08113.private ns3/Knsec3-to-rsasha1.kasp.+013+08113.state ns3/nsec3-to-rsasha1.kasp.db.signed.jnl
ns3/Knsec3-to-rsasha1.kasp.+005+08113.state ns3/nsec3-to-rsasha1.kasp.db
ns3/Knsec3-to-rsasha1.kasp.+013+08113.key ns3/nsec3-to-rsasha1.kasp.db.jbk
%
```
```
% more *103
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50279
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: b4e1d78c34d15ba70100000063c9e02dac6c36fa7c841c69 (good)
;; QUESTION SECTION:
;nsec3-to-rsasha1.kasp. IN DNSKEY
;; ANSWER SECTION:
nsec3-to-rsasha1.kasp. 3600 IN DNSKEY 257 3 5 AwEAAawagVzMn34eS6HLSz9abmIkj9l1migiobJkbGX2CoDqh+xaQ5mI UIPmS6AUMqKEsPL5hH0YWkD4qRKLe9HtC8e73mqpZBYmd5KhEsvPPSaB Za17TRTlTSpfJpE3XTL5LCUIxDBpgfz/NNLNChIMTLM4hKLnVoWhvz13 3Q9Xvma+wpb7l1OZVEf0kDxapvJo2Hug941E7OxNuGI8h0QmE5XA9Pxj c+BpIbx01U5iwKK47q0Zh57El7E86wxgzw+hBdE0sK/tJPFFA0WwvPl8 zY/MzyNunDiOUG9PdmB2hWszDAVzlUXheHv4/Glf/bK8JTYBeuA8zxe7 i8OlSwvST60=
nsec3-to-rsasha1.kasp. 3600 IN RRSIG DNSKEY 5 2 3600 20230203002817 20230119232817 8113 nsec3-to-rsasha1.kasp. DhIH5wi/8VCZ3WEr+R4B1NGvOD7U1UKUZQPQCg+xWAxmldsNAMhCdvTu eJpg4WryFyrmlZcbfzHEMv29tqpUMn+azZORdjX9VI0unBzElwfIAdn1 6Dapbq8n4CuBm3CsDM5plxVj/EUnJET/PKacyimC8CfuwqRlxDoxesuF ohY2Xt01NUqHp9ETrOJkPdd+hiL45j1YcrPYPWCpCFrpHVhMbnOpXajq UqQw5WgH0P2O/vPEwaqSVjgUtdQqguv/ebQAZ4C7N7zxQa9gv+Y7YEJa OJl0IMmmJt4FMuqAytvdSsZjz1QslYWXCkiAEVIxmsd2x7kDB44s6ml/ yApNxw==
%
```Not plannedMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3818Use asynchronous load and dump IO in named-checkzone, dnssec-signzone and pos...2023-01-23T11:37:07ZOndřej SurýUse asynchronous load and dump IO in named-checkzone, dnssec-signzone and possibly othersCurrently, in main, sending the SIGINT does nothing if the zone is loading or dumping because we run that on the main thread.
We need to switch to use asynchronous IO and then use `dns_loadctx_cancel()` and `dns_dumpctx_cancel()` when S...Currently, in main, sending the SIGINT does nothing if the zone is loading or dumping because we run that on the main thread.
We need to switch to use asynchronous IO and then use `dns_loadctx_cancel()` and `dns_dumpctx_cancel()` when SIGINT is received, so we can properly interrupt the zone loading and dumping.
This applies to all utilities that can load and dump zones, notably `named-checkzone` and `dnssec-signzone`.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3819hang in rndc dumpdb caused cookie system test failure.2023-11-02T17:03:41ZEvan Hunthang in rndc dumpdb caused cookie system test failure.There was an unexplained test failure in !7365 that doesn't seem to be related to the change: https://gitlab.isc.org/isc-projects/bind9/-/jobs/3094528
The test timed out while waiting for `rndc dumpdb` to complete. In `named.run`, it sa...There was an unexplained test failure in !7365 that doesn't seem to be related to the change: https://gitlab.isc.org/isc-projects/bind9/-/jobs/3094528
The test timed out while waiting for `rndc dumpdb` to complete. In `named.run`, it says:
```
23-Jan-2023 12:55:02.255 received control channel command 'dumpdb'
23-Jan-2023 12:55:02.255 dumpdb started
23-Jan-2023 12:55:02.259 freeing control connection
23-Jan-2023 12:55:08.491 expiring v4 for name 0x7f47adc6c400
23-Jan-2023 12:55:22.551 dumpdb complete
```
This suggests that the `dumpdb` completed, but it took 20 seconds, and the `rndc_dumpdb()` function in `conf.sh.common` only waits for five. I don't know whether that ADB namehook expiring is related or not.Not plannedhttps://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/3843Remove options allowing source ports to be specified2024-01-31T08:53:45ZMichał KępieńRemove options allowing source ports to be specifiedWith the options allowing source ports to be specified being deprecated
in 9.18 & 9.19/9.20, all the code associated with those options should
subsequently be completely removed in the 9.21/9.22 cycle, as previously
announced on *bind-us...With the options allowing source ports to be specified being deprecated
in 9.18 & 9.19/9.20, all the code associated with those options should
subsequently be completely removed in the 9.21/9.22 cycle, as previously
announced on *bind-users*:
https://lists.isc.org/pipermail/bind-users/2023-January/107165.html
The following features are going to be marked as ancient and made
non-functional:
* specifying `port` in the following statements:
- `query-source`
- `query-source-v6`
- `transfer-source`
- `transfer-source-v6`
- `notify-source`
- `notify-source-v6`
- `parental-source`
- `parental-source-v6`
* the following statements as a whole:
- `use-v4-udp-ports`
- `use-v6-udp-ports`
- `avoid-v4-udp-ports`
- `avoid-v6-udp-ports`
See #3781 for the corresponding option deprecation issue.Not plannedMichał KępieńMichał Kępień2024-03-01https://gitlab.isc.org/isc-projects/bind9/-/issues/3844Redesign RBTDB cache cleaning2023-10-31T11:26:25ZOndřej SurýRedesign RBTDB cache cleaningCurrent cache cleaning has two mechanisms in the RBTDB:
1. TTL-based cleaning implemented using `isc_heap` unit
2. LRU-based cleaning implemented using `isc_list` unit
### TTL-based cleaning
The TTL-based cleaning is just a priority q...Current cache cleaning has two mechanisms in the RBTDB:
1. TTL-based cleaning implemented using `isc_heap` unit
2. LRU-based cleaning implemented using `isc_list` unit
### TTL-based cleaning
The TTL-based cleaning is just a priority queue that uses TTL (`header->rdh_ttl`) to sort the nodes. There are two triggers:
#### Cleaning when adding data
This is triggered during adding new rdataset to the cache - the node is write locked, the tree is locked only when we are adding delegation type, adding to the auxiliary NSEC tree or the cache is overmem.
If we are overmem, the overmem cleaning is triggered (see below).
In all cases, we lookup the top element from the heap (with lowest TTL) and call `expire_header()` on header that has TTL (adjusted with stale-TTL) lower than now (adjusted by 5 minutes (`RBTDB_VIRTUAL`).
#### Cleaning when overmem
The overmem purge is also called when adding new data and it tries to purge at most two headers from a bucket that we are not currently in.
First, it does single TTL-based cleaning - only the `now` time is adjusted by 5 minutes (`RBTDB_VIRTUAL`) and then in goes to LRU-based cleaning.
If it doesn't find two headers in the current bucket it goes to the next bucket.
### Not-really an expire
We also "expire", but not really remove headers from `add32()` with following comment `/* The new rdataset is better. Expire the ncache entry. */`; but it only does mark header as ancient, and sets the TTL to 0 - and in one more place when `rbtversion == 0`.https://gitlab.isc.org/isc-projects/bind9/-/issues/3858Deprecate (or improve/replace) the fetches-per-zone option2023-12-19T09:21:45ZOndřej SurýDeprecate (or improve/replace) the fetches-per-zone optionThe `fetches-per-zone` is a measure to prevent abuse of the nameservers.
### How we pick a bucket?
When fetch (`fctx`) is created, the `fctx->domain` is initialized with a domain name that could be:
#### Argument passed by the called
...The `fetches-per-zone` is a measure to prevent abuse of the nameservers.
### How we pick a bucket?
When fetch (`fctx`) is created, the `fctx->domain` is initialized with a domain name that could be:
#### Argument passed by the called
`domain` passed by the caller - from `dns_adb`/`fetch_name` when `start_at_name` is set and from `ns_query`/`ns_query_recurse()`
No example here, we can (sort of) ignore this case.
#### In the forward-only mode
The `.` when we are in **forward-only** mode - there's only a single counter!
With QNAME Minimization On and Off
```
increasing counter for '.' in the '0x7fed97e3e000/www.google.com/A' to 1 (allowed 1 spilled 0)
increasing counter for '.' in the '0x7fed97a26800/com/DS' to 2 (allowed 2 spilled 0)
increasing counter for '.' in the '0x7fed97a25400/google.com/DS' to 3 (allowed 3 spilled 0)
decreasing counter for '.' in the '0x7fed97a26800/com/DS' to 2 (allowed 3 spilled 0)
increasing counter for '.' in the '0x7fed97226800/com/DNSKEY' to 3 (allowed 4 spilled 0)
decreasing counter for '.' in the '0x7fed97226800/com/DNSKEY' to 2 (allowed 4 spilled 0)
decreasing counter for '.' in the '0x7fed97a25400/google.com/DS' to 1 (allowed 4 spilled 0)
dropping counter for '.' in the '0x7fed97e3e000/www.google.com/A' to 0 (allowed 4 spilled 0)
```
#### Everything else
Whatever `dns_view_findzonecut()` returns. This includes **forward-first** configurations.
Example with QNAME minimization:
```
increasing counter for '.' in the '0x7f4b9983e000/www.google.com/A' to 1 (allowed 1 spilled 0)
increasing counter for '.' in the '0x7f4b9b81a000/_.com/A' to 2 (allowed 2 spilled 0)
decreasing counter for '.' in the '0x7f4b9b81a000/_.com/A' to 1 (allowed 2 spilled 0)
increasing counter for 'com' in the '0x7f4b9b81a000/_.com/A' to 1 (allowed 1 spilled 0)
dropping counter for 'com' in the '0x7f4b9b81a000/_.com/A' to 0 (allowed 1 spilled 0)
dropping counter for '.' in the '0x7f4b9983e000/www.google.com/A' to 0 (allowed 2 spilled 0)
increasing counter for 'com' in the '0x7f4b9983e000/www.google.com/A' to 1 (allowed 1 spilled 0)
increasing counter for 'com' in the '0x7f4b9b81a000/_.google.com/A' to 2 (allowed 2 spilled 0)
decreasing counter for 'com' in the '0x7f4b9b81a000/_.google.com/A' to 1 (allowed 2 spilled 0)
increasing counter for 'google.com' in the '0x7f4b9b81a000/_.google.com/A' to 1 (allowed 1 spilled 0)
dropping counter for 'google.com' in the '0x7f4b9b81a000/_.google.com/A' to 0 (allowed 1 spilled 0)
dropping counter for 'com' in the '0x7f4b9983e000/www.google.com/A' to 0 (allowed 2 spilled 0)
increasing counter for 'google.com' in the '0x7f4b9983e000/www.google.com/A' to 1 (allowed 1 spilled 0)
increasing counter for 'com' in the '0x7f4b9b81c800/google.com/DS' to 1 (allowed 1 spilled 0)
increasing counter for 'com' in the '0x7f4b99027800/com/DNSKEY' to 2 (allowed 2 spilled 0)
decreasing counter for 'com' in the '0x7f4b99027800/com/DNSKEY' to 1 (allowed 2 spilled 0)
dropping counter for 'com' in the '0x7f4b9b81c800/google.com/DS' to 0 (allowed 2 spilled 0)
dropping counter for 'google.com' in the '0x7f4b9983e000/www.google.com/A' to 0 (allowed 1 spilled 0)
```
Example without QNAME minimization:
```
increasing counter for '.' in the '0x7fc30803e000/www.google.com/A' to 1 (allowed 1 spilled 0)
dropping counter for '.' in the '0x7fc30803e000/www.google.com/A' to 0 (allowed 1 spilled 0)
increasing counter for 'com' in the '0x7fc30803e000/www.google.com/A' to 1 (allowed 1 spilled 0)
dropping counter for 'com' in the '0x7fc30803e000/www.google.com/A' to 0 (allowed 1 spilled 0)
increasing counter for 'com' in the '0x7fc30803e000/www.google.com/A' to 1 (allowed 1 spilled 0)
dropping counter for 'com' in the '0x7fc30803e000/www.google.com/A' to 0 (allowed 1 spilled 0)
increasing counter for 'google.com' in the '0x7fc30803e000/www.google.com/A' to 1 (allowed 1 spilled 0)
dropping counter for 'google.com' in the '0x7fc30803e000/www.google.com/A' to 0 (allowed 1 spilled 0)
increasing counter for 'google.com' in the '0x7fc30803e000/www.google.com/A' to 1 (allowed 1 spilled 0)
increasing counter for 'com' in the '0x7fc307c28c00/google.com/DS' to 1 (allowed 1 spilled 0)
increasing counter for 'com' in the '0x7fc307c27800/com/DNSKEY' to 2 (allowed 2 spilled 0)
decreasing counter for 'com' in the '0x7fc307c27800/com/DNSKEY' to 1 (allowed 2 spilled 0)
dropping counter for 'com' in the '0x7fc307c28c00/google.com/DS' to 0 (allowed 2 spilled 0)
dropping counter for 'google.com' in the '0x7fc30803e000/www.google.com/A' to 0 (allowed 1 spilled 0)
```
NOTE: The similar effect here has the `fetches-per-server` - but `fetches-per-server` is more fine-grained.BIND 9.21.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3861suspicious test results with 'reuseport no'2023-02-09T19:03:13ZPetr Špačekpspacek@isc.orgsuspicious test results with 'reuseport no'### Summary
This is suspicion, not a clear-cut bug.
### BIND version used
- ~"Affects v9.18": v9_18_11
Other versions were not tested.
### Steps to reproduce
- use 16-thread machine
- I was testing in AWS VM type c5n.4xlarge for s...### Summary
This is suspicion, not a clear-cut bug.
### BIND version used
- ~"Affects v9.18": v9_18_11
Other versions were not tested.
### Steps to reproduce
- use 16-thread machine
- I was testing in AWS VM type c5n.4xlarge for server and c5n.xlarge for client machine
- configure `reuseport no;` and "refuse everything"
- use dnsperf 2.11 [+ JSON output MR](https://github.com/pspacek/dnsperf/tree/json_output):
- `-Q 100000 -S1 -O suppress=timeout,unexpected -c 256 -q 65535 -t 1 -l 60 -O verbose-interval-stats -O json -O latency-histogram`
- query file with single line: `z123.test. SOA` - it should result in REFUSED because we don't have any such zone
- cycle through 10 dnsperf runs without restarting server
- hope that it reproduces erratic behavior; in my experiments it happens at least in in ~ 1/10 runs, sometimes more
### What is the current *bug* behavior?
**Sometimes** the server has high latency. Dunno why. I was testing against echo server and it did not exhibit this behavior.
![histogram-raw.svg](/uploads/e20182379751faeabcd967567e2978f9/histogram-raw.svg)
### What is the expected *correct* behavior?
Even performance.
### Relevant configuration files
[refused.conf](/uploads/f7255a304baba60c8dff5d02058b7e4d/refused.conf)
### Relevant logs and/or screenshots
Nothing suspicious.https://gitlab.isc.org/isc-projects/bind9/-/issues/3864Investigate the hot-keys problem2023-02-14T11:03:50ZOndřej SurýInvestigate the hot-keys problem### Hot Keys
Sharded data structures are somewhat vulnerable to hot keys. I.e. a single key which is frequently operated on. In this case there will be high contention on the shard for which this key belongs to. This can be mitigated by...### Hot Keys
Sharded data structures are somewhat vulnerable to hot keys. I.e. a single key which is frequently operated on. In this case there will be high contention on the shard for which this key belongs to. This can be mitigated by introducing a non-determinstic sharding function which places hot keys in more than 1 shard. This solution does complicate things though, and introduces a probabilistic component to the data structure (e.g. look ups may result in the key not being found, when in fact it is actually in another shard. This trade off is generally acceptable in cache scenarios, where failed look ups just result in the key being re-populated).
Source: http://quinnftw.com/sharding-to-reduce-mutex-contention/
(This seems like something that might be happening in the tree structure like DNS itself for the portions of the hierarchy close to the "trunk".)https://gitlab.isc.org/isc-projects/bind9/-/issues/3868tests require python 3.6 but configure allows python 22023-02-16T10:05:19ZEvan Hunttests require python 3.6 but configure allows python 2The `get_algorithms.py` script used in the system tests to choose signing algorithms for tests uses a python feature, dataclasses, which I believe did not exist until version 3.7.
I have a system that has both python2 and python3 instal...The `get_algorithms.py` script used in the system tests to choose signing algorithms for tests uses a python feature, dataclasses, which I believe did not exist until version 3.7.
I have a system that has both python2 and python3 installed. When building 9.18 or main, `configure` finds python3 and everything works fine, but on 9.16, it will use python2 instead, because the required minimum version is 2.7. System tests will then refuse to run:
```
File "/home/each/isc/bind9/bin/tests/system/get_algorithms.py", line 36
name: str
^
SyntaxError: invalid syntax
```
(In 9.18 and main, the minimum version is 3.6, and I suspect the dataclass will also be a problem there, but my own system has 3.8 so I haven't confirmed it.)
The easy solution would be to bump up the version requirement in all branches to python 3.7. If this is fraught in 9.16 because it's a stable branch, we could also just revert `get_algorithms.py` out of that branch.Known issues with current versionshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3870OPENSSL_cleanup fails to return all memory2023-03-21T00:21:28ZMark AndrewsOPENSSL_cleanup fails to return all memoryThe following discussions from !7417 should be addressed:
- [ ] @pemensik started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7417#note_345928): (+7 comments)
> But I found current 9.19.8 release does...The following discussions from !7417 should be addressed:
- [ ] @pemensik started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7417#note_345928): (+7 comments)
> But I found current 9.19.8 release does not compile on latest RHEL9 system with FIPS mode enabled. It crashes all programs:
>
> ```
> $ doc/misc/.libs/cfg_test --zonegrammar primary
> zone <string> [ <class> ] {
> type primary;
> ...
> zero-no-soa-ttl <boolean>;
> zone-statistics ( full | terse | none | <boolean> );
> };
> ../../../lib/isc/mem.c:993: REQUIRE(((ctx) != ((void *)0) && ((const isc__magic_t *)(ctx))->magic == ((('M') << 24 | ('e') << 16 | ('m') << 8 | ('C'))))) failed, back trace
> /root/rpmbuild/BUILD/bind-9.19.8/build/doc/misc/../../lib/isc/.libs/libisc-9.19.8.so(+0x2e6c3)[0x7ffff7a2e6c3]
> /root/rpmbuild/BUILD/bind-9.19.8/build/doc/misc/../../lib/isc/.libs/libisc-9.19.8.so(isc_assertion_failed+0x10)[0x7ffff7a2e450]
> /root/rpmbuild/BUILD/bind-9.19.8/build/doc/misc/../../lib/isc/.libs/libisc-9.19.8.so(isc__mem_free+0x91)[0x7ffff7a46741]
> /usr/lib64/ossl-modules/fips.so(+0x15074)[0x7ffff6a0a074]
> /lib64/ld-linux-x86-64.so.2(+0x9f5e)[0x7ffff7fd0f5e]
> /lib64/libc.so.6(+0x574b5)[0x7ffff76574b5]
> /lib64/libc.so.6(on_exit+0x0)[0x7ffff7657630]
> /lib64/libc.so.6(+0x3feb7)[0x7ffff763feb7]
> /lib64/libc.so.6(__libc_start_main+0x80)[0x7ffff763ff60]
> ```
>
> in gdb:
> ```
> (gdb) bt
> #0 0x00007ffff76a154c in __pthread_kill_implementation () from /lib64/libc.so.6
> #1 0x00007ffff7654d46 in raise () from /lib64/libc.so.6
> #2 0x00007ffff76287f3 in abort () from /lib64/libc.so.6
> #3 0x00007ffff7a2e455 in isc_assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>)
> at ../../../lib/isc/assertions.c:50
> #4 0x00007ffff7a46741 in isc__mem_free (ctx=<optimized out>, ptr=<optimized out>, flags=<optimized out>) at ../../../lib/isc/mem.c:993
> #5 0x00007ffff6a0a074 in cleanup () at providers/fips/self_test.c:170
> #6 0x00007ffff7fd0f5e in _dl_fini () at dl-fini.c:142
> #7 0x00007ffff76574b5 in __run_exit_handlers () from /lib64/libc.so.6
> #8 0x00007ffff7657630 in exit () from /lib64/libc.so.6
> #9 0x00007ffff763feb7 in __libc_start_call_main () from /lib64/libc.so.6
> #10 0x00007ffff763ff60 in __libc_start_main_impl () from /lib64/libc.so.6
> #11 0x0000555555555995 in _start ()
> ```
>
> It seems FIPS mode cleanup is different than normal OpenSSL. It works fine without FIPS mode. But does not even compile under it. Found when trying to test these changes can pass, but haven't even got so far. To be investigated later.
- [ ] @fabled started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7417#note_347559): (+1 comment)
> > @fabled This might affect the PKCS#11 provider as well.
>
> To some extent yes. But especially the case if using SoftHSMv2 with OpenSSL backend. Then there is circular dependency OpenSSL -> pkcs11-provider -> SoftHSMv2 -> OpenSSL. And care is needed to make sure things are released in right order during exit.https://gitlab.isc.org/isc-projects/bind9/-/issues/3876Follow-up from "Resolve "Dig fails to cleanup OpenSSL references""2023-02-17T07:39:57ZMark AndrewsFollow-up from "Resolve "Dig fails to cleanup OpenSSL references""The following discussion from !7535 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7535#note_352479): (+1 comment)
> I was thinking that this code might go into...The following discussion from !7535 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7535#note_352479): (+1 comment)
> I was thinking that this code might go into the library destructor with ease - we just need a single global atomic bool to indicate where we need deinit and add a wrapper with `atomic_compare_exchange()` to the `dst_lib_destroy()`, so it doesn't get run twice. That would solve the de-init for all uses of `dst_lib_init()` (which can't be run from the constructor because of the ENGINE initialization).Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3877Support _FORTIFY_SOURCE=32023-02-16T10:57:26ZTony FinchSupport _FORTIFY_SOURCE=3Recent versions of clang, gcc, and glibc support `_FORTIFY_SOURCE=3` which adds support for tracking sizes of allocations at run time in a way that can be checked by `memmove()` and friends. To make use of the new fortification level, al...Recent versions of clang, gcc, and glibc support `_FORTIFY_SOURCE=3` which adds support for tracking sizes of allocations at run time in a way that can be checked by `memmove()` and friends. To make use of the new fortification level, allocation functions need attributes indicating which argument is the size (`__alloc_size__`) and other functions need to tell the compiler which arguments are pointer, size pairs (`__access__`). For more details see https://developers.redhat.com/articles/2023/02/06/how-improve-application-security-using-fortifysource3#Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3878Missing and undocumented statistics from the HTTP stats channel in the ARM2023-11-02T16:30:30ZPieter LexisMissing and undocumented statistics from the HTTP stats channel in the ARMHi folks,
I'm implementing a new monitoring solution and adding a bunch of stats from the HTTP-based stats channel to said monitoring solution. I'm basing the descriptions on what I can find in the ARM section 8.5 (I'm using the one fro...Hi folks,
I'm implementing a new monitoring solution and adding a bunch of stats from the HTTP-based stats channel to said monitoring solution. I'm basing the descriptions on what I can find in the ARM section 8.5 (I'm using the one from 9.18 and 9.19), but some stats are missing there. Some of them are self-evident based on the name, but some are not. I've compiled a list here, the naming is based on the JSON from the webserver:
* nsstats.TCPConnHighWater
* nsstats.SynthNXDOMAIN
* nsstats.CookieNew
* nsstats.CookieIn
* in view.NAME.resolver.stats
* BucketSize
* ClientCookieOut
* ServerCookieOut
* CookieIn
* CookieClientOk
* BadCookieRcode
* NextItem
* Priming
* traffic
The following stats are mostly unclear:
* view.NAME.resolver.cachestats - none of these statistics are described
* view.NAME.resolver.adb - none of these statistics are described
* opcodes.CODE - Are these the counts of received opcodes from clients?
* rcodes.CODE - Are these the counts of rcodes sent to clients?
* qtypes.CODE - Are these the counts of qtypes that were queried by clients?
* view.NAME.resolver.qtypes - what do these numbers mean?
* view.NAME.resolver.cache - Are the current cache entries for these types?
Cheers,
PieterNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3885"Loop detected resolving..." and different query-behavior after flushing a ca...2023-11-02T16:30:30ZThomas Amgarten"Loop detected resolving..." and different query-behavior after flushing a cache entry between BIND-9.19.10 and BIND-9.18.12### Summary
Regarding https://www.mail-archive.com/bind-users@lists.isc.org/msg33119.html, I fill this GL issue.
BIND-9.19.10 behaves differently to BIND-9.18.12 regarding AAAA-Lookups, when an entry (for example A record for "ns2.comt...### Summary
Regarding https://www.mail-archive.com/bind-users@lists.isc.org/msg33119.html, I fill this GL issue.
BIND-9.19.10 behaves differently to BIND-9.18.12 regarding AAAA-Lookups, when an entry (for example A record for "ns2.comtronic.ch") was cached and then succesfully flushed with ``rndc flushname ns2.comtronic.ch``.
BIND-9.19.10 then always...
- does A and AAAA lookups for the requested query (``dig @resolver ns2.comtronic.ch``)
- shows an INFO ``21-Feb-2023 09:23:15.463 resolver: info: loop detected resolving 'ns2.comtronic.ch/A'``
... where BIND-9.18.12 only sporadic shows the loop detected info and doesn't do AAAA lookups.
### BIND version used
#### 9.19.10
```
$ named -V
BIND 9.19.10 (Development Release) <id:789be8e>
running on Linux x86_64 4.18.0-305.10.2.el8_4.x86_64 #1 SMP Tue Jul 20 20:34:55 UTC 2021
built by make with '--prefix=/usr/local/bind-9.19.10' '--sysconfdir=/opt/chroot/bind/etc/named/' '--mandir=/usr/local/share/man' '--localstatedir=/opt/chroot/bind/var' '--enable-largefile' '--enable-full-report' '--without-gssapi' '--with-json-c' '--enable-singletrace' '--enable-dnstap' '--with-libxml2' 'PKG_CONFIG_PATH=/usr/local/fstrm/lib/pkgconfig/:/usr/local/h2o/lib64/pkgconfig'
compiled by GCC 8.4.1 20200928 (Red Hat 8.4.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libuv version: 1.41.1
linked to libuv version: 1.41.1
compiled with libnghttp2 version: 1.33.0
linked to libnghttp2 version: 1.33.0
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.0
linked to protobuf-c version: 1.3.0
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: /opt/chroot/bind/etc/named/named.conf
rndc configuration: /opt/chroot/bind/etc/named/rndc.conf
DNSSEC root key: /opt/chroot/bind/etc/named/bind.keys
nsupdate session key: /opt/chroot/bind/var/run/named/session.key
named PID file: /opt/chroot/bind/var/run/named/named.pid
named lock file: /opt/chroot/bind/var/run/named/named.lock
```
#### 9.18.12
```
$ named -V
BIND 9.18.12 (Extended Support Version) <id:99783f9>
running on Linux x86_64 4.18.0-305.10.2.el8_4.x86_64 #1 SMP Tue Jul 20 20:34:55 UTC 2021
built by make with '--prefix=/usr/local/bind-9.18.12' '--sysconfdir=/opt/chroot/bind/etc/named/' '--mandir=/usr/local/share/man' '--localstatedir=/opt/chroot/bind/var' '--enable-largefile' '--enable-full-report' '--without-gssapi' '--with-json-c' '--enable-singletrace' '--enable-dnstap' '--with-libxml2' 'PKG_CONFIG_PATH=/usr/local/fstrm/lib/pkgconfig/:/usr/local/h2o/lib64/pkgconfig'
compiled by GCC 8.4.1 20200928 (Red Hat 8.4.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libuv version: 1.41.1
linked to libuv version: 1.41.1
compiled with libnghttp2 version: 1.33.0
linked to libnghttp2 version: 1.33.0
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.0
linked to protobuf-c version: 1.3.0
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: /opt/chroot/bind/etc/named/named.conf
rndc configuration: /opt/chroot/bind/etc/named/rndc.conf
DNSSEC root key: /opt/chroot/bind/etc/named/bind.keys
nsupdate session key: /opt/chroot/bind/var/run/named/session.key
named PID file: /opt/chroot/bind/var/run/named/named.pid
named lock file: /opt/chroot/bind/var/run/named/named.lock
```
### Steps to reproduce
```
# Start named on the resolver
$ systemctl start named
```
```
# Query the record, which causes the behavior
$ dig @resolver ns2.comtronic.ch
; <<>> DiG 9.19.10 <<>> @resolver ns2.comtronic.ch
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22395
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 6a9803403ae47edc0100000063f4e59976baec2fb3207c4a (good)
;; QUESTION SECTION:
;ns2.comtronic.ch. IN A
;; ANSWER SECTION:
ns2.comtronic.ch. 60 IN A 195.200.242.162
;; Query time: 12 msec
;; SERVER: 10.100.102.21#53(resolver) (UDP)
;; WHEN: Tue Feb 21 16:39:05 CET 2023
;; MSG SIZE rcvd: 89
```
```
# Run "rndc flushname ns2.comtronic.ch"
$ rndc flushname ns2.comtronic.ch
```
```
# Query the resolver with the same query again
$ dig @resolver ns2.comtronic.ch
; <<>> DiG 9.19.10 <<>> @resolver ns2.comtronic.ch
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43078
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 70097c934a18c03c0100000063f4e6a0cc14b1551adc474c (good)
;; QUESTION SECTION:
;ns2.comtronic.ch. IN A
;; ANSWER SECTION:
ns2.comtronic.ch. 60 IN A 195.200.242.162
;; Query time: 8 msec
;; SERVER: 10.100.102.21#53(resolver) (UDP)
;; WHEN: Tue Feb 21 16:43:28 CET 2023
;; MSG SIZE rcvd: 89
```
```
# On the resolver check the named.log for "loop detected"
21-Feb-2023 16:43:28.238 resolver: info: loop detected resolving 'ns2.comtronic.ch/A'
```
```
# On the resolver sniff dns traffic, which always shows A and AAAA lookups
16:43:28.239336 IP 10.100.2.62.43415 > 10.100.102.21.53: 43078+ [1au] A? ns2.comtronic.ch. (57)
16:43:28.240559 IP6 2001:db8::affe.44411 > 2603:1020:a01:2::34.53: 11540 [1au] A? ns2.comtronic.ch. (45)
16:43:28.240885 IP6 2001:db8::affe.33227 > 2001:67c:1010:2::53.53: 46123% [1au] AAAA? ns2.comtronic.ch. (45)
16:43:28.240984 IP6 2001:db8::affe.29014 > 2001:67c:1010:2::53.53: 50359% [1au] A? ns2.comtronic.ch. (45)
16:43:28.243680 IP6 2603:1020:a01:2::34.53 > 2001:db8::affe.44411: 11540*- 1/0/1 A 195.200.242.162 (61)
16:43:28.243951 IP 10.100.102.21.53 > 10.100.2.62.43415: 43078 1/0/1 A 195.200.242.162 (89)
16:43:28.246959 IP6 2001:67c:1010:2::53.53 > 2001:db8::affe.33227: 46123- 0/10/10 (695)
16:43:28.247176 IP6 2001:67c:1010:2::53.53 > 2001:db8::affe.29014: 50359- 0/10/10 (695)
16:43:28.247420 IP6 2001:db8::affe.36611 > 2a02:1368:1:47::53.53: 1441% [1au] AAAA? ns2.comtronic.ch. (45)
16:43:28.247515 IP6 2001:db8::affe.6551 > 2a02:1368:1:47::53.53: 45763% [1au] A? ns2.comtronic.ch. (45)
16:43:28.248042 IP6 2a02:1368:1:47::53.53 > 2001:db8::affe.36611: 1441*- 0/1/1 (96)
16:43:28.248080 IP6 2a02:1368:1:47::53.53 > 2001:db8::affe.6551: 45763*- 1/0/1 A 195.200.242.162 (61)
```
### What is the current *bug* behavior?
Regarding https://www.mail-archive.com/bind-users@lists.isc.org/msg33119.html it's not clear,
- what "loop detected resolving 'ns2.comtronic.ch/A' means here?
- why "loop detected resolving 'ns2.comtronic.ch/A'" always is reproducable in BIND-9.19.10 and sporadic in BIND-9.18.12?
- why BIND-9.19.10 behaves differently to BIND-9.18.12 regarding AAAA lookups after flushing the name "ns2.comtronic.ch"?
A ``tcpdump`` from BIND-9.18.12 shows the following traffic (excerpt from my mailing-list- question):
```
# Query from the client
09:36:34.242064 IP 10.100.2.62.59765 > 10.100.102.21.53: 58600+ [1au] A? ns2.comtronic.ch. (57)
# Query from the resolver to the authoritative
09:36:34.242787 IP6 2001:db8::affe.4717 > 2a02:1368:1:48::53.53: 26321 [1au] A? ns2.comtronic.ch. (45)
# Query from the resolver to the TLD server
09:36:34.242880 IP6 2001:db8::affe.25272 > 2001:620:0:ff::56.53: 50695% [1au] A? ns2.comtronic.ch. (45)
# Response back from the authoritative server
09:36:34.243673 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.4717: 26321*- 1/0/1 A 195.200.242.162 (61)
# Response back to the client
09:36:34.243841 IP 10.100.102.21.53 > 10.100.2.62.59765: 58600 1/0/1 A 195.200.242.162 (89)
# Delegation answer from the TLD server
09:36:34.244556 IP6 2001:620:0:ff::56.53 > 2001:db8::affe.25272: 50695- 0/10/10 (695)
# A 2nd query to the same authoritative
09:36:34.244750 IP6 2001:db8::affe.18083 > 2a02:1368:1:48::53.53: 21395% [1au] A? ns2.comtronic.ch. (45)
# 2nd response back from the authoritative server
09:36:34.245246 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.18083: 21395*- 1/0/1 A 195.200.242.162 (61)
```
### What is the expected *correct* behavior?
I'm not sure, which behavior is the correct one, 9.19.10 or 9.18.12.
### Relevant configuration files
--
### Relevant logs and/or screenshots
--
### Possible fixes
--Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3888Resolver under load retransmits even though the authoritative replies promptly2023-03-01T09:35:12ZŠtěpán BalážikResolver under load retransmits even though the authoritative replies promptly### Summary
With enough traffic going to and from BIND 9.18 running as a resolver, some packets from the authoritative (sent well before the 800ms retransmit deadline in packet capture seem) to get _stuck somewhere in BIND_.
### BIND v...### Summary
With enough traffic going to and from BIND 9.18 running as a resolver, some packets from the authoritative (sent well before the 800ms retransmit deadline in packet capture seem) to get _stuck somewhere in BIND_.
### BIND version
```shell
$ ./named -V
BIND 9.18.10 (Stable Release) <id:7011eaf>
```
### Steps to reproduce
1. Start an authoritative server serving this zone on `1.0.0.100` (Knot was used in testing):
```zone
. 86400 IN SOA j.root-servers.net. nstld.verisign-grs.com. 2019072500 1800 900 604800 86400
*. 3600 IN A 1.1.1.1
. 86400 IN NS j.root-servers.net.
```
2. Start BIND 9.18 with this config:
```
options {
listen-on {1.0.0.1; };
listen-on-v6 { };
directory "/tmp/maze-one_server-5y3fes_c/resolver";
recursion yes;
query-source address 1.0.0.1;
dnssec-validation no;
empty-zones-enable yes;
};
zone "." {
type hint;
file "/tmp/maze-one_server-5y3fes_c/resolver/root.hints";
}
```
with hints file:
```
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 1.0.0.100
```
3. Optional: set up constant delay on authoritative server's answers with `netem` (done in the example below (delay is set to 10ms), but not necessary).
4. Set up traffic capture.
5. Run `dnsperf` as a client to create traffic:
```
dnsperf -d q -Q 5000 -q 10000 -t 10
```
with the file `q` that contains the lines `0. A` to `9999. A`.
6. Inspect the resulting PCAP with Wireshark and filter for long delays on responses to client. This can be achieved with the filter `dns.time > 0.08`.
### Details (current behavior)
This was run as an comparison between `9.16.36`, `9.18.10` and `35e2842` (marked as `main` in the text and images bellow).
There is only one authoritative server in this case and its RTT is set to 10 ms. This was run on a 2-core/4-thread VM with Knot as the authoritative.
The resolution of culprit queries look like this when examined packet by packet:
```
t = 0 ms, client asks the resolver
t = 0+ε ms, resolver asks the authoritative
t = 10 ms, authoritative sends response
t = 800 ms, resolver asks the authoritative again
t = 810 ms, authoritative answers again
t = 810+ε ms, resolver finally answers
```
The delayed responses also appear in chunks pointing to them maybe being stuck in some kind of queue (_looking and you `libuv`_) this can be shown by graphing the response times to client with a sliding window average:
![comparison_sliding_windows.svg](/uploads/6a9eecfb005779a5be4edd6ebdda73ee/comparison_sliding_windows.svg)
Note, that there are no peaks with 9.16.
I also attach the [pcap](/uploads/b172ef4b6d77bfac220ec6e0211c6e3b/result_named-9-18.pcap) of the run with 9.18 for reference.
### Expected behavior
There should be no such retransmits.https://gitlab.isc.org/isc-projects/bind9/-/issues/3889Follow-up from "kasp: Add test case for migrating KSK/ZSK to CSK"2023-11-02T16:30:30ZMatthijs Mekkingmatthijs@isc.orgFollow-up from "kasp: Add test case for migrating KSK/ZSK to CSK"The following discussion from !7306 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7306#note_341267): (+4 comments)
> We also need a test without `-P sync`. Lot...The following discussion from !7306 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7306#note_341267): (+4 comments)
> We also need a test without `-P sync`. Lots of zones being converted to dnssec-policy will never have set `-P sync`. The key in the triggering issue only had:
>
> ```
> ; This is a key-signing key, keyid ${ID1}, for my.domain.
> ; Created: 20200401100731 (Wed Apr 1 13:07:31 2020)
> ; Publish: 20200401100731 (Wed Apr 1 13:07:31 2020)
> ; Activate: 20200401100731 (Wed Apr 1 13:07:31 2020)
> my.domain. IN DNSKEY 257 3 13 <X3>
> ```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3896Add the TLS SNI +[no]tls-sni option to dig for DoT and DoH2023-11-02T16:30:30ZAlexey ChernyakAdd the TLS SNI +[no]tls-sni option to dig for DoT and DoH### Description
Currently, when doing DoT or DoH lookups, `dig` does not include the Server Name Indication (SNI) extension during its TLS handshake `ClientHello` request.
This makes dig unusable as a DoT or DoH client with TLS proxies...### Description
Currently, when doing DoT or DoH lookups, `dig` does not include the Server Name Indication (SNI) extension during its TLS handshake `ClientHello` request.
This makes dig unusable as a DoT or DoH client with TLS proxies and HTTPS proxies and DoT/DoH servers that implement:
* SNI based routing of requests to the correct backends as part of name-based virtual hosting, and/or
* SNI filtering based access control.
Currently `dig` also has very poor handling of the fatal-level SNI-related TLS handshake `Alert` response from server.
Example of such TLS Alert server response:
```
Transport Layer Security
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unrecognized Name)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Unrecognized Name (112)
```
Current dig behaviour is as follows when the server aborts the handshake by sending such a fatal-level `unrecognized_name(112)` alert:
```
~ $ dig +https @dns.example.com example.com A; echo $?
;; Connection to 192.0.2.53#443(192.0.2.53) for example.com failed: TLS error.
;; Connection to 192.0.2.53#443(192.0.2.53) for example.com failed: TLS error.
;; Connection to 192.0.2.53#443(192.0.2.53) for example.com failed: TLS error.
9
~ $ dig +tls @dns.example.com example.com A; echo $?
0
~ $
```
There is no dependency on implementing SNI support in `named` (which also would be nice for ACLs and for multiple views).
While `named` can be placed behind a SNI-capable proxy, there's no workarounds for `dig` other than replacing it with a SNI-capable client such as `kdig`.
### Request
Add `+[no]tls-sni=STR` option to `dig` similar to the [option](https://www.knot-dns.cz/docs/3.2/html/man_kdig.html#options) in `kdig`.
Expected behaviour is something roughly along the lines of:
```
if request is DoT or DoH
if +tls-sni option is specified
SNIHostName = option value
else if +notls-sni option is specified
SNIHostName = NULL
else if @server argument is a hostname
SNIHostName = server hostname FQDN
else if +tls-hostname option is specified
SNIHostName = option value
else
SNIHostName = NULL
if SNIHostName
remove trailing FQDN dot from SNIHostName if specified
Do IDN format conversion to ASCII if necessary
validate SNIHostName against SNI HostName format specification
if SNIHostName format is valid
include SNIHostName as a SNI in TLS ClientHello
include SNIHostName in the first line of dig query output?
else
exit with an error
else
Don't include SNI in TLS ClientHello
if ServerHello response includes "server_name" extension
include SNIHostName in SERVER line in dig query output
```
Better error handling of the fatal-level `unrecognized_name(112)` alert TLS responses from server:
* Start returning an error during DoT instead of a silent success.
* Consider a more descriptive error message than the current `TLS error`:
```
if a <SNI> value was included in ClientHello
Error message something along the lines of: `'<SNI>' SNI is unrecognised by the server`
else
Error message something along the lines of: `SNI is required by the server`
```
### Links / references
For the most recent background and guidance on SNI see [Section 3.7 of RFC 9325](https://www.rfc-editor.org/rfc/rfc9325#name-server-name-indication-sni).
For the latest SNI specification defining SNI `HostName` format and client/server behaviour see [Section 3 of RFC 6066](https://www.rfc-editor.org/rfc/rfc6066.html#section-3).
When implementing, consider application of Internationalized Domain Names (IDN) in SNI as per [RFC 5890](https://www.rfc-editor.org/rfc/rfc5890) and TLS Encrypted Client Hello (ECH) as per the latest [draft](thttps://www.ietf.org/archive/id/draft-ietf-tls-esni-15.html).Not plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3897dig IPv6 Simplified Reverse Lookups2023-02-28T06:57:20ZChris Mirchandanidig IPv6 Simplified Reverse Lookups<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confident...<!--
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 make sure that you make the new issue
confidential!
-->
### Summary
When using -x with IPv6 the only address that is accepted is properly handled is a /128. If you try to use an IPv6 notation other than a /128, it assumes the address is an IPv4 address and converts the query value to the IPv4 dotted-decimal notation.
<details><summary>Correct IPv6 Handling for an IPv6 /128</summary>
$ dig +noall +answer +question -x 2607:f3f0:0:b:20c:29ff:fe10:14f8
;8.f.4.1.0.1.e.f.f.f.9.2.c.0.2.0.b.0.0.0.0.0.0.0.0.f.3.f.7.0.6.2.ip6.arpa. IN PTR
8.f.4.1.0.1.e.f.f.f.9.2.c.0.2.0.b.0.0.0.0.0.0.0.0.f.3.f.7.0.6.2.ip6.arpa. 86360 IN PTR msentry1.njwtech.com.
$ dig +noall +answer +question NS -x 2607:f3f0:0:b:20c:29ff:fe10:14f8
;8.f.4.1.0.1.e.f.f.f.9.2.c.0.2.0.b.0.0.0.0.0.0.0.0.f.3.f.7.0.6.2.ip6.arpa. IN NS
</details>
<details><summary>Incorrect Handling for an IPv6 /32</summary>
$ dig +noall +answer +question NS -x 2607:f3f0:0:b
;2607:f3f0:0:b.in-addr.arpa. IN NS
$ dig +noall +answer +question NS -x 2607:f3f0:0:b:
;2607:f3f0:0:b:.in-addr.arpa. IN NS
$ dig +noall +answer +question NS -x 2607:f3f0:0:b::/64
;2607:f3f0:0:b::/64.in-addr.arpa. IN NS
</details>
### BIND version used
$ dig -v
DiG 9.10.6
### Steps to reproduce
<details><summary>Incorrect Handling for an IPv6 /32</summary>
$ dig +noall +answer +question NS -x 2607:f3f0:0:b
;2607:f3f0:0:b.in-addr.arpa. IN NS
$ dig +noall +answer +question NS -x 2607:f3f0:0:b:
;2607:f3f0:0:b:.in-addr.arpa. IN NS
$ dig +noall +answer +question NS -x 2607:f3f0:0:b::/64
;2607:f3f0:0:b::/64.in-addr.arpa. IN NS
</details>
### What is the current *bug* behavior?
If you try to use an IPv6 notation other than a /128, it assumes the address is an IPv4 address and converts the query value to the IPv4 dotted-decimal notation.
### What is the expected *correct* behavior?
Dig should recognize an IPv6 address by looking for a colon and convert what is provided to the nibble format. I think the issue would be recognizing IPs like 234::/16. Using the same format as for IPv4 dig would not be able to distinguish between IPv4 and IPv6 as dig NS -x 234 could be 234.in-addr.arpa. or 4.3.2.0.ip6.arpa. I suggest one of the following options for IPv6.
1) Ending a IPv6 address with a colon like 234: for 4.3.2.0.ip6.arpa., 2607:f8b0: for 0.b.8.f.7.0.6.2.ip6.arpa., etc.
2) Using cider notation like 234::/16 for 4.3.2.0.ip6.arpa., 2607::/32 for 0.0.0.0.7.0.6.2.ip6.arpa., 2607:f8b0::/32 for 0.b.8.f.7.0.6.2.ip6.arpa., etc.
3) Having a dedicated option -X (that's a capital X) for simplified IPv6 reverse lookups.
For more clarity on the expected output for IPv6, with IPv4 address the octets needed to represent a class A, B, or C zone can be entered with -x and dig will convert them to the IPv4 dotted-decimal notation. This is very useful if you are looking for zone level records like SOA, NS, DNSSEC, etc. Dig also accepts RFC 2317 zone names with -x which is useful for every RDNS record type. I have provided some examples below for reference.
<details><summary>Class A Example</summary>
$ dig +noall +answer +question NS -x 8
;8.in-addr.arpa. IN NS
8.in-addr.arpa. 86400 IN NS x.arin.net.
8.in-addr.arpa. 86400 IN NS z.arin.net.
8.in-addr.arpa. 86400 IN NS u.arin.net.
8.in-addr.arpa. 86400 IN NS r.arin.net.
8.in-addr.arpa. 86400 IN NS y.arin.net.
8.in-addr.arpa. 86400 IN NS arin.authdns.ripe.net.
</details>
<details><summary>Class B Example</summary>
$ dig +noall +answer +question NS -x 8.8
;8.8.in-addr.arpa. IN NS
8.8.in-addr.arpa. 3600 IN NS ns2.Level3.net.
8.8.in-addr.arpa. 3600 IN NS ns1.Level3.net.
</details>
<details><summary>Class C Example</summary>
$ dig +noall +answer +question NS -x 216.139.200
;200.139.216.in-addr.arpa. IN NS
200.139.216.in-addr.arpa. 86172 IN NS ns1.esnet.com.
200.139.216.in-addr.arpa. 86172 IN NS ns4.esnet.com.
200.139.216.in-addr.arpa. 86172 IN NS ns2.esnet.com.
200.139.216.in-addr.arpa. 86172 IN NS ns3.esnet.com.
</details>
<details><summary>RFC 2317 NS Example</summary>
$ dig +noall +answer +question NS -x 24.96.81.192-28
;192-28.81.96.24.in-addr.arpa. IN NS
192-28.81.96.24.in-addr.arpa. 528 IN NS ns2.tvaoig.gov.
192-28.81.96.24.in-addr.arpa. 528 IN NS ns3.tvaoig.gov.
</details>
<details><summary>RFC 2317 PTR Example</summary>
$ dig +noall +answer +question -x 24.96.81.192-28.196
;196.192-28.81.96.24.in-addr.arpa. IN PTR
196.192-28.81.96.24.in-addr.arpa. 21586 IN PTR join.tvaoig.gov.
</details>
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
See examples provided above.
### Possible fixes
Not sure...Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3906ThreadSanitizer: data race lib/dns/request.c:1020 in req_senddone (v9_18)2023-03-01T16:11:39ZArаm SаrgsyаnThreadSanitizer: data race lib/dns/request.c:1020 in req_senddone (v9_18)TSAN report during the `xferquota` system test on commit 6b7d2df6 (based on `9_18`): https://gitlab.isc.org/isc-projects/bind9/-/jobs/3201521
```
==================
WARNING: ThreadSanitizer: data race (pid=24022)
Read of size 4 at 0x7...TSAN report during the `xferquota` system test on commit 6b7d2df6 (based on `9_18`): https://gitlab.isc.org/isc-projects/bind9/-/jobs/3201521
```
==================
WARNING: ThreadSanitizer: data race (pid=24022)
Read of size 4 at 0x7b44000615a0 by thread T6:
#0 req_senddone /builds/isc-projects/bind9/lib/dns/request.c:1020 (libdns-9.18.13-dev.so+0x1814d3)
#1 send_done /builds/isc-projects/bind9/lib/dns/dispatch.c:2061 (libdns-9.18.13-dev.so+0x68967)
#2 isc__nm_async_sendcb netmgr/netmgr.c:2930 (libisc-9.18.13-dev.so+0x2967b)
#3 isc__nm_sendcb netmgr/netmgr.c:2906 (libisc-9.18.13-dev.so+0x298ec)
#4 udp_send_cb netmgr/udp.c:806 (libisc-9.18.13-dev.so+0x3f9ec)
#5 uv__udp_run_completed /usr/src/libuv-v1.44.1/src/unix/udp.c:155 (libuv.so.1+0x264f2)
#6 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:189 (libisc-9.18.13-dev.so+0x80114)
Previous write of size 4 at 0x7b44000615a0 by thread T2 (mutexes: write M55023186806375632, write M56149086713218488):
#0 request_cancel /builds/isc-projects/bind9/lib/dns/request.c:889 (libdns-9.18.13-dev.so+0x181130)
#1 dns_request_cancel /builds/isc-projects/bind9/lib/dns/request.c:905 (libdns-9.18.13-dev.so+0x18191b)
#2 dns_requestmgr_shutdown /builds/isc-projects/bind9/lib/dns/request.c:230 (libdns-9.18.13-dev.so+0x181a9b)
#3 view_flushanddetach /builds/isc-projects/bind9/lib/dns/view.c:656 (libdns-9.18.13-dev.so+0x1ed89e)
#4 dns_view_detach /builds/isc-projects/bind9/lib/dns/view.c:716 (libdns-9.18.13-dev.so+0x1ed96f)
#5 ns_client_endrequest /builds/isc-projects/bind9/lib/ns/client.c:246 (libns-9.18.13-dev.so+0x13ceb)
#6 ns__client_reset_cb /builds/isc-projects/bind9/lib/ns/client.c:1621 (libns-9.18.13-dev.so+0x13ceb)
#7 nmhandle_detach_cb netmgr/netmgr.c:1851 (libisc-9.18.13-dev.so+0x279e5)
#8 isc__nm_async_detach netmgr/netmgr.c:2960 (libisc-9.18.13-dev.so+0x2ba57)
#9 process_netievent netmgr/netmgr.c:981 (libisc-9.18.13-dev.so+0x2ba57)
#10 process_queue netmgr/netmgr.c:1013 (libisc-9.18.13-dev.so+0x2bdce)
#11 process_all_queues netmgr/netmgr.c:767 (libisc-9.18.13-dev.so+0x2cb44)
#12 async_cb netmgr/netmgr.c:796 (libisc-9.18.13-dev.so+0x2cb44)
#13 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163 (libuv.so.1+0x1118e)
#14 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:189 (libisc-9.18.13-dev.so+0x80114)
Location is heap block of size 280 at 0x7b4400061580 allocated by thread T6:
#0 malloc <null> (libtsan.so.2+0x3f618)
#1 mallocx /builds/isc-projects/bind9/lib/isc/jemalloc_shim.h:35 (libisc-9.18.13-dev.so+0x5d262)
#2 mem_get /builds/isc-projects/bind9/lib/isc/mem.c:343 (libisc-9.18.13-dev.so+0x5d262)
#3 isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:761 (libisc-9.18.13-dev.so+0x5dfea)
#4 new_request /builds/isc-projects/bind9/lib/dns/request.c:362 (libdns-9.18.13-dev.so+0x17e093)
#5 dns_request_create /builds/isc-projects/bind9/lib/dns/request.c:665 (libdns-9.18.13-dev.so+0x180749)
#6 notify_send_toaddr /builds/isc-projects/bind9/lib/dns/zone.c:12693 (libdns-9.18.13-dev.so+0x211206)
#7 task_run /builds/isc-projects/bind9/lib/isc/task.c:815 (libisc-9.18.13-dev.so+0x745c5)
#8 isc_task_run /builds/isc-projects/bind9/lib/isc/task.c:896 (libisc-9.18.13-dev.so+0x745c5)
#9 isc__nm_async_task netmgr/netmgr.c:848 (libisc-9.18.13-dev.so+0x1fdeb)
#10 process_netievent netmgr/netmgr.c:920 (libisc-9.18.13-dev.so+0x2b0fd)
#11 process_queue netmgr/netmgr.c:1013 (libisc-9.18.13-dev.so+0x2bdce)
#12 process_all_queues netmgr/netmgr.c:767 (libisc-9.18.13-dev.so+0x2cb44)
#13 async_cb netmgr/netmgr.c:796 (libisc-9.18.13-dev.so+0x2cb44)
#14 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163 (libuv.so.1+0x1118e)
#15 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:189 (libisc-9.18.13-dev.so+0x80114)
Mutex M55023186806375632 is already destroyed.
Mutex M56149086713218488 is already destroyed.
Thread T6 'isc-net-0005' (tid=24096, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.2+0x5f0e6)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/thread.c:73 (libisc-9.18.13-dev.so+0x76b3a)
#2 isc__netmgr_create netmgr/netmgr.c:311 (libisc-9.18.13-dev.so+0x20890)
#3 isc_managers_create /builds/isc-projects/bind9/lib/isc/managers.c:31 (libisc-9.18.13-dev.so+0x5c8f3)
#4 create_managers /builds/isc-projects/bind9/bin/named/main.c:1029 (named+0x427f86)
#5 setup /builds/isc-projects/bind9/bin/named/main.c:1293 (named+0x427f86)
#6 main /builds/isc-projects/bind9/bin/named/main.c:1562 (named+0x427f86)
Thread T2 'isc-net-0001' (tid=24073, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.2+0x5f0e6)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/thread.c:73 (libisc-9.18.13-dev.so+0x76b3a)
#2 isc__netmgr_create netmgr/netmgr.c:311 (libisc-9.18.13-dev.so+0x20890)
#3 isc_managers_create /builds/isc-projects/bind9/lib/isc/managers.c:31 (libisc-9.18.13-dev.so+0x5c8f3)
#4 create_managers /builds/isc-projects/bind9/bin/named/main.c:1029 (named+0x427f86)
#5 setup /builds/isc-projects/bind9/bin/named/main.c:1293 (named+0x427f86)
#6 main /builds/isc-projects/bind9/bin/named/main.c:1562 (named+0x427f86)
SUMMARY: ThreadSanitizer: data race /builds/isc-projects/bind9/lib/dns/request.c:1020 in req_senddone
==================
ThreadSanitizer: reported 1 warnings
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3908Follow-up from "Remove TKEY Mode 2 (Diffie-Hellman)"2023-03-01T06:16:51ZOndřej SurýFollow-up from "Remove TKEY Mode 2 (Diffie-Hellman)"The following discussion from !7626 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7626#note_355457): (+5 comments)
> I was wondering if, with `DH` gone, we could...The following discussion from !7626 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7626#note_355457): (+5 comments)
> I was wondering if, with `DH` gone, we could also deprecate some options to `dnssec-keygen` and `-keyfromlabel`, such as `-n` and `-t` and `-T`.
>
> It looks like `-T` (which lets you choose `DNSKEY` vs `KEY` as the rdata type) is still used for SIG(0), so there are `KEY` records that aren't `DH`, so this option can't go away.
>
> Since we still need to be able to set the type to `KEY`, we also still need to be able to set the `KEY` rdata flags field, so `-t` also needs to stay. We don't make any real use of it, none of our tests currently set it, but it seems wrong to make it impossible to set. (Its purpose is to set the flags that indicate whether a key can be used for confidentiality or authentication or both or neither, the default being both.)
>
> `-n` is used for `ZONE` keys or `ENTITY` (aka `HOST`) keys. The function of that is to prevent certain keys from being found when searching for signing keys for a zone. I wonder if it we could just use the rrtype to do that (`DNSKEY` is always zone, `KEY` is always entity)? In any case it's also used for `USER` keys which are never used anywhere in BIND and could definitely go away.
>
> (This should spin off to a separate issue, I'm just writing about it here because I was thinking about it while reviewing this MR.)https://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/3913timing issue in statschannel system test2023-03-03T08:07:02ZTom Krizektiming issue in statschannel system testIn job [#3207137](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3207137) the `statschannel` failed on check `fetch zone 'dnssec' stats data after updating DNSKEY RRset (7)`.
The test expects 1 zsk sign operation and 1 ksk sign operat...In job [#3207137](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3207137) the `statschannel` failed on check `fetch zone 'dnssec' stats data after updating DNSKEY RRset (7)`.
The test expects 1 zsk sign operation and 1 ksk sign operation. These happen:
```
02-Mar-2023 09:10:06.228 add re-sign dnssec. 300 IN RRSIG DNSKEY 13 1 300 20230401091005 20230302081006 7913 dnssec. MT/JQRYMGsWYBwyRkdnj+tB7h2oSbpVfZ9n+DMr1oyDdXtRSoxGwydIO a2GRjUgP5kQ/N5JWUQMK2LkvThFvsA==
02-Mar-2023 09:10:06.228 add re-sign dnssec. 300 IN RRSIG SOA 13 1 300 20230401091006 20230302081006 35685 dnssec. unerVqERet0Xr8KV19/D174G3moa5NVkDoXIbvpc3cPQuzCd/z+eYC2h zuLlEZawAFe2NTI3jw+TDkIgKfpnCw==
```
Then the test waits for `next key event`:
```
02-Mar-2023 09:10:06.228 zone dnssec/IN: next key event: 02-Mar-2023 10:10:06.220
```
However, 100 milliseconds later, before the test retrieves the zone statistics from the statschannel, additional signing operations take place:
```
02-Mar-2023 09:10:06.328 zone_maintenance: zone dnssec/IN: enter
02-Mar-2023 09:10:06.328 zone_resigninc: zone dnssec/IN: enter
02-Mar-2023 09:10:06.328 zone_journal: zone dnssec/IN: enter
02-Mar-2023 09:10:06.328 writing to journal
02-Mar-2023 09:10:06.328 del dnssec. 300 IN SOA mname1. . 4 20 20 1814400 3600
02-Mar-2023 09:10:06.328 del re-sign dnssec. 300 IN RRSIG NS 13 1 300 20230309211006 20230302080959 35685 dnssec. kaS58YnGbS/p3V8088p+yREiSINte5ETOr/3QvFU9XsHyuxDqRLkux6i XqY5/PSkQFm094MO/wNLdbTp8LaB2g==
02-Mar-2023 09:10:06.328 del re-sign a.dnssec. 300 IN RRSIG NSEC 13 2 300 20230309211006 20230302080959 35685 dnssec. 12MDX1o0qgh0T3SoM0aKsu6AjJYcueqHpOT//xD0l/EjFJgBOVu3VJpA 0OO3R/VdQzFeBq1tgY88dpLnTwvKUw==
02-Mar-2023 09:10:06.328 del re-sign a.dnssec. 300 IN RRSIG MX 13 2 300 20230309211006 20230302080959 35685 dnssec. vGNl05h/fsvnnHvU1RX3yUuCRS5Egqd9Mr5HxZ8J3uZAleQNVxUa+gG9 f9ZJ+q6+Zp8Kz8AFHqCxN1vMq0+5zw==
02-Mar-2023 09:10:06.332 del re-sign mail.dnssec. 300 IN RRSIG A 13 2 300 20230309211006 20230302080959 35685 dnssec. RRafXWoDHpbErUBXOVzI3rbREe8ezmj8QEHpHampjKVNJrfzFWbP1cku meg3TPsTCQdy/1v6v4cvfB03SusQoQ==
02-Mar-2023 09:10:06.332 del re-sign a.dnssec. 300 IN RRSIG A 13 2 300 20230309211006 20230302080959 35685 dnssec. ofun5lwcYTsK0OawryLIViK/sdJHPSHT7RxoQR5ErmkAPpjZvTIoE4EO ua95xdHE1X5h/hnJCBYPpl5kHS+Lfg==
02-Mar-2023 09:10:06.332 del re-sign mail.dnssec. 300 IN RRSIG NSEC 13 2 300 20230309211006 20230302080959 35685 dnssec. GspggAHIxa6RQMbauI4On2esTEWifodSorcCjxqlwtZ71XOF7LdtWTbw HLf5o1xYP76o2RRN3CAZRPmAOs1Lkw==
02-Mar-2023 09:10:06.332 del re-sign ns2.dnssec. 300 IN RRSIG NSEC 13 2 300 20230309211006 20230302080959 35685 dnssec. FJXd9+ncwyBxhrMpmAO3xs1sEGlP3g0EhmOk9IHa4/Ljgv6qIJYIL7hW dz2JbfYjI3oI+QqbCEM/5mIM9AO5Jw==
02-Mar-2023 09:10:06.332 del re-sign ns2.dnssec. 300 IN RRSIG A 13 2 300 20230309211006 20230302080959 35685 dnssec. gzliUistEykm6hpMGY8ForYJewFzaUB4rPOJxHROOupf8jaX+GhbelWU tfcnLKmjypuWEIdyFkGugFpzE/slCA==
02-Mar-2023 09:10:06.332 del re-sign dnssec. 300 IN RRSIG SOA 13 1 300 20230401091006 20230302081006 35685 dnssec. unerVqERet0Xr8KV19/D174G3moa5NVkDoXIbvpc3cPQuzCd/z+eYC2h zuLlEZawAFe2NTI3jw+TDkIgKfpnCw==
02-Mar-2023 09:10:06.332 add dnssec. 300 IN SOA mname1. . 5 20 20 1814400 3600
02-Mar-2023 09:10:06.332 add re-sign dnssec. 300 IN RRSIG NS 13 1 300 20230401084359 20230302081006 35685 dnssec. C+vYMDHLb6wperZxXwTAAK3vM9XJ+7/WAGddPyQcdI+fp6hRXL6UM4hz C5qj8+hnKY0E2bHq1jYLoQaw62M/mw==
02-Mar-2023 09:10:06.332 add re-sign a.dnssec. 300 IN RRSIG NSEC 13 2 300 20230401084359 20230302081006 35685 dnssec. h1X7d4NBfaVyRJnkzcsiyjAZPXufVBgKPw08wxAm8Zx1W8N5Tg0WS2/m Xx6MyytvPoCSFFvFOQLkCXurucZUww==
02-Mar-2023 09:10:06.332 add re-sign a.dnssec. 300 IN RRSIG MX 13 2 300 20230401084359 20230302081006 35685 dnssec. J5uy5bjeXLdt73gV8nv4/dbj+cjOIcyFHuh6Qp/sdqFE/sswo8izCdRU 3/iYmjwLS9EeNs6dEb2xx0l9heRmDg==
02-Mar-2023 09:10:06.332 add re-sign mail.dnssec. 300 IN RRSIG A 13 2 300 20230401084359 20230302081006 35685 dnssec. wCLJPDVyC8ja84GHqaA/OnUrOocpAKNOZiTQJdHJkwkkd0BbVxLazYiP fE2rKG54VIFvGxC/EcXavXcqiFeQEg==
02-Mar-2023 09:10:06.332 add re-sign a.dnssec. 300 IN RRSIG A 13 2 300 20230401084359 20230302081006 35685 dnssec. /BXz8YtxNfEo3tJYFGRHVjMQQDAtzZ8ne2nJOm6CQm3d803qzs5JaHLy /4hmNB5oTEz1l9kXw3LQnB94iuH/yA==
02-Mar-2023 09:10:06.332 add re-sign mail.dnssec. 300 IN RRSIG NSEC 13 2 300 20230401084359 20230302081006 35685 dnssec. QWpfnMgaVTitdgvpdIBTimLxJY+YUPcCvcQcVlnVta8FkmhSxgRhLkRs NGM9H1J5o+4K9uFwso3bSmLTADq1YA==
02-Mar-2023 09:10:06.332 add re-sign ns2.dnssec. 300 IN RRSIG NSEC 13 2 300 20230401084359 20230302081006 35685 dnssec. o/RJ6s2Jcccttnk2PxugOcjnyQ9kX9BfxEu5nKLZglAcaFAl7pnPjhNm 9455gOUH62iNPlxHS3KXrac8HuruIQ==
02-Mar-2023 09:10:06.332 add re-sign ns2.dnssec. 300 IN RRSIG A 13 2 300 20230401084359 20230302081006 35685 dnssec. E59RXGdRykOWp+Oad6UJ6DjIJDJT0vtX326pRcoW54obolq/sc2ZjCha GZk634z/MvcNFHWaQnF2rmtOj0SuGg==
02-Mar-2023 09:10:06.332 add re-sign dnssec. 300 IN RRSIG SOA 13 1 300 20230401091006 20230302081006 35685 dnssec. aSQQxKw8rg8Pbn6bacb22o993cEwzPXchCB9wQM4nLjMWq5VgW5JIQeG Tkz2VIWj9dPCQVRv4xKInZmBjHSwfg==
```
This results in the test detecting extra 9 signature operations which it doesn't expect and thus fails.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3914ability to detect and restart stalled zone transfers2023-05-22T18:55:35ZPetr Špačekpspacek@isc.orgability to detect and restart stalled zone transfers### Description
Sometimes TCP connection can get stuck at very low throughput - network problem in remote locations etc. Low means > 0 througput, so transfer timeout does not kill it and it "never" finishes.
For context, this happens o...### Description
Sometimes TCP connection can get stuck at very low throughput - network problem in remote locations etc. Low means > 0 througput, so transfer timeout does not kill it and it "never" finishes.
For context, this happens on global DNS backbone, which literally spans the globe. The problem is not caused by BIND, but by network along the path and TCP stacks not coping that great with it. I.e. essentially this is workaround for someone else's mess.
### Request
First, implement #3883 Expose data about transfers
Then, this:
Provide configuration knob which sets something like (lower bound of transfer rate in bytes, check frequency). Check running transfers periodically, and kill transfers if they are slower than configured limit. This should cause retry down the road.
### Links / references
E.g. Red Hat package manager YUM has something like that. If download is too slow it reports error like:
> Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds
[Yum docs](https://github.com/rpm-software-management/yum/blob/4ed25525ee4781907bd204018c27f44948ed83fe/docs/yum.conf.5#L446)
I think this is a good mechanism as it removes need for alternative proposal: yet another rndc command to kill ongoing zone transfer. That is, good if we accept we should be solving this problem.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3918Add tests for ultra-complex NSEC(3) proofs2023-03-03T15:02:10ZPetr Špačekpspacek@isc.orgAdd tests for ultra-complex NSEC(3) proofsThis is essentially list of ideas for tests from DNS-OARC 40.
Check NSEC(3) proofs returned by auth, plus also ability to validate these.
- Chain of CNAME/DNAME alternating between zones on the same box
- Mix of NSEC/NSEC3/unsigned zon...This is essentially list of ideas for tests from DNS-OARC 40.
Check NSEC(3) proofs returned by auth, plus also ability to validate these.
- Chain of CNAME/DNAME alternating between zones on the same box
- Mix of NSEC/NSEC3/unsigned zones in the chain
- Wildcards in the mix
- Zone with wildcard and opt-out enabled for the LOLz?
Does forwarding change anything related to validation (the process how we gather data)?
Inspiration: https://indico.dns-oarc.net/event/46/contributions/979/ slides 17, 21, 22https://gitlab.isc.org/isc-projects/bind9/-/issues/3919Test RRSIG churn on large zones2023-03-03T15:06:25ZPetr Špačekpspacek@isc.orgTest RRSIG churn on large zonesObservation
===========
Large zones (in order of 10 M RRs) need RRSIG inception and expiration times to be spread out evenly so resigning does not cause CPUs and zone transfers to explode at single point in time. Spreading resigning then...Observation
===========
Large zones (in order of 10 M RRs) need RRSIG inception and expiration times to be spread out evenly so resigning does not cause CPUs and zone transfers to explode at single point in time. Spreading resigning then causes non-negligible sustained update rate, and that reportedly is or was problem for some providers.
Inspired by https://indico.dns-oarc.net/event/46/contributions/979/
Test ideas
==========
Impact of ongoing resigning on:
- [ ] AXFR
- [ ] IXFR
- [ ] journal maintenance
- [ ] query latency?
I guess, if nothing else, `fsync()` and journal compaction might cause some mess.https://gitlab.isc.org/isc-projects/bind9/-/issues/3920dnstap logging does not log "opening dnstap destination" to the dnstap channel2023-03-05T16:01:59ZJeremy Reeddnstap logging does not log "opening dnstap destination" to the dnstap channel
### Summary
I have a category dnstap setup and I get the "closing dnstap" logged to my dnstap channel. But the logging of "opening dnstap destination ..." did not go to my dnstap channel but to my default (syslog).
I am using dnstap t...
### Summary
I have a category dnstap setup and I get the "closing dnstap" logged to my dnstap channel. But the logging of "opening dnstap destination ..." did not go to my dnstap channel but to my default (syslog).
I am using dnstap to a unix domain socket. It works fine. I have a dnstap channel and category setup. I get the "closing dnstap" logged as expected at named shutdown.
### BIND version used
BIND 9.18.13-dev (Extended Support Version) <id:3e46baa>
But I also see that this happened in another version. See https://www.mail-archive.com/bind-users@lists.isc.org/msg30000.html which says "I would have expected to see logged in /var/opt/isc/scls/isc-bind/log/named/dnstap" and "... I can't seem to get any more
information out other than the single message about "closing dnstap"."
### What is the expected *correct* behavior?
The ./lib/dns/dnstap.c appears to show that the "opening dnstap destination ..." to be logged same as the "closing" message. Does this mean the dns_dt_create() happens before the (not-dnstap) logging subsystem is enabled?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3938Improve readability of 'rndc dnssec -status'2023-11-02T16:30:30ZMatthijs Mekkingmatthijs@isc.orgImprove readability of 'rndc dnssec -status'The output of `rndc dnssec -status` can be quite difficult to read.
1. The states "omnipresent", "unretentive", etc don't mean much to users. Some users for example think BIND is stuck because the DS stays in
"rumoured" state, while...The output of `rndc dnssec -status` can be quite difficult to read.
1. The states "omnipresent", "unretentive", etc don't mean much to users. Some users for example think BIND is stuck because the DS stays in
"rumoured" state, while in fact BIND is waiting to be signaled that the DS is published (with `rndc dnssec -checkds` or through parental
agents.
2. Perhaps the states shouldn't be printed at all, except when a to be implemented new argument is added, `-v` for verbose output.
3. "key signing:" sounds like it is signing the DNSKEY RRset, "signing:" might be better.
4. The additional blank line within each key block makes it actually more difficult to read, perhaps only have newline breaks between each key
block.
5. With many keys, sorting may be useful. Sort on rollover due/scheduled date and group keys by their role (CSK, KSK, ZSK).Not plannedMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3948Remove the artificial limit on max zone keys2023-03-15T09:37:28ZOndřej SurýRemove the artificial limit on max zone keysThe `struct dns_update_state` contains the following member `dst_key_t *zone_keys[DNS_MAXZONEKEYS];` limiting the number of the zone keys to `32`. This seems enough, but since we already pass memory context to both `lib/dns/zone.c:dns__...The `struct dns_update_state` contains the following member `dst_key_t *zone_keys[DNS_MAXZONEKEYS];` limiting the number of the zone keys to `32`. This seems enough, but since we already pass memory context to both `lib/dns/zone.c:dns__zone_findkeys()`, `lib/dns/dnssec.c:dns_dnssec_findzonekeys()`, and `lib/dns/update.c:find_zone_keys()` and return the number of found keys in `&nkeys`, we could as well allocate the array in `dns_dnssec_findzonekeys()` by calling `dns_rdataset_count()` first, allocating the array to hold all the possible keys and then shrinking to the actual number of keys.
Alternatively, this could be converted to `ISC_LIST()` instead of a static array.Not plannedhttps://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/3954Forwarding mode has unnecessary overhead2023-03-21T12:53:25Zshipei.xuForwarding mode has unnecessary overheadIn forwarding mode, when the domain name has a cname record, bind will send multiple requests to the target server. Even if the response obtained by the first forwarding request is already the final result.
For example:
- DomainA cname D...In forwarding mode, when the domain name has a cname record, bind will send multiple requests to the target server. Even if the response obtained by the first forwarding request is already the final result.
For example:
- DomainA cname DomainB
- DomainB cname DomainC
- DomainC A 1.1.1.1
In this example, bind will send three forwarding requests, the first request for DomainA's A record,and then get the final result of all above. The second request for DomainB's A record, and the third time for DomainC's A record. I think this is causing unnecessary overhead. Why is it designed this way?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3958Adjust default tcp-clients value upward2023-09-12T09:09:13ZVicky Riskvicky@isc.orgAdjust default tcp-clients value upwardThe default for tcp-clients is set at 150. As more users are now supporting encrypted DNS, which sessions use TCP, it is likely that the % of overall DNS sessions using TCP will increase, and the current default quota will be too low for...The default for tcp-clients is set at 150. As more users are now supporting encrypted DNS, which sessions use TCP, it is likely that the % of overall DNS sessions using TCP will increase, and the current default quota will be too low for many users.
Although it is impossible to determine the ideal setting for all users, it seems likely that users who need to limit TCP sessions can support at least an order of magnitude more sessions, like maybe 2,000.
If we are very worried about impacting small-system users of BIND, perhaps we could just change the setting for BIND -S, which is not available to hobbyists?https://gitlab.isc.org/isc-projects/bind9/-/issues/3969[meta] slow operations present in the hot path2023-12-13T12:27:38ZPetr Špačekpspacek@isc.org[meta] slow operations present in the hot pathThis is list of operations which should not be in the hot path, i.e. these should not block DNS query-answer processing:
- journal & XFR processing - #3556, #3658, !5115
- statistics channel - !7647
- RPZ update - #3746
- catalog zone ...This is list of operations which should not be in the hot path, i.e. these should not block DNS query-answer processing:
- journal & XFR processing - #3556, #3658, !5115
- statistics channel - !7647
- RPZ update - #3746
- catalog zone update - #3881
- UPDATE authorization via external policy - #3669
- #4480
[An interesting paragraph](https://wiki.samba.org/index.php/BIND9_DLZ_DNS_Back_End#The_Lockup_Problem) can be found on Samba wiki:
> When a BIND thread calls one of the BIND9_DLZ plugin API calls, execution can be blocked on database access calls if locks are out on the database at the time. Unfortunately, during that time, BIND will not be able to serve any queries, even external (non-samba) queries. Bind has a "-n" option that can increase the number of worker threads but testing has shown that increasing this number does not fix the problem, indicating that BIND's threading and queueing models are probably a bit broken. In small-scale environments this problem is unlikely to come up, but, in high-traffic environments, it may cause DNS outage. The only solution right now is to use an external DNS server that only forwards queries to BIND9_DLZ-backed samba DNS installations when the query is addressed to a zone managed by that node.
As a special category, anything which uses "exclusive mode" also affects query processing.https://gitlab.isc.org/isc-projects/bind9/-/issues/3979filter-aaaa plugin should mark replies it modified2023-03-30T14:17:02ZPetr Menšíkfilter-aaaa plugin should mark replies it modified### Description
Some network administrators choose to filter out AAAA queries on their legacy-only IPv4 networks. I do not think this is the best approach, but it should be possible to identify when a response were modified by filter-AA...### Description
Some network administrators choose to filter out AAAA queries on their legacy-only IPv4 networks. I do not think this is the best approach, but it should be possible to identify when a response were modified by filter-AAAA (or filter-A) query plugin.
I think the primary change should be in end devices to not ask unnecessary queries, not server blocking them. But it seems the only supported way in case AAAA queries generates costly traffic. No alternative system-wide way to reduce unnecessary queries does not seem to be supported.
### Request
I think Extended DNS Codes are ideal for small notice this not original response forwarded, but something created locally. But current plugins to not use any authority section nor EDE codes. Unless I can validate the response via DNSSEC, I have no way to say whether the address does not exist. Or just the network provider does not want me to try connecting there or just forward AAAA queries.
Unless the administrator wants to hide his change, I think named should mark synthetized empty response by indication this is not a reply from authoritative server itself. I haven't found a good matching EDE code for this use case in [RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html) or its registry. Should a new one for be allocated?
It seems to be very similar to overriding responses by RPZ rules.
```
# dig example.org @localhost aaaa
; <<>> DiG 9.16.23-RH <<>> example.org @localhost aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31531
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: fc6601cf1f17184a010000006425996e453f0431ac31b8e4 (good)
;; QUESTION SECTION:
;example.org. IN AAAA
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Mar 30 10:15:10 EDT 2023
;; MSG SIZE rcvd: 68
```
### Links / references
- Proposal to limit sent queries from clients - https://bugzilla.redhat.com/show_bug.cgi?id=2182745https://gitlab.isc.org/isc-projects/bind9/-/issues/3987Change DNSKEY TTL of inline-signed zone2024-02-24T07:55:08ZGerald VogtChange DNSKEY TTL of inline-signed zone### Description
I have a few zones using inline-signing which I have set up originally with 2d TTL. Due to this the existing DNSKEY RRs also have 2d TTL. Now I have been trying to reduce the TTL to 1d but it seems there is no supported ...### Description
I have a few zones using inline-signing which I have set up originally with 2d TTL. Due to this the existing DNSKEY RRs also have 2d TTL. Now I have been trying to reduce the TTL to 1d but it seems there is no supported way or tool to do so.
I have set dnskey-ttl to 1d and replace keys, still all DNSKEY RRs have 2d TTL. Setting it on the key with dnssec-settime doesn't help either and man pages specifically mention:
```
This option sets the default TTL to use for this key when it is converted into a DNSKEY RR.
This is the TTL used when the key is imported into a zone, unless there was already a DNSKEY
RRset in place, in which case the existing TTL takes precedence.
```
Running AlmaLinux 9 bind-9.16.23-5.el9_1.x86_64.
### Request
Add some way to change the TTL of DNSKEY RRs in inline-signed zones.
### Links / references
I have found a thread from 2016 about the same problem: https://www.mail-archive.com/bind-users@lists.isc.org/msg23186.htmlMay 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/3992The XFR unreachable cache redesign2024-03-01T09:52:29ZOndřej SurýThe XFR unreachable cache redesignThe unreachable cache for **dead primaries** was added to BIND 9 in 2006 via 1372e172d0e0b08996376b782a9041d1e3542489. It features a 10-slot LRU array with 600 seconds (10 minutes) fixed delay. During this time, any primary with a hicc...The unreachable cache for **dead primaries** was added to BIND 9 in 2006 via 1372e172d0e0b08996376b782a9041d1e3542489. It features a 10-slot LRU array with 600 seconds (10 minutes) fixed delay. During this time, any primary with a hiccup would be blocked for the whole block duration (unless overwritten by a different dead primary).
One can argue:
- 10 minutes is too long for a fixed, non-configurable delay
- 10 slots are not enough - servers could be running 1M and more zones with different primaries; and especially in situations like these, there's a high chance that more primaries would be having problems
I think this needs a redesign, but meanwhile - I think that we can drop the `UNREACH_HOLD_TIME` to something like 10 seconds (or 60?) - this should still prevent a thundering herd over the unresponsive server, but the recovery is going to be much faster.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4007mkeys: exceeded time limit waiting for 'dump_done' in ns5/named.run2023-04-06T12:42:02ZMichal Nowakmkeys: exceeded time limit waiting for 'dump_done' in ns5/named.runJob [#3300214](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3300214) failed for 8f73f5d0886d9e0f57f593fbf3bae862d13f9853:
```
I:mkeys:check 'rndc managed-keys' and islands of trust now that root is reachable (39)
I:mkeys:exceeded ti...Job [#3300214](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3300214) failed for 8f73f5d0886d9e0f57f593fbf3bae862d13f9853:
```
I:mkeys:check 'rndc managed-keys' and islands of trust now that root is reachable (39)
I:mkeys:exceeded time limit waiting for 'dump_done' in ns5/named.run
```
I've seen the 20-second limit exceeded several times.
Bumping it to 60 might be a good thing.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4010Allow for scripts / hooks for key rollovers2023-04-11T12:43:32ZKarol BabiochAllow for scripts / hooks for key rollovers### Description
It seems like currently there is no good way on how to automate a KSK rollover, since the corresponding DS record has to published in the parent zone. While there is [RFC7344](https://datatracker.ietf.org/doc/html/rfc734...### Description
It seems like currently there is no good way on how to automate a KSK rollover, since the corresponding DS record has to published in the parent zone. While there is [RFC7344](https://datatracker.ietf.org/doc/html/rfc7344), in reality it is not widely adopted. Personally I don't know any registrar who supports this yet. Anyway, this would require TSIG to be secure anyway.
One of my registrars offers an HTTPS-based API to manage DNSSEC records. Hence, its possible to write scripts that will automate the key rollover process.
### Request
There should be a way to trigger a script (with some inputs such as the key id, the DS record, etc.) whenever BIND is about to rotate a key. This way it should be possible to use `dnssec-policy` and fully automate the key rollover process, including the `KSK` key (rather than only the `ZSK` key).
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4013Add more tests for #4001 and #40022023-07-03T15:47:55ZOndřej SurýAdd more tests for #4001 and #4002This is a follow up from !7805 to add more tests for the source-port configuration.
To quote @pspacek:
> Well, this is pretty large change and needs tests. If nothing else I would like to see what happens if:
>
> * attempt to open TCP...This is a follow up from !7805 to add more tests for the source-port configuration.
To quote @pspacek:
> Well, this is pretty large change and needs tests. If nothing else I would like to see what happens if:
>
> * attempt to open TCP connection ends up in packet black-hole
> * connection is established and the remote side does not respond (established connection hangs)
> * the remote side responds with some something which does not parse as DNS
> * the remote side sends mismatching NOTIFY answer (say different zone name)Not plannedTom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4014Implement tests for maximum global and idle time for incoming XFR2023-05-04T14:23:14ZOndřej SurýImplement tests for maximum global and idle time for incoming XFRSpin-off from !7810 to not forget to write pytests for maximum global and idle time for incoming XFR.Spin-off from !7810 to not forget to write pytests for maximum global and idle time for incoming XFR.Not plannedTom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4017delv +ns does not respect +nomultiline2023-07-24T09:40:40ZPetr Špačekpspacek@isc.orgdelv +ns does not respect +nomultiline### Summary
`delv +ns` even with `+nomultiline` (which is still presumably default) still produces records split across lines.
### BIND version used
* ~"Affects v9.19": 453aaac
### Steps to reproduce
```console
$ delv +ns +nomultili...### Summary
`delv +ns` even with `+nomultiline` (which is still presumably default) still produces records split across lines.
### BIND version used
* ~"Affects v9.19": 453aaac
### Steps to reproduce
```console
$ delv +ns +nomultiline
```
### What is the current *bug* behavior?
See RRSIG at the bottom:
```
;; ANSWER SECTION:
;. 518400 IN NS g.root-servers.net.
;. 518400 IN NS j.root-servers.net.
;. 518400 IN NS e.root-servers.net.
;. 518400 IN NS l.root-servers.net.
;. 518400 IN NS d.root-servers.net.
;. 518400 IN NS a.root-servers.net.
;. 518400 IN NS b.root-servers.net.
;. 518400 IN NS i.root-servers.net.
;. 518400 IN NS m.root-servers.net.
;. 518400 IN NS h.root-servers.net.
;. 518400 IN NS c.root-servers.net.
;. 518400 IN NS k.root-servers.net.
;. 518400 IN NS f.root-servers.net.
;. 518400 IN RRSIG NS 8 0 518400 (
; 20230430050000 20230417040000 60955 .
; ixbH/37glxgsTPCpCAuQPTDMH98e
; 70cquz9G9NRI+ex75JQzxeAUMcsw
; TtiY19vVTEPfrbRorDAxLRC720BV
; pJ9ZOQBBl8A9ss2R022TCSoBR44d
; BqY2e7M5nyUBaIkFkvF9+wyxa24+
; MHBli9qC91C+4uuTpqVhZjtnOjKQ
; 8UMRVZoZ5qTrn6EV9x5qq5akItf7
; hi1BEjJKylYdcplg5x3JDqkKGnso
; OS45mvo3fOt0owujArlEnsPy8+I3
; LwL1W68VdjG1CnTEp2HFpqbnoxQ1
; KhpKWErf/HEYxOnDgsXljUDuWOEX
; wj+UOYSnRzRekFGfSu211D447iHl
; 8XHISQ== )
```
### What is the expected *correct* behavior?
RRSIG (or any other RR) is not split across lines.https://gitlab.isc.org/isc-projects/bind9/-/issues/4024named took too long to terminate in respdiff-long-third-party job2023-05-24T11:27:31ZMichal Nowaknamed took too long to terminate in respdiff-long-third-party jobJob [#3333558](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3333558) failed for 6892e463bf7daf93c332d33919c20f978a39b539.
60 seconds wasn't enough for `named` in `respdiff-long-third-party` to terminate and has been aborted instead....Job [#3333558](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3333558) failed for 6892e463bf7daf93c332d33919c20f978a39b539.
60 seconds wasn't enough for `named` in `respdiff-long-third-party` to terminate and has been aborted instead.
```
[Current thread is 1 (Thread 0x7f80690d6140 (LWP 17957))]
#0 0x00007f806b984d56 in epoll_wait (epfd=4, events=0x7ffe696dc2c0, maxevents=1024, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
#1 0x00007f806bd6d83a in uv__io_poll (loop=0x7f8068ca2220, timeout=-1) at /usr/src/libuv-v1.44.1/src/unix/epoll.c:236
#2 0x00007f806bd528ae in uv_run (loop=0x7f8068ca2220, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.44.1/src/unix/core.c:391
#3 0x00007f806c3e1b73 in loop_run (loop=loop@entry=0x7f8068ca2200) at loop.c:272
#4 0x00007f806c3e1c16 in loop_thread (arg=0x7f8068ca2200) at loop.c:299
#5 0x00007f806c3e29af in isc_loopmgr_run (loopmgr=0x7f8068c1c1c0) at loop.c:473
#6 0x000055ea5742e0e0 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1513
```
Full backtrace and logs were saved as part of CI artifacts.https://gitlab.isc.org/isc-projects/bind9/-/issues/4026REQUIRE(handle->sock->tid == isc_tid()) shortly after zone file changed in xf...2023-11-02T09:22:14ZMichal NowakREQUIRE(handle->sock->tid == isc_tid()) shortly after zone file changed in xferquota system testJob [#3337779](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3337779) failed for 6892e463bf7daf93c332d33919c20f978a39b539 on OpenBSD.
```
S:xferquota:2023-04-20T08:37:42+0000
T:xferquota:1:A
A:xferquota:System test xferquota
I:xferqu...Job [#3337779](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3337779) failed for 6892e463bf7daf93c332d33919c20f978a39b539 on OpenBSD.
```
S:xferquota:2023-04-20T08:37:42+0000
T:xferquota:1:A
A:xferquota:System test xferquota
I:xferquota:PORTS:14569,14570,14571,14572,14573,14574,14575,14576,14577,14578,14579,14580,14581
I:xferquota:starting servers
I:xferquota:Have 70 zones up in 1 seconds
I:xferquota:Changing test zone...
I:xferquota:Have 70 zones up in 2 seconds
...
I:xferquota:Have 70 zones up in 359 seconds
I:xferquota:Took too long to load zones
I:xferquota:stopping servers
I:xferquota:ns1 died before a SIGTERM was sent
```
The core dump timestamp is 8∶37∶49 UTC, 7 seconds after the test started, when `netmgr/netmgr.c:1016: REQUIRE(handle->sock->tid == isc_tid()) failed` was hit.
```
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:Core was generated by `named'.
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:Program terminated with signal SIGABRT, Aborted.
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#0 thrkill () at /tmp/-:3
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:[Current thread is 1 (process 317378)]
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#0 thrkill () at /tmp/-:3
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#1 0x00000b231f341b8e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#2 0x00000b2070b225f2 in assertion_failed (file=0xb22c97fc318 "netmgr/netmgr.c", line=1016, type=isc_assertiontype_require, cond=<optimized out>) at main.c:222
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#3 0x00000b22c98236a0 in isc_assertion_failed (file=0x0, line=6, type=isc_assertiontype_require, cond=0xb231f370d6a <thrkill+10> "r\001\303d\211\004% ") at assertions.c:48
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#4 0x00000b22c9811a1e in isc__nmhandle_detach (handlep=<optimized out>) at netmgr/netmgr.c:1016
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#5 0x00000b2294782f20 in dispentry_destroy (resp=0xb234a87c820) at dispatch.c:469
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#6 dns_dispentry_unref (ptr=0xb234a87c820) at dispatch.c:488
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#7 0x00000b2294849ae2 in request_cancel (request=0xb234a867820) at request.c:805
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#8 dns_request_cancel (request=0xb234a867820) at request.c:818
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#9 0x00000b2294849948 in dns_requestmgr_shutdown (requestmgr=<optimized out>) at request.c:192
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#10 0x00000b229488dcfc in dns_view_detach (viewp=<optimized out>) at view.c:479
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#11 0x00000b2070b38a0f in load_configuration (filename=<optimized out>, server=<optimized out>, first_time=<optimized out>) at server.c:9730
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#12 0x00000b2070b26d0c in loadconfig (server=0xb230654ca20) at server.c:10306
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#13 reload (server=0xb230654ca20) at server.c:10332
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#14 0x00000b22c9823a50 in isc__async_cb (handle=<optimized out>) at async.c:84
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#15 0x00000b22df1f474d in uv.async_io () from /usr/local/lib/libuv.so.4.1
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#16 0x00000b22df206812 in uv.io_poll () from /usr/local/lib/libuv.so.4.1
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#17 0x00000b22df1f4e08 in uv_run () from /usr/local/lib/libuv.so.4.1
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#18 0x00000b22c9838e82 in loop_run (loop=0xb22951bc020) at loop.c:272
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#19 loop_thread (arg=0xb22951bc020) at loop.c:299
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#20 0x00000b22c9838d4f in isc_loopmgr_run (loopmgr=0xb230654ff20) at loop.c:473
D:/builds/isc-projects/bind9/bin/tests/system/xferquota:#21 0x00000b2070b2209e in main (argc=<optimized out>, argv=<optimized out>) at main.c:1513
```
Artifacts were saved in GitLab CI.Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4036Run fuzz/ tests as part of unit CI jobs on bind-9.162023-04-26T10:39:20ZMichal NowakRun fuzz/ tests as part of unit CI jobs on bind-9.16On `bind-9.16`, the `fuzz/` tests are [not being run as part of the unit CI jobs](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3348523); they [are](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3348327) run on `main` and `bind-9.1...On `bind-9.16`, the `fuzz/` tests are [not being run as part of the unit CI jobs](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3348523); they [are](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3348327) run on `main` and `bind-9.18` as part of unit CI jobs.
On `bind-9.16`, `fuzz/` tests are only run when the `check` target is run from the root of the project.
Hence isc-projects/bind9#4035 was missed.https://gitlab.isc.org/isc-projects/bind9/-/issues/4051udp_recv_send unit test hangs intermittently, causing udp_test to fail2023-05-10T08:39:47ZMichał Kępieńudp_recv_send unit test hangs intermittently, causing udp_test to failhttps://gitlab.isc.org/isc-private/bind9/-/jobs/3366257
```
[==========] Running 18 test(s).
[ RUN ] mock_listenudp_uv_udp_open
[ OK ] mock_listenudp_uv_udp_open
[ RUN ] mock_listenudp_uv_udp_bind
[ OK ] mock_liste...https://gitlab.isc.org/isc-private/bind9/-/jobs/3366257
```
[==========] Running 18 test(s).
[ RUN ] mock_listenudp_uv_udp_open
[ OK ] mock_listenudp_uv_udp_open
[ RUN ] mock_listenudp_uv_udp_bind
[ OK ] mock_listenudp_uv_udp_bind
[ RUN ] mock_listenudp_uv_udp_recv_start
[ OK ] mock_listenudp_uv_udp_recv_start
[ RUN ] mock_udpconnect_uv_udp_open
[ OK ] mock_udpconnect_uv_udp_open
[ RUN ] mock_udpconnect_uv_udp_bind
[ OK ] mock_udpconnect_uv_udp_bind
[ RUN ] mock_udpconnect_uv_udp_connect
[ OK ] mock_udpconnect_uv_udp_connect
[ RUN ] mock_udpconnect_uv_recv_buffer_size
[ OK ] mock_udpconnect_uv_recv_buffer_size
[ RUN ] mock_udpconnect_uv_send_buffer_size
[ OK ] mock_udpconnect_uv_send_buffer_size
[ RUN ] udp_noop
[ OK ] udp_noop
[ RUN ] udp_noresponse
[ OK ] udp_noresponse
[ RUN ] udp_shutdown_connect
[ OK ] udp_shutdown_connect
[ RUN ] udp_shutdown_read
[ OK ] udp_shutdown_read
[ RUN ] udp_cancel_read
[ OK ] udp_cancel_read
[ RUN ] udp_timeout_recovery
[ OK ] udp_timeout_recovery
[ RUN ] udp_double_read
[ OK ] udp_double_read
[ RUN ] udp_recv_one
[ OK ] udp_recv_one
[ RUN ] udp_recv_two
[ OK ] udp_recv_two
[ RUN ] udp_recv_send
PID 7802 exceeded run time limit, sending SIGABRT
```
Not sure what happened here. Threads seem to be idle. Artifacts were
preserved, including a core dump of the hung test process.
So far I have only seen this on `main`.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4057dig XDG basedir support2023-05-12T07:24:54ZPaul Töttermandig XDG basedir support### Description
Check ${XDG_CONFIG_HOME}/dig/digrc in addition to ~/.digrc
### Links / references
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html### Description
Check ${XDG_CONFIG_HOME}/dig/digrc in addition to ~/.digrc
### Links / references
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.htmlNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4058BIND resolver incorrectly handles NODATA/NOERROR (NXRRSET) query response whe...2023-12-19T09:18:49ZCathy AlmondBIND resolver incorrectly handles NODATA/NOERROR (NXRRSET) query response when CNAME is queried during prefetch### Summary
"A" fetch to an auth server returns "CNAME". But (it appears), with prefetch enabled (the default), when the "CNAME" is fetched the authoritative sends back noanswer/noerror = NXRRSET). Clearly this is broken behaviour on t...### Summary
"A" fetch to an auth server returns "CNAME". But (it appears), with prefetch enabled (the default), when the "CNAME" is fetched the authoritative sends back noanswer/noerror = NXRRSET). Clearly this is broken behaviour on the part of the Auth servers (or they just changed their zone from providing a CNAME to providing an answer) but I still don't see why it breaks a BIND resolver - which should just at this point understand that the CNAME no longer exists and (as needed, as a result of client queries) query instead from the beginning with the RTYPE the client needs to have resolved.
Instead, the resolver is returning the empty answer to querying clients (who are not querying for CNAME, they are querying the resolver for A)
See [Support ticket 22027](https://support.isc.org/Ticket/Display.html?id=22027)
### BIND version used
9.16.35-S1
### Steps to reproduce
We don't have a reproducer at this time, but see the Support ticket for more details on what's happening. You need an authoritative server that responds with a CNAME (with a valid target) when queried for A (or other) rtypes for a name, but when queried explicitly for CNAME, sends back noerror/noanswer (essentially NXRRSET). Then enable prefetch and keep querying the server for record type A until the CNAME is close to expiry and is therefore prefetched explicitly...
### What is the current *bug* behavior?
When we are handling a client query, we are making queries to cache or to authoritative servers (cache miss) but all of those queries are for the RTYPE that we want to resolve. We don't query for type CNAME. IF we hit a CNAME along the way, then that will cause us to start a new query (from cache or initiate a fetch if we need to) using the target of the CNAME as the new name to be queried.
So far so good. This implies that the code that looks in cache and gets an answer from a fetch handles CNAME as a special case and that we likely look for or cache EXPLICITLY for CNAMEs while we're looking for the RTYPE that we actually want to resolve.
I suspect that we would not expect to find in cache an NXRRSET of type CNAME. Essentially this is meaningless to us - if CNAME doesn't exist than any other record type might exist, we just don't know, it might as well just not be there.
If we get back 'NXRRSET' from a fetch for type CNAME, do we even add it to cache, or does this result in us deleting the original CNAME RR?
Whatever we do with it, it appears to 'break' the cache so that clients get back NOANSWER (empty answer) instead of named doing another fetch based on the RTYPE of the client query made after this CNAME has been refreshed.
### What is the expected *correct* behavior?
Getting a 'NXRRSET' query response from an auth server that has explicitly been queried for a CNAME RR (to refresh what was in cache before - as instigated by prefetch) should not cause the cache to no longer be able to resolve queries for that name for other RTYPEs.
Subsequent client queries after receipt of the auth answer that says that the CNAME no longer exists, should cause new fetches to the auth server with the RTYPE of the client query in them.
Is it remotely possibly however, that finding a CNAME in cache (since we already know that we do something special if we find it) but then finding that it's not a pointer to 'go look up this name instead of the one you had' but instead is NXRRSET (whoa that wasn't what we expected to find!) could cause something aberrant to happen ... ? Or maybe this is a subtle race condition do with replacing the CNAME with NXRRSET for the CNAME (or deleting it entirely) because of the query response from the auth server, and this happening as a result of the prefetch, but now racing with the next client query that is looking in cache?
### Relevant configuration files
No configs - nothing special needed, just prefetch enabled so that when the CNAME in cache is close to expiry, a client query will trigger a prefetch.
### Relevant logs and/or screenshots
N/A - please see support ticket for more details
### Possible fixes
N/A
(P.S. With the info available and with what we know it was very hard to complete this report per the template).BIND 9.21.xMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4065Could query-source be made best-effort, not preventing startup in case of fai...2023-06-16T09:03:46ZPetr MenšíkCould query-source be made best-effort, not preventing startup in case of failure?### Description
Could be specification of outgoing addresses made non-fatal? Some users try to configure used outgoing address by named. But then they are surprised it creates problem during startup, because those addresses might not ye...### Description
Could be specification of outgoing addresses made non-fatal? Some users try to configure used outgoing address by named. But then they are surprised it creates problem during startup, because those addresses might not yet be available.
### Request
Could it be possible to specify ``query-source 10.1.2.3 optional;``, which would behave similar way to FREEBIND for listening sockets? If the socket could not be bound, just use whatever default address system provides. But try to use that address if that would work. It would allow also starting with not yet present addresses, which would appear later.
Alternative would be delaying root primining queries until listen-on machinery detects source address available. That seems a lot more complicated.
### Links / references
- https://bugzilla.redhat.com/show_bug.cgi?id=2195976https://gitlab.isc.org/isc-projects/bind9/-/issues/4084auto-tune transfers-in, transfers-out, transfers-per-ns and friends2023-05-30T12:53:01ZCathy Almondauto-tune transfers-in, transfers-out, transfers-per-ns and friends### Description
The problem, as noted in [Support ticket #21991](https://support.isc.org/Ticket/Display.html?id=21991), is that without testing in a production environment and under specific circumstances (speed of network, configuratio...### Description
The problem, as noted in [Support ticket #21991](https://support.isc.org/Ticket/Display.html?id=21991), is that without testing in a production environment and under specific circumstances (speed of network, configuration of primaries per zone, reachability, rate of zone update propagation and so on), it's hard to know what sane values to give to the options for tuning zone transfers. The types of things that need to be optimised are:
- Speed of synchronisation/completion of refreshes following a secondary server restart
- Effective use of CPU resources so that servers are not idling while there is work that could be done
- No interruption to client services during zone refreshes (for servers that are currently client-facing)
- Effective onward zone update propagation/refreshes (for servers that are intermediaries in the zone update propagation path)
- Speed of propagation of zone updates during normal operation (i.e. not when restarting something...)
### Request
I'd like transfers-in, transfers-out, transfers-per-ns and friends to be able to auto-tune themselves based on knowledge of how the server is performing.
See other work currently ongoing:
#3883
#3914
### Links / referencesNot plannedhttps://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/4092timer.c:223:timerevent_destroy(): fatal error: RUNTIME_CHECK(isc_mutex_unlock...2023-05-25T07:38:17ZMichal Nowaktimer.c:223:timerevent_destroy(): fatal error: RUNTIME_CHECK(isc_mutex_unlock((&timer->lock)) == ISC_R_SUCCESS) failedJob [#3411550](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3411550) failed for 66254cf56d7072833db6d8744e6bcef2109b72e2.
BIND 9.18 `task` unit test failed on `unit:gcc:oraclelinux8:amd64`.
```
[==========] Running 11 test(s).
[ RU...Job [#3411550](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3411550) failed for 66254cf56d7072833db6d8744e6bcef2109b72e2.
BIND 9.18 `task` unit test failed on `unit:gcc:oraclelinux8:amd64`.
```
[==========] Running 11 test(s).
[ RUN ] manytasks
[ OK ] manytasks
[ RUN ] all_events
[ OK ] all_events
[ RUN ] basic
timer.c:223:timerevent_destroy(): fatal error: RUNTIME_CHECK(isc_mutex_unlock((&timer->lock)) == ISC_R_SUCCESS) failed
../../tests/unit-test-driver.sh: line 36: 8595 Aborted (core dumped) "${TEST_PROGRAM}"
I:task_test:Core dump found: ./core.8595
D:task_test:backtrace from ./core.8595 start
[New LWP 8636]
[New LWP 8595]
[New LWP 8637]
[New LWP 8638]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/builds/isc-projects/bind9/tests/isc/.libs/lt-task_test'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f8c5b302aff in raise () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7f8c3bfff700 (LWP 8636))]
Thread 4 (Thread 0x7f8c412fa700 (LWP 8638)):
#0 0x00007f8c5b68846c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f8c5c4af725 in run (uap=0x7f8c591e1000) at timer.c:632
manager = 0x7f8c591e1000
now = {seconds = 1684976709, nanoseconds = 609640403}
result = <optimized out>
__func__ = "run"
#2 0x00007f8c5c4b4b20 in isc__trampoline_run (arg=0x1973730) at trampoline.c:189
trampoline = 0x1973730
result = <optimized out>
#3 0x00007f8c5b6821da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00007f8c5b2ede73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 3 (Thread 0x7f8c40af9700 (LWP 8637)):
#0 0x00007f8c5b3e4017 in epoll_wait () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f8c5c2460f9 in uv.io_poll () from /lib64/libuv.so.1
No symbol table info available.
#2 0x00007f8c5c234a74 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#3 0x00007f8c5c47aa6c in nm_thread (worker0=0x7f8c591f75b8) at netmgr/netmgr.c:698
r = <optimized out>
worker = 0x7f8c591f75b8
mgr = 0x7f8c59036000
__func__ = "nm_thread"
#4 0x00007f8c5c4b4b20 in isc__trampoline_run (arg=0x1974330) at trampoline.c:189
trampoline = 0x1974330
result = <optimized out>
#5 0x00007f8c5b6821da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#6 0x00007f8c5b2ede73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 2 (Thread 0x7f8c5ce04140 (LWP 8595)):
#0 0x00007f8c5b3ae9a8 in nanosleep () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f8c5b3dbf48 in usleep () from /lib64/libc.so.6
No symbol table info available.
#2 0x00007f8c5c4ac692 in isc__taskmgr_destroy (managerp=managerp@entry=0x607348 <taskmgr>) at task.c:1041
No locals.
#3 0x00007f8c5c49b4b0 in isc_managers_destroy (netmgrp=netmgrp@entry=0x607338 <netmgr>, taskmgrp=taskmgrp@entry=0x607348 <taskmgr>, timermgrp=timermgrp@entry=0x607340 <timermgr>) at managers.c:99
No locals.
#4 0x00000000004052ee in teardown_managers (state=<optimized out>) at isc.c:84
No locals.
#5 0x0000000000404f64 in _teardown (state=<optimized out>) at task_test.c:91
No locals.
#6 0x00007f8c5be1702e in cmocka_run_one_test_or_fixture () from /lib64/libcmocka.so.0
No symbol table info available.
#7 0x00007f8c5be179e0 in _cmocka_run_group_tests () from /lib64/libcmocka.so.0
No symbol table info available.
#8 0x000000000040516b in main () at task_test.c:1408
r = <optimized out>
Thread 1 (Thread 0x7f8c3bfff700 (LWP 8636)):
#0 0x00007f8c5b302aff in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f8c5b2d5ea5 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x00007f8c5c48f5c2 in isc_error_fatal (file=file@entry=0x7f8c5c4c45a6 "timer.c", line=line@entry=223, func=func@entry=0x7f8c5c4d07a0 <__func__.7544> "timerevent_destroy", format=format@entry=0x7f8c5c4c0814 "RUNTIME_CHECK(%s) failed") at error.c:72
args = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7f8c3bff9d00, reg_save_area = 0x7f8c3bff9c40}}
#3 0x00007f8c5c4af15f in timerevent_destroy (event0=0x7f8c51800b00) at timer.c:225
timer = 0x7f8c591e10a0
event = 0x7f8c51800b00
__func__ = "timerevent_destroy"
#4 0x00007f8c5c48f7e9 in isc_event_free (eventp=eventp@entry=0x7f8c3bff9d48) at event.c:93
event = <optimized out>
#5 0x0000000000403449 in basic_tick (task=<optimized out>, event=<optimized out>) at task_test.c:444
No locals.
#6 0x00007f8c5c4abf17 in task_run (task=0x7f8c591e73c0) at task.c:815
dispatch_count = 0
finished = false
quantum = <optimized out>
event = 0x7f8c51800b00
result = ISC_R_SUCCESS
dispatch_count = <optimized out>
finished = <optimized out>
event = <optimized out>
result = <optimized out>
quantum = <optimized out>
__func__ = "task_run"
__atomic_load_ptr = <optimized out>
__atomic_load_tmp = <optimized out>
__atomic_load_ptr = <optimized out>
__atomic_load_tmp = <optimized out>
__atomic_load_ptr = <optimized out>
__atomic_load_tmp = <optimized out>
__atomic_load_ptr = <optimized out>
__atomic_load_tmp = <optimized out>
__v = <optimized out>
#7 isc_task_run (task=0x7f8c591e73c0) at task.c:896
No locals.
#8 0x00007f8c5c472579 in isc__nm_async_task (worker=worker@entry=0x7f8c591f7000, ev0=ev0@entry=0x7f8c51805f80) at netmgr/netmgr.c:848
ievent = 0x7f8c51805f80
result = <optimized out>
#9 0x00007f8c5c479d78 in process_netievent (worker=worker@entry=0x7f8c591f7000, ievent=ievent@entry=0x7f8c51805f80) at netmgr/netmgr.c:920
No locals.
#10 0x00007f8c5c47a78e in process_queue (worker=worker@entry=0x7f8c591f7000, type=type@entry=NETIEVENT_TASK) at netmgr/netmgr.c:1013
next = 0x0
ievent = 0x7f8c51805f80
list = {head = 0x0, tail = 0x0}
__func__ = "process_queue"
#11 0x00007f8c5c47b23b in process_all_queues (worker=0x7f8c591f7000) at netmgr/netmgr.c:767
result = <optimized out>
type = 2
reschedule = false
reschedule = <optimized out>
type = <optimized out>
result = <optimized out>
#12 async_cb (handle=0x7f8c591f7360) at netmgr/netmgr.c:796
worker = 0x7f8c591f7000
#13 0x00007f8c5c2342f1 in uv.async_io.part () from /lib64/libuv.so.1
No symbol table info available.
#14 0x00007f8c5c245d15 in uv.io_poll () from /lib64/libuv.so.1
No symbol table info available.
#15 0x00007f8c5c234a74 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#16 0x00007f8c5c47aa6c in nm_thread (worker0=0x7f8c591f7000) at netmgr/netmgr.c:698
r = <optimized out>
worker = 0x7f8c591f7000
mgr = 0x7f8c59036000
__func__ = "nm_thread"
#17 0x00007f8c5c4b4b20 in isc__trampoline_run (arg=0x1976840) at trampoline.c:189
trampoline = 0x1976840
result = <optimized out>
#18 0x00007f8c5b6821da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#19 0x00007f8c5b2ede73 in clone () from /lib64/libc.so.6
No symbol table info available.
D:task_test:backtrace from ./core.8595 end
FAIL task_test (exit status: 134)
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4099[PATCH] +shortans2023-05-30T13:24:54ZFredrick Brennan[PATCH] +shortans# Patch
```diff
From 6041dcb60313b5fd81076bd53713b8a53fb95f87 Mon Sep 17 00:00:00 2001
From: Fredrick Brennan <copypaste@kittens.ph>
Date: Sat, 27 May 2023 08:23:45 -0400
Subject: [PATCH] [dig] +shortans
---
bin/dig/dig.c | 48 +++++...# Patch
```diff
From 6041dcb60313b5fd81076bd53713b8a53fb95f87 Mon Sep 17 00:00:00 2001
From: Fredrick Brennan <copypaste@kittens.ph>
Date: Sat, 27 May 2023 08:23:45 -0400
Subject: [PATCH] [dig] +shortans
---
bin/dig/dig.c | 48 ++++++++++++++++++++++++++++++++++++------------
bin/dig/dig.rst | 4 ++++
doc/man/dig.1in | 5 +++++
3 files changed, 45 insertions(+), 12 deletions(-)
diff --git a/bin/dig/dig.c b/bin/dig/dig.c
index 694924c0f2..dd9bfcd4a7 100644
--- a/bin/dig/dig.c
+++ b/bin/dig/dig.c
@@ -286,6 +286,8 @@ help(void) {
"short\n"
" form of answers - global "
"option)\n"
+ " +[no]shortans (equivalent to `+noall"
+ "+authority +answer`)\n"
" +[no]showbadcookie (Show BADCOOKIE message)\n"
" +[no]showsearch (Search with intermediate "
"results)\n"
@@ -1901,18 +1903,40 @@ plus_option(char *option, bool is_batchfile, bool *need_clone,
goto invalid_option;
}
switch (cmd[3]) {
- case 'r': /* short */
- FULLCHECK("short");
- short_form = state;
- if (state) {
- printcmd = false;
- lookup->section_additional = false;
- lookup->section_answer = true;
- lookup->section_authority = false;
- lookup->section_question = false;
- lookup->comments = false;
- lookup->stats = false;
- lookup->rrcomments = -1;
+ case 'r': /* shor… */
+ switch(cmd[4]) {
+ case 't': /* short… */
+ switch(cmd[5]) { /* short */
+ case '\0':
+ FULLCHECK("short");
+ short_form = state;
+ if (state) {
+ printcmd = false;
+ lookup->section_additional = false;
+ lookup->section_answer = true;
+ lookup->section_authority = false;
+ lookup->section_question = false;
+ lookup->comments = false;
+ lookup->stats = false;
+ lookup->rrcomments = -1;
+ }
+ break;
+ case 'a': /* shortans */
+ FULLCHECK("shortans");
+ lookup->section_question = !state;
+ lookup->section_authority = state;
+ lookup->section_answer = state;
+ lookup->section_additional = !state;
+ lookup->comments = !state;
+ lookup->stats = !state;
+ printcmd = !state;
+ break;
+ default:
+ goto invalid_option;
+ }
+ break;
+ default:
+ goto invalid_option;
}
break;
case 'w': /* showsearch */
diff --git a/bin/dig/dig.rst b/bin/dig/dig.rst
index a5bfb86556..75237f0ae0 100644
--- a/bin/dig/dig.rst
+++ b/bin/dig/dig.rst
@@ -571,6 +571,10 @@ abbreviation is unambiguous; for example, :option:`+cd` is equivalent to
form. This option always has a global effect; it cannot be set globally and
then overridden on a per-lookup basis.
+.. option:: +shortans, +noshortans
+
+ This option expands to :option:`+noall` :option:`+authority` :option:`+answer`.
+
.. option:: +showbadcookie, +noshowbadcookie
This option toggles whether to show the message containing the
diff --git a/doc/man/dig.1in b/doc/man/dig.1in
index d5f42ed852..1607d7f2ca 100644
--- a/doc/man/dig.1in
+++ b/doc/man/dig.1in
@@ -663,6 +663,11 @@ then overridden on a per\-lookup basis.
.UNINDENT
.INDENT 0.0
.TP
+.B +shortans, +noshortans
+This option expands to \fI\%+noall\fP \fI\%+authority\fP \fI\%+answer\fP\&.
+.UNINDENT
+.INDENT 0.0
+.TP
.B +showbadcookie, +noshowbadcookie
This option toggles whether to show the message containing the
BADCOOKIE rcode before retrying the request or not. The default
--
2.40.1
```
# Detached signature
```gpg
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQS1rLeeEfG/f0nzK7hYUwVpYvFOWAUCZHH3EAAKCRBYUwVpYvFO
WOiHAP9uTERa4rrztKKeqk1TSLkqP5RgDnBbgxcbTkHAt5q7/wEAvffIjE5SUX8P
RpxZ9yS2geRmVXwyLDiS4FjxN3u7vgE=
=i92K
-----END PGP SIGNATURE-----
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4100REQUIRE(((multi) != ((void *)0) && ((const isc__magic_t *)(multi))->magic == ...2023-05-30T08:09:36ZMichal NowakREQUIRE(((multi) != ((void *)0) && ((const isc__magic_t *)(multi))->magic == ((('q') << 24 | ('p') << 16 | ('m') << 8 | ('v'))))) in qp.cJob [#3424074](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3424074) failed for 2e8ceeea14e336980c9da80449b84ecd16afc7e5.
The `qpmulti_test` unit test failed.
```
[==========] Running 1 test(s).
[ RUN ] qpmulti
qp.c:634: REQUI...Job [#3424074](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3424074) failed for 2e8ceeea14e336980c9da80449b84ecd16afc7e5.
The `qpmulti_test` unit test failed.
```
[==========] Running 1 test(s).
[ RUN ] qpmulti
qp.c:634: REQUIRE(((multi) != ((void *)0) && ((const isc__magic_t *)(multi))->magic == ((('q') << 24 | ('p') << 16 | ('m') << 8 | ('v'))))) failed, back trace
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.14-dev.so(+0x2ddb2)[0x7f231ea2ddb2]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.14-dev.so(isc_assertion_failed+0xa)[0x7f231ea2dd2d]
/builds/isc-projects/bind9/lib/dns/.libs/libdns-9.19.14-dev.so(+0xb9fe3)[0x7f231e0b9fe3]
/lib64/liburcu.so.6(+0x37a9)[0x7f231d64e7a9]
/lib64/libpthread.so.0(+0x81da)[0x7f231dbdd1da]
/lib64/libc.so.6(clone+0x43)[0x7f231ceafe73]
../../tests/unit-test-driver.sh: line 36: 13597 Aborted (core dumped) "${TEST_PROGRAM}"
FAIL qpmulti_test (exit status: 134)
```
There's no core file or full backtrace in the logs.