Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
By default the "named.service" races with NetworkManager, which causes no trouble when "named" is listening on [::], [::1], 0.0.0.0 or 127.0.0.1, however, whenever an explicitly configured address is used in "named.conf", there is a risk of a failed bind to a socket before NetworkManager is even able to bring an interface up.
This has little effect on the DNS port (:53) as it bind binds to that last, however, has great effect on the "rndc" port (:953). This bug causes "named" to start not as configured.
Yes, the unit dependecy can be changed and worked-aroud using "network-online.target", however, that is not intuitive for the user. In my opinion the IP_FREEBIND (and non-Linux alternatives) socket option should be used, or any other mean of allowing binding on an address, that is not yet available on the system (e.g. watch for changes over netlink and retry later).
Version-Release number of selected component (if applicable):
bind-9.11.13-5.el8_2
How reproducible:
Always
Steps to Reproduce:
1. Configure a manually assigned IP address on an interface.
2. Add that address to the controls {}; section of /etc/named.conf:
controls {
inet 127.0.0.1 allow { localhost; };
inet 192.0.2.1 allow {192.0.2.1; };
};
3. Reboot the host.
4. Check "ss" or "netstat", bind does not bind on the rndc port for that address.
Actual results:
Error is logged, bind does not bind.
named[919]: configuring command channel from '/etc/rndc.key'
named[919]: /etc/named.conf:62: couldn't add command channel 192.0.2.1#953: address not available
Expected results:
No error, rndc working as expected.
Additional info:
Workaround: Make "named" to depend on "network-online.target" with the following override in /etc/systemd/system/named.service.d/override.conf:
[Unit]
After=network-online.target
Wants=network-online.target
I doubt IP_FREEBIND should be required for control channel. named does periodically rescan available addresses, in order to catch changes of addresses on interfaces.
It is possible it does not reuse this mechanism for control channel. It should be fixed to watch changes in addresses also.
Upstream complains transport security of control channel is not provided. As a workaround, ssh access to machine with named service can be used to run rndc commands just with localhost configured on control channel.
just use commands like:
ssh <named IP> rndc status
With use of SSH keys or key agents, it would still work without typing of passwords. It is also possible to limit accepted commands [1].
1. https://access.redhat.com/solutions/65822
Description of problem: By default the "named.service" races with NetworkManager, which causes no trouble when "named" is listening on [::], [::1], 0.0.0.0 or 127.0.0.1, however, whenever an explicitly configured address is used in "named.conf", there is a risk of a failed bind to a socket before NetworkManager is even able to bring an interface up. This has little effect on the DNS port (:53) as it bind binds to that last, however, has great effect on the "rndc" port (:953). This bug causes "named" to start not as configured. Yes, the unit dependecy can be changed and worked-aroud using "network-online.target", however, that is not intuitive for the user. In my opinion the IP_FREEBIND (and non-Linux alternatives) socket option should be used, or any other mean of allowing binding on an address, that is not yet available on the system (e.g. watch for changes over netlink and retry later). Version-Release number of selected component (if applicable): bind-9.11.13-5.el8_2 How reproducible: Always Steps to Reproduce: 1. Configure a manually assigned IP address on an interface. 2. Add that address to the controls {}; section of /etc/named.conf: controls { inet 127.0.0.1 allow { localhost; }; inet 192.0.2.1 allow {192.0.2.1; }; }; 3. Reboot the host. 4. Check "ss" or "netstat", bind does not bind on the rndc port for that address. Actual results: Error is logged, bind does not bind. named[919]: configuring command channel from '/etc/rndc.key' named[919]: /etc/named.conf:62: couldn't add command channel 192.0.2.1#953: address not available Expected results: No error, rndc working as expected. Additional info: Workaround: Make "named" to depend on "network-online.target" with the following override in /etc/systemd/system/named.service.d/override.conf: [Unit] After=network-online.target Wants=network-online.target