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
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.
Added the url of the merge request with the tentative fix.
(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?
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.
(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.
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
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"
(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.
(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.