Re: V 9.18.1 not listen on port 853 after rndc reload
Dear All, many thanks pointing me into the right direction. // Hans — > On 21.03.2022, at 17:58, Ondřej Surý wrote: > > This is already being tracked as > https://gitlab.isc.org/isc-projects/bind9/-/issues/3122 > > Ondrej > -- > Ondřej Surý (He/Him) > ond...@isc.org > > My working hours and your working hours may be different. Please do not feel > obligated to reply outside your normal working hours. > >> On 21. 3. 2022, at 17:12, MAYER Hans wrote: >> >> >> 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 wrote: >>> >>> >>> On 21 Mar 2022, at 14:51, MAYER Hans 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 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 > -- 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
Re: Using nsupdate in scripts
On 3/14/2022 3:11 PM, Philip Prindeville wrote: I was hoping that there's a trivial way to parse the named.conf file and figure out what it listens on for updates using a Bind utility, but I guess not... The utility 'rndc status' will return the full path of the configuration file: rndc status | grep "configuration file:" And the utility 'named-checkconf -px configfile' will print out the configuration in canonical form, from which you could grab anything you like. But if what you want isn't in the configuration file (e.g. passed as a command-line parameter, or compiled in), then named-checkconf isn't going to help. To learn those, I think you'll need to query the operating system for information about the specif process. I'd be looking at pgrep and ps, but there's probably better ways to do it. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- 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
Re: V 9.18.1 not listen on port 853 after rndc reload
This is already being tracked as https://gitlab.isc.org/isc-projects/bind9/-/issues/3122 Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 21. 3. 2022, at 17:12, MAYER Hans wrote: > > > 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 wrote: >> >> >> >>> On 21 Mar 2022, at 14:51, MAYER Hans 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 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 -- 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
Re: V 9.18.1 not listen on port 853 after rndc reload
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 mailto:bor...@sarenet.es>> wrote: On 21 Mar 2022, at 14:51, MAYER Hans 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 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
Re: V 9.18.1 not listen on port 853 after rndc reload
> 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 Known bug, see https://gitlab.isc.org/isc-projects/bind9/-/issues/3122 and the thread starting at https://lists.isc.org/pipermail/bind-users/2022-January/105596.html Steinar Haug, Nethelp consulting, sth...@nethelp.no -- 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
Re: V 9.18.1 not listen on port 853 after rndc reload
> On 21 Mar 2022, at 14:51, MAYER Hans 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. -- 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
V 9.18.1 not listen on port 853 after rndc reload
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
Survey on DNS resolver operations and DNSSEC
Hi everyone, The DNS Security Extensions (DNSSEC) add integrity and authenticity to the Domain Name System (DNS). Now, more than 17 years after their standardization, we would like to hear from DNS recursive resolver operators about their experience with DNSSEC. For this reason, we have set up a short survey. It’s directed mainly towards organisations that run a recursive resolver. Filling out the survey should take roughly 5 to 10 minutes. https://forms.gle/FxTD9FofaogdvLqcA (link directs to Google Forms) This survey is carried out by SIDN Labs (https://sidnlabs.nl) and by the Swedish Internet Foundation (https://internetstiftelsen.se/en/). You can contact us via email: moritz.mul...@sidn.nl Please excuse us, if you have received this email via different mailing lists. — Moritz Müller Research Engineer at SIDN Labs signature.asc Description: Message signed with OpenPGP -- 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