Bugzilla – Bug 547920
DNS Resolution works from command line but not in Gnome
Last modified: 2010-01-05 12:25:29 UTC
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 Clear RC1 install, neither software update or Firefox work in GNOME, report unable to resolve address. nslookup & ping from Gnome terminal works correctly both with names and IPV4 addresses. Referencing websites by IP address in firefox works correctly. resolv.conf is correctly configured for my network (automatic from DHCP) route table (from route -n) is correct for my network (again from DHCP) IPV6 was disabled during install Install created a bridge (br0) which received a DHCP address, brctl shows correct ethernet device associated with bridge (as expected from the DHCP address) There is no proxy on network, direct connect through DSL gateway (which also provides DHCP services) Firewall is disabled Machine intended to be a xen host server, gnome used primarily for admin so apparmour not installed and networkmanager set to no in config Lookup withing Network Tools does correctly resolve IPV4 addresses. Basically I cant see anything wrong with the network configuration. I'm guessing this is a configuration issue but this is a "broken out of the box" situation. While I'm reasonably savvy with both networking and Linux this is a return to SuSE after a gap of several years so it's possible I just plain missed something. Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: Software update and firefox not able to perform DNS resolution while network tool and command line can. Expected Results: Correctly resolved IPV4 addresses.
Setting static DNS servers in /etc/sysconfig/network/config failed to solve the problem (they were not written to resolv.conf on network restart or reboot) hard coding the upstream DNS servers for my ISP in resolv.conf did solve the problem I use Qwest.net via a Motorola 3347-02 DSL gateway. via DHCP this publishes itself as the local DNS server & forwards requests directly to the upstream servers (doesn't appear to cache locally but I cant be sure of this) Not sure what the problem is with the resolv.conf created by DHCP search local nameserver 192.168.0.1 as I can see the DNS reply (with correct IP address) in wireshark, it then appends the .local domain which of course fails resolution with the upstream servers hard coded as follows search local nameserver 192.168.0.1 nameserver 205.171.3.25 nameserver 205.171.2.25 DNS resolution works as expected. The first resolve.conf file above works fine on other Linux distro's and on my MAC. ***** I initially thought this was a Gnome problem as DNS lookup was fine from ***** the command line, I've since noted that lynx has similar resolution ***** problems from the command line, please reassign this as appropriate.
Can you try to log in in icewm and see if firefox can resolve dns there? Because I fail to see why this would be specific to GNOME...
Sorry for the delay in replying, works been crazy the last few days. I did a complete reinstall selecting a minimal x-windows install, the problem is present with firefox under twm as well. Gnome wasn't even present in the configuration. As I implied in my previous post this was beginning to look like a systemic problem rather than something specific to gnome. The above test seems to confirm this. I've done some web research and found other DNS issues on unreleated platforms with the DSL modem in question, apparently it barfs on IPV6 requests. Despite disabling IPV6 during the install it looks as if the bridge associated with eth0 was still being configured for IPV4/IPV6 dhcp (unless this is showing as the default in yast2). I can work around the problem in one of two ways, hand code resolv.conf or put the modem into bridging mode and move pppoe to the server (which I plan to do anyway once I finally manage to get create virtual machine to work correctly so I can set up a firewall VM) As far as I'm concerned the evidence confirms this is NOT a gnome problem. The problem is most likely specific to this DSL modem, given a workaround is possible I'm not even sure it's worth reassigning it to somewhere else, I'm not sufficiently cognizant of the normal opensuse bug handling practices to decide if/where to reassign it and would not have a problem with closing it.
I only just saw this entry, and am convinced it is the same bug that I just reported as issue 567877.
Ray: this looks close enough to bug 567877 that I'll mark it as duplicate. Hopefully, this will reach the right people -- but it's good that you have a workaround! *** This bug has been marked as a duplicate of bug 567877 ***