kerberos dynamic DNS and the internal DNS server

[Andrew Bartlett]

On Wed, 2011-12-28 at 08:34 +0100, Kai Blin wrote:
> On 2011-12-28 02:57, Andrew Bartlett wrote:

> That sounds like the Gnome3 way of thinking, and I don't like the "we
> know better than our users, let's decide for them" approach. I'm all
> for having the default setting be "always require GSS-TSIG", but why
> take away people's ability to completely allow or disallow updates?
> 
> Anyway, if everybody keeps telling people to not use the internal DNS
> until it's tested, and does have all sorts of extra features, it'll
> never get tested. I know it's still missing features, but currently
> it's only me working on this thing and I do have a day job.

Kai,

You are quite correct to suggest that if we have a provision option for
the internal DNS server, that it is quite reasonable that the generated
smb.conf be set up to reflect that.  

We should also encourage our users to test it.  In describing our DNS
options, we should be clear to our administrators what is supported.  

We should let them know that as an alternative to an external BIND
instance, that the internal DNS server supports read-only access to the
data mirrored in the directory and updated via any other multi-master
nodes.  This is an important mode of operation, particularly in an RODC
environment.  It is also a very important upgrade for administrators who
otherwise would run Bind 9.7 with the flat file back-end. 

Indeed, based on your work, we may be able to remove the BIND flat file
backend, reducing the different combinations we will have to support in
provision. 

You will of course have noted that I describe your DNS server as
read-only, and I know you disagree with me on that.  For me, GSS-TSIG
security is a required element before we can describe the server as
supporting dynamic updates, as this is what our client operating systems
require and expect. 

I know this is a high bar, but I cannot see how we can suggest
unauthenticated updates as a safe method for deployed operation.  I of
course understand that these unauthenticated updates are an important
step in your development, but it is not a feature we should advertise to
our users, nor support long-term.  

Once we have GSS-TSIG support, we should remove the option, in line with
the approach of 'be secure' and 'do the right thing' that Samba4 has
taken for other similar decisions elsewhere.  Samba4 generally avoids
presenting smb.conf options to our administrators unless absolutely
necessary. 

In the interim, I would like the smb.conf option modified to 'False,
unauthenticated, authenticated' so that users are clear about what they
are enabling. 

Writing a DNS server is a big task, and the progress you have made so
far is very encouraging.  Having this DNS 'just work' inside Samba is an
important part of making Samba4 easier to deploy in the real world, and
your efforts to address this usability gap is much appreciated. 

Thanks,

Andrew Bartlett

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