kerberos dynamic DNS and the internal DNS server

Kai Blin kai at
Fri Dec 30 03:22:50 MST 2011

On 2011-12-30 11:01, Andrew Bartlett wrote:

Hi Andrew,

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

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.


Kai Blin
Worldforge developer
Wine developer
Samba team member

More information about the samba-technical mailing list