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