# DNS Failover: автопереключение на резервный сервер

> DNS Failover меняет A-запись на резервный сервер при сбое основного, но скорость переключения упирается в TTL и кэш резолверов.

## Что такое DNS Failover

DNS Failover — это автоматическая замена IP-адреса в A или AAAA-записи, когда основной сервер перестаёт отвечать. Специальный мониторинг постоянно опрашивает основной хост, и при обнаружении сбоя система переписывает запись зоны на резервный сервер без участия человека. Это дешёвая альтернатива балансировщику нагрузки для сайтов, которым не нужна постоянная работа двух серверов одновременно, а нужна только страховка на случай отказа основного.

Технология не заменяет резервное копирование и не спасает от потери данных — она решает только задачу доступности домена, пока основная инфраструктура восстанавливается.

## Как работает проверка доступности

В основе DNS Failover — health check: внешний агент раз в 10–60 секунд обращается к серверу по HTTP, TCP или ping и ждёт корректного ответа. Настройка обычно выглядит так:

```
check_type: http
url: https://example.com/health
interval: 30s
timeout: 5s
failures_before_switch: 3
```

Порог в несколько подряд неудачных проверок (в примере — 3) нужен, чтобы не переключаться на резерв из-за одной случайной задержки в сети. После срабатывания порога система заменяет A-запись на IP резервного сервера и ждёт возврата основного к жизни, чтобы переключить обратно.

## Настройка низкого TTL для быстрого переключения

Скорость, с которой посетители увидят новый IP, определяется значением TTL записи, а не скоростью самого мониторинга. Пока старое значение живёт в кэше резолвера у провайдера пользователя, тот продолжит стучаться в упавший сервер. Для доменов с Failover TTL обычно снижают до 60–300 секунд:

```
example.com. 60 IN A 203.0.113.10
```

Подробно про выбор значения TTL и его влияние на скорость обновления — в статье [про настройку TTL](https://www.zevshost.net/ru/kb/ttl-dns-nastroika/). Здесь важно помнить компромисс: слишком низкий TTL увеличивает число запросов к DNS-серверам и немного повышает задержку резолвинга, слишком высокий — тормозит переключение при сбое.

## DNS Failover и Anycast: в чём разница

DNS Failover и Anycast решают похожую задачу — доступность сервиса — но разными способами. Failover меняет содержимое записи и зависит от TTL и скорости обновления кэшей резолверов по всему миру, поэтому переключение занимает минуты. [Anycast](https://www.zevshost.net/ru/kb/anycast-geodns/) отдаёт один и тот же IP с нескольких точек присутствия одновременно, а маршрутизация на уровне BGP сама уводит трафик от упавшего узла — переключение происходит на уровне сети, а не DNS, и укладывается в секунды.

Anycast сложнее и дороже в развёртывании, поэтому для небольших проектов DNS Failover остаётся разумным компромиссом между стоимостью и временем простоя.

## Ограничения и подводные камни

| Проблема | Почему возникает |
| --- | --- |
| Часть пользователей ещё видит старый IP | Резолвер провайдера держит запись дольше TTL, игнорируя его |
| Ложное переключение | Здоровье проверялось с одной точки, а сеть моргнула локально |
| Переключение произошло, но сайт всё равно недоступен | На резервном сервере не синхронизированы данные или конфигурация |
| Переключение назад не происходит | Основной сервер отвечает на health check, но приложение на нём всё ещё сломано |

## Чек-лист внедрения DNS Failover

- Настройте health check по тому же протоколу, что использует реальный трафик, а не просто ping.
- Снизьте TTL записи заранее, за сутки до включения Failover, чтобы старые значения выпали из кэшей.
- Держите резервный сервер с актуальными данными и конфигурацией, а не только с установленным ПО.
- Проверяйте переключение через [dig с разных резолверов](https://www.zevshost.net/ru/kb/proverka-dns-zony-dig/), а не только с одного устройства.
- Настройте порог в несколько неудачных проверок подряд, чтобы избежать ложных срабатываний.

---

Источник: https://www.zevshost.net/ru/kb/dns-failover-pereklyuchenie/