DNS lookup issue: Many sites consistently take a long time to resolve after first launching Firebird 0.8 series.

RESOLVED DUPLICATE of bug 68796

Status

()

Core
Networking
RESOLVED DUPLICATE of bug 68796
15 years ago
15 years ago

People

(Reporter: Drew D. Saur, Assigned: Blake Ross)

Tracking

Trunk
PowerPC
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

17.51 KB, application/octet-stream
Details
(Reporter)

Description

15 years ago
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.
(Reporter)

Comment 1

15 years ago
Confirmed that this does not happen on identically-dated nightly Windows builds.
-DDS at 11:00 AM on 1/28/2004.

Comment 2

15 years ago
WFM on windows
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7a) Gecko/20040128
Firebird/0.8.0+ (scragz)

Comment 3

15 years ago
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.
(Reporter)

Comment 4

15 years ago
Interesting point, but that does not explain why there are no issues using 0.7.1
on the same box!

Comment 5

15 years ago
>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.
(Reporter)

Comment 6

15 years ago
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?
(Reporter)

Updated

15 years ago
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.

Comment 7

15 years ago
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?
(Reporter)

Comment 8

15 years ago
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

Comment 9

15 years ago
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?

Comment 10

15 years ago
(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...

Comment 11

15 years ago
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

Comment 12

15 years ago
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.

Comment 13

15 years ago
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.

Comment 14

15 years ago

*** This bug has been marked as a duplicate of 231607 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 15

15 years ago
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

Comment 16

15 years ago

*** This bug has been marked as a duplicate of 68796 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → DUPLICATE

Updated

15 years ago
No longer depends on: 231607

Comment 17

15 years ago
Drew: can you come up with a shorter summary?
QA Contact: benc
(Reporter)

Updated

15 years ago
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.