Bug 426984 - Problems with host resolving after glibc 2.7.90-1
Summary: Problems with host resolving after glibc 2.7.90-1
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: i386
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-12-29 10:14 UTC by Boyan Anastasov
Modified: 2008-01-23 23:59 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-01-23 23:59:44 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Boyan Anastasov 2007-12-29 10:14:32 UTC
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 217.24.1.134

(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 127.0.0.1.32771 > 127.0.0.1.53: 54528+ AAAA? google.com. (28)
11:19:26.364088 IP 192.168.168.7.43152 > 216.239.34.10.53: 48625% [1au] AAAA?
google.com. (39)
11:19:26.869097 IP 192.168.168.7.43152 > 216.239.38.10.53: 35010% [1au] AAAA?
google.com. (39)
11:19:27.372325 IP 192.168.168.7.27327 > 216.239.36.10.53: 58503% [1au] AAAA?
google.com. (39)
11:19:27.875528 IP 192.168.168.7.1598 > 216.239.32.10.53: 46288% [1au] AAAA?
google.com. (39)
11:19:28.378901 IP 192.168.168.7.35454 > 216.239.34.10.53: 15981% [1au] AAAA?
google.com. (39)
11:19:28.437101 IP 216.239.34.10.53 > 192.168.168.7.35454: 15981*- 0/1/1 (89)
11:19:28.437538 IP 127.0.0.1.53 > 127.0.0.1.32771: 54528 0/1/0 (78)
11:19:28.438005 IP 127.0.0.1.32771 > 127.0.0.1.53: 30069+ AAAA? google.com. (28)
11:19:28.438210 IP 127.0.0.1.53 > 127.0.0.1.32771: 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
comment:

# 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 10:54:06 UTC
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 23:22:41 UTC
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.