Ok, this is a major security issue. BIND by default listens on the remote control (rndc) port 953. It would be fine, but it does so without any named.conf settings specifying that it does. Looking at named.conf there’s nothing saying that BIND’s remote control is on that would alert users to disable remote access capability.
I had something try to connect to that port today, and it was not me. So I have to bring this up with the Fedora community. Right now, the only way to disable it is to ask Grok, basically.
Btw there is no security issue. sudo ss -naptl | grep 953
You will see that the port is listening on localhost (if you haven’t changed the default configuration), so it is not accessible from the network.
In addition, if you haven’t changed the configuration, by default firewalld should be blocking such port.
It does listen on localhost address, port 953 by default, yes. I would not call it a security issue if it listens on localhost only. If you configure controls to anything specific, that will override defaults. You can disable it explicitly. But there is nothing unsafe about having rndc.key generated automatically on the first start. Because it does not listen on any addresses on IPv4 or IPv6, there is no danger in listening there. Having the rndc is very useful to have and we definitely want it enabled by default. You can check it listens only on localhost by command: ss -lntp sport = :953. Even if it did not, it won’t accept commands unless you provide correct shared secret stored in /etc/rndc.key or /etc/rndc.conf. You can prevent creating it just by systemctl mask named-setup-rndc command, but it would not prevent named from listening on port 953. Empty controls {}; block will do that, as mentioned already. It is clearly declared in bind ARM and also mentioned in man 8 rndc. I think majority of users want to have rndc interface enabled and working by default and it is there.
Is there any specific reason, why do you want the control port disabled? It can be misused only by local running processes, because it is listening on localhost by default. Just like it does with port 53 anyway in default package configuration.
logrotate will trigger periodic systemctl reload named calls, which result in rndc reload calls. That might be local connections you saw and were not you. logrotate script is shipped with bind package and is enabled just by installing bind. Could this be what have scared you?
Yes, and you have internet connected applications running on localhost, like browsers! And browsers have access to localhost ports by default and also have read access to /etc files. So yes, I believe having it on is a security issue unless configured properly by default, which it will probably never be (configured properly by default).
rndc.key is readable only by named group or root user. Normal processes on localhost cannot read that file, unless the user adds himself into named group.
More importantly, unlike unbound-control interface, rndc is more limited and typically can trigger just some maintenance or cache flush, but not a behaviour change. By default adding or removing dynamic zones runtime is not possible. It is possible to trigger configuration file reload or dnskey rollover, but not to change configuration via rndc interface. That typically requires root user to edit configuration file. Local process ability to connect to that socket still lacks correct key “rndc-key” secret knowledge, which is never accessible by unprivileged users.
I think it is configured by default and quite secure in default configuration. Sure, you can change it, but defaults are secure. I think only few rndc commands could be misused, like disabling validation or stopping the daemon. I think SELinux would not allow browser to read rndc.key anyway, but did not test it.
In any case, it uses relatively common pattern to use IPC communication. Group authentication is used by unbound the same way. I think similar service control machanisms are common. apachectl could be just example.
Besides this behaviour were present minimally since 9.11.0, which is quite old. This is far from new behaviour, has there been for ages. I think some versions before 9.11 required explicit rndc.conf, but that is old history. A bit annoying is that unix socket control is no longer supported, but group-only readable secret is good enough protection anyway.
Could be tuned by refusing browsers to connect to port 953 perhaps by SELinux policy. But I do not think anything needs to be changed in bind configuration related to control channel.
Okay, well, I was sort of seeing weird behavior after I started using BIND with default configuration. I didn’t thoroughly investigate it, but everything is okay now that I disabled BIND’s port 953 and disabled “controls” in options to allow bind to communicate with remote hosts (which is on by default).