Closed Bug 185128 Opened 23 years ago Closed 14 years ago

DNS: timeout delay too short?

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Version:
1.0 Branch
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: mozilla, Unassigned)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6 Whenever I restart Chimera for whatever reason and go to Yahoo the first time, I get alerts about "unknown host". I click again and it works. Then I go to a n ew article and the same thing happens for rd.yahoo.com and then again for story. news.yahoo.com when I go to the full article. I'm not sure what the interaction with Yahoo is, but this is the only site that really has this problem (that I g o to regularly). Maybe they just have slow nameservers and the timeout in Chime ra is too small? Reproducible: Always Steps to Reproduce: 1. Do something that gets the nameserver cache cleared after quitting Chimera 2. Start Chimera 3. Go to www.yahoo.com Actual Results: Unknown host Expected Results: Taken a little longer and gone to the yahoo home page
er??? I can't reproduce. sounds more like a problem with your local network or your ISP. What is this magical step 1, how do I do that? Also, can you reproduce this in Mozilla, and IE?
It turns out that Mozilla does indeed exhibit the behavior as well. It's not ISP related, as my Windoze box using the same nameservers does not exhibit it. But it should probably be moved to Mozilla, rather than Chimera.
moz
Component: General → Networking
Product: Chimera → Browser
Version: unspecified → 1.0 Branch
Alan, can you still reproduce this problem using a current nightly build? Is the DNS confirmation of your Mac *exactly* the same as the Windows box on which the Win32 Moz build works for you? That is, the same DNS servers, in the same order?
URL: http://www.yahoo.com → http://www.yahoo.com/
Summary: short dns timeouts → DNS timeout delay too short?
I'm afraid it does still occur, and the nameservers are the same on both Windoze and the Mac. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030219
Alan, what OS X version are you using?
Mac OS X 10.2.4 (6I32) I just did the latest update a couple of days ago...
I think this is related: When I run Mozilla, and I'm connecting to web sites, I will often be stuck waiting for DNS for minutes, for things like 'us.i1.yimg.com'. while Moz is 'Resolving host us.i1.yimg.com', I run 'host us.i1.yimg.com' in a terminal window, and it returns immediately. Also, running Safari, or IE, these issues do not occur.Running 2003022103, on a tiBook with 1G ram and 800MHz processor. OSX 10.2.4
Sorry about comment #8. Safari doesn't do wrapping, I guess.
In my experience (particularly via modem) Mozilla 1.3B frequently reports that a host is unreachable almost as soon as I try to connect. At the same time, I can connect to the same host using IE 5.2.2, Or Safari 1.0 Beta (v60) This problem renders Mozilla much less useful over a modem.
qa to me. Alan: There are a couple aspects of this that should be looked at. First of all, do you find that certain hosts always have this problem (.yahoo.com hosts?) Second, if you could get either Mozilla 1.0.x or Netscape 7.0.2, and see if this problem happens as well, you could help confirm this is a 1.0 branch problem. Third, if you think this problem is Mac-only, you need to see the problem in the following order: mac fails, win works, quit mac, run mac, mac fails again. The reasons why is a Windows works result after an initial failure could be due to the nameserver getting the response from the DNS system after you initial timeout. Since you nameserver caches, subsequent requests would be served out of cache, and work.
QA Contact: winnie → benc
Summary: DNS timeout delay too short? → DNS: timeout delay too short?
yahoo.com is more likely to show it than others, but it can happen with most anything I think. I'm not using the mac as much these days for various reasons, but the problem is absolutely Mac only. I don't think I've ever seen the problem on Win2K. In fact, just to verify it, since I haven't used the Mac for browsing in a while, I brought up www.yahoo.com on the Win2K box, then switched over to the Mac and fired up Mozilla. Sure enough, it timed out on www.yahoo.com, and then fetched it on retry. I'm not going to have a chance to try installing different versions for a few weeks, but if you still need me to try it in say mid-April, let me know and I should be able to do it then.
Last question. Mac-only for you is Mac OS X-only right? no Mac OS 9 or earlier problems?
I'm currently using Mac OS X as much as possible.I'd been blaming my recent problems on our DNS servers, until I noticed I had fewer problems using other browsers on Mac OS X.FWIW, I too have noticed a particular problem with the yahoo.com domain, but most especially with story.news.yahoo.com. (I assume this is because it's less likely to be cached on our local DNS than www.yahoo.com or my.yahoo.com.) However, I would not say that yahoo.com is the only domain that causes problems.I had imagined a timeout preference (since it seems this is not a universal problem.)
Yes, I'm running OSX with the latest updates.
There are several reports of that DNS name causing problems, and I have not looked at it in detail yet (maybe a low TTL + other factors). One person did isolate some Linux (and possibly BSD/Solaris/Mac OS X) problems to the fact that their resolver did a transport mode switch from UDP to TCP to resolve the name. At this point, I'm not sure we have the full picture of what breaks, hence all the questions (thanks for answering them!).
Shouldn't Mozilla (on Win XP) be using the system DNS lookup timeout settings? On my Win XP SP1 machine with Mozilla 1.5 (I know, I'm not up to date), I have the registry setting for DNS lookup timeout set to 30 seconds, but Mozilla (browser and mail client) report "Failed to connect to host xxx" after approximately 15 seconds. My situation: I'm connecting via WLAN to a router that connects via DSL. Sometimes my ISP takes about 15-20 seconds to process my logon -- that's when this bug shows up.
We had a recent check-in to fix a DNS regression. Does this problem still occur with Mozilla 1.7 RC1 or later?
(v1.7.3 20040910, OS X 10.3.5 - I was running a 1.7 beta from March and just now downloaded 1.7.3 with no change to the problem) This has been happening to me for the past couple of weeks, and has happened every now and then in the past. So I finally used Ethereal to see what it was doing. Mozilla is making four DNS queries only 700ms apart. After four of queries with no response, it then adds the search domain and tries again. I run my own DNS server at home (BIND 9.2.3) on a fixed IP DSL connection, and sometimes it takes more than 2.8 seconds to get a DNS reply. Once a query is made using the search domain provided from DHCP, for which my DNS server is authoritative (www.example.com.local), that query gets an immediate "domain does not exist" response. Then the responses to the initial DNS requests come in too late, as Mozilla has already put up the alert. One query every 700 ms sounds rather agressive, especially when timing out after only four of them. That means that if the response is not received in a mere 2.8 seconds, and the domain name in question was unambiguous (as in it already had .com rather than the browser having to try adding .com, .net, .org, etc.), it then tries the local domain, which is doomed to failure. When it gets a failure after adding the local domain, it immediately stops resolving and ignores any further responses. It looks like right now my DNS server is returning a response in 4-10 seconds. This may be an OS-level problem, since Safari is exhibiting similar behavior, four queries 700 ms apart, then a query with the local domain. There is a difference, however. After the original four queries without the search domain, and one with, Safari does two more queries without the search domain, then another query for an AAAA record. It still reported that the web site was not found, as six queries in 3600ms still wasn't not long enough. I think this is a broken way to resove domain names in that it doesn't give enough time for slow resolution. The resolver shouldn't take a positive failure on the search-appended domain name as a complete lookup failure, when no response at all had been received for previous queries. These tests were all done by clicking on links, mostly by using fark.com as a link farm. No URLs were entered into the address bar. I tried both a kill -HUP and a stop/start of named, with no effect on the response time from the server. I really don't want to disable my local search domain.
> This has been happening to me for the past couple of weeks, and has happened > every now and then in the past. So I finally used Ethereal to see what it was > doing. This problem has also got much worse for me with recent builds. It's now pretty severe (1/4 of newly-resolved domains fail, using SBC DSL) on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041103 Firefox/1.0RC2. I think I first saw this with Firefox 1.0PR (though I guess my nameservers could be getting slower). By the way, 267068 is a dupe.
<AOL>Me Too</AOL> (In fact, I probably need to go write an apology letter to the Cox Cable guys, whom I gave a hard time over... since I hadn't changed anything in my network config. Didn't think that a system change (to FireFox 1.0 and OSX 10.3.6) might conspire to cause this issue.) This is with Cox cable modem service in San Diego. Used to work fine on same laptop, but recently (2-3 weeks) I've started seeing near-instant timeouts on name resolution failures (when I was used to waiting the obligatory 30 seconds per nameserver). Let me know if I can test anything here.
connectivity problems are the most prominent cause for folks to complain to webmaster-de at mozilla europe about FF 1.0.
Severity: normal → major
For me at least, this was fixed long ago by an OS update (10.3.6? 10.3.7?).
I solved the problem long ago by setting up my DNS server to forward requests to my ISP's (SBC) DNS server. However, given what Ben says about the problem going away with an OS update, and with Safari also exhibiting the same behavior, this was probably an OS bug with name resolution and the bug should be closed.
(In reply to comment #24) > However, given what Ben says about the problem going away with an OS update, > and with Safari also exhibiting the same behavior, this was probably an OS bug > with name resolution and the bug should be closed. If you'll read my (previous) comments, I found that Safari did not exhibit the same behavior, nor did any other browser. OTOH: I have not seen this problem with Firefox recently. I would not attribute the fix to an OS update, however it seems to be fixed.
And if you'll read _my_ commment #19, I found Safari doing the same thing, only trying a couple more times.
Assignee: saari → nobody
QA Contact: benc → networking
marking invalid based comment #26
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.