ISC releases BIND 10 1.2, renames it, and turns it over to community

Posted Apr 18, 2014 4:16 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
Parent article: ISC releases BIND 10 1.2, renames it, and turns it over to community

Ok, I tried to install and test it. Ugh.

It created 6 daemons in the minimal configuration. In the complete configuration it'll have something like 12 daemons running, including its very own message bus (DBUS is too plebe). And anyway, I was not able to setup DNSSEC and it doesn't even support DNSSEC for DynDNS.

This all smells like DJB-envy. But djbdns was a small and nimble daemon, very easy to manage. It used regular tools like rsync for zone management and a very unixy zone files.

I think I'll stick to BIND9 or maybe switch to PowerDNS someday.

ISC releases BIND 10 1.2, renames it, and turns it over to community

Posted Apr 18, 2014 12:08 UTC (Fri) by TimSmall (guest, #96681) [Link]

I've always wondered why NSD isn't more popular for authoritative-only sites. Uses BIND-compatible zone files too (and has DNSSEC support)...

ISC releases BIND 10 1.2, renames it, and turns it over to community

Posted Apr 25, 2014 12:13 UTC (Fri) by shane (subscriber, #3335) [Link] (2 responses)

I'm the former project lead for BIND 10.

The reason we have so many processes is fault isolation and minimal bug surface area.

For example, if you don't need Dynamic DNS (DDNS) then you don't need to run b10-ddns, which is the component which supports that functionality. So any bugs in that code won't affect you, plus you don't carry the memory footprint for it and so on.

Further, if you *do* need DDNS, then any bugs that affect that code won't corrupt other parts of the system, and the DDNS component can be restarted in the worst case without affecting query processing or zone transfer (for example).

As for dbus, we did look at this, and really, really wanted to use it, but client library support and licensing issues made it really tough for us to adopt such technologies. We documented part of the effort here:

http://bind10.isc.org/wiki/msgqReplacements

We had pretty much decided on using Apache Qpid late last year, except that by that time the project was already on life support.

BIND 10 is in no way djb-envy. The goal was to replace BIND 9, which is a full-featured, scalable DNS server, not djbdns, which is neither.

ISC releases BIND 10 1.2, renames it, and turns it over to community

Posted Apr 25, 2014 12:28 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

I understand that process isolation might be good. But 12 processes? That is just too much.

Also,what is the security model? Will a compromise in, say, DNSSEC module allow an attacker unlimited control over all hosted zones?

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) [Link]

I just did a "ps ax" on my system and counted more than 80 kernel threads in my process table. Is this too many? Why?

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.