<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);">
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.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);">
-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.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);">
Looking at the process ID, you may be able to track back to the root process and determine if these are just service threads.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 14pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="Signature">
<div style="font-size:14pt;color:#000000;font-family:Calibri,Helvetica,sans-serif" dir="ltr" id="divtagdefaultwrapper">
<p style="margin-top: 0px; margin-bottom: 0px;">Robert Wagner<br>
</p>
</div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> bind-users <bind-users-bounces@lists.isc.org> on behalf of Thomas Hungenberg via bind-users <bind-users@lists.isc.org><br>
<b>Sent:</b> Monday, July 8, 2024 4:52 AM<br>
<b>To:</b> bind-users@lists.isc.org <bind-users@lists.isc.org><br>
<b>Subject:</b> netstat showing multiple lines for each listening socket</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">This email originated from outside of TESLA<br>
<br>
Do not click links or open attachments unless you recognize the sender and know the content is safe.<br>
<br>
Hello,<br>
<br>
we have been running some BIND nameservers on Debian-based systems for many years.<br>
<br>
Until (including) Debian 10 with BIND 9.11.5, netstat always showed only one line<br>
per listening socket, e.g.<br>
<br>
tcp 0 0 10.x.x.x:53 0.0.0.0:* LISTEN 1234/named<br>
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 1234/named<br>
udp 0 0 10.x.x.x:53 0.0.0.0:* 1234/named<br>
udp 0 0 127.0.0.1:53 0.0.0.0:* 1234/named<br>
<br>
<br>
We noticed that with Debian 11 and 12 (BIND 9.16.48 / 9.18.24), netstat instead<br>
shows multiple (on some systems four, on others up to 20) completely identical lines<br>
for each listening socket, like this:<br>
<br>
tcp 0 0 10.x.x.x:53 0.0.0.0:* LISTEN 1234/named<br>
tcp 0 0 10.x.x.x:53 0.0.0.0:* LISTEN 1234/named<br>
tcp 0 0 10.x.x.x:53 0.0.0.0:* LISTEN 1234/named<br>
tcp 0 0 10.x.x.x:53 0.0.0.0:* LISTEN 1234/named<br>
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 1234/named<br>
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 1234/named<br>
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 1234/named<br>
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 1234/named<br>
udp 0 0 10.x.x.x:53 0.0.0.0:* 1234/named<br>
udp 0 0 10.x.x.x:53 0.0.0.0:* 1234/named<br>
udp 0 0 10.x.x.x:53 0.0.0.0:* 1234/named<br>
udp 0 0 10.x.x.x:53 0.0.0.0:* 1234/named<br>
udp 0 0 127.0.0.1:53 0.0.0.0:* 1234/named<br>
udp 0 0 127.0.0.1:53 0.0.0.0:* 1234/named<br>
udp 0 0 127.0.0.1:53 0.0.0.0:* 1234/named<br>
udp 0 0 127.0.0.1:53 0.0.0.0:* 1234/named<br>
<br>
<br>
We wonder what is causing this and if this is intended behaviour?<br>
<br>
<br>
- Thomas<br>
<br>
--<br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at
<a href="https://www.isc.org/contact/">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
bind-users@lists.isc.org<br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</div>
</span></font></div>
</body>
</html>