Hi Borja,

Many thanks for this hint. I tried to allow with
setcap 'CAP_NET_BIND_SERVICE=+eip'  /usr/local/sbin/named
but it didn’t help.

On other hand there is no issue on port 53 and 953. Why should it be just on 
port 853 ?

Kind regards
Hans



On 21.03.2022, at 15:26, Borja Marcos 
<bor...@sarenet.es<mailto:bor...@sarenet.es>> wrote:



On 21 Mar 2022, at 14:51, MAYER Hans 
<hans.ma...@iiasa.ac.at<mailto:hans.ma...@iiasa.ac.at>> wrote:


Looking at the log I see:
network: error: creating TLS socket: permission denied

Why doesn’t named have the permissions after a „rndc reload“ but it has the 
permissions after a start ? And why on one server but not on another ?
In both cases the daemon is running as user „bind“ with UID below 128 but not 
as root.

Because it usually starts as root and it demotes itself to “bind” whenever 
possible.

Maybe there is a mechanism in Linux to grant permission to a certain UID to 
bind() a socket to certain privileged
port number, as it is used for NTP on FreeBSD?




Borja.






On 21.03.2022, at 14:51, MAYER Hans 
<hans.ma...@iiasa.ac.at<mailto:hans.ma...@iiasa.ac.at>> wrote:



Dear All,

now BIND 9.18 is supporting DoT directly I tried to go away from a solution 
with stunnel4 and therefore I compiled 9.18.1 and modified named.conf
So far everything is working fine. All the tests with dig , openssl and lsof is 
showing it’s working.
The problem: when I run a „rndc reload“ the named process is not listen on 
853/tcp anymore. All tests with TLS fail. And this on IPv4 as well on IPv6.
The rest of BIND is working well. Still listening on port 53 on UDP and TCP
When I restart the service so that named stops and a new process is started and 
running then DoT is working again.
I run this on Debian 10 buster.
The interesting story is I run the same version 9.18.1 on a different Debian 10 
buster server. On this server the process „named" survives a „rndc reload“  on 
port 853

Looking at the log I see:
network: error: creating TLS socket: permission denied

Why doesn’t named have the permissions after a „rndc reload“ but it has the 
permissions after a start ? And why on one server but not on another ?
In both cases the daemon is running as user „bind“ with UID below 128 but not 
as root.

Any ideas where to look ?

Kind regards
Hans

—


maybe the important part of the config

       listen-on {
                  my.ipv4.hiding.here  ;
                  127.0.0.1 ;
       };
       listen-on port 853 tls iiasaatls { any; };
       listen-on-v6 { any ; } ;
       listen-on-v6 port 853 tls iiasaatls { any; };




-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to