Closed
Bug 135724
Opened 22 years ago
Closed 21 years ago
DNS: Random lookup failures / very slow operation
Categories
(Core :: Networking, defect)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: cce, Assigned: gordon)
References
Details
After using Mozilla for a period of time, DNS lookups start to hang. I don't think this is relevant, but I'm using DJB's local DnsCashe program (part of TinyDNS) and lookups are done at 127.0.0.1 via the loopback address.
Comment 1•22 years ago
|
||
I perceive the same problem. Network failure and DNS server failure have been ruled out. In my case, I am not using DNS caching. As the reporter states, DNS lookups function perfectly well for the first little bit of time. Within the same faulty session, DNS lookups will sometimes succeed after multiple clicks on links, but this does not always work. And, of course, when Mozilla is exited and restarted, DNS lookups function fine again. It was not stated by the original reporter, but in my case, I am testing a native freebsd build of mozilla, not the linux version via binary compatibility.
Comment 2•22 years ago
|
||
Provide build IDs please. I assume nslookup etc. can still look up things properly ?
Component: URL Bar → Networking
Comment 3•22 years ago
|
||
I'm experiencing this on a fairly old build of FreeBSD 4.5-STABLE with RC2. I thiiiink I first noticed it with .9.9, which I also installed around the time I ran that build, so it could just as likely be FreeBSD at fault...? Pertinent information for anyone chasing this: Mozilla 1.0 Release Candidate 2 Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc2) Gecko/20020514 FreeBSD obie 4.5-STABLE FreeBSD 4.5-STABLE #3: Mon Feb 4 10:49:31 EST 2002 floid@obie:/usr/obj/usr/src/sys/OBIE i386 (Tree was probably pulled on 2/3..) pkg_info (port revision): mozilla-1.0.rc2,1 The open source, standards compliant web browser I installed RC2 with portupgrade -R, so all the port dependencies should be fresh and shiny and new as of last week or so. The behavior seems to bear some resemblence to http://bugzilla.mozilla.org/show_bug.cgi?id=117613 , but it's so random that I can't say I've really seen a pattern to it. It *is* very, very annoying when it hits with 10-15 tabs open. One theory that I might look into- I've noticed Mozilla throws A6 queries for all lookups. Maybe Something Bad happens intermittently when a domain actually has an A6 record? (Like most users, I've got IPv6 active, as the BSDs basically require now, but haven't done anything to configure it. Definitely no 6bone link.) The problem seems to have gotten mildly more common after I *stopped* using a local djbdns cache and switched to my ISP's. Anyone experienced a cure via a fresher build of FreeBSD?
Comment 4•22 years ago
|
||
Just built today's 4-STABLE tree of FreeBSD, leaving me with: FreeBSD obie 4.6-RC FreeBSD 4.6-RC #0: Thu May 30 22:35:22 EDT 2002 floid@obie:/usr/obj/usr/src/sys/OBIE i386 Still sucks with the same installation of RC2. Next stop, RC3 if it's available from ports and I can free up the disk space. Haven't yet tried deciphering a tcpdump of a 'hanging' lookup/load attempt.
Comment 5•22 years ago
|
||
Been on RC3 since the day I posted the previous comment; it's "better," but not perfect. As there are many things about RC3 that are better but far from perfect (Thus far, every session I launch hits a showstopper with the 'Find in this page' feature long before this enter-the-URI-and-page-refuses-to-load 'feature' kicks in), I'm going to assume this really hinges on whatever code lets multiple windows and tabbed browsing multitask properly, and probably whatever was causing the persistent 'Transferring...' bug. I'm assuming many of those remaining (better-defined) bugs will be quashed for the release, so perhaps this'll let up fully in 1.0. If it proves otherwise, then I'll definitely have to peel my lazy brain up and see if I can tcpdump any evidence of a resolver problem. (I'd still be really happy to know if anyone reading *doesn't* experience this... if I'm part of a special case, then I should definitely expend effort tracking this down even if I'm a relative noob... If everyone knows it sucks on FreeBSD, I think I'd do a greater service reducing the s/n of everyone's inbox..)
Comment 6•22 years ago
|
||
Oops- my RC3 build ID: Mozilla 1.0 Release Candidate 3 Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020531
Comment 7•22 years ago
|
||
This has been happening to me for the last several releases. I had to cancel my eMusic.com subscription because of it. It's currently trivially reproduceable on both of my FreeBSD machines. Just go to http://www.emusic.com/, something will happen that keeps the page from loading for several minutes (I think they're doubleclick.net banner ad IFRAMEs). It's not just that page - trying to load any other pages in the same or different windows/tabs just hangs for a few minutes. Then something times out and it's back to normal. I use Galeon, but I have confirmed the same behavior in Mozilla Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020610 and even Netscape 6 Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 (running on FreeBSD's linux compatibility).
Comment 8•22 years ago
|
||
This may have something to do with weird DNS behavior for images.geo.mp3.com. I'm getting SERVFAIL sometimes, an IP address other times, and occasionally: chris@lion-around:~$ dig images.mp3.com a ; <<>> DiG 8.3 <<>> images.mp3.com a ;; res options: init recurs defnam dnsrch ;; old answer: ;; ns_initparse: Message too long ;; old answer: ;; ns_initparse: Message too long ;; old answer: ;; ns_initparse: Message too long ;; old answer: ;; ns_initparse: Message too long
Comment 9•22 years ago
|
||
I can confirm this too, tested with 1.0, 1.0rc3 and 1.1alpha on FreeBSD 4.4. I've had this problem with several sites, not all sites seem to suffer from it though. When I try to access the same site with opera, it opens instantly, so there can't be a problem with the system DNS, also looking up the hostname with 'host' works immediately.
Comment 10•22 years ago
|
||
does this problem still exist with 1.1beta?
Comment 11•22 years ago
|
||
hi, i have seen this in netscape 4.x as well as in mozilla 0.9x-1.1b --- every time our central dns server had trouble. is the following discussion outdated? http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&oe=UTF-8&frame=right&th=a5a54f22f6f45ba2&seekm=6dch1v%24ngj5%40secnews.netscape.com#s in my case, this happens using the following configuration: -NT workstations get information to use internal DNS via dhcp. -proxy autoconfig uses isInNet(host, "192.168.5.0","255.255.255.0") for resolving whether the host is on the net, the name is resolved using the internal DNS. while the central DNS is lagging, every time you open a link in a new window/tab which requires a lookup, the browser freezes. well, that way we were always quickly informed when something had gone wrong with our dns server, so maybe it's not a bug, but . .......? platform: only freebsd?
Comment 12•22 years ago
|
||
jhacker: there are some complaints that DNS is still synchronous and blocking. This disucssion however, should be focused on problems just in BSD. There are several bugs about how BSD+IPv6 are causing problems w/ DNS performance. My DNS expertise is pre-IPv6, so I do not fully grasp the situation. Most of these bugs are in Networking, w/ BSD as the OS. If anyone could summarize or dupe, that would be great.
Assignee: hewitt → new-network-bugs
Keywords: qawanted
QA Contact: claudius → benc
Summary: Random DNS lookup failures / very slow operation → DNS: Random lookup failures / very slow operation
Assignee | ||
Comment 13•22 years ago
|
||
Is anyone still seeing this on FreeBSD with a moz 1.2 build?
Assignee: new-network-bugs → gordon
Assignee | ||
Comment 14•22 years ago
|
||
*** Bug 154536 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 15•22 years ago
|
||
*** Bug 157880 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 16•22 years ago
|
||
Marking ASSIGNED to get it on my radar.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment 17•22 years ago
|
||
I tried Mozilla 1.2b and 1.1 today under the latest FreeBSD-STABLE and both seem to exhibit this problem. It's quite more annoying than anyone else has claimed though, and seems to happen more (though it might be my imagination) when I'm trying to resolve a host without the 'www.' part... ie. 'bugzilla.mozilla.org' or 'search.yahoo.com'... Whereas resolving www.yahoo.com and www.mozilla.org seemed quick.
Comment 18•22 years ago
|
||
I continue to have the same problem described by #7. Recent win32 builds of Moz and Phoenix(20021213) hang on certain elements of a page while loading and the rest of the page won't load. Stopping the browser and then reloading the page usually gets me in. When this happens and I try Internet Explorer, it gets in instantly while Mozilla continue to hang. Nslookup continues to work while experiencing this problem. Since this is a general summary problem I'll also mention bugs 146769,185128,174733 http://bugzilla.mozilla.org/show_bug.cgi?id=146769 http://bugzilla.mozilla.org/show_bug.cgi?id=185128 http://bugzilla.mozilla.org/show_bug.cgi?id=174733 since they may be related.
Comment 19•22 years ago
|
||
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=58992+0+current/freebsd-hackers http://docs.freebsd.org/cgi/getmsg.cgi?fetch=62407+0+current/freebsd-hackers http://docs.freebsd.org/cgi/getmsg.cgi?fetch=65094+0+current/freebsd-hackers http://docs.freebsd.org/cgi/getmsg.cgi?fetch=69503+0+current/freebsd-hackers some posts about the problem on the freebsd mailing list.
Comment 20•22 years ago
|
||
Sorry. The FreeBSD links went bad pretty quick. If you do a search for the thread Multi-threaded or async Mozilla (NSPR, really) You'll find the posts in the FreeBSD mailing list. removing ip6 support from the kernel is supposed to be a work around.
Comment 21•22 years ago
|
||
I'm having this same issue. DNS lookups are quick and work fine for www.whatever.com, but for URLs of the structure subdomain.whatever.com they hang forever. For the stories on my.yahoo.com, they link to story.news.yahoo.com, and this name _never_ resolves. I'm running 1.0.1 which came with the RedHat 8 distro I just slapped on my laptop.
Comment 22•22 years ago
|
||
If this is caused by the IPv6 AAAA (or A6?) DNS queries made by Mozilla/NSPR (see comment 3 and comment 20), this bug and bug 181610 are the same problem. But I can't tell if this bug is really caused by the AAAA/A6 DNS queries made by Mozilla/NSPR because this bug is very long and contains some speculations and irrelevent info. Just wanted to note that I have checked in a fix for bug 181610 that will cause Mozilla 1.4alpha to not make AAAA/A6 DNS queries on a machine with no IPv6 connectivity.
Comment 23•21 years ago
|
||
The observation made in another bug is that AAAA records and long domain names would cause the resolver to do a transport mode switch to TCP. We seem to behave badly when that happens, although I also think people are using local DNS servers that reject TCP connections. That would also explain why many of the problem reports relate just uk, yahoo, and doubleclick domains. Checking in that change that change sounds great. We can at least start polling the non-IPv6 users and see if the problem went away. I'll put a cleanup of these bugs on my list for next week.
Comment 24•21 years ago
|
||
I recently experienced the same problem on SuSE 8.2 (2.4.20 kernel). I experienced slow dns lookups in lynx, konqueror and mozilla. However, dig and nslookup routinely resolved hostnames in about 10 ms. The problem was that SuSE loads the ipv6 module by default, even with nothing configured to use ipv6. For linux users, I aliased net-pf-10 to off in /etc/modules.conf. I had to reboot because for some reason the 'Used by' count was -1, and I could not rmmod the module. Hopefully this will help Redhat users as well. It seems to me that there are 3 distinct issues here: - There is a bug in (several) OS vendor configurations. Ipv6 should not be enabled in the kernel if it is not used. - This is iffy: Can an application readily determine that it must use ipv4 if the kernel is providing support for ipv6? I haven't done any development using ipv6, so I can't help here. I do seem to recall that openssh had a similar problem on Slackware 8.0, and I had to compile with --disable-ipv6 (or something similar). - Is mozilla able to properly resolve hostnames using ipv6 in an ipv6 environment. I'm not sure this has been, or needs to be addressed in this bug. This discussion is primarily centered on properly *not* using ipv6. :) IMHO, this particular bug is an OS vendor issue and should be closed. The third item above, if a problem at all, is a separate bug. Sorry I couldn't be more helpful to the FreeBSD folks. Does FreeBSD use a module mechanism similar to Linux? Any way to convince the FreeBSD team that ipv6 kernel support should be dynamically enabled?
Comment 25•21 years ago
|
||
*** Bug 198700 has been marked as a duplicate of this bug. ***
Comment 26•21 years ago
|
||
I see something like this on 1.5beta, running RH 9 with all the updates. nslookup works fine, but mozilla hangs trying to resolve. One way to trigger it faster is to load lots of different pages while the machine is compiling something large (ie, heavy disk & memory pressure, so mozilla processes are slow at times). I've noticed that I can reload pages I've recently hit (I'm assuming it cached the DNS result?) If I shutdown (pres the X), then even after the GUIs go away, the process is still there... I have to kill it with killall or similar. I'm on an SMP machine, and this smells of deadlock to me, but I don't know for certain.
Comment 27•21 years ago
|
||
this should be fixed on the trunk now. see bug 205726 for details. please reopen if problem is reproducible on the trunk.
Comment 28•21 years ago
|
||
V: Please try 1.6f for BSD. New problems to new bugs please.
Status: RESOLVED → VERIFIED
Keywords: qawanted
You need to log in
before you can comment on or make changes to this bug.
Description
•