Bug 602396
| Summary: | Resolver requests fail | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dan Williams <dcbw> |
| Component: | glibc | Assignee: | Jeff Law <law> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 14 | CC: | fweimer, jakub, schwab |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-01-25 18:00:39 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: | |||
| Attachments: | |||
Created attachment 422655 [details] packet capture of failed "wget http://lwn.net" Created attachment 422657 [details]
failed and successful wgets for novell.com
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 Created attachment 422659 [details]
failed and successful wgets for novell.com (with only dns packets)
Created attachment 422662 [details]
successful DNS request from RH's DNS servers using openvpn on the same machine
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. 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"? This is probably why Chrome works but FF doesn't: http://code.google.com/p/chromium/issues/detail?id=28943 This bug could be the same as: https://bugzilla.redhat.com/show_bug.cgi?id=505105 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... What do you get from dig aaaa lwn.net? 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... dig uses its own stub resolver, so it is important to get its output. 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 This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. *** This bug has been marked as a duplicate of bug 505505 *** |
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).