User-Agent: Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115 The majority of the time, it takes quite a long time for Mozilla to look up hostnames. My DNS server is BIND 8.3.7-REL on FreeBSD 5.2-RELEASE-p2. Other browsers do not experience this problem and performing "host www.url.com" from a shell also seems almost instantaneous. Reproducible: Sometimes Steps to Reproduce: 1.Attempt to go a a URL that has not been visited yet in a session. 2. 3. Actual Results: The DNS lookup takes much longer than it should. Expected Results: Immediately try to contact the site. Please let me know if it would help to have access to my DNS server.

Mozilla just uses the APIs provided by Linux (gethostbyname2 and friends), so i wonder if this is a Mozilla bug. You have anything special in your /etc/hosts file?

Nothing at all out of the ordinary in /etc/hosts. This problem also appears in FireFox. The same problem happens under any Linux OS and any Mozilla for my name server. Interestingly, if I set it to use the web proxy (squid) that is on the same machine as the DNS server, there are no problems at all. Konqueror, Dillo, or any other net app do not demonstrate this problem. Could there be something happening before the gethostbyname call that could cause a delay? I would say this is a BIND bug if bug if other apps were showing similar behavior. $ cat /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 yellow localhost.localdomain localhost

--> Networking. May be related to Darin's DNS overhaul. Does a 1.0 branch or 1.4 branch work correctly? If so, that would be my guess. In any case, over to networking.

Ok, here is another really weird one that I had forgotten about. For some reason, Mozilla (Sea Monkey or Firebird/Fox/etc) can never resolve service.bfast.com. The URL I just reproduced this with is: http://www.slickdeals.net/?pno=4183&lno=1&afsrc=1 (it redirects) I always get an immediate error that says it can not resolve the host. I can quite easily do this though: $ host service.bfast.com service.bfast.com has address 66.207.130.76

That URL Works for me. Try with a new profile, and see if that remedy's the problem. Secondly. Can you reproduce this on any other computer? In particular one that uses a different ISP? What ISP are you using?

I can reproduce it on another computer. So far I've tried, Debian Sarge and Fedora Core 2 test1 for OS's. My ISP is Comcast and the host resolves fine using their nameservers directly (though my nameserver is set to use theirs).

Reporter, are you using IPv6 somewhere in your configuration ? Maybe the clients try to contact your DNS-server with IPv6, time out, and retry with IPv4. Darin's DNS-rewrite now uses getaddrinfo() where possible, instead of gethostbyname2() and friends (which are used by other apps). This has had several consequences, f.i. bug 68796.

The machine running the DNS server is IPV6 capable, but only to the extent provided by the default install. Is there a build you could give me that would do some DNS debug logging? Is there a version that predates the DNS changes that was compiled with gcc 3 that I could test out as well?

You should be able to retrieve some logging with 2 environment variables : set NSPR_LOG_FILE to /tmp/nspr.log set NSPR_LOG_MODULES to all:5 then start mozilla form the same shell where you've set these variables. But it will log a lot of data, not just DNS-lookups. Mozilla 1.5 still uses the 'old' implementation. Mozilla 1.6a was the first with the rewritten code (bug 205726).

I'm using mozilla 1.6. When browsing, mozilla hangs for about 10+ seconds before continuing. When there are a lot of images or other stuff on the page, the browser can hang again during load. Hang = complete, no button action, when switching display, no refresh, no cpu usage. I started mozilla in debug, and it appears to hang on an nslookup. Browsing to the same pages using konqueror works fine. Our dns server is located on the same LAN in the same subnet.

http://www.bhmj.net/~bhirsch/nspr.log Sorry it took so long for me to get around to this.

I'm using version 1.6 now, because 1.7b would hardly work for me this morning. The DNS lookups were horribly slow, or were timing out far too fast for the servers my dialup ISP uses. I removed 1.7b and reinstalled 1.6 and it's doing ok. The problem is in the communication, not the DNS servers or other problems outside this box. I could not make my POP3 connection to my main mailserver, as the address would not resolve. So I used the MIRC chat program and did a DNS lookup of the server and got the result right away. Website lookups stalled quite often too. After reinstalling Mozilla 1.6, I didn't have lookup problems to speak of. Whatever the DNS problem is with 1.7b's web and mailserver lookups, it's much less severe with version 1.6. So the DNS lookup code and whatever calls lookups seems to have changed for the worse in 1.7b. Testing of DNS lookup and related network functions might be easier to test if the chatzilla module had /dns, /ping and /trace implemented. The speed of lookups would be readily apparent then.

This is probably fixed by bug 240759. Please try Mozilla 1.7 RC1 or later. Does that solve the problem?

This happens to me all the time in Mozilla 1.7.3 for Linux. Mozilla sits for 5-10 seconds with "Resolving host foo.bar.com..." in the status bar for virtually every DNS lookup. My DNS is fine: "host foo.bar.com" returns in less than 1 second.

I stopped using Mozilla regularly over a year ago in favor of Firefox, which does not have the problem. At the time, Mozilla still had the problem and it occurred constantly. I use Mozilla occasionally and don't recall seeing the problem recently, but then again, I've also upgraded from Suse Linux 9.1 to 10.0 since then.

It's still happening for me. I'm using Mozilla 1.7.13 regularly now, have tested trunk versions until Win98SE support was removed, and try 1.1 nightlies now and then. I think the problem is that Mozilla, etc tries a lookup and times out too fast (in much less than a second. Maybe the connection is assumed to be broadband or a LAN with caching that should respond very fast. When it doesn't, Mozilla then seems to wait for a number of seconds before trying again (no modem activity), and maybe times out then too. I click on a link several times hoping to get the attention of whatever is causing the delay. This also happens when connecting to my local mail server, which responds with an SMTP error message. I often have to try several times to get the message sent. There's got to be a DNS lookup timeout variable someplace in the Mozilla code that should be set to a larger value, and perhaps be an adjustable preference. Linux might be responding faster because of DNS lookup caching. I think WinXP does this too. But Win9x doesn't. I've recently thought that Mozilla should have its own DNS cache perhaps for the 200 most recent lookups.

closing per comment 15 and per Olivier 2006-06-21 "Last time I tried, no, it wasn't an issue (Ubuntu 5.10 + Firefox 1.5.x)." Reporter, Ben is not in a position to evaluate and the nspr log is gone. John T, this is a linux-only bug. If you still have a problem you might ask in the mozillazine forums or visit an existing bug*. If you don't find a match please create a new bug and attach to it an nspr log (comment 9) using seamonkey trunk build or v1.1.1 *https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwords&short_desc=dns&product=Core&product=Firefox&product=Mozilla+Application+Suite&product=Thunderbird&product=Toolkit&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=FIXED&resolution=---&bug_severity=major&bug_severity=normal&op_sys=All&op_sys=Windows+95&op_sys=Windows+98&op_sys=Windows+ME&op_sys=Windows+NT&op_sys=Windows+2000&op_sys=Windows+XP&op_sys=Windows+Server+2003&op_sys=Windows+Vista&op_sys=Windows+CE&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=short_desc&type0-0-0=nowordssubstr&value0-0-0=crash