Created attachment 980044 [details] patch to add AI_ADDRCONFIG to threaded resolver Description of problem: Curl fails to resolve hosts on the first attempt. This causes problems for yum and other users of libcurl. The problem seems to be with the DNS resolver on the local router, which does not cope with AAAA DNS queries. This can be worked around by using the AI_ADDRCONFIG flag in getaddrinfo(3) though see https://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG for the complications. Note that AI_ADDRCONFIG has benefits even on correctly-working single-stack network nodes. How reproducible: $ curl -v google.com * Rebuilt URL to: google.com/ * Could not resolve host: google.com * Closing connection 0 curl: (6) Could not resolve host: google.com Subsequent invocatios work correctly. Curl works if either: - It's compiled with --disable-ipv6 - It's called with --ipv4 - IPV6 connectivity is disabled and curl is patched to use the AI_ADDRCONFIG flag. Simply patching curl is not enough, because the ethernet interface will always have an IPV6 address, so there will be link-local IPV6 addresses even when there is only IPV4 internet connectivity - see bug #505105. IPV6 connectivity can be disabled with 'sysctl -w net.ipv6.conf.all.disable_ipv6=1' - see bug #982740 comment #13. Note that it seems that IPV6 sockets can still be created, thus lib/hostip6.c: Curl_ipv6works() will not work for these purposes. Version-Release number of selected component (if applicable): curl-7.37.0-11.fc20.local.1.x86_64 [F21 version rebuilt on F20] glibc-2.18-16.fc20.x86_64 kernel-3.17.7-200.fc20.x86_64
Thanks for the patch! I will propose it upstream on your behalf.
I have been searching more info on this topic. Now I do not have the impression that the AI_ADDRCONFIG flag can be safely used as a default any more. If this gets merged in curl, it needs to be optional I guess. Please have a look at the following resources (among others): * bug #699576 comment #1 * https://bugzilla.mozilla.org/614526 * https://code.google.com/p/chromium/issues/detail?id=5234 Simply speaking, applications using the AI_ADDRCONFIG need to implement their own workarounds to avoid unintended changes in behavior. Also the implementation of the flag is different on different OSes (and different versions of them).
Yeah, I guess curl would need to special-case localhost(6). Or could move complexity into libcurl by doing IPv4 and IPv6 lookups on two different threads. Neither option seems particularly appealing, but then the alternative is to wait for some clarity to come at the glic/nsswitch level. I'm now coming round to the idea that resolv.conf(5) options are a better workaround for my buggy router - see bug #505105 comment #76. Though it's slightly frustrating that disabling IPv6 connectivity does not function as a workaround.
(In reply to Oliver Henshaw from comment #3) > Yeah, I guess curl would need to special-case localhost(6). It does not sound easy considering all configurations curl has to support. > Or could move > complexity into libcurl by doing IPv4 and IPv6 lookups on two different > threads. That would double the network traffic produced by name resolution I guess. > Neither option seems particularly appealing, but then the > alternative is to wait for some clarity to come at the glic/nsswitch level. > > I'm now coming round to the idea that resolv.conf(5) options are a better > workaround for my buggy router - see bug #505105 comment #76. Yes, that sounds like a reasonable workaround at the time being.
As there is no solution in upstream (lib)curl, I am closing this out. The actual cause of the issue is a broken network device. Affected users can change the configuration of the system name resolver to work around the issue system-wide. Note there is a similar bug report about libcurl not being able to connect (despite it is able to resolve the hostname), which is going to be fixed in the near future: bug #1187531