Bug 602396 - Resolver requests fail
Summary: Resolver requests fail
Status: CLOSED DUPLICATE of bug 505505
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 14
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Law
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-06-09 19:01 UTC by Dan Williams
Modified: 2016-11-24 15:48 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2012-01-25 18:00:39 UTC

Attachments (Terms of Use)
packet capture of failed "wget http://lwn.net" (2.05 KB, application/octet-stream)
2010-06-09 19:03 UTC, Dan Williams
no flags Details
failed and successful wgets for novell.com (with only dns packets) (1.48 KB, application/octet-stream)
2010-06-09 19:11 UTC, Dan Williams
no flags Details
successful DNS request from RH's DNS servers using openvpn on the same machine (20.51 KB, application/octet-stream)
2010-06-09 19:24 UTC, Dan Williams
no flags Details

Description Dan Williams 2010-06-09 19:01:57 UTC
At a coffee shop which has a Netopia 3000 WiFi AP hooked up via SBC/AT&T DSL, apparently.  I do *NOT* have IPv6 enabled (/proc/sys/net/ipv6/conf/all/disable_ipv6 is set to "1" and no interfaces have an IPv6 address).  It makes no difference if nscd is running or not.

Network interface configuration is:

wlan0     Link encap:Ethernet  HWaddr 00:22:xx:xx:xx:xx  
          inet addr:  Bcast:  Mask:
          RX packets:7911 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6156 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4871529 (4.6 MiB)  TX bytes:711944 (695.2 KiB)

DNS requests fail to resolve for most programs, including Firefox.  For example:

[dcbw@localhost foo]$ wget http://lwn.net
--2010-06-09 11:47:21--  http://lwn.net/
Resolving lwn.net... failed: Name or service not known.
wget: unable to resolve host address “lwn.net”

Yet Google Chrome is able to access any address, and wget -4 works correctly.

Two packet captures are attached.  The first (lwn.pcap) shows the first failed "wget http://lwn.net".  The second shows both "wget http://novell.com" (which fails) and second "wget -4 http://novell.com" (which works).

Comment 1 Dan Williams 2010-06-09 19:03:15 UTC
Created attachment 422655 [details]
packet capture of failed "wget http://lwn.net"

Comment 2 Dan Williams 2010-06-09 19:04:25 UTC
Created attachment 422657 [details]
failed and successful wgets for novell.com

Comment 3 Dan Williams 2010-06-09 19:08:20 UTC
I assume 'wget -4' just tells getaddrinfo to use AF_INET and not both, so glibc returns only the IPv4 address.  Or something like that?

In any case, I can't see the nameserver returning any valid IPv6 results for anything in these packet captures, but it does return IPv4 results.

/etc/resolv.conf is:

# Generated by NetworkManager

and my glibc version is:


Comment 4 Dan Williams 2010-06-09 19:11:38 UTC
Created attachment 422659 [details]
failed and successful wgets for novell.com (with only dns packets)

Comment 5 Dan Williams 2010-06-09 19:24:34 UTC
Created attachment 422662 [details]
successful DNS request from RH's DNS servers using openvpn on the same machine

Comment 6 Dan Williams 2010-06-09 19:26:13 UTC
It's pretty clear that the AP kinda sucks, but I thought that if IPv6 wasn't enabled on any interfaces, that glibc wouldn't try requesting AAAA records or something like that?  That's sub-optimal though since by default most people will have at least an IPv6 LL address, so maybe it would make more sense to not request AAAA records unless at least one interface has a non-LL address.

Comment 7 Dan Williams 2010-06-09 19:33:21 UTC
Setting the hostname to 'localhost' to suppress glibc's queries for lwn.net.localdomain doesn't work either.  Seems like the problem is that the DNS server doesn't actually return any answers for the AAAA query though it says "success"?

Comment 8 Dan Williams 2010-06-09 19:37:36 UTC
This is probably why Chrome works but FF doesn't:


Comment 9 Dan Williams 2010-06-09 19:39:34 UTC
This bug could be the same as:


Comment 10 Dan Williams 2010-06-09 20:17:58 UTC
So I assume most apps will make name queries with AF_UNSPEC.  In that case, if no usable AAAA answers are returned, since the app didn't specifically request IPv6 or IPv4, shouldn't glibc return the partial answer successfully?  Then it's up to the app to sort through the list and pick out which one it wants to use, either IPv4 or IPv6...

Comment 11 Andreas Schwab 2010-06-10 08:26:56 UTC
What do you get from dig aaaa lwn.net?

Comment 12 Dan Williams 2010-06-16 16:28:17 UTC
I'm not in that location anymore, but are the packet captures above not sufficient?  I can't imagine that dig would return anything materially different than what glibc wanted...

Comment 13 Andreas Schwab 2010-06-17 08:50:28 UTC
dig uses its own stub resolver, so it is important to get its output.

Comment 14 Bug Zapper 2010-07-30 12:05:02 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:

Comment 15 Fedora Admin XMLRPC Client 2011-11-14 19:44:04 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 16 Jeff Law 2012-01-25 18:00:39 UTC

*** This bug has been marked as a duplicate of bug 505505 ***

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