Review request: DNS server implementation

[Andrew Bartlett]

On Tue, 2010-10-12 at 15:00 +0200, Kai Blin wrote:
> 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.

I was wondering if for this layer (only) if there would be advantages to
using unbound?

http://www.unbound.net/documentation/libunbound-tutorial-4.html

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

I shared Simo's view that we didn't want to get into the DNS server
game, until I started working with Tridge on this.  I've never even
tried to get this working, but from numerous reports this is currently
this is the single most unreliable aspect of our provision and HOWTO.  

We have to do something here - with the upcoming requirements for the
LDB DNS backend, we can't even hope to leave the effort 'just' at coming
up with a foolproof, cross-distro configuration script.  

Even then, we keep hitting small (but blocking) issues with the
formatting of BIND replies that throw some non-Windows update clients
off track.  

While I'm cautious because DNS has been a security minefield in the
past, I think that given the situation at hand, and the clean, clear
code you have presented so far, this adds up to pretty good reasons to
consider your proposal. 

BTW, given quite how similar this is to the KDC (so much so that it
still bears comments like:
	/* Call krb5 */

I wonder if we could/should have an abstraction that handles this
boilerplate for the KDC, kpasswd and DNS server with more common code?

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20101013/f73018f6/attachment.pgp>