417242 - Weird DNS failures in Fx3

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[Deb Richardson [:dria] (plz NEEDINFO)]

Every so often I'll try to load a URL in Fx3 that, for whatever reason, gets "stuck" somehow and can't be found.  I'll get a "Firefox can't find the server at [url]" error page, and after that happens I am unable to load that URL or any other URL at that domain until I run "dscacheutil -flushcache" on the command line.

I was under the impression that it was some combination of network and OS X caching behaviour until earlier today when, just to test, I opened Fx2 to see if it could load the URL without flushing the cache.  Turns out it could, so I'm not sure OS X's caching is to blame.

Anyhow, I am unable to reliably reproduce this behaviour, but it happens at least a couple of times per day.  It may simply be due to frequency, but I notice it most often when handing URLs off from my feed reader (Vienna) to Firefox, or from IRC to Firefox.  I don't *think* it has happened when opening a URL in Firefox directly (either through URL bar or clicking a link), but cannot be 100% sure of that right now.  I'll continue to watch behaviour and update if I notice anything else that may be relevant.

Here's a screenshot that shows Fx3 in "stuck" mode, and Fx2 able to find the URL just fine, regardless of cache state.

http://dria.org/images/Fx2vFx3.png

Comment 1

[Dave Townsend [:mossop]]

I see this quite frequently on my home network, can't say I've tried firefox 2 when it happens. However when firefox is unable to resolve the name the same is true of ping, so pinging the address finds no address, but dig and nslookup can.

I'll check with Firefox 2 next time and see if that works for me too.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

I wonder whether this might be related to bug 408881.

Comment 3

[David Luyer]

I don't see any 'typical' AAAA DNS query failure modes on www.macobserver.com;
it all looks fine from test queries.

Dave: Are you using Leopard? (I see Deb is from the reference to dscacheutil.)

Deb/Dave: Can you list some other sites so we can look for any commonalities?
There might be some DNS bug when the cache in Leopard contains CNAME and A,
and is then q
I notice www.macobserver.com is an alias for macobserver.com, for example.  

Comment 4

[David Luyer]

I don't see any 'typical' AAAA DNS query failure modes on www.macobserver.com;
it all looks fine from test queries.

Dave: Are you using Leopard? (I see Deb is from the reference to dscacheutil.)

Deb/Dave: Can you list some other sites so we can look for any commonalities?
There might be some DNS bug when the cache in Leopard contains CNAME and A,
and is then queried for a AAAA for that record, for example; a few more
sites would show what we could look for and test.

I notice www.macobserver.com is an alias for macobserver.com, for example.  

Comment 5

[Lorenzo Colitti]

For what it's worth, I can get to www.macobserver.com fine from an IPv6-connected machine. Is your home network box somehow corrupting AAAA queries?

Comment 6

[Dave Townsend [:mossop]]

I am using leopard yes. I don't off hand have a list of sites I've seen it with, though I know that google and bugzilla have been hit. I'll remember to make notes the next time i hit it.

Comment 7

[Deb Richardson [:dria] (plz NEEDINFO)]

I've definitely hit it on google.  I'll also make notes.

Comment 8

[David Luyer]

OK, so far we have consistency (although a very small dataset):

- 2/2 reports are on Lepoard
- 3/3 sites reported are CNAME records to A-only sites
  (www.google.com, www.macobserver.com, bugzilla.mozilla.org)

There is also some reasonably probability all these may have been accessed by
an application requesting the A (older Firefox, or some other application),
before Firefox requested the AAAA+A.

My impression (especially given that dscacheutil fixes it) is that this is
almost definitely OS X bug, which if we can correctly describe and identify, 
Apple should be willing to fix for us in an automatic update.

Comment 9

[Mike Shaver (:shaver emeritus)]

Per: http://timtrueman.com/2008/02/28/frigtarded-leopard-dns-issue/

Can people see NEG entries when they're hitting this?

Comment 10

[Dave Townsend [:mossop]]

As it happen's I don't think I've seen this since my last comment. I will continue to keep an eye out but it might just be that my ISP was being flakey for a time and that negative caching thing was exacerbating the situation.

Comment 11

[Deb Richardson [:dria] (plz NEEDINFO)]

I haven't seen this nearly as often lately, and when I do hit it, the page always comes up on a reload so I don't have to do the "dscacheutil" thing.  I have updated to 10.5.2 recently, but can't remember if that was before or after I filed this.

Comment 12

[philippe (part-time)]

FWIW (and I think this is related to this bug), using 10.5.x, I have had repeated problems downloading nightly builds (Camino & Minefield). The download will start but stalls halfway. ftp.mozilla.org is the only download server I've had trouble with.
This is apparently not browser dependent, I have reproduced the same issue with Safari and Transmit(FTP client).
The  thing is, I can _always_ download from ftp.mozilla.org using 10.3.9 and 10.4 machines.

Just had it again, (after doing a dscacheutil -flushcache):

$ dscacheutil -cachedump -entries
DirectoryService Cache Overview:
    AAAA Queries  - Disabled (link-local IPv6 addresses)
    Buckets Used  - 6
    Cache Size    - 1

    Entry count by category:
        Host  - 1

Cache entries (ordered as stored in the cache):

      Category         Best Before         Last Access      Hits    Refs       TTL    Neg  DS Node
    ----------  ------------------  ------------------  --------  ------  --------  -----  ---------
          Host   03/02/08 21:35:09   03/02/08 21:25:09         0       7       600         
                     Key: h_aliases:ftp.mozilla.org ipv4:1 ipv6:1
                     Key: h_aliases:ftp.mozilla.org ipv6:1
                     Key: h_aliases:ftp.mozilla.org ipv4:1
                     Key: h_name:dm-ftp01.mozilla.org ipv4:1 ipv6:1
                     Key: h_name:dm-ftp01.mozilla.org ipv6:1
                     Key: h_name:dm-ftp01.mozilla.org ipv4:1


$ ping dm-ftp01.mozilla.org
PING dm-ftp01.mozilla.org (63.245.208.138): 56 data bytes
^C
--- dm-ftp01.mozilla.org ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss

(access is from Japan, with NTT B-Flets [fiber], ISP is asahi-net.or.jp).

Comment 13

[Lorenzo Colitti]

(In reply to comment #12)
> FWIW (and I think this is related to this bug), using 10.5.x, I have had
> repeated problems downloading nightly builds (Camino & Minefield).

FWIW, this does not seem to be related to IPv6: you seem to have IPv6 queries turned off, and ftp.mozilla.org doesn't have an IPv6 record in the DNS anyway.

Comment 14

[Wayne Mery (:wsmwk)]

Deb, still see this?  If it doesn't work in 3 but worked in 2, one would think a log would pinpoint the problem.

Comment 15

[Deb Richardson [:dria] (plz NEEDINFO)]

I don't use Firefox 3 anymore, to be sure.  And no i haven't seen this happen in a long time.  Not sure why.

Comment 16

[[e-mail] (:bhearsum)]

I haven't seen this in ages either.

Comment 17

[Wayne Mery (:wsmwk)]

WFM per comment 15, ...