Closed Bug 267068 Opened 20 years ago Closed 20 years ago

DNS lookups are reattempted with the localdomain (and derivatives) appended too quickly

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: andrew-bugzilla, Assigned: bugzilla)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10

Frequently when browsing to new sites (like when clicking on links in Google
search results), if I watch the DNS traffic with tcpdump, I see about four
requests for the domain get fired off, closely followed by the original domain
with my local domain appended, which tends to return an NXDomain response faster
than my local nameserver returns a response for the original question, resulting
in Firefox displaying a "$DOMAIN could not be found" type error message.

Reproducible: Sometimes
Steps to Reproduce:
1. Pick a website that's probably not in the local computer's DNS cache
2. Attempt to browse to it
3. If it says "Looking up $DOMAIN" for too long in the status bar, it's
generally going to do it

Actual Results:  
Either the website loads, or a DNS resolution error dialog pops up. If analysing
the DNS traffic with tcpdump, it's quite clear what's going on.

Expected Results:  
Loaded the website

Here's some tcpdump output:

09:24:56.154469 IP 172.16.1.12.50723 > 172.16.1.1.53:  16753+ A?
www.froogle.com. (33)
09:24:56.867043 IP 172.16.1.12.50723 > 172.16.1.1.53:  16753+ A?
www.froogle.com. (33)
09:24:57.579458 IP 172.16.1.12.50723 > 172.16.1.1.53:  16753+ A?
www.froogle.com. (33)
09:24:58.286637 IP 172.16.1.12.50723 > 172.16.1.1.53:  16753+ A?
www.froogle.com. (33)
09:24:58.993697 IP 172.16.1.12.50724 > 172.16.1.1.53:  46736+ A?
www.froogle.com.andrew.net.au. (47)
09:24:58.995855 IP 172.16.1.1.53 > 172.16.1.12.50724:  46736 NXDomain* 0/1/0 (98)
09:24:58.996180 IP 172.16.1.12.50725 > 172.16.1.1.53:  56194+ A?
www.froogle.com.net.au. (40)
09:24:59.031906 IP 172.16.1.1.53 > 172.16.1.12.50725:  56194 NXDomain 0/1/0 (111)
09:25:01.447109 IP 172.16.1.1.53 > 172.16.1.12.50723:  16753 4/11/6 CNAME[|domain]
09:25:01.448866 IP 172.16.1.1.53 > 172.16.1.12.50723:  16753 4/11/6 CNAME[|domain]
09:25:01.450252 IP 172.16.1.1.53 > 172.16.1.12.50723:  16753 4/11/6 CNAME[|domain]
09:25:01.451811 IP 172.16.1.1.53 > 172.16.1.12.50723:  16753 4/11/6 CNAME[|domain]
I think Product/Component Browser/Networking fits better. 
I see this too.  It's pretty annoying.  I see the 'could not be found' message
for about 1/4 of all newly-resolved domains when the computer is connected
wirelessly to DSL.  On a faster, wired university network, the problem goes away.

I didn't see this before 1.0RC1 (though perhaps this is because the latency of
my nameservers has lengthened). 
As Ben points out in bug 185123 comment 20, this is probably a duplicate /
resurfacing of that bug.  Someone want to close this as a dup?  Or do we suspect
the old behavior was fixed, and this is a new problem that should be tracked here?
(In reply to comment #3)
> As Ben points out in bug 185123 comment 20, this is probably a duplicate /
> resurfacing of that bug.  Someone want to close this as a dup?  Or do we suspect
> the old behavior was fixed, and this is a new problem that should be tracked here?

Did you quote the right bug number there?

(In reply to comment #4)

> Did you quote the right bug number there?

Of course not.  That'll teach me to poke at bugs at 3 in the morning...

Actual bug I meant was:  Bug 185128 DNS: timeout delay too short?
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3)
Gecko/20040913 Firefox/0.10
> Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3)
Gecko/20040913 Firefox/0.10
> 
> Frequently when browsing to new sites (like when clicking on links in Google
> search results), if I watch the DNS traffic with tcpdump, I see about four
> requests for the domain get fired off, closely followed by the original domain
> with my local domain appended, which tends to return an NXDomain response faster
> than my local nameserver returns a response for the original question, resulting
> in Firefox displaying a "$DOMAIN could not be found" type error message.
> 
> Reproducible: Sometimes
> Steps to Reproduce:
> 1. Pick a website that's probably not in the local computer's DNS cache
> 2. Attempt to browse to it
> 3. If it says "Looking up $DOMAIN" for too long in the status bar, it's
> generally going to do it
> 
> Actual Results:  
> Either the website loads, or a DNS resolution error dialog pops up. If analysing
> the DNS traffic with tcpdump, it's quite clear what's going on.
> 
> Expected Results:  
> Loaded the website
> 
> Here's some tcpdump output:
> 
> 09:24:56.154469 IP 172.16.1.12.50723 > 172.16.1.1.53:  16753+ A?
> www.froogle.com. (33)
> 09:24:56.867043 IP 172.16.1.12.50723 > 172.16.1.1.53:  16753+ A?
> www.froogle.com. (33)
> 09:24:57.579458 IP 172.16.1.12.50723 > 172.16.1.1.53:  16753+ A?
> www.froogle.com. (33)
> 09:24:58.286637 IP 172.16.1.12.50723 > 172.16.1.1.53:  16753+ A?
> www.froogle.com. (33)
> 09:24:58.993697 IP 172.16.1.12.50724 > 172.16.1.1.53:  46736+ A?
> www.froogle.com.andrew.net.au. (47)
> 09:24:58.995855 IP 172.16.1.1.53 > 172.16.1.12.50724:  46736 NXDomain* 0/1/0 (98)
> 09:24:58.996180 IP 172.16.1.12.50725 > 172.16.1.1.53:  56194+ A?
> www.froogle.com.net.au. (40)
> 09:24:59.031906 IP 172.16.1.1.53 > 172.16.1.12.50725:  56194 NXDomain 0/1/0 (111)
> 09:25:01.447109 IP 172.16.1.1.53 > 172.16.1.12.50723:  16753 4/11/6 CNAME[|domain]
> 09:25:01.448866 IP 172.16.1.1.53 > 172.16.1.12.50723:  16753 4/11/6 CNAME[|domain]
> 09:25:01.450252 IP 172.16.1.1.53 > 172.16.1.12.50723:  16753 4/11/6 CNAME[|domain]
> 09:25:01.451811 IP 172.16.1.1.53 > 172.16.1.12.50723:  16753 4/11/6 CNAME[|domain]

I've actually managed to reproduce this with the likes of ping, and there are
countless Mac forum posts from Safari users complaining of the same problem. I
therefore believe the problem is actually with the MacOS X DNS resolver.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Regarding the "countless reports", here is a sampling:

http://technology.rustybrick.com/blog/archives/000651.html

Tries to modify resolv.conf ... I've done some similar modifications, but they
didn't seem to help.  It doesn't help that OSX doesn't use resolv.conf directly,
but rather goes through an insanely convoluted path to do hostname lookups.

http://blog.simon-cozens.org/6771.html

A sampler of that twisty path.

http://www.macworld.com/forums/ubbthreads/showflat.php?Cat=&Board=UBB1&Number=271151&page=0&view=collapsed&sb=5&o=&fpart=1
http://forums.macnn.com/showthread.php?s=d17b1f33363010719e762a8b7c98f87b&threadid=233359
http://discussions.info.apple.com/webx?14@162.7RLMa4CEAPP.0@.689e2c88
http://www.cubeowner.com/forums//index.php?s=6a0efba93ce04804fbb4b8e225872580&showtopic=8622&st=0&#entry49268

Various forum postings showing people with this difficulty.  It seems to cross
browser boundaries (meaning that it's likely not a WebKit problem) and there are
lots of other variables -- the only constant seems to be an onset within the
last few weeks.

I asked a friend who works in Apple Support, and she does not recall hearing
about this issue from users ... but she is seeing it on her own machine at work.
 So maybe I'll hear more from that front.

Either way, it seems likely that the most recent Security Updates and/or 10.3.6
OS update caused or uncovered this issue.
(In reply to comment #7)
> Either way, it seems likely that the most recent Security Updates and/or 10.3.6
> OS update caused or uncovered this issue.

I filed a bug at bugreport.apple.com, #3885265.  I can't imagine I'm the first.
 If only apple used bugzilla, I'd have been able to check...
You need to log in before you can comment on or make changes to this bug.