[SSSD] better handling of DNS timeouts

Dmitri Pal dpal at redhat.com
Fri Aug 19 18:07:37 UTC 2011


On 08/19/2011 01:57 PM, Simo Sorce wrote:
> On Fri, 2011-08-19 at 13:53 -0400, Dmitri Pal wrote:
>> On 08/19/2011 12:28 PM, Simo Sorce wrote:
>>> 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.
>>>
>> I am not sure what people want but is seems that if you have Auth and ID
>> servers in different parts of the network like KDC and LDAP now or in
>> case when KDC on one of the IPA servers stopped functioning you might
>> want to setup different timeouts for establishing connection to
>> authentication server and to the identity server because having online
>> authentication is more important than online identity lookup. How it
>> translates to the internal logic is an implementation detail.
> The implementation details involve a forced id check during auth, so
> nope, identity servers are not less important then auth servers.
>
> Simo.
>
I think you are wrong and there use cases when the timeout should be
different. But I will stop insisting.
And IMO if the auth can't go without the internal ID lookup is also
wrong. It should be an option to trust the auth server to do the right
thing and use id from cache.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the sssd-devel mailing list