How secure is rndc?

Marc Haber mh+bind-users at
Wed Jan 3 18:34:55 UTC 2007

On Thu, Dec 21, 2006 at 02:48:13PM +0100, Marc Haber wrote:
> I am wondering whether it is a problem to run rndc over the Internet
> to a remote server. I am usually using ssh to "tunnel" the rndc
> request (ssh remotehost rndc foo) but I am wondering whether I'd lose
> much security if I'd use rndc -s remotehost foo instead.

I would like to thank anybody who has commented in this thread. In the
mean time, I have found out why ssh remotehost rndc reload failed
after a few invocations, and have fixed this symptom. I therefore do
not need to run rndc over the Internet any more.

The new problem is the following: I have a client C, a host running
bind9 H that is behind a firewall and a shell host S which is being
used as an ssh proxy to access H.

I therefore issue
ssh -o "proxycommand ssh S socket %h %p" H rndc reload
to reload bind on H. In this setup, each invocation of rndc leaves two
sshd processes behind on H and a socket process on S. The sshd
processes on H stay around indefinetely, and thus with each invocation
I get two more sshd processes until finally the memory is depleted and
no more rndc is possible. This does not happen when invoking other
processes such as "ls", "sudo /etc/init.d/bind9 stop" or even "true"
via this channel, so it must be an rndc issue. I suspect that rndc
leaves some file descriptors open or does not free all of its
resources, and so sshd does still think that the kid process is running.

I have solved this issue by setting a rather short ssh keepalive
timeout on H by setting "ClientAliveInterval 15" in sshd_config.

But what goes wrong with rndc in the first place? Why don't the sshd
daemons terminate correctly when the invoked process is rndc?


Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

More information about the bind-users mailing list