User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 When trying to visit http://overnet.com.. mozilla says "resolving host overnet.com" and does not continue... AND other URL's can also not be resolved anymore... except they are in the cache... clearing the cache/history/cookies does not help.. A restart of mozilla makes all site available again (except overnet.com of course)... I have this problem for several days now... Reproducible: Always Steps to Reproduce: 1.type overnet.com an address bar 2.press enter 3.wait wait wait Actual Results: wait wait wait wait wait wait Expected Results: load overnet.com or at least other sites
Works for me in 1.2.1 on Win2k. Are you having the same problem in other builds? Does it load correctly in other browsers on the same system?
tried konquerer and opera... all browsers cannot open this site... tried them all at the same time.. difference is that when opening with opera or konquerer, name resolution is not being blocked as with mozilla.... When opening this site with opera or konquerer mozilla works fine, too -> so calling this site does not block name resolution system wide... Name resolution seems only to be blocked when using mozilla ... Tried the following: Opened this site with mozilla -> name resolution is blocked... opened another site with opera at the same time -> name resolution works fine for opera... didn't experience this with other sites. Only with overnet.com haven't tried another build yet
page works here and no problems after - try to update your build.
OK... I logged in at my university and set $DISPLAY on my xserver... downloaded the same mozilla version as I use at home (1.3a )and it worked... So my ISP might be blocking the name resolution for overnet.com !? My ISP is netcologne... I used nslookup and dig... both cannot resolve the name Why does mozilla refuse to resolve sites other than overnet.com while trying to connect to overnet.com... I'll cancel this bug, as soon as I now, that it's my ISP's fault..
so I've got some news: Name resolution is not a failure for mozilla Many people do habe the same problem (not with mozilla but with connecting to overnet.com by URL)... Connecting with this IP-address is no problem http://22.214.171.124/ dig www.overnet.com ; <<>> DiG 9.2.1 <<>> www.overnet.com ;; global options: printcmd ;; connection timed out; no servers could be reached Strange thing is, that my DNS-server does not send "server not found", but times out... So my bug report reduces to the fact, that mozilla blocks all name resolution queries while waitung for this time-out.... who has the same troubles ??
Overnet.com seems to have their DNS wedged. I also get --->dig www.overnet.com ; <<>> DiG 8.3 <<>> www.overnet.com ;; res options: init recurs defnam dnsrch ;; res_nsend to server default -- 127.0.0.1: Connection timed out but when I do --->dig overnet.com ns ; <<>> DiG 8.3 <<>> overnet.com ns ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; overnet.com, type = NS, class = IN ;; ANSWER SECTION: overnet.com. 5h14m34s IN NS www.overnet.com. ;; AUTHORITY SECTION: overnet.com. 5h14m34s IN NS www.overnet.com. So the only way to find the address of www.overnet.com is to ask www.overnet.com. Good luck!
+clean-report Your overnet.com request gets jammed, we have a serialized queue for DNS requests. It should timeout or die after some point. Something abnormal is happening that causes Mozilla to wedge.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: dougt → gordon
found another page with the same symptoms... Trying to open this page blocks all nameserver queries for mozilla given, that the nameserver query for this page fails... http://story.news.yahoo.com/ This page sometimes works, sometimes not.. !?
This bug seems to be the same as: http://bugzilla.mozilla.org/show_bug.cgi?id=193827 It happens because DNS resolution in tcp mode seems not working right. The timeout (in tcp mode) not set right. DNS in udp mode works OK. Set (on linux) iptables -A OUTPUT -d your.dns.server.ip -j LOG iptables -A INPUT -s your.dns.server.ip -j LOG And I bet you will get the same packet trace as in http://bugzilla.mozilla.org/show_bug.cgi?id=193827 also try dig story.news.yahoo.com You will probably get (sometimes) the same DNS error as in http://bugzilla.mozilla.org/show_bug.cgi?id=193827 This seems to be DNS in tcp mode problem. This bug existed in netscape/mozilla for ages. I seen very similar problem back in netscape 4.x or may be even 3.x
This is DNS trace for Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 obtained from /var/log/messages after iptables -A OUTPUT -d 126.96.36.199 -j LOG iptables -A INPUT -s 188.8.131.52 -j LOG iptables -A OUTPUT -d 184.108.40.206 -j LOG iptables -A INPUT -s 220.127.116.11 -j LOG (the 18.104.22.168 and 22.214.171.124 are my DNS servers) From this log it is clear what kind of DNS requests mozilla makes.
Any idea why DNS would end up in TCP mode?
Summary: DNS lookup fails for all pages if trying to visit overnet.com → DNS: lookup fails for all pages if trying to visit overnet.com
Seems relevant: http://colalug.org/members/resources/IP-Chains/HOWTO-5.html 5.2 What not to filter out. TCP connections to DNS (nameservers). If you're trying to block outgoing TCP connections, remember that DNS doesn't always use UDP; if the reply from the server exceeds 512 bytes, the client uses a TCP connection (still going to port number 53) to get the data. This can be a trap because DNS will `mostly work' if you disallow such TCP transfers; you may experience strange long delays and other occasional DNS problems if you do.
*** Bug 224447 has been marked as a duplicate of this bug. ***
Depends on: 79893
Summary: DNS: lookup fails for all pages if trying to visit overnet.com → DNS Resolving is blocked during lookup of another domain
This was probably fixed by the DNS rewrite. Marking WORKSFORME since last comment was over a year ago. Reporter, please reopen if you still see the bug on a recent build.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Uhhh... No. See bug 224447 for a recent reproduction. Bug 224447 comment 0: "The easiest way to see this is to open two firebird windows. Then in the first, go to http://www.citizenwatches.com. In the second pick a url at random that you know should work...i did http://www.ford.com." Reopening.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to comment #16) > Uhhh... No. See bug 224447 for a recent reproduction. > > Bug 224447 comment 0: > "The easiest way to see this is to open > two firebird windows. Then in the first, go to http://www.citizenwatches.com. > In the second pick a url at random that you know should work...i did > http://www.ford.com." WFM Linux Firebird trunk build from a few days ago. Can someone reproduce this using a current build? If not, will resolve WORKSFORME (again!). Note: when attempting to reproduce this, be sure to turn proxy autoconfig off, otherwise you'll be seeing bug 235853, which is something else.
I was seeing this problem very frequently on Win 98 until very recently. I believe this may have been fixed in bug 240759. Please try Mozilla 1.7 RC1 or later. Does that solve the problem?
I haven't had this problem for a long while, too. But I don't know whether it is solved, since it appears very seldomly. I cannot decide about the question, whether the problem is solved or not, sorry.
No problem. If you see it again on Mozilla 1.7 RC1 or later, re-open the bug. *** This bug has been marked as a duplicate of 240759 ***
Status: REOPENED → RESOLVED
Closed: 16 years ago → 15 years ago
Resolution: --- → DUPLICATE
*** Bug 237582 has been marked as a duplicate of this bug. ***
*** Bug 231284 has been marked as a duplicate of this bug. ***
*** Bug 277419 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.