Answer Steering and Failover

## What round-robin DNS is **Round-robin DNS** is the simplest form of answer steering: the zone publishes several address records for one name, and the authoritative server hands them all back, usually in a different order each time. For `www.example.com` the zone might hold three `A` records, `192.0.2.10`, `192.0.2.11` and `192.0.2.12`, forming one **RRset** (resource record set: all records sharing a name, class and type, RFC 2181 §5). A query for that name and type returns the whole RRset (RFC 2181 §5.1). Because most clients open their connection to the first address in the list they receive, rotating the order spreads new clients across the three servers. Nothing here is a special record type or a protocol flag. The rotation is an **implementation choice** of the authoritative server. The DNS itself gives record order no meaning: RFC 1034 §5.2.1 notes that the DNS does not preserve the order of RRs, and that the host's lookup function may sort the returned addresses or pick the best one. ## Who can change the order before a client connects Several parties touch the list between the zone file and the client's connection: 1. **The authoritative server** may rotate the RRset on every response, or return a fixed order. 2. **The recursive resolver** caches the RRset for its TTL. Some resolvers rotate cached RRsets themselves; others return the ordering they received to every client until the entry expires. 3. **The host's resolver library** may sort the addresses. RFC 1123 §6.1.3.4 says a host that meets a name with multiple addresses SHOULD rank or sort them using knowledge of its directly connected networks and any performance history; hosts also apply their own address-selection preferences, such as IPv6 before IPv4. 4. **The application** decides whether it uses only the first address or walks the list. So the rotation the authoritative server applied is a suggestion. It survives only when every later hop passes the order through untouched. ## Why the spread is coarse - **No load feedback.** The authoritative server has no idea how busy `192.0.2.10` is; plain round robin gives every address an equal turn regardless. - **No health feedback.** A dead server's address stays in the RRset until someone edits the zone or a health-checking layer withdraws it. - **The unit is a cache fill, not a user.** A resolver serving a large population may hand one ordering to thousands of clients for the whole TTL, say 300 seconds, while a small office resolver gets its own rotation. Traffic follows resolver populations. - **Connections, not requests.** A client that opens one long-lived connection stays on that server for its lifetime, however many requests it sends. - **Re-sorting defeats rotation.** If hosts sort addresses by locality or preference, many clients converge on the same address whatever order the server sent. ## The free fallback list The multi-address answer has one real strength: every client receives alternatives. RFC 1123 §2.3 says application protocol implementations SHOULD be prepared to try multiple addresses from the list until one succeeds. A client that does this survives one dead server at the cost of a connection timeout on the first attempt. A client that only ever uses the first address does not. That behaviour lives in the client, not in DNS, so round robin is a crude failover mechanism only for well-behaved clients. ## Round robin compared with a load balancer | Property | Round-robin DNS | Dedicated load balancer | |---|---|---| | Where the decision is made | Authoritative server, once per cache fill | Per connection or per request | | Knows backend load | No | Usually | | Knows backend health | No, unless a checker edits the answers | Yes, from its own checks | | Granularity | A resolver's population for one TTL | One connection | | When a backend dies | Client must retry the next address | Balancer stops sending to it | | Extra infrastructure | None | A balancer tier that must itself be redundant | The balancing algorithms a real balancer uses are a separate subject; the point here is where the decision sits and what it can see. ## What a good answer sounds like A strong answer names the RRset, says that record order is not significant by specification and that rotation is the server's choice, and then gives the reasons the result is coarse: caching makes the resolver's population the unit, there is no load or health awareness, and hosts may re-sort. It ends on what round robin does well, a list of alternatives that a well-behaved client walks when one address fails.