Re: 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  on behalf of Thomas 
Hungenberg via bind-users 
Sent: Monday, July 8, 2024 4:52 AM
To: 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.

tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.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:

tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 10.x.x.x:53 0.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN  
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 10.x.x.x:53 0.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.0.0.0:*   
1234/named
udp0  0 127.0.0.1:530.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

Re: Question about ISC BIND COPR repositories for 9.16->9.18 ESV transition

[Robert Wagner]

If 9.16 was EOL at the end of April: 
https://kb.isc.org/docs/bind-9-end-of-life-dates  Help me understand why ESV 
wasn't rolled to 9.18 at that time or before in 2023 when it was marked as ESV?

It is difficult to explain to leadership why something was marked as EOL, but 
is still active in the pipeline.

The rollover plan and the graphic ISC's Software Support Policy and Version 
Numbering<https://kb.isc.org/v1/docs/aa-00896> do not seem to match.

Robert Wagner



From: bind-users  on behalf of John Thurston 

Sent: Monday, June 17, 2024 11:19 AM
To: bind-users@lists.isc.org 
Subject: Re: Question about ISC BIND COPR repositories for 9.16->9.18 ESV 
transition

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.

Have you considered scheduling the change in version published in each COPR 
repository so it doe not coincide with the release of a new version of BIND?

I have some hosts tied to the COPR for BIND-ESV, and some tied to BIND. I hit a 
stumbling block during the last "roll over" event, and it took me a a bit to 
figure out if it was due to the switch of BIND-ESV from 9.11 - > 9.16 in the 
repository, or the switch from 9.16.x -> 9.16.y in the code-release.

If we could have the version published in the BIND-ESV repository advance to 
the same version which was most recently published in BIND repository (i.e. 
ship 9.18.x in BIND, a couple of weeks later roll BIND-ESV to 9.18.x and BIND 
to 9.20.x, and a couple of weeks later release 9.18.y and 9.20.y), then 
problems with the COPR "roll over" would be a little more obvious.

--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov<mailto:john.thurs...@alaska.gov>
Department of Administration
State of Alaska

On 6/17/2024 2:32 AM, Michał Kępień wrote:

While I don't have a specific date for you, we plan to do such a
"rollover" again when BIND 9.20.1 or 9.20.2 gets released, i.e. in about
2-3 months from now.  We will definitely roll all three repositories at
the same time, i.e.:

  - "bind-esv" will move from 9.16 to 9.18,
  - "bind" will move from 9.18 to 9.20,
  - "bind-dev" will move from 9.19/9.20 to 9.21.
-- 
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

Re: Make dig and nslookup DNSSEC aware?

[Robert Wagner]

https://www.isc.org/blogs/bind-doh-update-2021/
BIND DoH Update
Status of DNS-over-HTTPS support in BIND 9 as of March, 2021 The latest 
development release of BIND 9 contains a significant number of improvements to 
DNS-over-HTTP (DoH).
www.isc.org

It looks like +https was added in version 9.17 I just need to get RedHat to 
start using it


RW


From: bind-users  on behalf of Havard Eidnes 
via bind-users 
Sent: Wednesday, May 22, 2024 11:47 AM
To: don.frie...@gov.bc.ca 
Cc: ond...@isc.org ; bind-users@lists.isc.org 

Subject: Re: Make dig and nslookup DNSSEC aware?

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.

>   Doesn't dig already offer DoT using +tls and DoH using +https?

You're right, it does.

I need to sort out my $PATH...

Regards,

- Håvard
--
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

Make dig and nslookup DNSSEC aware?

[Robert Wagner]

Sorry if this has already been hashed through, but I cannot find anything in 
the archive.  Is there any chance someone can make dig and nslookup DNSSEC 
aware and force it to use DoT or DoH ports - TCP 443 or 853 only?

RW
-- 
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