I observe the same behaviour. I have similar output for TCP/53 on the loopback
and public IP addresses. The IP addresses and port numbers are the same, but
the fd (file descriptors?) are different. I assumed different threads of the
same process.
# named -V | grep ^BIND
BIND 9.18.26 (Extended Support Version) <id:936d80b>
# ss -lntp | grep 953
LISTEN 0 5 127.0.0.1:953 *:* users:(("named",pid=9623,fd=64))
LISTEN 0 5 127.0.0.1:953 *:* users:(("named",pid=9623,fd=61))
LISTEN 0 5 127.0.0.1:953 *:* users:(("named",pid=9623,fd=63))
LISTEN 0 5 127.0.0.1:953 *:* users:(("named",pid=9623,fd=62))
-----Oorspronkelijk bericht-----
Van: bind-users <[email protected]> Namens Thomas Hungenberg via
bind-users
Verzonden: maandag 8 juli 2024 13:13
Aan: Robert Wagner <[email protected]>; [email protected]
Onderwerp: Re: netstat showing multiple lines for each listening socket
Hi Robert,
it's the same PID for all lines, parent process is systemd.
The lines in the netstat output are exact duplicates (same IP, port and PID).
Other tools like ss show the same, so it's not a problem with netstat.
It's the same bahaviour on different machines, some upgraded from Debian < 11
and others installed from scratch with Debian 11 or 12.
I also set up a test VM and started BIND with the default configuration shipped
with Debian.
Same behaviour: All lines are shown twice.
It looks like on machines with only two interfaces (lo / eth0) the lines are
shown twice
while on machines with more interfaces (active or not) there are up to 20
duplicate lines.
- Thomas
On 08.07.24 12:10, Robert Wagner wrote:
> 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 <[email protected]> on behalf of Thomas
> Hungenberg via bind-users <[email protected]>
> Sent: Monday, July 8, 2024 4:52 AM
> To: [email protected] <[email protected]>
> 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
> [email protected]
> 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
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
________________________________________
Disclaimer High Tech Campus Eindhoven: The information contained in this
message and attachments may be confidential and legally protected under
applicable law. The message and attachments are intended solely for the
addressee(s). If you are not the intended recipient, you are hereby notified
that any use, forwarding, dissemination, or reproduction of this message and
attachments is strictly prohibited and may be unlawful. If you are not the
intended recipient, please contact the sender by return e-mail and destroy all
copies of the original message. Please visit:
http://www.hightechcampus.com/go/pages/disclaimer for the most recent
disclaimer.
--
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
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
