[SSSD] better handling of DNS timeouts

Simo Sorce simo at redhat.com
Fri Aug 19 16:28:47 UTC 2011


On Fri, 2011-08-19 at 10:40 -0400, Dmitri Pal wrote:
> On 08/19/2011 09:59 AM, Simo Sorce wrote:
> > On Fri, 2011-08-19 at 09:14 -0400, Dmitri Pal wrote:
> >> On 08/19/2011 06:32 AM, Jan Zelený wrote: 
> >>>> On Fri, Aug 19, 2011 at 09:30:44AM +0200, Jan Zelený wrote:
> >>>>>> On Thu, 2011-08-18 at 13:47 +0200, Jakub Hrozek wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> In light of https://bugzilla.redhat.com/show_bug.cgi?id=726467 I have
> >>>>>>> been thinking about improving how we handle DNS timeouts in general.
> >>>>>>>
> >>>>>>> Currently there is one timeout option we pass to c-ares. However,
> >>>>>>> that option is per-nameserver. I guess that makes sense from a
> >>>>>>> resolver library POV - as a resolver library you want to control how
> >>>>>>> long you talk to each name server.
> >>>>>>>
> >>>>>>> We have been mostly OK with this because in most situations the
> >>>>>>> resolver can't connect the socket to the name server at all at times
> >>>>>>> out immediatelly. Problems arise when the server is very slow to
> >>>>>>> respond, drops packets.
> >>>>>>>
> >>>>>>> To solve this in SSSD we need to have control over how long a name
> >>>>>>> resolution takes regardless of the number of name servers and also
> >>>>>>> regardless of the number of servers in failover.
> >>>>>>>
> >>>>>>> The failover in SSSD has the concept of "services". LDAP is a
> >>>>>>> service, Kerberos is a service etc. From back end you don't care and
> >>>>>>> don't know how many servers there are in a service. From fail over
> >>>>>>> we don't know and don't care how many name servers there are.
> >>>>>>>
> >>>>>>> My proposal is to:
> >>>>>>> 1) change the current "dns_resolver_timeout" to be per-service, so
> >>>>>>> the semantics would be "How long to wait until we get an LDAP server
> >>>>>>> IP address" for example
> >>>>>>> 2) introduce a new option, something like
> >>>>>>> "dns_resolver_server_timeout", that would control a per-server
> >>>>>>> timeout. This option could maybe be undocumented, it seems quite
> >>>>>>> low-level.
> >>>>>>> 3) hide the per-nameserver resolver timeout (only #define it). It is
> >>>>>>> too low level.
> >>>>>>>
> >>>>>>> Thoughts, comments and ideas are welcome.
> >>>>>> I have nothing to add to this. It sounds like exactly the right
> >>>>>> approach to me.
> >>>>> Agreed.
> >>>>>
> >>>>> Just one thought: would it make sense to distinguish time to resolve
> >>>>> LDAP, KRB, ... by having different config options for each of them?
> >>>>>
> >>>>> Jan
> >>>> I can't think of a situation where you would like to wait different
> >>>> amount of time for id versus auth?
> >>> Yeah, me neither. That's why I asked if perhaps someone else knows.
> >> Just a speculation...
> >> What if it is not LDAP or SC auth is used but identity is from LDAP
> >> (when we support it).
> >> Would in these cases expectations be different?
> >> Also auth is one operation per many hours while id lookup happens all
> >> the time.
> >> So expectation for id lookup to be much faster and timeout much
> >> shorter than for the auth. 
> > You do not want to wait long times at the login prompt for things to
> > timeout anyways.
> > So no real difference between auth and id resolution, they both have to
> > happen as fast as possible or fallback to offline.
> >
> > Simo.
> >
> If the fail over includes bouncing over several potential servers I am
> willing to wait extra for the real online auth since it will give me the
> ticket but Ok to fail over to the cached identities earlier since I do
> not care if they are local or not. If the timeout is too low for auth it
> might never have enough time to figure which server is available if it
> is at the bottom of the list.

That's not what people want when they are offline though.
Perhaps we should resolve all servers at the same time with parallel
searches so at least for the DNS step we have one single timeout and no
risk of leaving stuff out.

Simo.

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




More information about the sssd-devel mailing list