[SSSD] better handling of DNS timeouts

Jan Zelený jzeleny at redhat.com
Fri Aug 19 07:30:44 UTC 2011


> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110819/52b51f80/attachment.sig>


More information about the sssd-devel mailing list