User-Agent: Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040127 Firebird/0.8.0+ DNS lookup issue: This site (and certain others) consistently takes a long time to resolve after first launching the Firebird 0.8 series for Mac OS X. This is NOT an issue with the 0.7 series (and using the same preferences) on the very same machine. Reproducible: Always Steps to Reproduce: 1. Quit Firebird and relaunch. 2. At any time after relaunching (even after visiting other sites), visit www.allmusic.com. Watch long timeframe for DNS lookup. 3. Repeat several times to note identical behavior. 4. Use 0.7.1 instead; problem does not occur. I do realize that it is possible that there are issues with the DNS records (and/or their propagation) for the sites that demonstrate this issue. However, what is 0.7.1 doing right that 0.8 is not? Expected Results: Should perform a swift DNS lookup for site, as is the case with 0.7.1. Followup: this happened with bugzilla.mozilla.org as I submitted this form! Using Mac OS X 10.3.2 with a 600 MHz iBook / 640MB RAM.
Confirmed that this does not happen on identically-dated nightly Windows builds. -DDS at 11:00 AM on 1/28/2004.
WFM on windows Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7a) Gecko/20040128 Firebird/0.8.0+ (scragz)
Confirmed on Gecko/20040121 Firebird/0.8.0+ But: the dns lookup is unusually long when fetching the index page with curl http://www.allmusic.com on a linux box. Most probably a DNS issue on server side.
Interesting point, but that does not explain why there are no issues using 0.7.1 on the same box!
>that does not explain why there are >no issues using 0.7.1 on the same box! Indeed. Nor does it explain why the lookup is fast on safari, or when I use wget instead of curl. The lookup is slow on the lynx browser on linux, too. Weird.
Holy cow, you're right. Don' have access to my Mac right now, so just tried it in on a FreeBSD machine using Lynx 2.8.3, with the same issue (it took even LONGER than Firebird Mac 0.8!). Funny thing - on the same FreeBSD machine where Lynx 2.8.3 exhibits this behavior, curl 7.10.5 works just fine. I haven't been involved in Firebird development, but it certainly makes me wonder if version 0.8 saw a switch in the DNS lookup subsystem between 0.7 and 0.8...a switch to the same method or subsystem that Lynx is using?
Summary: DNS lookup issue: This site (and certain others) consistently takes a long time to resolve after first launching Firebird 0.8 series. This is NOT an issue with the 0.7 series (and using the same preferences) on the very same machine. → DNS lookup issue: This site (and many others) consistently takes a long time to resolve after first launching Firebird 0.8 series. This is NOT an issue with the 0.7 series (and using the same preferences) on the very same machine.
This tool here reports some warnings for the allmusic.com zone: http://dnsreport.com/tools/dnsreport.ch?domain=allmusic.com And here is a clue. Of the two nameservers returned by 'dig allmusic.com soa' the second one (m-hostmaster.ems.att.com) doesnt exist. Which still doesnt explain why some clients are delayed, while others aren't. I thought the hostname resolution part was handled by a system call to the OS?
Is there any reason that no action is being taken on this item (is it not even a duplicate bug?), and that 0.8 was released without doing anything about it? 0.8 is pretty unsatisfactory on OS X, yet Firefox may be the most important browser for the Mac community (given that cross-platform considerations). On my own site (www.macorchard.com), I recommend that Mac users stick with 0.7.1 instead, at least for now. Drew
There was a similar problem/behavior going between Mozilla 1.5 and Mozilla 1.6 or later. Mozilla 1.5 loads the page fine. Mozilla 1.6 and later causes odd pauses. The problem is exacerbated if I use a proxy file to determine whether or not I need to use a proxy server. Is this possibly the same as BugID 231607?
15 years ago
Depends on: 231607
(In reply to comment #9) > > Is this possibly the same as BugID 231607? It's very possible that this bug is a dupe of bug 231607. Drew: what type of network are you on? Can you get a packet trace of the DNS lookups? To get a packet trace run the command tcpdump -s 0 -w dnstrace.trc port 53 and attache dnstrace.trc to the bug. A cursory glance at the DNS records for www.allmusic.com show that the time-to-live is set for 5 seconds, which is just plain silly. That's going to exacerbate the problem we are seeing in bug 231607, which I suspect is the problem here. Please get back with the trace ASAP, I have an idea for a workaround, but I want to make sure it's the same problem...
In the mean time, this bug needs to be confirmed. Drew, you need to respond. Otherwise, if you post your patch code (I know it's work to code with possible futile ends), I'm sure one of the Mac users here would be happy to compile a version with that code included and see whether it fixes the problem. The choice is up to you--to wait, or have a longer testing period and start working on it now. Thanks Team Mozilla, --Sam
Created attachment 141472 [details] DNS Trace I'm not the bug filer, but attaching what I see on this end. Let me know if I can gather any more data for you.
Wow. getaddrinfo() is even more broken on MacOS (and presumeably FreeBSD) than I thought. In this case, the DNS server does not respond to AAAA (IPv6) host queries, so the mac ends up sending them out a total of eight time, with about a 10 second lag from the first request to when it finally stops. This bug should be marked a dupe of bug 231607. I'll create a patch to disable getaddrinfo by default, but have a pref that lets users who are actually using IPv6 enable it, and attach it to that bug.
*** This bug has been marked as a duplicate of 231607 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
This is actually a duplicate of bug 68796. Reopening to be able to mark as such.
Status: RESOLVED → UNCONFIRMED
Component: General → Networking
Product: Firefox → Browser
Resolution: DUPLICATE → ---
Version: unspecified → Trunk
*** This bug has been marked as a duplicate of 68796 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago → 15 years ago
Resolution: --- → DUPLICATE
Drew: can you come up with a shorter summary?
QA Contact: benc
Summary: DNS lookup issue: This site (and many others) consistently takes a long time to resolve after first launching Firebird 0.8 series. This is NOT an issue with the 0.7 series (and using the same preferences) on the very same machine. → DNS lookup issue: Many sites consistently take a long time to resolve after first launching Firebird 0.8 series.
You need to log in before you can comment on or make changes to this bug.