Re: problem running named in non 0 rdomain
On 1. jan. 2012, at 23.40, Stuart Henderson wrote: > On 2012-01-01, Pete Vickers wrote: >> snippet from /etc/named-gn.conf : >> controls { >> inet 10.20.30.2 port 954 allow {10.20.30.2;} keys {"rndc-key";}; >> }; >> >> then it also fails and complains thus: >> >> Jan 1 09:01:49 ns0 named[8504]: [child]: disallowed port 954 >> Jan 1 09:01:49 ns0 named[8504]: /etc/named-gn.conf:19: couldn't add command >> channel 10.20.30.2#954: permission denied >> Jan 1 09:01:49 ns0 named[8504]: running >> >> So I guess that named's (unprivileged?) child does not honour (inherit?) the >> parent's rdomain, and thus cannot bind to either rdomain '0' or '1', >> succesfully ? > > The child process only allows binding to ports 53/953/921, see > usr.sbin/bind/lib/isc/unix/privsep.c line 190. > > I'm pretty sure the child will be inheriting the rdomain from the process > which forked it. > ahh. Indeed. Once I used an approved port, it appear happy even in the non-defualt table: root@ns0 ~ # route -T 1 exec rndc -s 10.20.30.2 status number of zones: 3 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is ON recursive clients: 0/0/1000 tcp clients: 0/100 server is up and running thanks for the clue. /Pete
Re: problem running named in non 0 rdomain
On Sun, Jan 1, 2012 at 5:40 PM, Stuart Henderson wrote: > I'm pretty sure the child will be inheriting the rdomain from the process > which forked it. > I can offer the anecdote that when I ran sshd using the route -exec wrapper my child session would exist in whatever rdomain was hosting the daemon. Ended up backing away from this approach and sticking with pf rules, so I didn't have sshd parent processes littering my machine. I'll assume you don't want to use pf to land queries on the daemon, so the next question is did you try creating a loopback address in the non-zero rdomain to get the control port you need?
Re: problem running named in non 0 rdomain
On 2012-01-01, Pete Vickers wrote: > snippet from /etc/named-gn.conf : > controls { >inet 10.20.30.2 port 954 allow {10.20.30.2;} keys {"rndc-key";}; > }; > > then it also fails and complains thus: > > Jan 1 09:01:49 ns0 named[8504]: [child]: disallowed port 954 > Jan 1 09:01:49 ns0 named[8504]: /etc/named-gn.conf:19: couldn't add command > channel 10.20.30.2#954: permission denied > Jan 1 09:01:49 ns0 named[8504]: running > > So I guess that named's (unprivileged?) child does not honour (inherit?) the > parent's rdomain, and thus cannot bind to either rdomain '0' or '1', > succesfully ? The child process only allows binding to ports 53/953/921, see usr.sbin/bind/lib/isc/unix/privsep.c line 190. I'm pretty sure the child will be inheriting the rdomain from the process which forked it.
problem running named in non 0 rdomain
Hi, I am having difficulty running named in a non-default rdomain, on the following platform: root@ns0 ~ # uname -a OpenBSD ns0.whatever 5.0 GENERIC#36 sparc64 I have an interface in a rdomain '1': root@ns0 ~ # ifconfig bge1 | head -1 bge1: flags=28843 rdomain 1 mtu 1500 and happy: root@ns0 ~ # ping -c 1 -V 1 10.20.30.2 PING 10.20.30.2 (10.20.30.2): 56 data bytes 64 bytes from 10.20.30.2: icmp_seq=0 ttl=255 time=0.215 ms However, when I try to start the named daemon in that rdomain with the following command: # route -T 1 exec /usr/sbin/named -4 -i /var/run/named-gn.pid -c /etc/named-gn.conf the daemon starts successfully, but cannot open a control port on the loopback interface, and complains thus: Jan 1 09:12:19 ns0 named[23519]: [child]: disallowed port 954 Jan 1 09:12:19 ns0 named[23519]: /etc/named-gn.conf:21: couldn't add command channel 127.0.0.1#954: address not available This is fair enough I guess since the loopback interface is in the default rdomain, and is thus unavailable to named process. However if I instead explicitly configure the control port to be on the correct interface (IP address), thus: snippet from /etc/named-gn.conf : controls { inet 10.20.30.2 port 954 allow {10.20.30.2;} keys {"rndc-key";}; }; then it also fails and complains thus: Jan 1 09:01:49 ns0 named[8504]: [child]: disallowed port 954 Jan 1 09:01:49 ns0 named[8504]: /etc/named-gn.conf:19: couldn't add command channel 10.20.30.2#954: permission denied Jan 1 09:01:49 ns0 named[8504]: running So I guess that named's (unprivileged?) child does not honour (inherit?) the parent's rdomain, and thus cannot bind to either rdomain '0' or '1', succesfully ? To make matters worse, since I can't now use rndc to reload zones on the fly, I tried to HUP the named process, but this also fails miserably (since it appears to re-read the default config file instead) Is this a bug, or am I doing something silly ? (Suggestions regarding using other DNS daemons are not really helpful unless they are 1. in base, 2. can host both recursive & master services on the same IP/port) thanks & happy new year ! /Pete