Error sending notify to IPv6 secondary: notify to <IP addr> failed: address family

Hi,

I'm using the latest developer release of BIND (9.19.23-dev) on my master name server.

$ rndc status
version: BIND 9.19.23-dev (Development Release) <id:ae2b59b>
running on localhost: Linux x86_64 5.15.0-94-generic #104-Ubuntu SMP Tue
Jan 9 15:25:40 UTC 2024
boot time: Tue, 02 Apr 2024 16:43:02 GMT
last configured: Tue, 02 Apr 2024 21:24:43 GMT
configuration file: /usr/local/etc/named.conf
CPUs found: 8
worker threads: 8
number of zones: 130 (100 automatic)
debug level: 0
xfers running: 0
xfers deferred: 0
xfers first refresh: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/900/1000
tcp clients: 0/150
TCP high-water: 1
server is up and running

The sending of NOTIFY messages via IPv6 to the secondary name server(s) will end up in the following log message:

03-Apr-2024 13:10:31.341 notify: info: zone example.com/IN (signed):
sending notifies (serial 2023111192)
03-Apr-2024 13:10:31.341 notify: info: zone example.com/IN (signed):
sending notify to <REDACTED> : TSIG
(ns1.example.com.ns2.example.com.2023)
03-Apr-2024 13:10:31.341 notify: notice: zone example.com/IN
(signed): notify to <REDACTED> failed: address family
mismatch: retrying over TCP
03-Apr-2024 13:10:31.341 notify: warning: zone example.com/IN
(signed): notify to <REDACTED> failed: address family mismatch

The same happens for all zones on this primary server. On the primary I have explicitly set "notify-source" and "notify-source-v6" to a dedicated ip address because the server has more than one ip/ipv6 address.

My understanding of the info/warning message is, that named sends the NOTIFY to the ipv6 destination, but using an ipv4 source address?!

To be honest, for me this alone is a bit weird and I guess that sending the same message via TCP will not help. (However a NOTIFY is a one way message, so maybe no one cares.)

Taking a look at the source code at lib/dns/zone.c line 12470 shows that in this case, a loop is started with TCP_BIT set and dns_request_create() is called again. However, setting the TCP flag is the only thing that has changed in between, so I'm assuming that the parameter "src" is still configured with the wrong source address. So the second call of dns_request_create() fails again, which results in the second error message seen in the log.

At the end the NOTIFY is not send to the secondary name server. And because the server in question is only reachable via IPv6 no NOTIFY is reaching the secondary server.

Can anyone please take a look at this, if it is an error or just a weird config on my side?

Thanks for your help, best regards Holger