[SSSD-users] FW: 1.11.5 ddns failure on Ubuntu 14.04[SOLVED]

Simo Sorce simo at redhat.com
Wed Jun 25 15:00:47 UTC 2014


On Wed, 2014-06-25 at 16:22 +0200, Jakub Hrozek wrote:
> On Wed, Jun 25, 2014 at 04:07:12PM +0200, steve wrote:
> > On Wed, 2014-06-25 at 15:43 +0200, Jakub Hrozek wrote:
> > > On Wed, Jun 25, 2014 at 09:34:25AM -0400, Simo Sorce wrote:
> > > > On Wed, 2014-06-25 at 09:30 +0000, Longina Przybyszewska wrote:
> > > > > With correct domain ;)...
> > > > > 
> > > > > >By default, we contact the server we establish the LDAP connection with. I’m sorry, I got a bit lost in the thread — what was >the difference between the right server and the wrong server in your setup.
> > > > > 
> > > > > In our case,  DNS server is not LDAP - it is separate win DNS serer.
> > > > > There is also split DNS server resolving all in/out requests from intern clients.
> > > > > This one is known for resolver on all clients, but can't be used for dyndns updates. 
> > > > > 
> > > > > >In general, SSSD tries to do as little as possible and we try to let nsupdate do its job right..
> > > > > 
> > > > > 
> > > > > But sssd supplies data for update record for nsupdate, right?
> > > > 
> > > > Please open a bug against sssd.
> > > 
> > > Please don't (yet).
> > > 
> > > > 
> > > > For some reason the server name is being forcibly served top nsupdate
> > > > and that shouldn't be the case, passing a "server" option should be only
> > > > a fallback case.
> > > 
> > > It is only a fallback, the way I read the code. I haven't seen the full
> > > domain logs, so I can't tell if the sssd falls back to trying the server
> > > or tries the server right away (which would be a bug).
> > > 
> > > > 
> > > > Nsupdate should be let the ability to discover the correct server by
> > > > querying the DNS and picking the available authoritative server.
> > > > 
> > > > Feel free to quote the above ion the ticket. It is definitely a bug in
> > > > sssd.
> > > 
> > > No, it's not.
> > 
> > But if we already know the answer for which DNS server to use, surely
> > sssd should not override what has been set locally at /etc/resolv.conf
> > should it? If you must pass the server name then choose the one which
> > has already been given, not the one which you've found via SRVs.
> > Just our €0,02 
> > Steve
> 
> You're describing something different than what Simo was describing.
> 
> So you're proposing that the 'server' directive is a server from
> /etc/resolv.conf, not whatever server we are talking to?
> 
> If that's the case, then it wouldn't work. Quite often, the server in
> resolv.conf would be just 127.0.0.1 and a local dnsmasq or similar would
> be running on the client machine. Or the AD server could be resolved
> with the help of /etc/hosts..

Correct, however the way the AD code uises the server names makes little
sense. It uses the name used to connect to the LDAP server. Although
this is generally a Domain Controller, it is not necessarily a DNS
server (can be even a RODC). So if we need a fallback that should be an
option specified in sssd.conf: something like: fallback_dns_master or
similar.
Deriving the DNS server from the LDAP name will be wrong more times than
it is right in large environments.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the sssd-users mailing list