Bug 1849710

This bug is created as a clone of upstream ticket:
https://github.com/SSSD/sssd/issues/3057

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2015
- Created at 2013-07-11 06:46:52 by [stgraber](https://pagure.io/user/stgraber)
- Assigned to nobody
- Associated bugzillas
  - https://bugzilla.redhat.com/show_bug.cgi?id=1021435
  - https://bugzilla.redhat.com/show_bug.cgi?id=1802209

---

I recently started cutting IPv4 access to a bunch of VMs on my network as they no longer required it to function, resulting in those only having IPv6 connectivity.

I had previously confirmed that sssd was indeed properly connecting to my samba4 servers over IPv6 and so expected the switch to go seamlessly, but it didn't.

As far as I can tell, the problem is that SSSD properly finds the two samba4 servers from the SRV records, then queries for A record from the DNS server, which sure enough returns both IPv4 addresses, it then attempts to contact those and fails (Network is unreachable). Instead of then doing a AAAA query and using it, sssd appears to just give up.

I see two problems there:
    - SSSD should have favored IPv6 to start with (to match the libc's behaviour)
    - SSSD shouldn't fail to connect completely when getting "Network is unreachable", instead it should try the next protocol and try that

In a perfect world, I'd have expected SSSD to first query for AAAA (or just use getaddrinfo?), try to connect to those addresses and in case of failure, fallback to IPv4.

I'm attaching a log file containing:
    - log output of sssd (-d4 -i)
    - proof that getent and netcat both perfectly manage to resolve the same host and connect to it
    - tcpdump of the sssd run
    - tcpdump of the getent call

### Comments

---

**Comment from [stgraber](https://pagure.io/user/stgraber) at [2013-07-11 06:47:05](https://pagure.io/SSSD/sssd/issue/2015#237867)**

attachment
[sssd.log](/SSSD/sssd/issue/raw/files/aef4b745ac5dd551034ffdbade9987ec40c3674588bdd4b3c274d585a8ce87eb-sssd.log)

---

**Comment from [jhrozek](https://pagure.io/user/jhrozek) at [2013-07-11 11:29:31](https://pagure.io/SSSD/sssd/issue/2015#237868)**

Hi, thank you for the bug report. 

Did you have a chance to take a look at the lookup_family_order parameter of sssd ? The thing is that glibc's interfaces like getaddrinfo are blocking and SSSD is completely asynchronous, so we decided to use the [c-ares](http://c-ares.haxx.se/) library instead. The lookup_family_order parameter controls which address families the SSSD should be using, defaulting to ipv4_first.

---

**Comment from [stgraber](https://pagure.io/user/stgraber) at [2013-07-11 15:11:41](https://pagure.io/SSSD/sssd/issue/2015#237869)**

Hi,

I somehow missed lookup_family_order when looking for IPv6 related options yesterday, lookup_family_order = ipv6_first indeed fixes the issue for me.

I still think there's a bug with ipv4_first not working at all on IPv6-only machines, but at least setting the option to ipv6_first gives a working workaround.

Thanks!

---

**Comment from [jhrozek](https://pagure.io/user/jhrozek) at [2013-07-11 17:03:47](https://pagure.io/SSSD/sssd/issue/2015#237870)**

According to the logs you sent you are right. I'll change the title of the ticket, unfortunately I don't have any IPv6 only machine to test at the moment.

Thanks for testing the ipv6_first parameter.

---

**Comment from [jhrozek](https://pagure.io/user/jhrozek) at [2013-07-11 17:04:41](https://pagure.io/SSSD/sssd/issue/2015#237871)**

Fields changed


summary: SSSD fails to connect when on a machine with only IPv6 and server is dual-stack => SSSD fails to connect with ipv4_first when on a machine with only IPv6 and server is dual-stack

---

**Comment from [dpal](https://pagure.io/user/dpal) at [2013-07-18 15:19:22](https://pagure.io/SSSD/sssd/issue/2015#237872)**

Fields changed


milestone: NEEDS_TRIAGE => SSSD 1.13 beta
rhbz:  => todo

---

**Comment from [bzhmurov](https://pagure.io/user/bzhmurov) at [2013-07-29 17:03:23](https://pagure.io/SSSD/sssd/issue/2015#237873)**

Got same problem with sssd-1.8 series. But in our case, we have mixed IPv4/IPv6 and IPv6 only servers, so we cannot deploy same config on all servers. Is there any quick fix for broken ipv4_first? Thanks.

---

**Comment from [bzhmurov](https://pagure.io/user/bzhmurov) at [2013-07-29 17:18:14](https://pagure.io/SSSD/sssd/issue/2015#237874)**

With mixed network (IPv4 and IPv6) option "lookup_family_order = ipv6_first" doesn't work either. sssd is not going to "ldap_uri".
Looks like there is a bunch of complicated issues around lookup_family_order...


_comment0: With mixed network (IPv4 and IPv6) option "lookup_family_order = ipv6_first" doesn't work either. Looks like there is a bunch of complicated issues around lookup_family_order... => 1375111130743718

---

**Comment from [jhrozek](https://pagure.io/user/jhrozek) at [2013-07-29 18:06:16](https://pagure.io/SSSD/sssd/issue/2015#237875)**

Replying to [comment:7 bzhmurov]:
> With mixed network (IPv4 and IPv6) option "lookup_family_order = ipv6_first" doesn't work either. sssd is not going to "ldap_uri".
> Looks like there is a bunch of complicated issues around lookup_family_order...

Hi, can you attach (sanitized) logs? Simply put debug_level=9 into the domain section, restart sssd and then attach /var/log/sssd/sssd_$domain.log. 

With the log we should at least see what kind of queries the SSSD did.

---

**Comment from [bzhmurov](https://pagure.io/user/bzhmurov) at [2013-08-02 19:44:05](https://pagure.io/SSSD/sssd/issue/2015#237876)**

Here is log file.
http://kernelpanic.ru/sssd.txt

The case is:
1. we have ldap.domain.com.
2. it has IPv4 and IPv6 addresses (A and AAAA records for ldap.domain.com)
3. we have "lookup_family_order = ipv6_first" option enabled
4. on IPv4 + IPv6  clients everything is OK
5. on IPv4 only hosts sssd does not work, because sssd tries to resolv ldap.domain.com, finds 
   AAAA IPv6 record and ignore IPv4 A dns record. But clients, that does not have IPv4 only
   address, cannot connect to IPv6 AAAA address, so sssd gets:
   "connect failed [101][Network is unreachable]"

---

**Comment from [jhrozek](https://pagure.io/user/jhrozek) at [2013-08-05 16:32:53](https://pagure.io/SSSD/sssd/issue/2015#237877)**

Ah thanks for the logs, I see what the problem is now. But frankly I'm not sure if it's a bug..the lookup_family_order option only affects the name resolution, so when the name was successfully resolved already, but the server is down, we don't retry the second address, the host is simply marked as being down. I think this use case would better be served by using "ipv4_first" or "ipv4_only" rather than changing the failover mechanism.

---

**Comment from [bzhmurov](https://pagure.io/user/bzhmurov) at [2013-08-07 00:03:03](https://pagure.io/SSSD/sssd/issue/2015#237878)**

So we have to figure out, what version of IP server has (IPv4 or IPv6) and change sssd.conf dynamically while installation process? Isn't it ugly? And what if we have to migrate from IPv4 to IPv6? We have not to forget to change sssd.conf... In our case (thousands servers) it kinda looks like hell :(

---

**Comment from [preichl](https://pagure.io/user/preichl) at [2015-09-21 10:15:27](https://pagure.io/SSSD/sssd/issue/2015#237879)**

Fields changed


mark:  => 0
owner: somebody => preichl
sensitive:  => 0

---

**Comment from [jhrozek](https://pagure.io/user/jhrozek) at [2016-02-16 12:09:49](https://pagure.io/SSSD/sssd/issue/2015#237880)**

This requires larger changes in the responder and fail over which are unfortunately out of scope for 1.14 at the moment.


milestone: SSSD 1.14 beta => SSSD 1.15 beta

---

**Comment from [jhrozek](https://pagure.io/user/jhrozek) at [2016-03-02 11:15:19](https://pagure.io/SSSD/sssd/issue/2015#237881)**

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1021435 (*Red Hat Enterprise Linux 7*)


rhbz: todo => [https://bugzilla.redhat.com/show_bug.cgi?id=1021435 1021435]

---

**Comment from [stgraber](https://pagure.io/user/stgraber) at [2017-02-24 14:57:07](https://pagure.io/SSSD/sssd/issue/2015#237882)**

**Metadata Update from @stgraber**:
- Issue assigned to preichl
- Issue set to the milestone: SSSD Future releases (no date set yet)

---

**Comment from [jhrozek](https://pagure.io/user/jhrozek) at [2017-07-09 21:18:44](https://pagure.io/SSSD/sssd/issue/2015#447908)**

I think this might have been fixed with https://pagure.io/SSSD/sssd/issue/1498

---

**Comment from [jhrozek](https://pagure.io/user/jhrozek) at [2017-07-09 21:18:45](https://pagure.io/SSSD/sssd/issue/2015#447909)**

**Metadata Update from @jhrozek**:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field sensitive reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None

---

**Comment from [stevetraylen](https://pagure.io/user/stevetraylen) at [2018-06-28 11:33:38](https://pagure.io/SSSD/sssd/issue/2015#518818)**

I would say this is a particular case of https://pagure.io/SSSD/sssd/issue/552 but the workaround there makes no sense for this case.

Certainly I'd like to be able to dhcp machine and not have to configrue sssd.conf depending on what comes back.

---

**Comment from [thalman](https://pagure.io/user/thalman) at [2020-03-13 13:53:47](https://pagure.io/SSSD/sssd/issue/2015#633160)**

**Metadata Update from @thalman**:
- Custom field design_review reset (from false)
- Custom field mark reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue tagged with: Canditate to close

---

**Comment from [pbrezina](https://pagure.io/user/pbrezina) at [2020-03-24 14:11:40](https://pagure.io/SSSD/sssd/issue/2015#636652)**

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

---

**Comment from [pbrezina](https://pagure.io/user/pbrezina) at [2020-03-24 14:11:41](https://pagure.io/SSSD/sssd/issue/2015#636653)**

**Metadata Update from @pbrezina**:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

---

**Comment from [abbra](https://pagure.io/user/abbra) at [2020-03-26 14:03:53](https://pagure.io/SSSD/sssd/issue/2015#637752)**

@pbrezina @thalman I'd like us to re-open this. We need it to support IPv6-only systems as IPA clients when IPA servers are dual-stacked.

---

**Comment from [rcritten](https://pagure.io/user/rcritten) at [2020-03-30 20:05:31](https://pagure.io/SSSD/sssd/issue/2015#638874)**

It's that or we're going to have to kludge this into the IPA client installer and possibly create more problems as a result by having to try to determine if it is an IPv6-only machine at install time and set lookup_family_order = ipv6_first

---

**Comment from [abbra](https://pagure.io/user/abbra) at [2020-03-31 16:40:35](https://pagure.io/SSSD/sssd/issue/2015#639066)**

Ideal solution would be to let SSSD to configure c-ares resolver at startup to follow `/etc/gai.conf`-provided policy. That would allow the same behavior as the rest of the OS, since glibc-provided resolver is used also by krb5 and other components.

---

**Comment from [pbrezina](https://pagure.io/user/pbrezina) at [2020-03-31 16:49:54](https://pagure.io/SSSD/sssd/issue/2015#639068)**

**Metadata Update from @pbrezina**:
- Custom field design_review adjusted to on (was: false)
- Custom field mark adjusted to on (was: false)
- Custom field patch adjusted to on (was: false)
- Custom field review adjusted to on (was: false)
- Custom field sensitive adjusted to on (was: false)
- Custom field testsupdated adjusted to on (was: false)
- Issue status updated to: Open (was: Closed)

---

**Comment from [pbrezina](https://pagure.io/user/pbrezina) at [2020-03-31 16:50:10](https://pagure.io/SSSD/sssd/issue/2015#639069)**

**Metadata Update from @pbrezina**:
- Assignee reset
- Issue **un**tagged with: Candidate to close
- Issue tagged with: Future milestone

---

**Comment from [pbrezina](https://pagure.io/user/pbrezina) at [2020-03-31 16:50:49](https://pagure.io/SSSD/sssd/issue/2015#639070)**

Ok, I reopened it.

---

**Comment from [pbrezina](https://pagure.io/user/pbrezina) at [2020-04-01 11:26:47](https://pagure.io/SSSD/sssd/issue/2015#639156)**

**Metadata Update from @pbrezina**:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1021435 https://bugzilla.redhat.com/show_bug.cgi?id=1802209 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1021435)
- Issue **un**tagged with: Future milestone
- Issue tagged with: bugzilla