Everyone seems to think that you are talking about WWW servers, even though you explicitly wrote
like a backup name-server or mail server
The oft-overlooked truth is that HTTP service is the exception
and not the norm when it comes to this. In the normal case, yes, there is
a mechanism for publishing information to clients via the DNS so that they properly fallback from primary servers to backup servers. That mechanism is
SRV resource records, as used by service clients for many other protocols apart from HTTP.
See RFC 2782.
SRV resource records, clients are told a list of servers, with priorities and weights, and are required to try servers in order order of priority, picking amongst servers with equal priorities according to weight, choosing higher-weighted servers more often than lower-weighted ones. So with
SRV resource records, server administrators can tell clients what the fallback servers are, and how to distribute their load across a set of equal-priority servers.
Now content DNS servers are located by a special type of resource record of their own,
NS resource records, which don't have priority and weight information. Equally, SMTP Relay servers are located by their own special type of resource record,
MX, which has priority information but no weighting information. So for content DNS servers there's no provision for publishing fallback and load distribution information; and if one is using
MX resource records then for SMTP Relay servers there's no provision for publishing load distribution information.
SRV-capable MTSes now exist. (The first was
exim, which has been
SRV-capable since 2005.) And for other service protocols, unencumbered with the baggage of
NS resource records,
SRV adoption is far more thorough and widespread. If you have a Microsoft Windows domain, for example, then a whole raft of services are located through
SRV lookups in the DNS. That's been the case for more than a decade, at this point.
The problem is that everyone thinks of HTTP, when HTTP is by far, nowadays in 2011, the exception and not the rule here.