[SSSD] [PATCH 1/2] Set default DNS resolution timeout to 15 seconds.
Simo Sorce
simo at redhat.com
Thu Jul 4 17:45:02 UTC 2013
On Thu, 2013-07-04 at 16:23 +0200, Michal Židek wrote:
> https://fedorahosted.org/sssd/ticket/1966 (SSSD failover doesn't work if
> the first DNS server in resolv.conf is unavailable).
>
> The problem here is, that if first nameserver in resolv.conf is down,
> the resolution is too slow and SSSD will not wait for the result of
> ares_search and go offline. In my case the resolution was sometimes more
> than a minute, because all search domains in resolv.conf were searched
> inside ares_search() call using the first (not working) nameserver in
> the first place and then with the working nameserver (and before that,
> SSSD tried to figure out the domain name from my incorrectly set
> hostname, which added more unnecessary DNS lookups).
>
> To avoid this problem, the option dns_discovery_domain must be set
> properly, so that only the correct domain is searched, but even that is
> not enough, because the default timeout for dns resolver operation in
> sssd is too low. This patch rises the default value to 15 seconds
> (instead of 5 seconds).
>
> Another option might be to lower the amount of time ares waits for a
> nameserver to respond (currently it is 5 seconds, that is why 5 second
> for the entire dns resolution is not sufficient), but I do not want to
> do this.
Why not ?
5 seconds these days is quite awfully high all in all.
I think 1 second should be plenty in most cases, so maybe a default of 2
seconds should be considered.
> These patches also change man pages, so probably master only (string
> freeze)? Even if this is a really small change.
>
> I was also thinking, would it make sense to write a warning to the logs
> if the dns_discovery_domain option is not set? It seem to be important
> to set it properly for cases like this one.
I wonder, should we use the machine name to automatically set the
discovery domain, and only if that fails fall back to the ones defined
in resolv.conf ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
More information about the sssd-devel
mailing list