WIP: RESOLV: Avoid DNS search to improve fail-over reaction

[thalman]

In case of unreachable DNS server or invalid hostname sssd/c-ares tries
to search in multiple domains based on the search directive
in resolv.conf

But the hostnames in config file are fully qualified and this just
extends the time spent with DNS resolution.

This patch set the c-ares library flags to avoid DNS search

Resolves:
#5390

[thalman]

Despite the change is small, it changes the default behaviour and we should discuss it across the team.

Once we agree the change I will also add commit with man page update to explicitly state that servers must be IP address or FQDN.

From discussion with @sumit-bose I got that it should be safe to do it because of relation to kerberos (kerberos would not work with short hostnames) but are there any other use ceases?

CI runs fine in my environment.

[pbrezina]

Does SSSD even work if the hostname or domain name is not qualified? If not then what change of behavior do you refer to?

[thalman]

Does SSSD even work if the hostname or domain name is not qualified? If not then what change of behavior do you refer to?

I discussed that with @sumit-bose and as he explained to me we have FQDN in configuration anyway. Kerberos requires FQDN to work and we can assume that SSSD has it in configuration. Then this patch is safe to include.

But is anyone aware of a case that I missed and short names may be there? Perhaps with LDAP provider?

[pbrezina]

In theory I think it is possible to set dns_discovery_domain without the whole domain part and since it is used only in DNS it should work with the domain search. But the man page say specifies the domain part of the service discovery DNS query so I think we are safe here.

[pbrezina]

Please try to set ldap_uri to non-qualified name and see if the domain search works. If there is not Kerberos authentication there maybe no requirement for this.

[thalman]

my test shows that user can have NOT qualified names in ldap_uri now

ldap_uri = ldap://ldap/

and it works thanks to the domain search. With this patch users are no longer resolved.

[sumit-bose]

Hi @thalman,

what about using your suggestion from https://bugzilla.redhat.com/show_bug.cgi?id=1608496#c26?

bye,
Sumit

[pbrezina]

'hostname.subdomain' will still work through domain search if subdomain is not a top level domain, wouldn't it?

[sumit-bose]

'hostname.subdomain' will still work through domain search if subdomain is not a top level domain, wouldn't it?

Hi,

no, as @thalman suggested in https://bugzilla.redhat.com/show_bug.cgi?id=1608496#c26 we would check if there is a '.' in the name and since hostname.subdomain has a dot we would add a dot to the end which would skip the domain searches.

Since we cannot reliable determine if what follows the '.' is a fully-qualified domain or just the first part which has to be extended with what's available in /etc/resolv.conf I guess we cannot avoid a config option which can switch options.flags = ARES_FLAG_NOSEARCH; on and off.

bye,
Sumit

[thalman]

Suggested solution with "." lookup is still possible but this one is more simple, elegant and consistent.

I would rather see a new option "perform_dns_search" which will give as the possibility to keep old behaviour rather than to do the trailing dot.

I also think there will be very few installation where admins depends on domain search. Maybe some testing installation.

[sumit-bose]

Suggested solution with "." lookup is still possible but this one is more simple, elegant and consistent.

I would rather see a new option "perform_dns_search" which will give as the possibility to keep old behaviour rather than to do the trailing dot.

I also think there will be very few installation where admins depends on domain search. Maybe some testing installation.

Hi,

I agree, but perform_dns_search sounds misleading, I would suggestion something like `dns_resolver_use_default_search_domains'.

bye,
Sumit

[thalman]

Patch works for ldap provider but it looks like DNS search is still performed in case of AD provider. I need to investigate it more

[elkoniu]

@thalman If this PR is still alive and ongoing? If not maybe close it and reopen when there will be new changes? @alexey-tikhonov If I remember correct last time you run some upstream PR list cleaning to close long standing WIP PRs?

[alexey-tikhonov]

This PR was discussed on a team meeting and Tomas said he plans to finish it.

[thalman]

I decided to close the PR due to my capacity. I will reopen it once there is a progress.