Bug 1849661

Summary: bind: cannot bind on controls socket with address explicitly configured - race with NetworkManager
Product: Red Hat Enterprise Linux 8 Reporter: Stepan Broz <sbroz>
Component: bindAssignee: Petr Menšík <pemensik>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: medium    
Version: 8.2CC: aegorenk, fkrska, pemensik, thozza, tkorbar
Target Milestone: rcKeywords: Reproducer, Triaged
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-10-23 11:12:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1771008    

Description Stepan Broz 2020-06-22 12:57:03 UTC 
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
Comment 1 Petr Menšík 2020-06-23 08:45:27 UTC 
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.
Comment 7 Petr Menšík 2020-09-23 10:08:28 UTC 
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