392953 - Handling Multiple Records for DNS - High Availability Issue

Status: RESOLVED DUPLICATE of bug 641937

(Core :: Networking, defect)

Description

[Jim Frantzen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

A common technique in load balancing traffic is to return multiple IP's for a DNS request. If the first 3 IP's in the list are dead, FF will not remember this next time it needs to make a request.

The wininet lib seems to get this right. Internet Explorer, for example, will remember that the 4th IP was good and any subsequent requests will use that resource.


Reproducible: Always

Steps to Reproduce:
1. Setup your DNS to return multiple records, take all but 1 of them down.
2. Sniff Firefox's packets as requests are made to your domain.
3. Watch the delays.
Actual Results:  
FF delays for several seconds as it tries each record until the requests goes through. A subsequent request won't remember the good record and start from the beginning all over again.

Expected Results:  
FF should cache the last known good position in the list of IP's and start there for each subsequent request.

Comment 2

[James Ponder]

This should be given higher priority to fixing.  This hurts adoption of Firefox in enterprise environments where high availability is paramount.

Comment 3

[Matt Chapman]

I realise that the document is out of date, but the behaviour experienced in this bug does not fit the implementation explanation stated in the Mozilla documentation at http://www.mozilla.org/docs/netlib/dns.html.

Specifically the sentence: "Once an ip address fails, it's out, removed from the host entity in the cache."

Comment 6

[Patrick McManus [:mcmanus]]

josh you should retest this before spending a lot of time on it. I think I fixed it as 641937 about a year ago.. but maybe I'm misreading the bug description.

Comment 7

[Josh Aas]

This seems to be a dupe of bug 641937, looking at the code suggests to me that this isn't a problem any more.