This already exists - it's called a SRV record. SRV records allow you to assign a priority and a weight for a lookup query, the same way you can with MX records

This already exists - it's called a SRV record. SRV records allow you to assign a priority and a weight for a lookup query, the same way you can with MX records (in SRV you can give different ports as well, very cool). It was proposed by Microsoft in 2000 and was first used in Win2k in ActiveDirectory and is now a standard (it was around before 2000, can't remember where exactly). It has been widely adopted, it is used in zeroconf, SIP, XMPP and there are proposals to route WHOIS lookups using SRV. Everywhere but in browsers, for various reasons. You can do MX in email, because the time it takes to do the multiple lookups is not an issue since email goes out in the background. A records were designed to be round-robin. In theory, SRV records in browsers are a fantastic solution that would change the web and make it easy to have failover. Here is the problem. Even if the first server is up all the time, you double the number of DNS queries on the web. SRV records dont store IP addresses, they store names. So the browser does a SRV req, orders by priority and weight, picks one, then does an A lookup and attempts connection. Then, if that connection were to fail (meaning 10-20 seconds). It would move to the next. This then raises issues of caching. If you have a high TTL, it defeats the purpose, so you lose all benefit of DNS caching. If you bring it down again the browser will just keep checking the failed A record each time it hits expiry. Multiply this out by the number of elements on a page and you start to see why SRV is implemented almost everywhere else except for web browsers. It reaches a point where having the record management on the server end makes more sense, because it is determined once which servers are healthy and all clients are informed, rather than each client checking for itself each time.