BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-10-28T18:58:08Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3291Supporting HTTPS in parallel with CNAME2022-10-28T18:58:08ZMark AndrewsSupporting HTTPS in parallel with CNAMEAs HTTPS take-up happens there will likely be zones that emit both CNAME and HTTP at the same name (especially at the zone apex). We want to encourage HTTPS use and the presence of the CNAME record in a cache will prevent the HTTPS reco...As HTTPS take-up happens there will likely be zones that emit both CNAME and HTTP at the same name (especially at the zone apex). We want to encourage HTTPS use and the presence of the CNAME record in a cache will prevent the HTTPS record being looked up and returned. Tag CNAME records learnt via HTTPS lookups (HTTPSCNAME) and only return CNAMEs so tagged when looking for HTTPS records. This will interact with the tagging of CNAME learnt via DS lookups. Existing DSCNAME attributes (!6140) will need to copied to the new header when adding a HTTPSCNAME and vice versa.
This should be a sort term change with a lifetime of a few years.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3282When using a forwarder, zones that return CNAME queries at the apex fail to v...2022-05-04T15:57:57ZMark AndrewsWhen using a forwarder, zones that return CNAME queries at the apex fail to validateIn theory CNAME and DS records should never potentially exist at the same name. When servers return CNAME for apex queries this property is broken resulting in caches where DS and CNAME can both appear at the same name. The attached ...In theory CNAME and DS records should never potentially exist at the same name. When servers return CNAME for apex queries this property is broken resulting in caches where DS and CNAME can both appear at the same name. The attached named.run show this using the named.conf below which implements both the local recursive server and forwarder within the one process. Restrict the operating family to IPv4 and turned off qname-minimization and empty-zones-enable to reduce the extraneous logging.
bin/named/named -g -c named.conf -d 100 -4 > & named.run
dig -p 7777 @127.0.0.1 am-explorer.com
```
key forward {
algorithm hmac-sha256;
secret "aaaabbbbccccdddd";
};
options {
listen-on port 7777 { any; };
listen-on-v6 port 7777 { any; };
pid-file none;
qname-minimization off;
empty-zones-enable no;
};
view local {
server 127.0.0.1 { keys forward; };
match-clients { !key forward; any; };
forwarders port 7777 { 127.0.0.1; };
forward only;
};
view forward {
match-clients { key forward; };
};
```
[named.run](/uploads/d8e891290cffc1fc59b4f70b5adfe317/named.run)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3277Follow-up from "Draft: Don't delete CDS DELETE after zone sign"2022-04-12T13:18:41ZMatthijs Mekkingmatthijs@isc.orgFollow-up from "Draft: Don't delete CDS DELETE after zone sign"The following discussion from !5706 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5706#note_259110):
While the changes are fine. I'm worried about a disconnect betwe...The following discussion from !5706 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5706#note_259110):
While the changes are fine. I'm worried about a disconnect between parent and child over the signalling method (CDS vs CDNSKEY) in use. Always publishing matching CDS DELETE and CDNSKEY DELETE records avoids this.
When an update adds a CDS DELETE record, BIND should also add the corresponding CDNSKEY DELETE record (if not already done in the update), and vice versa. Also when an update removes a CDS DELETE record, BIND should remove the corresponding CDNSKEY DELETE record (if not already done in the update), and vice versa.
It is unclear what the desired behavior is if an update adds a CDS DELETE record and removes a CDNSKEY DELETE record at the same time.
Note that with `dnssec-policy` the CDS DELETE and CDNSKEY DELETE records are already synced (when setting `dnssec-policy` to `insecure`).Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3231forward queries via DoH2023-11-02T17:05:04ZDaniel Mittonforward queries via DoH### Description
How do you configure bind to forward queries, regardless of initial connection type, via DoH/DoT?
### Request
Forwarder configuration that specifies that forwarded queries are to be forwarded over DoH/Dot.
### Links /...### Description
How do you configure bind to forward queries, regardless of initial connection type, via DoH/DoT?
### Request
Forwarder configuration that specifies that forwarded queries are to be forwarded over DoH/Dot.
### Links / referencesNot plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3192[ISC-support #20070] Wildcards, literal asterisk labels, and RPZ zones2024-02-14T14:54:18ZChuck Stearns[ISC-support #20070] Wildcards, literal asterisk labels, and RPZ zones### Summary
A literal asterisk in a RR label can be used to bypass RPZ records.
### BIND version used
9.11.33-S1 (though I think this also affects 9.16 and 9.18)
### Steps to reproduce
RPZ entries:
```
test.com CNAME .
*.test.com C...### Summary
A literal asterisk in a RR label can be used to bypass RPZ records.
### BIND version used
9.11.33-S1 (though I think this also affects 9.16 and 9.18)
### Steps to reproduce
RPZ entries:
```
test.com CNAME .
*.test.com CNAME .
```
AND
test.com zone containing `*.test.com {type} {value}` (must not be delegated)
OR
sub.*.test.com zone definition
Example test:
```
$ dig @0 test.sub.\*.test.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> @0 test.sub.*.test.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62448
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;test.sub.*.test.com. IN A
;; ANSWER SECTION:
test.sub.*.test.com. 3600 IN A 127.0.0.1
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(0.0.0.0)
;; WHEN: Wed Jan 26 16:47:19 EST 2022
;; MSG SIZE rcvd: 64
```
### What is the current *bug* behavior?
Queries containing a literal asterisk (such as `sub.*.test.com` or `*.test.com`) will be answered, rather than caught by RPZ.
### What is the expected *correct* behavior?
RPZ expected to catch the query, like so:
```
$ dig @0 sub.test.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> @0 sub.test.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31154
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sub.test.com. IN A
;; ADDITIONAL SECTION:
localhost.rpz. 1 IN SOA localhost. postmaster.localhost. 2004052401 3600 1800 604800 3600
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(0.0.0.0)
;; WHEN: Wed Jan 26 16:40:21 EST 2022
;; MSG SIZE rcvd: 110
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3136dnstap-read: add incremental packet number to the output2022-02-10T15:06:10Zmartinvonwittichdnstap-read: add incremental packet number to the output### Description
Currently, `dnstap-read` doesn't print any kind of unique identifier per packet. E.g. if I'm using it without any options to get the short summary format:
```
09-Feb-2022 02:33:36.294 CQ 127.0.0.1:41718 -> 127.0.0.1:0 U...### Description
Currently, `dnstap-read` doesn't print any kind of unique identifier per packet. E.g. if I'm using it without any options to get the short summary format:
```
09-Feb-2022 02:33:36.294 CQ 127.0.0.1:41718 -> 127.0.0.1:0 UDP 33b example.com/IN/MX
09-Feb-2022 02:33:36.334 RR 192.168.1.2:55163 <- 192.168.1.1:53 UDP 71b example.com/IN/MX
09-Feb-2022 02:33:36.294 RQ 192.168.1.2:55163 -> 192.168.1.1:53 UDP 33b example.com/IN/MX
09-Feb-2022 02:33:36.334 CR 127.0.0.1:41718 <- 127.0.0.1:0 UDP 102b example.com/IN/MX
09-Feb-2022 02:33:38.453 CQ 127.0.0.1:57293 -> 127.0.0.1:0 UDP 33b example.com/IN/MX
09-Feb-2022 02:33:38.453 CR 127.0.0.1:57293 <- 127.0.0.1:0 UDP 102b example.com/IN/MX
```
and then I want to lookup the details of one of these packets in the `-p` format, I have to search for the whole line to find it.
It's even worse in the `-y` format because contrary to the `-p` format, the YAML representation doesn't contain the original summary line, and while the summary and `-p` will print timestamps in the local timezone, `-y` will print UTC timestamps.
### Request
I would like `dnstap-read` to prefix each packet with an incremental number in the summary and in the `-p` output, so that the details for a packet can easily be searched. The YAML representation should contain the number in an additional YAML field.
### Links / references
I like the way it works in `tshark` - each line in the summary is prefixed with an incremental packet number:
```
server ~ # tshark -i ens3 -w test.pcap
Running as user "root" and group "root". This could be dangerous.
Capturing on 'ens3'
4 ^C
server ~ # tshark -r test.pcap
Running as user "root" and group "root". This could be dangerous.
1 2022-02-09 17:43:01,528756106 02:00:62:3e:71:f5 → 02:00:62:3e:71:f9 ARP 42 Who has 172.16.56.10? Tell 172.16.0.1
2 2022-02-09 17:43:01,528792938 02:00:62:3e:71:f9 → 02:00:62:3e:71:f5 ARP 42 172.16.56.10 is at 02:00:62:3e:71:f9
3 2022-02-09 17:43:02,068971390 172.16.56.10 → 172.21.0.10 SSH 102 Server: Encrypted packet (len=36)
4 2022-02-09 17:43:02,170798836 172.21.0.10 → 172.16.56.10 TCP 66 55798 → 22 [ACK] Seq=1 Ack=37 Win=990 Len=0 TSval=1691964300 TSecr=1370499909
```
When printing the capture file with the `-V` option, the first line of each frame is prefixed with `Frame n`, which makes it easy to search in a pager:
```
server ~ # tshark -r test.pcap -V | head -n 5
Running as user "root" and group "root". This could be dangerous.
Frame 1: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) on interface 0
Interface id: 0 (ens3)
Interface name: ens3
Encapsulation type: Ethernet (1)
Arrival Time: Feb 9, 2022 17:43:01.528756106 CET
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3135dnstap-read: add sorting option2022-02-10T15:06:08Zmartinvonwittichdnstap-read: add sorting option### Description
`dnstap-read` currently prints the DNS packets in the order in which they were stored in the file.
Unfortunately, the packets aren't necessarily stored in chronological order (probably due to the fact that dnstap loggin...### Description
`dnstap-read` currently prints the DNS packets in the order in which they were stored in the file.
Unfortunately, the packets aren't necessarily stored in chronological order (probably due to the fact that dnstap logging is understandably a low-priority task for BIND).
For example:
```
09-Feb-2022 02:33:36.294 CQ 127.0.0.1:41718 -> 127.0.0.1:0 UDP 33b example.com/IN/MX
09-Feb-2022 02:33:36.334 RR 192.168.1.2:55163 <- 192.168.1.1:53 UDP 71b example.com/IN/MX
09-Feb-2022 02:33:36.294 RQ 192.168.1.2:55163 -> 192.168.1.1:53 UDP 33b example.com/IN/MX
09-Feb-2022 02:33:36.334 CR 127.0.0.1:41718 <- 127.0.0.1:0 UDP 102b example.com/IN/MX
09-Feb-2022 02:33:38.453 CQ 127.0.0.1:57293 -> 127.0.0.1:0 UDP 33b example.com/IN/MX
09-Feb-2022 02:33:38.453 CR 127.0.0.1:57293 <- 127.0.0.1:0 UDP 102b example.com/IN/MX
```
Obviously the resolver query (RQ) comes before the resolver response (RR), and while the timestamps reflect this, the ordering does not. This can make reading the logs rather confusing, especially when piping `dnstap-read -p` or `dnstap-read -y` through a pager - when I'm looking at the RQ, then I expect to be able to search for the RR e.g. with `/55163`, but as `/` searches forward, I won't find it.
### Request
Add the ability to sort the packets chronologically, with a switch.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2996Migrate PKCS11 from "engine" to "provider"2022-12-26T19:20:52ZMark AndrewsMigrate PKCS11 from "engine" to "provider"OpenSSL 3.0.0 has deprecated the `engine` api in favour of the `provider` api. We currently use the `engine` api and OpenSC for pkcs11 access to HSMs. We need to move to using the `provider` api as soon as possible.
OpenSC has an open...OpenSSL 3.0.0 has deprecated the `engine` api in favour of the `provider` api. We currently use the `engine` api and OpenSC for pkcs11 access to HSMs. We need to move to using the `provider` api as soon as possible.
OpenSC has an open ticket for OpenSSL 3.0.0 https://github.com/OpenSC/OpenSC/issues/2308Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2078mem.c:869: INSIST(!ctx->checkfree || dl->ptr == ((void *)0)) failed, back trace2023-07-24T15:12:04ZMichal Nowakmem.c:869: INSIST(!ctx->checkfree || dl->ptr == ((void *)0)) failed, back traceThe `dyndb` test [failed](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1087998#L3283) with `mem.c:869: INSIST(!ctx->checkfree || dl->ptr == ((void *)0)) failed, back trace`. @wpk seems to [say](https://mattermost.isc.org/isc/pl/63m5a...The `dyndb` test [failed](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1087998#L3283) with `mem.c:869: INSIST(!ctx->checkfree || dl->ptr == ((void *)0)) failed, back trace`. @wpk seems to [say](https://mattermost.isc.org/isc/pl/63m5a6i84ifiiqwkrmx5ie9emh) it's "a memory leak in ADB".
```
18-Aug-2020 10:05:38.878 dispatch 0x7fc53d4ab8c0: shutting down; detaching from sock (nil), task 0x7fc590697be8
18-Aug-2020 10:05:38.878 dispatchmgr 0x7fc5a098fe58: destroy_mgr_ok: shuttingdown=1, listnonempty=1, depool=9, rpool=0, dpool=9
18-Aug-2020 10:05:38.878 dispatch 0x7fc53d4a8ac0: shutting down; detaching from sock (nil), task 0x7fc5905f5db8
18-Aug-2020 10:05:38.878 dispatchmgr 0x7fc5a098fe58: destroy_mgr_ok: shuttingdown=1, listnonempty=1, depool=8, rpool=0, dpool=8
18-Aug-2020 10:05:38.878 dispatch 0x7fc53c0392c0: shutting down; detaching from sock (nil), task 0x7fc5906ba760
18-Aug-2020 10:05:38.878 dispatchmgr 0x7fc5a098fe58: destroy_mgr_ok: shuttingdown=1, listnonempty=1, depool=7, rpool=0, dpool=7
18-Aug-2020 10:05:38.878 dispatch 0x7fc53d4a3480: shutting down; detaching from sock (nil), task 0x7fc5905ad590
18-Aug-2020 10:05:38.878 dispatchmgr 0x7fc5a098fe58: destroy_mgr_ok: shuttingdown=1, listnonempty=1, depool=6, rpool=0, dpool=6
18-Aug-2020 10:05:38.878 dispatch 0x7fc53c035f00: shutting down; detaching from sock (nil), task 0x7fc5906dd590
18-Aug-2020 10:05:38.878 dispatchmgr 0x7fc5a098fe58: destroy_mgr_ok: shuttingdown=1, listnonempty=1, depool=5, rpool=0, dpool=5
18-Aug-2020 10:05:38.882 mem.c:869: INSIST(!ctx->checkfree || dl->ptr == ((void *)0)) failed, back trace
18-Aug-2020 10:05:38.882 #0 0x56450e36ee3e in _fini()+0x56450e0d902a
18-Aug-2020 10:05:38.882 #1 0x56450e561a4d in _fini()+0x56450e2cbc39
18-Aug-2020 10:05:38.882 #2 0x56450e570086 in _fini()+0x56450e2da272
18-Aug-2020 10:05:38.882 #3 0x56450e574e38 in _fini()+0x56450e2df024
18-Aug-2020 10:05:38.882 #4 0x56450e574595 in _fini()+0x56450e2de781
18-Aug-2020 10:05:38.882 #5 0x56450e5837aa in _fini()+0x56450e2ed996
18-Aug-2020 10:05:38.882 #6 0x56450e4ed88e in _fini()+0x56450e257a7a
18-Aug-2020 10:05:38.882 #7 0x56450e4edf04 in _fini()+0x56450e2580f0
18-Aug-2020 10:05:38.882 #8 0x56450e4ee0ae in _fini()+0x56450e25829a
18-Aug-2020 10:05:38.882 #9 0x56450e585928 in _fini()+0x56450e2efb14
18-Aug-2020 10:05:38.882 #10 0x7fc5a6d49ea7 in _fini()+0x7fc5a6ab4093
18-Aug-2020 10:05:38.882 #11 0x7fc5a6c65dcf in _fini()+0x7fc5a69cffbb
18-Aug-2020 10:05:38.882 exiting (due to assertion failure)
```
```
S:dyndb:2020-08-18T10:04:04+0000
T:dyndb:1:A
A:dyndb:System test dyndb
I:dyndb:PORTRANGE:7600 - 7699
I:dyndb:starting servers
I:dyndb:adding test1.ipv4.example.nil. A 10.53.0.10 (1)
I:dyndb:adding test2.ipv4.example.nil. A 10.53.0.11 (2)
I:dyndb:adding test3.ipv4.example.nil. A 10.53.0.12 (3)
I:dyndb:adding test4.ipv6.example.nil. AAAA 2001:db8::1 (4)
I:dyndb:deleting test1.ipv4.example.nil. A (was 10.53.0.10) (5)
I:dyndb:deleting test2.ipv4.example.nil. A (was 10.53.0.11) (6)
I:dyndb:deleting test3.ipv4.example.nil. A (was 10.53.0.12) (7)
I:dyndb:deleting test4.ipv6.example.nil. AAAA (was 2001:db8::1) (8)
I:dyndb:checking parameter logging (9)
I:dyndb:checking dyndb still works after reload
I:dyndb:ns1 server reload successful
I:dyndb:adding test5.ipv4.example.nil. A 10.53.0.10 (10)
I:dyndb:adding test6.ipv6.example.nil. AAAA 2001:db8::1 (11)
I:dyndb:deleting test5.ipv4.example.nil. A (was 10.53.0.10) (12)
I:dyndb:deleting test6.ipv6.example.nil. AAAA (was 2001:db8::1) (13)
I:dyndb:exit status: 0
I:dyndb:stopping servers
I:dyndb:Core dump(s) found: dyndb/ns1/core.6735
R:dyndb:FAIL
D:dyndb:backtrace from dyndb/ns1/core.6735:
D:dyndb:--------------------------------------------------------------------------------
D:dyndb:Core was generated by `/builds/isc-projects/bind9/bin/named/named -D dyndb-ns1 -X named.lock -m record'.
D:dyndb:Program terminated with signal SIGABRT, Aborted.
D:dyndb:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:dyndb:[Current thread is 1 (Thread 0x7fc59c309700 (LWP 6751))]
D:dyndb:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:dyndb:#1 0x00007fc5a6b8d537 in __GI_abort () at abort.c:79
D:dyndb:#2 0x000056450e36efd9 in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at ./main.c:261
D:dyndb:#3 0x000056450e561a4d in isc_assertion_failed (file=file@entry=0x56450e6094a1 "mem.c", line=line@entry=869, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x56450e6088d0 "!ctx->checkfree || dl->ptr == ((void *)0)") at assertions.c:46
D:dyndb:#4 0x000056450e570086 in destroy (ctx=ctx@entry=0x7fc53d449760) at mem.c:866
D:dyndb:#5 0x000056450e574e38 in isc___mem_putanddetach (ctxp=<optimized out>, ptr=0x7fc590629020, size=40, file=0x56450e5c325e "stats.c", line=88) at mem.c:998
D:dyndb:#6 0x000056450e574595 in isc__mem_putanddetach (mctxp=mctxp@entry=0x7fc590629028, ptr=ptr@entry=0x7fc590629020, size=size@entry=40, file=file@entry=0x56450e5c325e "stats.c", line=line@entry=88) at mem.c:2446
D:dyndb:#7 0x000056450e5837aa in isc_stats_detach (statsp=statsp@entry=0x7fc53c0279d8) at stats.c:88
D:dyndb:#8 0x000056450e4ed88e in destroy (view=0x7fc53c027800) at view.c:536
D:dyndb:#9 0x000056450e4edf04 in dns_view_weakdetach (viewp=viewp@entry=0x7fc59c308d68) at view.c:727
D:dyndb:#10 0x000056450e4ee0ae in resolver_shutdown (task=<optimized out>, event=<optimized out>) at view.c:744
D:dyndb:#11 0x000056450e585928 in dispatch (threadid=<optimized out>, manager=0x7fc5a097d020) at task.c:1152
D:dyndb:#12 run (queuep=<optimized out>) at task.c:1344
D:dyndb:#13 0x00007fc5a6d49ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
D:dyndb:#14 0x00007fc5a6c65dcf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
D:dyndb:--------------------------------------------------------------------------------
D:dyndb:full backtrace from dyndb/ns1/core.6735 saved in core.6735-backtrace.txt
D:dyndb:core dump dyndb/ns1/core.6735 archived as dyndb/ns1/core.6735.gz
E:dyndb:2020-08-18T10:05:42+0000
```
[core.6735.gz](/uploads/db0af934d39cf77abdfaca204b7fcaec/core.6735.gz)
[core.6735-backtrace.txt](/uploads/b2f1a0fea130c1062454037497acf7ff/core.6735-backtrace.txt)
[named.run](/uploads/f4639f67366d1e08781de01bef55b5fe/named.run)https://gitlab.isc.org/isc-projects/bind9/-/issues/1793failed query to a `forward only` forwarder increments `serverquota` counter (...2023-11-02T16:58:14ZCathy Almondfailed query to a `forward only` forwarder increments `serverquota` counter (spilled due to server quota)As observed in [Support ticket #16297](https://support.isc.org/Ticket/Display.html?id=16297)
I was inspecting the stats output and was very surprised to see this:
` 13779 spilled due to server quota`
The server in questi...As observed in [Support ticket #16297](https://support.isc.org/Ticket/Display.html?id=16297)
I was inspecting the stats output and was very surprised to see this:
` 13779 spilled due to server quota`
The server in question does not have `fetches-per-server` configured, so this defaults to zero (unlimited). But yet...
Looking at the code - I suspect there's a failure mode that drops through the 'out' block in fctx_getaddresses() without resetting all_spilled (which starts at 'true').
```c
static isc_result_t
fctx_getaddresses(fetchctx_t *fctx, bool badcache) {
dns_rdata_t rdata = DNS_RDATA_INIT;
isc_result_t result;
dns_resolver_t *res;
isc_stdtime_t now;
unsigned int stdoptions = 0;
dns_forwarder_t *fwd;
dns_adbaddrinfo_t *ai;
bool all_bad;
dns_rdata_ns_t ns;
bool need_alternate = false;
bool all_spilled = true;
```
...
```c
/*
* If all of the addresses found were over the
* fetches-per-server quota, return the configured
* response.
*/
if (all_spilled) {
result = res->quotaresp[dns_quotatype_server];
inc_stats(res, dns_resstatscounter_serverquota);
}
```
This is a server that is using global forwarding, so we skip case 'normal_nses', which is where 'all_spilled' is normally reset from true to false during processing:
```c
if (fctx->fwdpolicy == dns_fwdpolicy_only)
goto out;
```
So I'm guessing that what's been 'counted' and then reported here, is failures in getting responses back from any of the global forwarders (which tallies quite nicely with the problem I'm investigating - even though this wasn't a counter I was expecting to see in the stats!).
The assumption seems to be if it's a failure for any other reason than fetch-limits, that something will reset the 'all_spilled' flag - it would appear that assumption is flawed for some configurations and situations. Could someone have a look at this please - it should be an easy one to fix.
I note that this has also been noticed before on bind-users:
https://lists.isc.org/pipermail/bind-users/2016-June/097011.html
I observed this in 9.11.15-S1, but the code path looks the same still on master.
Requested changes:
- [ ] fix serverquota counter
- [ ] add a new counter for specifically for situation when all forwarders have failedNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1666Intermittent tcp (high-water) test failure2023-12-01T14:40:36ZMatthijs Mekkingmatthijs@isc.orgIntermittent tcp (high-water) test failurehttps://gitlab.isc.org/isc-projects/bind9/-/jobs/742012
```
I:tcp:incorrect TCP high-water value: got 18, expected 17
I:tcp:failed
```https://gitlab.isc.org/isc-projects/bind9/-/jobs/742012
```
I:tcp:incorrect TCP high-water value: got 18, expected 17
I:tcp:failed
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4652query.c:10467: INSIST(namereln == dns_namereln_subdomain) failed, back trace2024-03-27T14:02:05ZOndřej Surýquery.c:10467: INSIST(namereln == dns_namereln_subdomain) failed, back trace### Summary
Server crash caused by external UDP queries.
### BIND versions affected
```
BIND 9.19.23-dev (Development Release) <id:b1ebd49>
running on Linux x86_64 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29)
bui...### Summary
Server crash caused by external UDP queries.
### BIND versions affected
```
BIND 9.19.23-dev (Development Release) <id:b1ebd49>
running on Linux x86_64 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29)
built by make with 'CC=' 'LD=' 'CFLAGS=-O0 -ggdb -Wno-deprecated-declarations -fno-omit-frame-pointer -fno-optimize-sibling-calls -mtune=alderlake -DISC_MEM_USE_INTERNAL_MALLOC=0 -DISC_MEM_TRACKLINES=1 -DISC_TRACK_PTHREADS_OBJECTS' 'LDFLAGS=' '--enable-developer' '--enable-warn-error' '--with-openssl' '--with-zlib' '--with-libxml2' '--with-json-c' '--with-readline' '--with-libidn2' '--disable-dnstap' '--with-libtool' '--without-make-clean'
compiled by GCC 12.2.0
compiled with OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
linked to OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with liburcu version: 0.15.0-pre
compiled with jemalloc version: 5.3.0
compiled with libnghttp2 version: 1.52.0
linked to libnghttp2 version: 1.52.0
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
linked to maxminddb version: 1.7.1
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): no
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /dev/null
rndc configuration: /usr/local/etc/rndc.conf
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
geoip-directory: /usr/share/GeoIP
```
9.18 is not affected with the same attack pattern.
### Preconditions and assumptions
None.
### Attacker's abilities
Ability to send queries to the server.
### Impact
Server crashes with assertion failure.
### Steps to reproduce
1. Run `bin/named/named -g -c /dev/null -p 12345`
2. Run 2x `dnsperf -d queryfile-example-10million-201202 -p 12345 -s 10.10.10.20 -t 20 -S 1 -e -D -b 16000`
3. Wait
### What is the current *bug* behavior?
Server crashes.
### What is the expected *correct* behavior?
Server doesn't crash.
### Relevant logs
```
21-Mar-2024 14:58:36.219 REFUSED unexpected RCODE resolving 'www.pressrepublicanevents.com/A/IN': 64.40.12.250#53
21-Mar-2024 14:58:36.227 REFUSED unexpected RCODE resolving '3.gvt0.com/A/IN': 2001:4860:4802:32::a#53
21-Mar-2024 14:58:36.259 DNS format error from 89.108.89.143#53 resolving 4kings.ru/MX for 10.10.10.106#36493: empty question section
21-Mar-2024 14:58:36.283 REFUSED unexpected RCODE resolving '3.gvt0.com/A/IN': 2001:4860:4802:34::a#53
21-Mar-2024 14:58:36.311 REFUSED unexpected RCODE resolving 'bioquimicasrl.com/A/IN': 209.244.0.3#53
21-Mar-2024 14:58:36.323 SERVFAIL unexpected RCODE resolving 'www.tom-morrow-land.com/AAAA/IN': 1.1.1.1#53
21-Mar-2024 14:58:36.327 REFUSED unexpected RCODE resolving '3.gvt0.com/A/IN': 216.239.36.10#53
21-Mar-2024 14:58:36.331 REFUSED unexpected RCODE resolving 'www.pressrepublicanevents.com/A/IN': 64.40.12.251#53
21-Mar-2024 14:58:36.331 query client=0x7fa869baf000 thread=0x7fa86cefd680(www.pressrepublicanevents.com/A): query_gotanswer: unexpected error: failure
21-Mar-2024 14:58:36.331 query client=0x7fa83b1a3400 thread=0x7fa85b3fe680(www.pressrepublicanevents.com/A): query_gotanswer: unexpected error: failure
21-Mar-2024 14:58:36.339 success resolving 'www.angrybirdsfree.net/AAAA' after disabling qname minimization due to 'ncache nxdomain'
21-Mar-2024 14:58:36.339 query client=0x7fa83b221400 thread=0x7fa85b3fe680(www.tom-morrow-land.com/AAAA): query_gotanswer: unexpected error: failure
21-Mar-2024 14:58:36.339 query client=0x7fa869a3e400 thread=0x7fa86cefd680(www.tom-morrow-land.com/AAAA): query_gotanswer: unexpected error: failure
21-Mar-2024 14:58:36.359 success resolving 'e1.mc658.mail.yahoo.com/AAAA' after disabling qname minimization due to 'ncache nxdomain'
21-Mar-2024 14:58:36.371 validating ksg07.harvard.edu/MX: no valid signature found
21-Mar-2024 14:58:36.371 REFUSED unexpected RCODE resolving '3.gvt0.com/A/IN': 216.239.38.10#53
21-Mar-2024 14:58:36.379 success resolving 'a-0.19-21098801.c0c0083.1518.19d4.3ea1.210.0.qfptcsf437v6s7kaak2qs267pq.avqs.mcafee.com/A' after disabling qname minimization due to 'ncache nxdomain'
21-Mar-2024 14:58:36.387 REFUSED unexpected RCODE resolving 'www.untwistedvortex.com/A/IN': 128.199.213.165#53
21-Mar-2024 14:58:36.387 query client=0x7fa869b1f000 thread=0x7fa86cefd680(www.untwistedvortex.com/A): query_gotanswer: unexpected error: failure
21-Mar-2024 14:58:36.387 query client=0x7fa83b2d7000 thread=0x7fa85b3fe680(www.untwistedvortex.com/A): query_gotanswer: unexpected error: failure
21-Mar-2024 14:58:36.403 query.c:10467: INSIST(namereln == dns_namereln_subdomain) failed
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4446deprecate --enable-fixed-rrset / rrset-order fixed2024-03-07T19:20:29ZPetr Špačekpspacek@isc.orgdeprecate --enable-fixed-rrset / rrset-order fixed### Discussion
I wonder if we should deprecate `configure --enable-fixed-rrset`? It seems that it might create trouble down the road when we try to improve database/node structure...
We don't have to touch it for QPDB in 9.20, but I th...### Discussion
I wonder if we should deprecate `configure --enable-fixed-rrset`? It seems that it might create trouble down the road when we try to improve database/node structure...
We don't have to touch it for QPDB in 9.20, but I think it will get in our way when we fix #3405.
### Proposal
Deprecate deprecate `configure --enable-fixed-rrset` / `rrset-order fixed` statement in 9.20, remove in 9.21.
### Links / referencesBIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4370Check that a zone is served by IPv6 servers if it has AAAA records2023-12-05T09:04:32ZMark AndrewsCheck that a zone is served by IPv6 servers if it has AAAA recordsOne thing that is often forgotten when turning on an IPv6 service is to ensure that the zone holding the AAAA records for that service is also served over IPv6. This can be relatively easy be checked for by named-checkzone by looking fo...One thing that is often forgotten when turning on an IPv6 service is to ensure that the zone holding the AAAA records for that service is also served over IPv6. This can be relatively easy be checked for by named-checkzone by looking for AAAA records in the zone contents, including glue AAAA records, and then checking that there are AAAA records published for some of the nameservers if any are found (in zone or elsewhere). This can also sometimes be determined by named without needing to look beyond the zone's contents, but cannot be guaranteed.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4366XFR (dispatch) doesn't shutdown TCP connection on timeout2023-12-05T15:50:25ZOndřej SurýXFR (dispatch) doesn't shutdown TCP connection on timeoutAfter switching the XFR to use `dns_dispatch`, the TCP connection doesn't get cancelled properly when `dns_dispatch_done()` is called and it waits for the TCP connection to timeout on the server side.After switching the XFR to use `dns_dispatch`, the TCP connection doesn't get cancelled properly when `dns_dispatch_done()` is called and it waits for the TCP connection to timeout on the server side.https://gitlab.isc.org/isc-projects/bind9/-/issues/4348implement QPDB databases2024-03-08T23:38:09ZEvan Huntimplement QPDB databasesCreate QP-trie based databases to take the place of RBTDB, for use as a:
- [ ] zone database
- [ ] cacheCreate QP-trie based databases to take the place of RBTDB, for use as a:
- [ ] zone database
- [ ] cacheBIND 9.21.xEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/4341Investigate the memory spike when the cache is cold2023-12-05T15:58:56ZOndřej SurýInvestigate the memory spike when the cache is coldOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4330Add support to parse and display DSO (opcode 6) messages2023-11-01T14:43:41ZMark AndrewsAdd support to parse and display DSO (opcode 6) messagesSee [RFC 8490](https://www.rfc-editor.org/rfc/rfc8490.txt). These contain 1 or more TLVs immediately after the DNS messages header.
Add support to dig to be able to send arbitrary DSO messages.See [RFC 8490](https://www.rfc-editor.org/rfc/rfc8490.txt). These contain 1 or more TLVs immediately after the DNS messages header.
Add support to dig to be able to send arbitrary DSO messages.Long-termMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4315CID 465566-465575: Passing tainted expression "*name.ndata" to "name_prefix"2023-11-02T09:19:55ZMichal NowakCID 465566-465575: Passing tainted expression "*name.ndata" to "name_prefix"Coverity Scan claims several `TAINTED_SCALAR` CIDs on `main` in `lib/dns/rdata/`.
```
** CID 465575: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID ...Coverity Scan claims several `TAINTED_SCALAR` CIDs on `main` in `lib/dns/rdata/`.
```
** CID 465575: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465575: (TAINTED_SCALAR)
/lib/dns/rdata/generic/afsdb_18.c: 88 in totext_afsdb()
82 dns_rdata_toregion(rdata, ®ion);
83 num = uint16_fromregion(®ion);
84 isc_region_consume(®ion, 2);
85 snprintf(buf, sizeof(buf), "%u ", num);
86 RETERR(str_totext(buf, target));
87 dns_name_fromregion(&name, ®ion);
>>> CID 465575: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
88 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
89 : 0;
90 return (dns_name_totext(&prefix, opts, target));
91 }
92
93 static isc_result_t
/lib/dns/rdata/generic/afsdb_18.c: 88 in totext_afsdb()
82 dns_rdata_toregion(rdata, ®ion);
83 num = uint16_fromregion(®ion);
84 isc_region_consume(®ion, 2);
85 snprintf(buf, sizeof(buf), "%u ", num);
86 RETERR(str_totext(buf, target));
87 dns_name_fromregion(&name, ®ion);
>>> CID 465575: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
88 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
89 : 0;
90 return (dns_name_totext(&prefix, opts, target));
91 }
92
93 static isc_result_t
** CID 465574: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465574: (TAINTED_SCALAR)
/lib/dns/rdata/in_1/svcb_64.c: 689 in generic_totext_in_svcb()
683
684 /*
685 * TargetName.
686 */
687 dns_name_fromregion(&name, ®ion);
688 isc_region_consume(®ion, name_length(&name));
>>> CID 465574: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
689 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
690 : 0;
691 RETERR(dns_name_totext(&prefix, opts, target));
692
693 while (region.length > 0) {
694 isc_region_t r;
/lib/dns/rdata/in_1/svcb_64.c: 689 in generic_totext_in_svcb()
683
684 /*
685 * TargetName.
686 */
687 dns_name_fromregion(&name, ®ion);
688 isc_region_consume(®ion, name_length(&name));
>>> CID 465574: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
689 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
690 : 0;
691 RETERR(dns_name_totext(&prefix, opts, target));
692
693 while (region.length > 0) {
694 isc_region_t r;
** CID 465573: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465573: (TAINTED_SCALAR)
/lib/dns/rdata/in_1/kx_36.c: 77 in totext_in_kx()
71 snprintf(buf, sizeof(buf), "%u", num);
72 RETERR(str_totext(buf, target));
73
74 RETERR(str_totext(" ", target));
75
76 dns_name_fromregion(&name, ®ion);
>>> CID 465573: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
77 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
78 : 0;
79 return (dns_name_totext(&prefix, opts, target));
80 }
81
82 static isc_result_t
/lib/dns/rdata/in_1/kx_36.c: 77 in totext_in_kx()
71 snprintf(buf, sizeof(buf), "%u", num);
72 RETERR(str_totext(buf, target));
73
74 RETERR(str_totext(" ", target));
75
76 dns_name_fromregion(&name, ®ion);
>>> CID 465573: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
77 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
78 : 0;
79 return (dns_name_totext(&prefix, opts, target));
80 }
81
82 static isc_result_t
** CID 465572: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465572: (TAINTED_SCALAR)
/lib/dns/rdata/generic/mx_15.c: 123 in totext_mx()
117 snprintf(buf, sizeof(buf), "%u", num);
118 RETERR(str_totext(buf, target));
119
120 RETERR(str_totext(" ", target));
121
122 dns_name_fromregion(&name, ®ion);
>>> CID 465572: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
123 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
124 : 0;
125 return (dns_name_totext(&prefix, opts, target));
126 }
127
128 static isc_result_t
/lib/dns/rdata/generic/mx_15.c: 123 in totext_mx()
117 snprintf(buf, sizeof(buf), "%u", num);
118 RETERR(str_totext(buf, target));
119
120 RETERR(str_totext(" ", target));
121
122 dns_name_fromregion(&name, ®ion);
>>> CID 465572: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
123 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
124 : 0;
125 return (dns_name_totext(&prefix, opts, target));
126 }
127
128 static isc_result_t
** CID 465571: Insecure data handling (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465571: Insecure data handling (TAINTED_SCALAR)
/lib/dns/rdata/any_255/tsig_250.c: 525 in tostruct_any_tsig()
519 isc_region_consume(&sr, 2);
520
521 /*
522 * Other.
523 */
524 INSIST(sr.length == tsig->otherlen);
>>> CID 465571: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted expression "tsig->otherlen" to "mem_maybedup", which uses it as an offset.
525 tsig->other = mem_maybedup(mctx, sr.base, tsig->otherlen);
526
527 tsig->mctx = mctx;
528 return (ISC_R_SUCCESS);
529 }
530
** CID 465570: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465570: (TAINTED_SCALAR)
/lib/dns/rdata/generic/lp_107.c: 77 in totext_lp()
71 snprintf(buf, sizeof(buf), "%u", num);
72 RETERR(str_totext(buf, target));
73
74 RETERR(str_totext(" ", target));
75
76 dns_name_fromregion(&name, ®ion);
>>> CID 465570: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
77 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
78 : 0;
79 return (dns_name_totext(&prefix, opts, target));
80 }
81
82 static isc_result_t
/lib/dns/rdata/generic/lp_107.c: 77 in totext_lp()
71 snprintf(buf, sizeof(buf), "%u", num);
72 RETERR(str_totext(buf, target));
73
74 RETERR(str_totext(" ", target));
75
76 dns_name_fromregion(&name, ®ion);
>>> CID 465570: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
77 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
78 : 0;
79 return (dns_name_totext(&prefix, opts, target));
80 }
81
82 static isc_result_t
** CID 465569: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465569: (TAINTED_SCALAR)
/lib/dns/rdata/in_1/px_26.c: 98 in totext_in_px()
92 RETERR(str_totext(" ", target));
93
94 /*
95 * MAP822.
96 */
97 dns_name_fromregion(&name, ®ion);
>>> CID 465569: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
98 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
99 : 0;
100 isc_region_consume(®ion, name_length(&name));
101 RETERR(dns_name_totext(&prefix, opts, target));
102 RETERR(str_totext(" ", target));
103
/lib/dns/rdata/in_1/px_26.c: 98 in totext_in_px()
92 RETERR(str_totext(" ", target));
93
94 /*
95 * MAP822.
96 */
97 dns_name_fromregion(&name, ®ion);
>>> CID 465569: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
98 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
99 : 0;
100 isc_region_consume(®ion, name_length(&name));
101 RETERR(dns_name_totext(&prefix, opts, target));
102 RETERR(str_totext(" ", target));
103
** CID 465568: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465568: (TAINTED_SCALAR)
/lib/dns/rdata/generic/rt_21.c: 85 in totext_rt()
79 num = uint16_fromregion(®ion);
80 isc_region_consume(®ion, 2);
81 snprintf(buf, sizeof(buf), "%u", num);
82 RETERR(str_totext(buf, target));
83 RETERR(str_totext(" ", target));
84 dns_name_fromregion(&name, ®ion);
>>> CID 465568: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
85 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
86 : 0;
87 return (dns_name_totext(&prefix, opts, target));
88 }
89
90 static isc_result_t
/lib/dns/rdata/generic/rt_21.c: 85 in totext_rt()
79 num = uint16_fromregion(®ion);
80 isc_region_consume(®ion, 2);
81 snprintf(buf, sizeof(buf), "%u", num);
82 RETERR(str_totext(buf, target));
83 RETERR(str_totext(" ", target));
84 dns_name_fromregion(&name, ®ion);
>>> CID 465568: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
85 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
86 : 0;
87 return (dns_name_totext(&prefix, opts, target));
88 }
89
90 static isc_result_t
** CID 465567: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465567: (TAINTED_SCALAR)
/lib/dns/rdata/in_1/srv_33.c: 137 in totext_in_srv()
131 RETERR(str_totext(" ", target));
132
133 /*
134 * Target.
135 */
136 dns_name_fromregion(&name, ®ion);
>>> CID 465567: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
137 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
138 : 0;
139 return (dns_name_totext(&prefix, opts, target));
140 }
141
142 static isc_result_t
/lib/dns/rdata/in_1/srv_33.c: 137 in totext_in_srv()
131 RETERR(str_totext(" ", target));
132
133 /*
134 * Target.
135 */
136 dns_name_fromregion(&name, ®ion);
>>> CID 465567: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
137 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
138 : 0;
139 return (dns_name_totext(&prefix, opts, target));
140 }
141
142 static isc_result_t
** CID 465566: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465566: (TAINTED_SCALAR)
/lib/dns/rdata/generic/naptr_35.c: 299 in totext_naptr()
293 RETERR(str_totext(" ", target));
294
295 /*
296 * Replacement.
297 */
298 dns_name_fromregion(&name, ®ion);
>>> CID 465566: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
299 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
300 : 0;
301 return (dns_name_totext(&prefix, opts, target));
302 }
303
304 static isc_result_t
/lib/dns/rdata/generic/naptr_35.c: 299 in totext_naptr()
293 RETERR(str_totext(" ", target));
294
295 /*
296 * Replacement.
297 */
298 dns_name_fromregion(&name, ®ion);
>>> CID 465566: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
299 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
300 : 0;
301 return (dns_name_totext(&prefix, opts, target));
302 }
303
304 static isc_result_t
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4272stress:rpz:fedora:38:arm64 crashed (async_restart at query.c:5843)2023-10-03T15:24:25ZMichal Nowakstress:rpz:fedora:38:arm64 crashed (async_restart at query.c:5843)After one minute runtime, the `stress:rpz:fedora:38:arm64` [crashed](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3599502) on `main`.
```
Core was generated by `/builds/isc-projects/bind9/.local/usr/local/sbin/named -f -c ./named.co...After one minute runtime, the `stress:rpz:fedora:38:arm64` [crashed](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3599502) on `main`.
```
Core was generated by `/builds/isc-projects/bind9/.local/usr/local/sbin/named -f -c ./named.conf'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000ffff9949e5e0 in async_restart (arg=0xffff15302000) at query.c:5843
5843 isc_mem_put(client->manager->mctx, qctx, sizeof(*qctx));
[Current thread is 1 (Thread 0xffff96cfe300 (LWP 24042))]
#0 0x0000ffff9949e5e0 in async_restart (arg=0xffff15302000) at query.c:5843
#1 0x0000ffff99755b10 in isc__async_cb (handle=<optimized out>) at async.c:111
#2 0x0000ffff98cda0c0 in uv__async_io (loop=0xffff974830a0, w=0xffff97483270, events=1) at /usr/src/libuv-v1.46.0/src/unix/async.c:176
#3 0x0000ffff98cf6d0c in uv__io_poll (loop=0xffff974830a0, timeout=5) at /usr/src/libuv-v1.46.0/src/unix/linux.c:1476
#4 0x0000ffff98cdb084 in uv_run (loop=0xffff974830a0, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.46.0/src/unix/core.c:447
#5 0x0000ffff99768800 in loop_thread (arg=arg@entry=0xffff97483080) at loop.c:282
#6 0x0000ffff997787c8 in thread_body (wrap=wrap@entry=0x3e733a90) at thread.c:85
#7 0x0000ffff997787f8 in thread_run (wrap=0x3e733a90) at thread.c:100
#8 0x0000ffff9861bc74 in start_thread () from /lib64/libc.so.6
#9 0x0000ffff9868925c in thread_start () from /lib64/libc.so.6
```
[core.24039-backtrace.txt](/uploads/61b63bae17f042b4dc2d1153cc9948dc/core.24039-backtrace.txt)
[named.log](/uploads/10dd091e5632bfcc7457c0f367874b4b/named.log)
On [retry](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3600371) it didn't immediately crash.Not planned