ISC releases BIND 10 1.2, renames it, and turns it over to community
ISC releases BIND 10 1.2, renames it, and turns it over to community
Posted Apr 25, 2014 18:09 UTC (Fri) by shane (subscriber, #3335)In reply to: ISC releases BIND 10 1.2, renames it, and turns it over to community by Cyberax
Parent article: ISC releases BIND 10 1.2, renames it, and turns it over to community
There are 14 processes with "akonadi" in my process table. Is this too many? Why?
I see 6 "getty" processes. Is that too many? Why?
And so on...
----
Just to be clear, none of the fast-path processing requires context switching between processes. The approach does not hurt performance, and may even improve it (depending on the exact model of processes vs. threads on a given OS & system architecture).
With BIND 10 we realized that a lot of administrators would not like to see that many processes. It's "weird". So we make sure that all of the startup, shutdown, and (if necessary) re-starting of processes is handled transparently by the application itself. We also made sure that every process is named starting with "b10-" so that administrators can easily see all of the BIND 10-related processes running... I don't like seeing strange processes running on my systems that I have no idea what they are doing, and I expect many sysadmins feel the same.
Still, it is clear that people get nervous by a DNS server running multiple processes, in spite of the fact that their web browser does it, their database server does it, their mail server does it, and even very popular DNS servers (NSD) do it.
----
BIND 10 does a lot of things that are not the current way of doing things. In retrospect, this was a mistake, as we exceed most people's tolerance for change. (Especially administrators, who are mostly a very conservative and even somewhat superstitious lot...)
----
We don't have any security between components, which are protected by normal Unix-domain socket file permissions. The components are intended to be different parts of a single application, running on a single machine. A compromise of the one component would not give an attacker direct access to all other running components, but it should be easy to cause a certain amount of mischief by using the message bus to send bogus commands around to other parts of the system.
The idea was to limit the complexity of an already complex architecture as much as possible. By using separate process spaces rather than a threaded or event-driven model (like all other name servers that I know of), we might be a bit more secure, but that's explicitly NOT a goal of the approach.