Review request: DNS server implementation

[Kai Blin]

On 2010-10-12 14:09, simo wrote:

> In all seriousness, while I think it must be exciting to build new
> things, I think we have to stop building new servers.

I agree in principle, and this isn't a step I took lightly.

> This NIH syndrome is destructive. Who is going to maintain this code in
> the long run ? We can barely maintain the code we have, adding new
> servers seem to me like begging for problems later on.

So far, this is around thousand lines of code, about half of that is s4
task and tsocket boilerplate.

> What is wrong in building a BIND plugin and reducing the amount of work
> to maintain to the minimum necessary for us ?

Ah. I've got a list here.

1) Current BIND as shipped by distributions out there don't support
Kerberos-signed updates the way Windows AD wants it.

2) In order to get a version of BIND that suppports the AD features, you
need to grab BIND from ISC and compile it yourself. Last time I wanted
to do this (shortly before SDC), they noticed they had some bug in the
release candidate I needed and pulled the source.

3) You need to pay money to get access to the ISC CVS repository, so no
chances of getting the source there.

4) Tridge sent patches to the ISC and didn't receive feedback on their
status, which meant I spent some fun time playing "where's the patch"
with the b2 tarball that tridge got from the ISC after mailing them and
waiting for a couple of weeks.

5) Even if you have the right combination of BIND sources and tridge's
add-on patches, correctly setting this up is pretty painful. I
personally managed to get this to work once this year, at SambaXP with
tridge holding my hand for half an hour.

6) On the SDC plugfest and on the following AD interop plugfest, none of
the team members who wanted to set up an AD managed to get this to work
without tridge helping out. Doesn't look like a model that scales well.

7) Debugging BIND/GSSAPI issues is pretty painful unless you have an
intimate knowledge of Kerberos and BIND.

8) The configuration required is different for every distribution. The
suggestions samba4 provisioning prints out doesn't work on Ubuntu, or
openSUSE.

9) We have no way of figuring out that some BIND update broke this
pretty fragile setup before it hits our users, as there's no easy way to
get BIND tested in make test.

10) Adding a BIND ldb plugin is possible, but so far there's no way a
backend plugin can make decisions about who's allowed to do updates to
what records from the way I understand the code. We could possibly add
that, but that requires us to play "find the patch" again once we start
getting this upstream. Also, I can't help to notice that the bind-ldap
plug-in isn't maintained upstream but out-of-tree.

11) samba3 uses libaddns, which is a hand-marshalled DNS client library.
There's currently 1814 lines of code in the *.c files. We can easily
replace this with an IDL-generated library, allowing us to maintain
_that_ particular implementation of DNS in Samba. Given that the storage
backend for the DNS server already exists, all that's left is a pretty
thin layer of code.

All in all I'm not convinced that going the BIND route is less work,
pain, or long term maintenance effort.

Cheers,
Kai

-- 
Kai Blin
Worldforge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/