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

Status: RESOLVED DUPLICATE of bug 68796

(Core :: Networking, defect)

Description

[Drew D. Saur]

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.

Comment 1

[Drew D. Saur]

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

Comment 2

[Seb Perez-D]

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

Comment 3

[Marco]

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.

Comment 4

[Drew D. Saur]

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

Comment 5

[Marco]

>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.

Comment 6

[Drew D. Saur]

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?

Comment 7

[Marco]

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?

Comment 8

[Drew D. Saur]

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

[James Hsieh]

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

[Jerry Talkington]

(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

[Sam Katz]

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

[James Hsieh]

Attachment: 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

[Jerry Talkington]

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

[louis bennett]

*** This bug has been marked as a duplicate of 231607 ***

Comment 15

[Lorenzo Colitti]

This is actually a duplicate of bug 68796. Reopening to be able to mark as such.

Comment 16

[Lorenzo Colitti]

*** This bug has been marked as a duplicate of 68796 ***

Comment 17

[benc]

Drew: can you come up with a shorter summary?