Some diagnostics is needed. When you reboot, does it show it up multiple binds
to the same port? Can your run netstat -tP to identify the process ID (are
they the same or different). There may also be other options to provide more
diagnostics.
-Trying to determine if you are really binding the service four times to the
same port or this is just a ghost in the netstat program... Most systems are
designed to prevent binding multiple applications to the same ip/port, but a
service can spawn multiple threads on the same ip/port. You may be seeing the
threads and not unique service instances.
Looking at the process ID, you may be able to track back to the root process
and determine if these are just service threads.
Robert Wagner
________________________________
From: bind-users <bind-users-boun...@lists.isc.org> on behalf of Thomas
Hungenberg via bind-users <bind-users@lists.isc.org>
Sent: Monday, July 8, 2024 4:52 AM
To: bind-users@lists.isc.org <bind-users@lists.isc.org>
Subject: netstat showing multiple lines for each listening socket
This email originated from outside of TESLA
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
Hello,
we have been running some BIND nameservers on Debian-based systems for many
years.
Until (including) Debian 10 with BIND 9.11.5, netstat always showed only one
line
per listening socket, e.g.
tcp 0 0 10.x.x.x:53 0.0.0.0:* LISTEN
1234/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
1234/named
udp 0 0 10.x.x.x:53 0.0.0.0:*
1234/named
udp 0 0 127.0.0.1:53 0.0.0.0:*
1234/named
We noticed that with Debian 11 and 12 (BIND 9.16.48 / 9.18.24), netstat instead
shows multiple (on some systems four, on others up to 20) completely identical
lines
for each listening socket, like this:
tcp 0 0 10.x.x.x:53 0.0.0.0:* LISTEN
1234/named
tcp 0 0 10.x.x.x:53 0.0.0.0:* LISTEN
1234/named
tcp 0 0 10.x.x.x:53 0.0.0.0:* LISTEN
1234/named
tcp 0 0 10.x.x.x:53 0.0.0.0:* LISTEN
1234/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
1234/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
1234/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
1234/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
1234/named
udp 0 0 10.x.x.x:53 0.0.0.0:*
1234/named
udp 0 0 10.x.x.x:53 0.0.0.0:*
1234/named
udp 0 0 10.x.x.x:53 0.0.0.0:*
1234/named
udp 0 0 10.x.x.x:53 0.0.0.0:*
1234/named
udp 0 0 127.0.0.1:53 0.0.0.0:*
1234/named
udp 0 0 127.0.0.1:53 0.0.0.0:*
1234/named
udp 0 0 127.0.0.1:53 0.0.0.0:*
1234/named
udp 0 0 127.0.0.1:53 0.0.0.0:*
1234/named
We wonder what is causing this and if this is intended behaviour?
- Thomas

--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
