Default DNS server for Samba 4.0

[Morten Kramer]

Hi,

I'm not a dev, but just a 'user' of Samba4, but would also like to see 
the internal DNS more tightly embedded in Samba4.


Been using it since beta2 now, not having the encrypted updates in it.
Not sure what implications it will have, if it's not the default, but 
rather an alternative to Bind.

All i know is that I don't feel very comfortable using this huge Bind 
software and this DLZ plugin which is not issue-free as well. Having DNS 
integrated into Samba seems like the way to go. It's kind of what 
Windows does as well.





Regards,
Morten



Am 06.09.2012 14:03, schrieb Kai Blin:
> On 2012-09-06 13:16, Andrew Bartlett wrote:
>
> Hi Andrew,
>
>> I'm not sure where you got the idea that it was acceptable to have
>> untested code in Samba.  That the DLZ code is in this state (which I am
>> working to rectify) is no excuse to introduce more untested code.
> Well, I got the idea by looking at the other DNS implementation we had.
> I agree it's nice to have tests, and I'd have bought the argument if the
> tests had been in there a couple of betas ago.
>
>> Secondly, I'm sorry if you felt that the required feature standard was
>> anything less than DNS forwarding and GSS-TSIG correctly coupled to the
>> directory ACLs.  I'm not sure how that wasn't clear, but you clearly
>> feel mislead.
> This probably is twenty bloody lines of code, looking at the DLZ plugin.
>
>> In terms of the deadline, yes, it keeps changing.  When we previously
>> talked about needing to close off Samba 4.0 to new features, you raised
>> that you will not be able to complete this feature in time, and asked
>> that you be allowed an even closer approach to the RC to finish your
>> features off.  Perhaps it would have been kinder to have left this at
>> the beta stage, but then we wouldn't have this impressive facility at
>> all!
> I can't shake the impression that our betas were simply alphas with a
> different name, though. The release candidate stage is where we stop
> working on new features and work on stabilizing the ones we have. If
> "has to be bug free" is the bar, then we probably should just give up.
> But yes, I agree that I'd probably have spent my time differently if it
> had been clear we don't care about the internal DNS a couple of months
> back. This certainly is a reason why this feels like bait-and-switch. It
> sure is the reason why I'm disappointed.
>
>> I do hope you didn't feel I promised you that you would have the
>> automatic right to change the default, because I always intended to
>> assess the state of the two options at the time the internal DNS server
>> is 'finished'.
> No, but I had the impression that you are not the only person who gets
> to decide what the 4.0 release will look like. And I had the feedback
> from other people that they were really interested in getting the
> internal server in as the default implementation. That's why I brought
> this up on the mailing list.
>
>> You described your testing as joining a Windows7 client.  I'm
>> particularly concerned to ensure that things like DC joins also work, as
>> do the other things I mentioned.
> Right. There's a wiki page for DNS, how about we put a test matrix
> there. That'll give people an idea of what's been tested, and which dns
> backend they want to use.
>
>> We should walk before we run:  Get the feature finished, get the
>> automated tests written, make it available and ask that people test it.
>> Test it with the various windows combinations that we need.  Get it into
>> the SerNet appliance.
> I'm happy to work on all that. I just don't see why this has to be done
> before even considering the implementation. I see this as part of the
> "shake out bugs" phase.
>
>> Then, with that backing, you would have good grounds to discuss a change
>> in the default.  Anything else is premature, particularly as we don't
>> yet even have correct ACL checking on the updates.
> Right. If you point me at the tests for the ACL stuff in bind_dlz, I'm
> happy to make them work in the internal server.
>
>> It is particularly premature to ask to change the default the day you
>> finish the most complex component, before adding the required tests.
> At least it's a component where adding tests is an option.
>
>> I'm happy that you have managed to almost complete the feature before
>> RC1.  This means we can include it in the release.
> Thank you.
>
>> No, I don't see the release candidate period as a time to flip features
>> on and off.  The agreed procedure is for bug fixes, with a genuine
>> feeling that this is a release candidate, not just another period of
>> betas.
> Right, my suggestion was for the case that we couldn't fix the bug in
> time. We try to make it work on the "easy for the users" end, and if
> that doesn't work, we can still fall back to the bind_dlz backend.
>
>> I'm glad you understand my position.  Had we had this code in the tree
>> even just a couple of betas ago, and the tests had been finished in the
>> meantime, I think this would be a very different discussion.
> As I mentioned before, I didn't see that much difference between the
> alpha and beta releases. We had two beta releases that were more broken
> than many of our alphas were. I fail to see how that is stabilization.
> RC1 is the first point were we draw a line on the ground and say "from
> here on, we focus on making it work reliably".
>
> Anyway, we seem to be measuring our DNS implementations using different
> scales, and I happen to be passionate for the one that got the shorter
> stick. It was pretty clear from our IRC conversation yesterday that we
> disagree on this. You have made some clear points, even if they aren't
> necessarily convincing in my arguably biased opinion. Anybody else with
> an opinion to get us out of this?
>
> Cheers,
> Kai
>