Bug 602396 - Resolver requests fail
Resolver requests fail
Status: CLOSED DUPLICATE of bug 505505
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Jeff Law
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-09 15:01 EDT by Dan Williams
Modified: 2016-11-24 10:48 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-25 13:00:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
packet capture of failed "wget http://lwn.net" (2.05 KB, application/octet-stream)
2010-06-09 15:03 EDT, 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 15:11 EDT, 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 15:24 EDT, Dan Williams
no flags Details

  None (edit)
Description Dan Williams 2010-06-09 15:01:57 EDT
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:192.168.1.98  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          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 15:03:15 EDT
Created attachment 422655 [details]
packet capture of failed "wget http://lwn.net"
Comment 2 Dan Williams 2010-06-09 15:04:25 EDT
Created attachment 422657 [details]
failed and successful wgets for novell.com
Comment 3 Dan Williams 2010-06-09 15:08:20 EDT
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
nameserver 192.168.1.254


and my glibc version is:

glibc-2.12-2.x86_64
Comment 4 Dan Williams 2010-06-09 15:11:38 EDT
Created attachment 422659 [details]
failed and successful wgets for novell.com (with only dns packets)
Comment 5 Dan Williams 2010-06-09 15:24:34 EDT
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 15:26:13 EDT
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 15:33:21 EDT
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 15:37:36 EDT
This is probably why Chrome works but FF doesn't:

http://code.google.com/p/chromium/issues/detail?id=28943
Comment 9 Dan Williams 2010-06-09 15:39:34 EDT
This bug could be the same as:

https://bugzilla.redhat.com/show_bug.cgi?id=505105
Comment 10 Dan Williams 2010-06-09 16:17:58 EDT
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 04:26:56 EDT
What do you get from dig aaaa lwn.net?
Comment 12 Dan Williams 2010-06-16 12:28:17 EDT
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 04:50:28 EDT
dig uses its own stub resolver, so it is important to get its output.
Comment 14 Bug Zapper 2010-07-30 08:05:02 EDT
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 15 Fedora Admin XMLRPC Client 2011-11-14 14:44:04 EST
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 13:00:39 EST

*** 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.