Default DNS server for Samba 4.0

[Andrew Bartlett]

On Wed, 2012-09-05 at 14:02 +0200, Kai Blin wrote:
> Hi folks,
> 
> if you watched the patch stream, you might have noticed that I pushed a
> set of patches this morning that get the internal DNS server to a point
> where it can correctly negotiate GSS-based TKEYs and then use those
> TKEYs to verify TSIG signatures, e.g. for updates. I have tested this
> with a Samba3 client and a Win7 client, and both can successfully update
> their DNS records using GSS-TSIG signed update requests. (I actually
> pushed a messy set and have reverted it, sorry about that. I'll have a
> clean version up later today.)
> 
> With this code in place, I would suggest that we switch to the internal
> DNS as default for new Samba provisions. Seeing how much of our support
> burden is caused by the BIND setup, I'm hoping to make life easier for
> our users with this step. Defaulting to the internal DNS is something
> that we have discussed a couple of times in the past, and usually the
> only blocker people came up with was the lack of GSS-TSIG support. With
> the blocker gone, let's make the switch.

Kai,

As you know, I oppose changing the default implementation at this time.
I know you feel quite bad about this, so I hope I can explain why I feel
this way.

Indeed, the background for my position is best explained by what I wrote
in May on our private list:

> I think the situation around both our DNS solutions isn't ideal.  On
> the
> bind9_dlz side of things, we have no internal testsuite, the
> more-complex arrangement to segregate the DNS partitions, and we
> require
> Bind 9.8 or 9.9.  
> 
> On the Internal DNS side of things, we have simplicity of
> configuration,
> but major bugs outstanding.  On both we have a distinct lack of
> maintainer resources - with neither maintainer (Amitay or Kai) having
> work time to apply to ongoing issues.
> 
> The big difference between state of the two solutions as I see it is
> that the internal DNS server has much further to go in order for it to
> become the default.  That is due not only to the missing features and
> the serious bugs mentioned above, but also simply to the available
> developer time that would be required to fix any further issues that
> arise.  
> 
> Naturally, if a co-maintainer were to step up, this would greatly
> alleviate that situation, but *as it is* I find it hard to back a
> change
> from the current default when these are unimplemented, we are trying
> to
> pin down things for a release and the primary development is in such
> short, isolated bursts. 
> 
> On the flip side, I still fully support enabling and using the DNS
> server in make test, as a replacement for the flat-file that we
> currently use. 
> 
> Kai:  I know you are passionate about the DNS server, and I've enjoyed
> working with you on the GSS-TSIG support.  I wish you the best with
> it's
> continued development, because at some point (perhaps after 4.0) it's
> clear it will become the default, but I cannot support at change for
> 4.0
> at this stage, on the current status. 
> 
> Andrew Bartlett

Now, the current status of the DNS server has changed:  The recursive
issues are apparently resolved (but not tested in make test, as far as I
can see), and while the GSS-TSIG code and tests are still not in master,
you at least have them working for your initial tests.  Getting these in
master with is really important, because with these features it will be
possible to recommend to folks that the internal DNS server may provide
them with useful options.  It has also been great to see others step up
to handle some of the issues such as the async recursion. 

You have the advantage of choosing a design that allows internal
testing, so having that testing is clearly a blocker on proposing any
such change.   Having 'make test' run based on the internal DNS server
would be a good way to show it handling a higher-load, complex
environment, but at a minimum the recursive handling and TSIG code needs
a test.

Now once we have this in, we can gain the confidence of real-world use,
with multiple replicating DCs, joining Windows DCs to Samba, migrations
from dlz_bind9 etc.  We can refer users who have difficulties with bind
to this alternative, and we can understand how it behaves in
production. 

When we last discussed this, we were expecting to have or major features
in place before the beta, and it was clear you could not meet that
deadline.  However, at least I had the impression that you were planning
on working on it during the early part of the beta series.  It's now
just before RC1, and it has been great to see these features finally
about to make the tree.  

However, the RC1 date looms very, very soon (tomorrow or the start of
next week is the agreed date), and so the burden on you to propose a
change in the default is now quite high.  It certainly is a higher
burden than back in May, because over 3 months of potential testing,
particularly with the TSIG code in the real world has passed.  (I'm most
concerned about the TSIG code not just because it is new, but because
crypto bugs do take time to shake out). 

It is always incredibly painful for everyone when we have to make
decisions like this about such a promising feature.  But in the same way
that I came to the view that TDB2 was being modified and proposed too
soon before our release, this is why I cannot support changing the
default DNS server in these circumstances.

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org