The dns_dispatch_add() function fails to set the source port when using TCP

Summary

The dispatch module ignores the source port of the local address when registering a new TCP dispatch using the dns_dispatch_add() function.

The result is that the dns_dispatch_add() function registers the resp entry into disp->mgr->qids hash table with resp->port being 0, but in tcp_recv_success(), when looking up an entry in the hash table after a successfully received data, the port is used so is not always 0 when creating the lookup key:

	dns_dispentry_t key = {
		.id = id,
		.peer = *peer,
		.port = isc_sockaddr_getport(&disp->local),
	};
	struct cds_lfht_iter iter;
	cds_lfht_lookup(disp->mgr->qids, qid_hash(&key), qid_match, &key,
			&iter);

So it never finds the entry and eventually returns ISC_R_UNEXPECTED.

BIND version affected

Looks like the code responsible for the source port assignment was removed in aa0971027caddd84387012e873e2918ddb52bab0 of !8304 (merged), so v9.18 is unaffected, but all v9.20 and v9.21 versions are affected.

Steps to reproduce

I found the easiest way to reproduce is to use mdig.

# Build BIND and use mdig for a TCP query with assigned source address and port, for example:
$ bin/tools/mdig +tcp -b 10.53.0.1#55555 @10.53.0.1 example
01-Oct-2024 13:15:07.640 dispatch 0x79af79af3f00: shutting down due to TCP receive error: 10.53.0.1#9053: unexpected error
response failed with unexpected error

What is the current bug behavior?

A TCP query which uses the dispatch module (i.e. mdig) with a defined source address and port fails with an "unexpected error".

What is the expected correct behavior?

A successful query.

Relevant configuration files

None.

Relevant logs

01-Oct-2024 13:15:07.640 dispatch 0x79af79af3f00: shutting down due to TCP receive error: 10.53.0.1#9053: unexpected error