Description of problem: Version-Release number of selected component (if applicable): firefox 3.x.x How reproducible: Type URL for any site in address bar of firefox or elinks Steps to Reproduce: 1. Configure Network to DSL modem 2. Open firefox 3. Type any URL into address bar, you'll get "DNS error" instead of the site contents Actual results: "DNS error" and the URL in address bar gets changed to: "http://webhelp.qwest.net/main?AddInType=Bdns&Version=1.4.11&FailureMode=1&ParticipantID=iil7m3f3h23ub7r46n5xmju72a5h65bb&ClientLocation=us&Referer=&FailedURI=http%3A%2F%2Fwww.google.com%2F&SearchQuery=" Expected results: The particular website example "http://www.google.com" should open Additional info: If I type the IP address in the browser, the contents of the site come The default nameserver is 192.168.0.1 which is actually the IP address of DSL modem/router When I replace the DNS server in /etc/resolv.conf to any other server except DSL modem's DNS IP, again, everything starts working fine Could it be due to TCP/UDP type of DNS queries going to the DSL modem's mini DNS server which cause issue ?
There's pretty much no way this is a Firefox bug. If it were anything to do with Fedora at all, it would be bind-libs. But it's almost certainly a problem either with the DSL modem/router and its built-in resolver, or the ISP service (I suppose it's Qwest? Or is it a Qwest reseller?) and its DNS servers that the modem/router gets by DHCP.
yes, it's Qwest. I agree that this might be an issue with bind-libs However, there's no issue when I use RHEL5/CentOS5 Could this be due to the recent versions of bind-libs ?
I totally agree, reassigning to bind component, but I would be afraid it is NOTABUG and some kink on Qwest side.
This bug is definitely not related to bind-* packages because they are not used in the resolving process at all. However try to get & attach those information, please. It will show where exactly problem is. 1. capture DNS traffic when resolving fails - run "tcpdump -i <your_network_interface_name> port 53 -s 0 -w dns_broken" 2. your DLS modem has to forward DNS lookups somewhere. Please set that forwarder as the "nameserver" in your resolv.conf. After that run tcpdump again and verify if your DNS is still broken. 3. capture DNS traffic when resolving is successful Then attach all traffic dumps here, please. Thanks.
I had the same problem. I was able to resolve it by using the /etc/resolv.conf file generated form eth0 init and using that file after wlan0 had gone through dhcp. One odd thing was that even when /etc/resolv.conf only had the router (192.168.0.1) as a DNS server ping would still resolve names. I could ping a site get the IP address copy it into firefox and it would work? Everything worked fine with the ethernet, but didn't work with the wireless. tcpdump never returned anything with the -w dns_broken flag, but without that it looked the same between eth0 and wlan0. I also turned off SE linux. I thought I copied the resolv.conf file before disabling SE linux, and it didn't work. I was getting SE linux warnings when I did "dhclient wlan0", but that doesn't explain why the good resolv.conf wasn't working. thanks, Paul
(In reply to comment #5) > I had the same problem. I was able to resolve it by using the /etc/resolv.conf > file generated form eth0 init and using that file after wlan0 had gone through > dhcp. > > One odd thing was that even when /etc/resolv.conf only had the router > (192.168.0.1) as a DNS server ping would still resolve names. I could ping a > site get the IP address copy it into firefox and it would work? "ping" is IPv4 only utility thus it performs IPv4 lookups only and your DNS seems fine. There is "ping6" utility which performs IPv6 lookups and sends ICMPv6 packets. > Everything worked fine with the ethernet, but didn't work with the wireless. > tcpdump never returned anything with the -w dns_broken flag, but without that > it looked the same between eth0 and wlan0. with the "-w dns_broken" param tcpdump should create file called "dns_broken". It will be very helpful if you get that file and attach it here for further inspection. If you are not able to get the output with "-w" flag then attach the output in plaintext, please. Additionally would it be possible to specify which wireless driver do you use and type of your router, please? > I also turned off SE linux. I thought I copied the resolv.conf file before > disabling SE linux, and it didn't work. I was getting SE linux warnings when I > did "dhclient wlan0", but that doesn't explain why the good resolv.conf wasn't > working. I don't think this is the SELinux issue, it seems you have broken router.
Thanks for the help. I'm not actually at that location any more so I can't do any more testing. The reason the ethernet connection was working is that it was going through a BSD router, and not directly connected to the qwest router. I'm sure this is an issue with the qwest router, but at the same time it was very frustrating that the linux computer was the only one that didn't work with the wireless.