On 07/04/2013 07:45 PM, Simo Sorce wrote:
On Thu, 2013-07-04 at 16:23 +0200, Michal Židek wrote:
(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.
I also think that 5 seconds is high value, but in general, I have bad
feeling when lowering not configurable timeouts (theoretically it could
cause some DNS servers that are reachable now to become unreachable).
Another possibility would be to make this value configurable. Then I
would have no problem lowering the default value. But, should this be
configurable? We already have one option to configure timeout for the
entire DNS resolution, adding another timeout for subtaks of this
operation does not sound nice to me. But I do not have strong opinion
Btw, once the correct data is returned from DNS servers, we no longer
require any DNS operation, so it only happens first time the service
is required (for example the first 'getent' call will be slow, but
after that the service is fast). This is not so bad IMO.
> These patches also change man pages, so probably master only
> 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 ?
Actually, we do this. Wireshark shows that the first srv lookup was
constructed from my hostname. But the whole process is unclear to me,
for example I do not know why we call the resolv_gethostbyname_send()
inside of resolv_get_domain_send(). It adds another DNS lookups
for A records (which causes another slow-down in the case of bad
nameserver searched first). In wireshark I also see searches for A/AAA
records for names like:
is my hostname and searchdom1/2/3 are search
domains specified in resolv.conf. Why do we even try to resolve these
names? It seems like waste of time to me. If the dns_discovery_domain is
properly set, these lookups do not appear.
PS: Patches are the same as before.