Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 548396

Summary:	[RFE] support records with both IPv4 and IPv6 addresses
Product:	[Fedora] Fedora	Reporter:	Kamil Dudka <kdudka>
Component:	c-ares	Assignee:	Tom "spot" Callaway <spotrh>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	daniel, jhrozek, kdudka
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	548269	Environment:
Last Closed:	2023-09-12 13:41:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Kamil Dudka 2009-12-17 10:50:44 UTC

+++ This bug was initially created as a clone of Bug #548269 +++

Description of problem:
My last yum update on rawhide included curl and libcurl, and since then I can't access fedoraproject.org via yum (w/ libcurl) or even directly with curl.

Version-Release number of selected component (if applicable):
curl-7.19.7-8.fc13.i686
libcurl-7.19.7-8.fc13.i686

(also happens on x86_64)

How reproducible:
100%

Steps to Reproduce:
1. curl -v fedoraproject.org
  
Actual results:
  * About to connect() to fedoraproject.org port 80 (#0)
  *   Trying 2610:28:200:1::fed0:1... Failed to connect to 2610:28:200:1::fed0:1: Network is unreachable
  * Success
  * couldn't connect to host
  * Closing connection #0
  curl: (7) Failed to connect to 2610:28:200:1::fed0:1: Network is unreachable

Expected results:
The HTML dump of Fedora's home. :)

Additional info:
Curl appears to be fine with pure-IPv4 hosts (e.g. www.google.com).

If I completely disable IPv6 in the kernel, then curl says:
  * About to connect() to fedoraproject.org port 80 (#0)
  * couldn't connect to host
  * Closing connection #0
  curl: (7) couldn't connect to host

If I explicitly add "--ipv4", then it works fine.  With the previous version, that wasn't necessary, of course.  And I have no way of forcing other libcurl apps in this way.

According to yum history, my previously working curl/libcurl was 7.19.7-4.fc13.i686.  I can't find that version at the moment to try rolling back, as koji seems to be down.  However, I tried 7.19.6-10.fc12.i686, and that seems to work fine as well.

--- Additional comment from kdudka on 2009-12-17 05:44:39 EDT ---

Thanks for the report! curl was switched to c-ares for name resolving in Fedora 13 and this feature hasn't been implemented in c-ares yet. I'll clone this bug for that package.

> If I explicitly add "--ipv4", then it works fine.  With the previous version,
> that wasn't necessary, of course.  And I have no way of forcing other libcurl
> apps in this way.

We can of course implement a way to do the same for applications in the meantime. What about adding a new environment variable (e.g. CURL_DISABLE_IPV6) to achieve this? Which applications are you actually focused on? 

> According to yum history, my previously working curl/libcurl was
> 7.19.7-4.fc13.i686.  I can't find that version at the moment to try rolling

The above mentioned change was done in 7.19.6-11.fc13. If the same worked for you in 7.19.7-4.fc13, it must have been a bug in your network ;-)

Comment 1 Josh Stone 2009-12-18 21:27:25 UTC

I poked a bit around in the c-ares source for this.  I think that since c-ares is producing a struct hostent, it will be limited to only a single protocol of results.  There's only one h_addrtype field to represent the entire list of results, so it can't mix IPv4 and IPv6.

Thus, I believe the API would have to change to support mixed protocols.

Comment 2 Tom "spot" Callaway 2010-01-21 03:42:15 UTC

The upstream for c-ares is pretty active, so they might be open to considering making an API change to support this functionality.

Comment 3 Kamil Dudka 2010-01-21 05:13:03 UTC

Sure.  Upstream is aware of the situation in Fedora.  I've discussed the topic with Daniel Stenberg (already CC'd) and he has really no problem with accepting such a patch.

Comment 4 Kamil Dudka 2010-04-21 20:10:25 UTC

I've experimentally built (lib)curl based on threaded DNS resolver in order to replace c-ares.  We'll see if the approach fits well into Fedora.

http://koji.fedoraproject.org/koji/buildinfo?buildID=168222

Comment 5 Kamil Dudka 2010-06-02 10:53:05 UTC

Starting by 7.20.1-1.fc13, libcurl no longer uses c-ares for name resolving.  It means that up2date libcurl is no more affected by this bug.

Comment 6 Fedora Admin user for bugzilla script actions 2020-06-03 02:47:27 UTC

This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.