kerberos dynamic DNS and the internal DNS server
kai at samba.org
Fri Dec 30 03:22:50 MST 2011
On 2011-12-30 11:01, Andrew Bartlett wrote:
> 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.
> 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 disagree on the require part, at least for all clients, but I do agree
that we need support for GSS-TSIG. No arguments there. All I'm saying is
that I've seen setups that even under windows require people to allow
non-authenticated DNS updates, and I'm confident that we can give people
_that_ level of DNS already.
> 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.
Windows does. It seems we see things a bit different there, but at least
with my Wine background I'm fine with being bug-for-bug compatible. :) I
agree that we should be secure by default. Any other approach to
security is silly. But I also believe that if people want to run a
different set-up, we should allow them too. Personally, few things are
more annoying than a piece of software that, when I need to set a
potentially dangerous setting, flat out goes "Sorry Dave, but I can't
let you do that". There's a good reason most unix command line tools
come with a "--force" option.
> 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
Sure. You don't set anything, you get the default. But if you want
something else, you can still set it without having to recompile.
> 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.
Sure, feel free to change this. I'm not hung up on the wording.
Worldforge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
More information about the samba-technical