From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010608 BuildID: 2001060810 This bug was found trying to load a large page with graphics. The page contained contained a single reference to an ad. and DNS servers responcible for records from that reference were down. As a result all that was displayed was a blank page for quite some time. The same page in Netscape 4 did fully load. Only the ad. with DNS problems was missing. Reproducible: Always Steps to Reproduce: Test setup: 2 Unix hosts. Host #1 and Host #2 have Bind installed. Host #2 runs HTTP server on primary interface. Host #1 has Mozilla installed. 1. Create VIF (virtual interface, ifconfig eth0:1 ...) on Host #2. 2. Create bogus domain (example.com) name on Host #1\ 3. Create a record in the bogus domain with deligation to just created VIF on Host #2 (bad.example.com) and add appropriate SOA records on Host #2 (for bad.example.com). 4. Create a web page on HTTP sever Host #2 that includes multiple images from Yahoo, Netscape, etc., and a single image from bad.example.com. 5. Verify that page loads with graphics correctly in Mozilla running on Host 1. 6. Empty cache in Mozilla and DNS server. 7. Bring VIF on Host #2 down (ifconfig eth0:1 down) 8. Repeate request in 5. Actual Results: Mozilla stalls for minutes. Nothing gets displayed. Expected Results: Only an image from bad.example.com should not load. All other images should be loaded and displayed.
What error messages, if any appear? If the unresolvable URL is last, does the information ahead of it load at all?
Component: Browser-General → Networking
QA Contact: doronr → benc
Summary: Resolving a DNS name in a domain that is down prevents entire page from loading → DNS: resolution failure in page stops remaining activity
No error messages appear. The problem is harder to reproduce then I first thought. It seems also to be attributed to various network delays + different OSs. On RedHat 7.1/linux-2.4.2 (Mozilla build 2001060810) Tcpdump shows 2 query attempts to primary DNS resolver waiting 5 seconds for each to complete then try appending prefixes from /etc/resolv.conf "domain" and "search" to get immediate "No such name" reply. Total of a little over 10 seconds wasted which seems to be acceptable. Page loads without errors with just unresolvable URL missing. Information ahead of unresolvable URL does load. On RedHat 6.2/linux-2.2.19 (Mozilla build 2001060722) (platform where the problem was actually observed) Tcpdump shows 4 query attempts to primary DNS resolver (delay between 3rd and 4th query was 10 seconds vs. 5 seconds between the rest) and it looks like system actually waited for DNS "Server Failure" responce (it got it 7 seconds after the 4th query). Attempts with "appends" didn't take long. Total 27 seconds wasted. Page loads without errors with just unresolvable URL missing. Information ahead of unresolvable URL does load. If DNS "Server failure" gets delayed for longer (i.e. fast ethernet in the lab is removed from equation) it looks like the "wasted" time will increase too in the above case. I guess I will be upgrading soon...
Severity: major → normal
Okay. Some more DNS fixes landed for this week, so please update us when you have a chance to get a newer build.
Reporter: Can you retest with a newer build ?
marking WORKSFORME No problems here.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
reporter: This bug is a "futured" or "untargeted" bug which has been "resolved/works for me". Most bugs meeting this criteria are usually somewhat out of date or working in the current builds. If this bug is not happening for you in a recent build (such as the Mozilla daily build, Mozilla 0.9.3, or Netscape 6.1), please use the friendly "Mark bugs as VERIFIED" radio button to set this bug to "VERIFIED/WORKS FOR ME" If you reported the bug on a platform (e.g. Linux) and other contributors reported on another platform (e.g. Mac OS), please comment that it works for you but do not verify it yet. For these multi-platform bug reports, we need to verify all reported platforms -OR- create new "still broken on platform X" bugs when you verify.
You need to log in before you can comment on or make changes to this bug.