Closed Bug 392953 Opened 13 years ago Closed 8 years ago

Handling Multiple Records for DNS - High Availability Issue


(Core :: Networking, defect)

Windows XP
Not set





(Reporter: jim.frantzen, Assigned: jaas)



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

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.
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
Duplicate of this bug: 412259
Severity: major → normal
Ever confirmed: true
This should be given higher priority to fixing.  This hurts adoption of Firefox in enterprise environments where high availability is paramount.
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

Specifically the sentence: "Once an ip address fails, it's out, removed from the host entity in the cache."
Duplicate of this bug: 171195
Duplicate of this bug: 565862
Assignee: nobody → joshmoz
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.
This seems to be a dupe of bug 641937, looking at the code suggests to me that this isn't a problem any more.
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 641937
You need to log in before you can comment on or make changes to this bug.