On my dual-stack network where some machines actually don't have IPv4 connectivity I am finding that whatever is writing IP addresses into /var/lib/sss/pubconf/kdcinfo.DOMAIN is only writing the IPv4 addresses and not the KDC's IPv6 addresses.
The result is that such an IPv6 machine cannot reach a KDC until I remove that file. It ends up being recreated at some subsequent point again with only the KDC's IPv4 addresses.
Is this a bug or a problem with my configuration?
Cheers, b.
Am Fri, Mar 18, 2022 at 06:00:25PM -0400 schrieb Brian J. Murrell:
On my dual-stack network where some machines actually don't have IPv4 connectivity I am finding that whatever is writing IP addresses into /var/lib/sss/pubconf/kdcinfo.DOMAIN is only writing the IPv4 addresses and not the KDC's IPv6 addresses.
The result is that such an IPv6 machine cannot reach a KDC until I remove that file. It ends up being recreated at some subsequent point again with only the KDC's IPv4 addresses.
Is this a bug or a problem with my configuration?
Hi,
there is the 'lookup_family_order' option for the [domain/...] section of sssd.conf. The default is 'ipv4_first' and it looks like you might want to change this on the given hosts to 'ipv6_first' or even 'ipv6_only'. Please see man sssd.conf for details.
HTH
bye, Sumit
Cheers, b. _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Sat, 2022-03-19 at 11:33 +0100, Sumit Bose wrote:
Hi,
Hi Sumit. Thanks for the response. Some comments below...
there is the 'lookup_family_order' option for the [domain/...] section of sssd.conf. The default is 'ipv4_first' and it looks like you might want to change this on the given hosts to 'ipv6_first' or even 'ipv6_only'. Please see man sssd.conf for details.
Hrm. Any of the choices don't seem to be ideal. In fact the idea of having to choose an address family and then only writing the addresses that are found in the chosen family to that file seems very rigid, particularly with the *_first choices. The name of the default choice is not even accurate: ipv4_first because once the IPv4 values have been cached to that file, IPv6 is never even tried (so there is no "first" aspect to it after the caching), ever again, even if IPv4 connectivity no longer works.
I believe the general approach for dual-stack machines is that IPv6 should always be tried first and IPv4 should automatically fall-back if IPv6 fails, so the default of ipv4_first seems to violate that approach.
But even the caching the addresses from a single family into that file seems broken. Are those addresses cached in that file when found, or after they are successfully used? Because in a network supporting mixed family machines, there is always going to be addressing for both families.
Why are those addresses even cached like that? Why aren't they queried on each use? Seems like any kind of DNS caching performance belongs in the domain (NPI) of software specifically designed to do that such as nscd, or unbound/dnsmasq/bind9 (in caching resolve mode).
Can this caching be turned off given that it's so broken?
It looks like I am not the first person to find this entire mechanism lacking: https://pagure.io/SSSD/sssd/issue/2015 https://github.com/SSSD/sssd/issues/3057 https://bugzilla.redhat.com/show_bug.cgi?id=1849710
It's really disturbing to see the BZ closed as WONTFIX as this behaviour seems all quite broken IMHO.
Cheers, b.
It's always so funny to go hunting for a solution to a problem only to figure out at the end of a mailing list message (and thread, to which there was no response) that you are reading, in fact reading one of your old messages from the past.
Any more thoughts on all of this?
Why does SSSD even need to have it's own KDC cache? Why can it not simply query the name service(s) when it needs to find a KDC?
Why is the cache only containing values from an sssd.conf configuration of a given point in history? I.e. if I change my lookup_family_order from ipv4* to ipv6* the cache of IPv4 values is actually invalid/incorrect. (And what do I do to manually get this file updated once I have changed that value?)
Surely that cache should always have both IPv4 and IPv6 values in it and the lookup_family_order filters on that list that is in the cache rather than using lookup_family_order's value to populate the cache with an already filtered list.
I think all of this really points out why this cache is simply not a good idea and why direct lookups, when necessary are a better option.
For further reference: https://github.com/SSSD/sssd/issues/3057 https://bugzilla.redhat.com/show_bug.cgi?id=1849710
Thoughts?
Cheers, b.
sssd-users@lists.fedorahosted.org
-
Brian J. Murrell -
Sumit Bose