Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 426984 - Problems with host resolving after glibc 2.7.90-1
Problems with host resolving after glibc 2.7.90-1
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-12-29 05:14 EST by Boyan Anastasov
Modified: 2008-01-23 18:59 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-23 18:59:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Boyan Anastasov 2007-12-29 05:14:32 EST
Description of problem:

Programs using getaddrinfo with unspecified protocol receive (or otherway said -
glibc is sending only AAAA requests) and receive only IPv6 (AAAA records), even
if the kernel does not support IPv6 protocol.

After upgrading glibc to 2.7.90-1 some programs started to fail resolving
addresses - for example konqueror, kweatherservice, elinks, subversion...
No matter if the queried address have AAAA records or only A.
The problem appears to be the usage of glibc getaddrinfo function.
For example elinks is using getaddrinfo with ai_family = AF_UNSPEC. Perhaps the
other failing programs do the same. I have local dns, but disabling it is the
same thing - only IPv6 queries are performed.

Example for only A record is http://svn.madwifi.org when trying the command:

# svn checkout http://svn.madwifi.org/madwifi/trunk madwifi
svn: PROPFIND request failed on '/madwifi/trunk'
svn: PROPFIND of '/madwifi/trunk': Could not resolve hostname `svn.madwifi.org':
Host not found (http://svn.madwifi.org)

# host svn.madwifi.org
svn.madwifi.org has address

(host -a svn.madwifi.org does not show presence of AAAA records).

Same problem with elinks and http://google.com which has AAAA records.

 Tcpdump shows:
11:19:26.363414 IP > 54528+ AAAA? google.com. (28)
11:19:26.364088 IP > 48625% [1au] AAAA?
google.com. (39)
11:19:26.869097 IP > 35010% [1au] AAAA?
google.com. (39)
11:19:27.372325 IP > 58503% [1au] AAAA?
google.com. (39)
11:19:27.875528 IP > 46288% [1au] AAAA?
google.com. (39)
11:19:28.378901 IP > 15981% [1au] AAAA?
google.com. (39)
11:19:28.437101 IP > 15981*- 0/1/1 (89)
11:19:28.437538 IP > 54528 0/1/0 (78)
11:19:28.438005 IP > 30069+ AAAA? google.com. (28)
11:19:28.438210 IP > 30069 0/1/0 (78)

My kernel is vanilla 2.6.23, and does not have IPv6 compiled in.
I'm not sure if this is configurable, but found that /etc/gai.conf may be used 
for this. Tested with creating /etc/gai.conf and specifying as last line as in

# For sites which prefer IPv4 connections change the last line to
precedence ::ffff:0:0/96  100

but strace shows that this file is not opened at all, or maybe those preferences
are for others trying to connect to me.

Additionaly I've found that in /etc/resolv.conf exists option inet6 which
prefers IPv6 queries, and I see that then the queries shows AAAA and A records,
but programs fail again, maybe because of tunneled form as written in the man
page. If there were some option to force IPv4 queries (which should be default
without inet6 option) would be great.

Version-Release number of selected component (if applicable):
Including glibc 2.7.90-1 and up.

How reproducible:
Every time when the programs try to resolve addresses with unspecified protocol.

Steps to Reproduce:
1. Start elinks, svn or konqueror with some address.

Actual results:
The programs return error that the host is not found.

Expected results:
Working programs, as before glibc 2.7.90 version.
Comment 1 Jakub Jelinek 2008-01-21 05:54:06 EST
Can you still reproduce it with 2.7.90-4?
There have been several fixes in this area.
Comment 2 Boyan Anastasov 2008-01-23 18:22:41 EST
Not reproducible with 2.7.90-4. Thanks!

Note You need to log in before you can comment on or make changes to this bug.