NDC vs. kill -HUP

[Jim Reid]

>>>>> "Michael" == Michael Kohne <mhkohne at discordia.org> writes:

    Michael> I'm sorry, I just had to respond to Jim on this one.

There's no need to apologise. Respond away....

    Michael> Yes, signals are a little broad, and I guess you could
    Michael> say they are 'crude', but in reality, it's just not very
    Michael> fine grained. If you run nameservers that only have one
    Michael> or two zones (as I do) what is the benefit of more fine
    Michael> grained control? I edit my named configs perhaps once
    Michael> quarterly - why should I bother with something like ndc,
    Michael> which adds complexity (and therefore risk) to my systems,
    Michael> and gives me almost nothing in return?

Because using signals for IPC is very crude and limiting. There are a
very small number of "messages" that can be sent with signals. What
will you do when the name server offers more management capabilities
than can be addressed by the 30 available signal numbers? Or if you
just want to reload one zone? Or if the UID running the name server
doesn't have a login shell? I suspect the overall risk of using ndc to
manage the name server is no different from sending signals.

    Michael> I guess what really triggered this message is that you
    Michael> called signals 'old-fashined'. I'm sorry, but I want my
    Michael> systems to run, not be fashionable. And I don't like
    Michael> being called old-fashioned just because I don't grab
    Michael> every new and (for me) inappropriate tool that comes
    Michael> along.

Fine. If you're happy with prehistoric IPC facilities, carry on using
them. After all it's your name server and how you choose to run it is
nobody else's business. If you thing ndc is an inappropriate tool,
we'll just have to agree to differ. [The interface provided by ndc is
clumsy and ugly, but the principle of using a socket to talk to the
name server is the right way to do things IMHO.] BTW, using signals as
a means of controlling the name server is going to go away in BIND9. A
grown up version of ndc that works securely over the net is provided
instead. Albeit that rndc lacks some functionality at present. It
might be a good idea to start preparing for that change by getting out
of the habit of typing "kill -FOO ` cat /var/run/named.pid `".

    Michael> If Mark has more than a few zones or changes them daily,
    Michael> then ndc is probably valuable. Otherwise, why bother?

See above. Or as I explained earlier, what if SIGHUP/SIGINT/SIGIOT etc
doesn't do what you expected on some future/earlier version of BIND?
And what if the name server is running under a non-root UID that has
/bin/false as its login shell? How will you send signals to the
process then? There are bound to be lots of security vulnerabilities
in the solutions to that problem. Or how about if the pid file you use
to signal the name server accidentally or deliberately contains the
PID of some other process?

Remember that signals were originally never meant to be an IPC
mechanism. They were "software interrupts" to allow a process to clean
up before exiting when something went wrong. Since that was the only
way for unrelated processes to talk to each other in early UNIX
implementations, signals got abused for all sorts of things they were
never intended for. The limitations of signals for IPC and the impact
they have on software that relies on them are all too painful.