Closed Bug 188332 Opened 22 years ago Closed 20 years ago

DNS Resolving is blocked during lookup of another domain

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 240759

People

(Reporter: uzsmwd, Assigned: gordon)

References

(
URL
)

Details

Attachments

(1 file)

DNS trace
4.93 KB, text/plain
Details 
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://66.118.150.158/

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
-> gordon
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
Attached file DNS trace — 
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 194.8.160.90 -j LOG
iptables -A INPUT   -s 194.8.160.90 -j LOG
iptables -A OUTPUT  -d 195.131.52.130 -j LOG
iptables -A INPUT   -s 195.131.52.130 -j LOG

(the 194.8.160.90 and 195.131.52.130 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: 20 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: 20 years ago → 20 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.

Attachment

General

Creator:
Created:
Updated:
Size: