explicit notify-source port configuration breaks notification if a server is not responding

Summary

Notification to a non-responding secondary triggers bug and notifications are not sent to other secondaries.

BIND version used

• Affects v9.19: 45893249
• Affects v9.18: v9.18.13

Versions not affected:

• v9.18: v9.18.12

• v9.16: v9.16.39

  • See tcpdump output below - maybe there is a different bug as I can't see retries?

• Other versions were not tested

Steps to reproduce

• Specify explicit notify-source with a local IP address and one port
• Add one non-responding server to beginning of list of secondary servers to be notified

sudo ip addr add 192.0.2.1 dev lo

zone "example.com" {
	type master;
	file "example.com.zone";
	also-notify {
		192.0.2.10;
		192.0.2.20;
		192.0.2.30;
	};
	notify-source 192.0.2.1 port 10053;
	notify explicit;
};

What is the current bug behavior?

Affected versions resend notification couple times to non-responding server (maybe selected randomly at the first try??) and then stop.

What is the expected correct behavior?

All servers are notified, even if some of them do not respond.

Relevant logs and/or screenshots

tcpdump output - fresh daemon start is indicated by (QM)? line with version number:

$ sudo tcpdump -ttt -i enp0s13f0u1u2u3 'port 12345 or port 30016 or syslog or net 192.0.2.0/24'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s13f0u1u2u3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
 00:00:00.000000 IP p.50697 > 192.0.2.0.mdns: 28839+ [1au] A (QM)? main. (45)
 00:00:01.017566 IP p.10053 > 192.0.2.30.domain: 30882 notify [b2&3=0x2400] [1a] SOA? example.com. (86)
 00:00:15.001368 IP p.10053 > 192.0.2.30.domain: 30882 notify [b2&3=0x2400] [1a] SOA? example.com. (86)
 00:00:15.003376 IP p.10053 > 192.0.2.30.domain: 30882 notify [b2&3=0x2400] [1a] SOA? example.com. (86)

 00:00:25.638915 IP p.56503 > 192.0.2.0.mdns: 64578+ [1au] A (QM)? v9.18.13. (49)
 00:00:01.021154 IP p.10053 > 192.0.2.10.domain: 51136 notify [b2&3=0x2400] [1a] SOA? example.com. (86)
 00:00:15.013238 IP p.10053 > 192.0.2.10.domain: 51136 notify [b2&3=0x2400] [1a] SOA? example.com. (86)
 00:00:15.013284 IP p.10053 > 192.0.2.10.domain: 51136 notify [b2&3=0x2400] [1a] SOA? example.com. (86)

 00:00:15.352825 IP p.37245 > 192.0.2.0.mdns: 64736+ [1au] A (QM)? v9.18.12. (49)
 00:00:01.051049 IP p.46220 > 192.0.2.10.domain: 62557 notify [b2&3=0x2400] [1a] SOA? example.com. (86)
 00:00:00.499636 IP p.47822 > 192.0.2.30.domain: 53931 notify [b2&3=0x2400] [1a] SOA? example.com. (86)
 00:00:00.000016 IP p.57753 > 192.0.2.20.domain: 21729 notify [b2&3=0x2400] [1a] SOA? example.com. (86)
 00:00:14.503287 IP p.46220 > 192.0.2.10.domain: 62557 notify [b2&3=0x2400] [1a] SOA? example.com. (86)
 00:00:00.496634 IP p.47822 > 192.0.2.30.domain: 53931 notify [b2&3=0x2400] [1a] SOA? example.com. (86)
 00:00:00.000018 IP p.57753 > 192.0.2.20.domain: 21729 notify [b2&3=0x2400] [1a] SOA? example.com. (86)
 00:00:14.513350 IP p.46220 > 192.0.2.10.domain: 62557 notify [b2&3=0x2400] [1a] SOA? example.com. (86)
 00:00:00.486623 IP p.47822 > 192.0.2.30.domain: 53931 notify [b2&3=0x2400] [1a] SOA? example.com. (86)
 00:00:00.000021 IP p.57753 > 192.0.2.20.domain: 21729 notify [b2&3=0x2400] [1a] SOA? example.com. (86)

 00:00:13.433247 IP p.42787 > 192.0.2.0.mdns: 55201+ [1au] A (QM)? v9.16.39. (49)
 00:00:01.073539 IP p.10053 > 192.0.2.10.domain: 27105 notify [b2&3=0x2400] [1a] SOA? example.com. (86)
 00:00:00.480005 IP p.10053 > 192.0.2.30.domain: 57615 notify [b2&3=0x2400] [1a] SOA? example.com. (86)
 00:00:00.000054 IP p.10053 > 192.0.2.20.domain: 19683 notify [b2&3=0x2400] [1a] SOA? example.com. (86)

Funnily enough it seems that v9.16.39 sends notification to all secondaries, but does not retry...

Workaround

Omit port specification. It's deprecated anyway.