netstat showing multiple lines for each listening socket

[Robert Wagner]

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-bounces at lists.isc.org> on behalf of Thomas Hungenberg via bind-users <bind-users at lists.isc.org>
Sent: Monday, July 8, 2024 4:52 AM
To: bind-users at lists.isc.org <bind-users at 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 at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240708/db28d807/attachment-0001.htm>