Review request: DNS server implementation

[Andrew Bartlett]

On Wed, 2010-10-13 at 08:12 +0200, Kai Blin wrote:
> -----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.

I was just thinking for the generic forwarding of lookup requests
(only), so as to handle the DNSSEC stuff, which from a position of no
real understanding seemed tricky.

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

I think perhaps I miss-emphasised the tone of my e-mail.  We are in
violent agreement here :-)

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

I'm not sure it's even about proving you wrong - someone would have to
write and maintain the LDB backend for BIND, and manage the process of
getting those extra hooks into distribution-shipped versions first :-)

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

Anyway, I look forward to seeing this in the tree.  It is great to see a
positive proposal for a way out of this quagmire. 

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/a31c872d/attachment.pgp>