Review request: DNS server implementation

[Kai Blin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2010-10-13 00:20, Andrew Bartlett wrote:

>> 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

I'm not quite sure I understand your suggestion here. The layer I'm
talking about is the glue code that translates from the DNS wire format
to and from the in-LDAP storage format of DNS, which is pretty similar
but slightly different. (Thank you Microsoft.) For the update code,
there's some additional sanity checks the server needs to do to return
the correct error codes. I'm not sure how libunbound, an async dns
resolver library, helps here. Or are you suggesting to drop libaddns in
favour of libunbound? In that case we'd have to check libunbound in
versions available in common distros groks GSSAPI signing of update
requests.

>> 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.  

Just my point. And we can only test for working setups manually.

> 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.  

If someone is willing to prove me wrong, I'm happy to be convinced.

> 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. 

The code is obviously still missing a test suite, and there's also a
security-related test suite at
https://www.ee.oulu.fi/research/ouspg/PROTOS_Test-Suite_c09-dns. I think
this is a manageable risk.

> 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?

I'd tend to agree, but given that I need to stick in some code into the
basic startup code, I'm not sure how that'd work in a generic case.

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/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky1Tb4ACgkQEKXX/bF2FpTGogCgiGL1VnfZxPILwIqejuI9uDc+
L7cAoJotQOQRzAoV1TSzSQDDeeBWJavz
=jR58
-----END PGP SIGNATURE-----