Bug 281006

Summary: dns/bind920: not listening to rndc port
Product: Ports & Packages Reporter: takefu
Component: Individual Port(s)Assignee: Mathieu Arnold <mat>
Status: New ---    
Severity: Affects Only Me CC: peter, russo, tatsuki_makino, xxjack12xx
Priority: --- Flags: bugzilla: maintainer-feedback? (mat)
Version: Latest   
Hardware: Any   
OS: Any   
URL: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/9123
Attachments:
Description Flags
bind920-9.20.1_1.patch none

Description takefu 2024-08-23 05:21:35 UTC
Created attachment 253030 [details]
bind920-9.20.1_1.patch

I lost control of rndc so I searched for a solution and found one.

https://gitlab.isc.org/isc-projects/bind9/-/compare/main...4793-bind-9-19-24-not-listening-to-rndc-port-953-on-localhost
Comment 1 Jack 2024-08-23 05:29:31 UTC
I worked around it by setting net.inet.ip.portrange.reservedhigh to lower than 953 and set net.inet.ip.portrange.first to lower than 953 also.
Comment 2 Mathieu Arnold freebsd_committer freebsd_triage 2024-08-25 08:14:11 UTC
Added the url of the merge request with the tentative fix.
Comment 3 takefu 2024-08-25 23:30:59 UTC
(In reply to Jack from comment #1)

I configured /etc/sysctl.conf as suggested in 14.1-RELEASE-p3 but it doesn't work.

# echo net.inet.ip.portrange.first=952 >> /etc/sysctl.conf
# echo net.inet.ip.portrange.reservedhigh=952 >> /etc/sysctl.conf
# reboot

# sysctl net.inet.ip.portrange.first
net.inet.ip.portrange.first: 1024
# sysctl net.inet.ip.portrange.reservedhigh
net.inet.ip.portrange.reservedhigh: 952

Is there anything else I can try besides the patch you submitted?
Comment 4 Mathieu Arnold freebsd_committer freebsd_triage 2024-08-26 08:51:42 UTC
If you want to try an experimental patch, I would suggest you taking the one from the merge request, but bear in mind it has not been fully reviewed, and may not work properly.
Comment 5 takefu 2024-08-27 01:38:22 UTC
(In reply to Mathieu Arnold from comment #4)

I couldn't figure out how to get the diff file from gitlab.isc.org, so I created a patch file.
It works as expected in my environment, but it's an experimental diff, waiting for mainstream certification.
Comment 6 Tatsuki Makino 2024-08-29 09:07:40 UTC
By the way, why did the order of execution of named_controls_configure and named_os_changeuser change?

https: //gitlab.isc.org /isc-projects/bind9/-/blob/bind-9.18/bin/named/server.c?ref_type=heads#L9537
https: //gitlab.isc.org /isc-projects/bind9/-/blob/bind-9.18/bin/named/server.c?ref_type=heads#L9561

https: //gitlab.isc.org /isc-projects/bind9/-/blob/bind-9.20/bin/named/server.c?ref_type=heads#L9426
https: //gitlab.isc.org /isc-projects/bind9/-/blob/bind-9.20/bin/named/server.c?ref_type=heads#L9787
Comment 7 Tatsuki Makino 2024-08-30 05:54:18 UTC
When we change the portrange in sysctl, we also need to make sure that we don't set a variable in /etc/rc.conf that changes it.
The variables are ip_portrange_first and ip_portrange_last, and are used in /etc/rc.d/netoptions.
It's about doing it one way or the other.

Another possible workaround is to change the control port.
For example,
controls { inet ::1 port 1953 allow { localhost; } keys { "rndc-key"; }; };

In this case, rndc_flags variable needs to be added to /etc/rc.conf in order to add port options to rndc.
However, as we see in /usr/local/etc/rc.d/named, if rndc.conf or rndc.key file exists and the size is not 0, we must not forget to specify an option on it.
For example, chroot-ed to /var/named, named.conf is exist in /usr/local/etc/namedb,
rndc_flags="-p 1953 -k /var/named/usr/local/etc/namedb/rndc.key"
Comment 8 takefu 2024-09-19 22:56:38 UTC
(In reply to Tatsuki Makino from comment #7)

Will the change from the 'rndc' standard port confusing the users?
If it is changed, you need to describe the 'UPDATING' file.
Comment 9 Tatsuki Makino 2024-09-20 01:37:44 UTC
(In reply to takefu from comment #8)

Of course, it's not a good thing to normalize. It's just a workaround that doesn't patch the code.
It is present on page 15 by accessing the URL written in /etc/services, but since it is a registered port, it should be used.

And since that port is a well-known port, I don't think it should be avoided from being bound during privileged operations.