Default DNS server for Samba 4.0

[Kai Blin]

On 2012-09-06 01:11, Andrew Bartlett wrote:

Hi Andrew,

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

That's exactly why I was working on changing that status, which was "no
GSS-TSIG support".

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

They are, and were by the time you wrote this email. They don't have
tests yet, but I'm sure we can get s3 to join and update DNS info pretty
easily.

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

Stop harping on the fact that the patches aren't in master, because THEY
ARE! They were not by the time I wrote this email, because I was at work
and the patches were at home, but I fixed that once I got home. I can't
help it that I'm not paid to work on samba and thus have all my samba
code around on my work machine during the day.

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

So now it's testing? You keep raising the bar on me, every time I
proposed using the internal server. When I first got it to work, we
couldn't use it because it didn't do updates. Then I implemented
updates, and we couldn't use it because they couldn't be signed. Now
they can be signed, and we can't use them because they have no tests?
You're telling me that I'm late because I fail to hit a constantly
moving target for a moving deadline?

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

We have real world use data with the DNS server. It's running on the
SerNet appliance, and turned up a couple of bugs when they first started
using it. Those were fixed, and I haven't heard any complaints in quite
a while. Don't tell me that we don't have experience because you don't
have experience. Otherwise I can make the same claim. I've never managed
to get the BIND stuff to work for me, and I can set up the internal
server within minutes.

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

But we did agree that the target was "before RC1". I was planning on
working on this sooner, but as it happens, I do have a day job, and
crypto stuff isn't exactly trivial, so I didn't manage to get it in
beforehand.

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

As far as I understand we're still holding the release for SMB3 code to
even hit the tree. Now while you can argue that Metze certainly is a
more experienced developer than I am, it's still new, untested code.
Getting things tested and shaking out bugs is what release candidates
are for. And if things do go wrong, we can tell people to fall back to
the bind solution. That way they only need to go through the setup
hassle if the internal dns doesn't work.

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

We just changed printing, the file server, parts of the file server
build system. That was fine. TDB2 was a huge change touching many parts
of the code base. Comparing the dns server to TDB2 is an apples to
oranges comparison.

But I can see that we won't manage to agree on this before the RC1. I
appreciate your comments, and you certainly defined the roadmap of
further work on the internal dns server, but I don't consider them to be
blockers, seeing how much easier this will make it for people to get
started with a samba AD deployment.

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120906/060cecce/attachment.pgp>