When a DNS authoritative server does health-checked failover for app.example.com, what changes in its answers when an endpoint fails, and what bounds how fast clients follow?

## What the authoritative server changes DNS itself has no notion of health. An `A` record has no "up" flag, and recursive resolvers do not probe the addresses they cache. **Health-checked failover** is logic in front of, or inside, the authoritative server: probes from one or more vantage points test each endpoint, and the answer-generation step consults the latest health state for every query, building the answer only from endpoints that pass. Some deployments have the checker rewrite the zone instead, for example with DNS UPDATE (RFC 2136); the effect on answers is the same. Two common shapes: | Shape | Answer while healthy | Answer after the primary fails | |---|---|---| | Active-passive | the primary only, e.g. `192.0.2.30` | the secondary only, e.g. `198.51.100.30` | | Active-active | every healthy address | the list without the failed address | The change applies to the **next query the authoritative server receives**, and only to that. An answer already handed out cannot be recalled. ## What bounds how fast clients follow 1. **Detection.** The checker needs several consecutive failed probes before it declares an endpoint down, to avoid flapping on one lost probe. The probe interval and the failure threshold are configuration, not protocol, and together often add up to tens of seconds. 2. **Caches between the server and the client.** Recursive resolvers, forwarders and stub caches keep the old answer until its TTL expires. How to choose that TTL, and why some caches hold answers longer, is the caching topic's subject. 3. **Hosts and applications.** A process may keep a resolved address, or an open connection, well beyond the DNS answer's lifetime. 4. **Client fallback.** Whether a client tries another address after a failed connection is up to the client; RFC 1123 §2.3 says applications SHOULD try multiple addresses until one succeeds. The time from failure until every client has moved is therefore detection, plus the longest cache hold, plus whatever the application does. Only the first term belongs to the steering logic. ## Why the answer's shape matters An **active-passive** answer gives each client exactly one address. When the primary dies, a client holding the cached answer has nothing else to try until the cache expires and a fresh lookup returns the secondary. An **active-active** answer gives clients a list. When one address fails, a client that walks the list connects to another address at once, from the answer it already holds. For such clients failover happens at connection-timeout speed, and the authoritative withdrawal merely stops *new* lookups from including the dead address. The price is that every listed endpoint must be able to take traffic at all times. ## When nothing is healthy If every endpoint fails its checks, or the checker loses its own connectivity and only believes they have, the steering logic must still answer something: - **Return no records.** `NOERROR` with an empty answer section is a **NODATA** response. Resolvers may cache it as a negative answer, and per RFC 2308 its negative TTL is the lesser of the SOA record's own TTL and the SOA `MINIMUM` field. After the endpoints recover, clients behind those resolvers can keep getting no address until that entry expires. - **Fail open.** Return all configured addresses, on the reasoning that a partly working service beats an empty answer and that a fault in the checker is a real possibility. This is a common implementation choice. - **Return `NXDOMAIN`.** Worse than either: it says the name does not exist at all, for every record type, and it is negatively cached too. ## Checker vantage versus user vantage - A checker in one network can see an endpoint as down while users reach it, or the reverse. - Probing from several locations and requiring a quorum reduces false failovers. - A checker's own outage should never be able to empty every answer, which is one more argument for failing open. ## Summary The authoritative server's answers change at the first query after detection; everything after that is bounded by caches and clients the server does not control. Give clients more than one address where you can, decide deliberately what to return when nothing is healthy, and measure failover time from the client's side, not from the checker's log.