BIND9 is the emacs of DNS servers: It includes everything but the 
kitchen sink.  This results in a full-featured DNS server that has
about 5,000 features you will never use.  

BIND is a very large application.  On my system, a stripped BIND 9.2.6
binary is some 1,117,348 bytes in size.  The maradns binary is only
150,912 bytes in size.  The zoneserver binary, if needed, is only
110,912 bytes in size--resulting in a combined size of 261,824 bytes.
This is a fraction of the size of BIND, making MaraDNS more suitable
for embedded applications or on systems with limited resources (such as
heavily loaded web servers).

BIND's configuration is somewhat cryptic.  For example, here a BIND
setup that uses a custom root server; this shell scipt will set up
all the files needed to start up BIND9 and run named in the current
directory:

cat > named.conf << EOF
options {
	directory "$( pwd )";
	pid-file "named.pid";
	allow-query { 127.0.0.1/8; };
};
zone "." { 
	type hint; 
	file "root.hint"; 
};
EOF
cat > root.hint << EOF
\$TTL 86400
.		IN NS a.root.bogus.
a.root.bogus.	IN A  127.0.3.1
EOF
chown root:root .
named -c named.conf

Note that this basic configuration needs two different files with two
different syntaxes.  Compare this to MaraDNS, which needs just one 
simple four-line file:

cat > mararc << EOF
chroot_dir = "$( pwd )"
ipv4_bind_addresses = "127.0.0.1"
recursive_acl = "127.0.0.1/8"
root_servers["."] = "127.0.3.1"
EOF 
maradns -f mararc

One key difference between this simple MaraDNS configuration and
the corresponding simplified named configuration is that the named
server will run as root with full access to the filesystem; the 
corresponding simple MaraDNS confiuration will run as "nobody" in
a limited-access chroot() environment.  While it is possible to
run BIND as an unprivileged user in a chroot() environment, this
configuration is non-trivial and not fully described in BIND's
documentation.

Indeed, BIND9 has had one remotely exploitable buffer overflow.
Basically, older versions of BIND9 linked to the OpenSSL library, which
had the offending buffer overflow.  This is why MaraDNS has a strong
"not invented here" policy; the only external libraries that MaraDNS
uses are the libc library and the pthreads library.  The reason for this
is to minimize security problems that external libraries may cause--a
problem that bit BIND9.

BIND, to its credit, does have a number of features which I haven't
yet implemented in MaraDNS.  BIND supports standard RFC-compliant zone
files.  While MaraDNS' csv2 zone file format is mostly BIND-like, there
are differences that make the two zone files incompatible.  I plan on
writing a converter in the near future and eventually having full RFC
zone file support.   BIND, of course, also has full support for being
a DNS slave, including NOTIFY and IXFR support--features which I may
eventually add to MaraDNS.

One of the reasons why BIND has good RFC support is because the BIND
developers are the people most involved with the DNS standards.  For many
years, BIND was the only usable DNS server that existed; as more and
more features were added to BIND, the standards were revised to have the
new features.  There are no less than 96 different RFCs which at least
in part discuss DNS; very few, if any, people are familiar with all of
the relevant DNS standards.  Not even BIND follows all of the standards;
for example, BIND only supports a QDCOUNT of 0 or 1, but the stadnards
say that a DNS server should support a QDCOUNT between 0 and 65535
(RFC1035 section 4.1.1).

In conclusion, while BIND9 has better RFC compliance and more features,
it is a far bigger program that is more difficult to configure than 
MaraDNS.  It is a bigger binary that uses up more memory than MaraDNS.
Its security history is not as good as MaraDNS' security history.  The
two DNS servers have different compromises between code size, features,
ease of use, and security.

