[Pdns-users] NOTIFY messages not sent from correct address
matt at conundrum.com
Wed Aug 5 16:08:26 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
I seem to have run into a problem with NOTIFY messages sent from a
master pdns server to its slaves. It seems that the interface
selected to be the source of the notify messages is not necessarily
the same interface that pdns listens to for answering queries... and
therefore may not be the interface where slaves expect to find their
master. This is using pdns 2.9.22 on various operating systems.
I'm managing a configuration with many name server processes running
on individual servers, each holding zones belonging to a single
customer or service. In the this example case I'm dealing with now, I
have two pdns masters running on one server handling different sets of
zones. The server is configured with two interfaces, 192.0.2.1 and
Using the local-address directive, the first master is configured to
use 192.0.2.1 and the second is using 192.0.2.2. The master on
192.0.2.1 works fine, and the slaves see notify messages from the
correct place and all is good. However, the second master is also
sending its notify messages from 192.0.2.1. Since its slaves are
configured to talk to 192.0.2.2, they see this as a notify from an
unauthorized source, and so they ignore it.
I initially thought this might be a problem with the network
configuration on the servers, until I took a look at the pdns
processes with lsof. Here is the lsof output section reporting the
network interfaces pdns is connected to:
pdns_serv 21870 root 5u IPv4 45796887 UDP
pdns_serv 21870 root 7u IPv6 45796889 UDP
pdns_serv 21870 root 9u IPv4 45796891 TCP
pdns_serv 21870 root 11u IPv6 45796893 TCP
pdns_serv 21870 root 13u IPv4 45796895 TCP
pdns_serv 21870 root 17u IPv4 45796903 UDP *:
I can see on the slave side that notify messages are arriving from
192.0.2.1:27740. It seems pretty clear that the master is using the
UDP port bound to INADDR_ANY to send notify messages, which seems to
me to be a problem.
It seems likely this could be fixed by changing that particular socket
call to use the address defined by local-address in the .conf file.
Unfortunately, my c++ isn't nearly good enough to track that down and
produce a patch.
Can anyone else confirm this behaviour, and/or suggest a fix?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)
-----END PGP SIGNATURE-----
More information about the Pdns-users