DNS, который не врёт в три часа ночи
Записи, TTL и cutover, которые держат миграции спокойными — и проверки до правок в проде.
DNS-инциденты кажутся мистикой, пока записи не становятся контрактами. Тогда большинство «загадок» — это математика TTL и пропущенные проверки.
Сначала план cutover
До любых живых правок:
- Инвентаризируйте все имена, которые должны резолвиться после переезда.
- Зафиксируйте стратегию TTL на окно заморозки.
- Явно назовите набор записей для rollback.
TTL — это расписание
Если TTL равен секундам, планируйте так, будто клиенты могут кэшировать ответ ещё целые после публикации. Это и есть длина cutover — не момент нажатия «Save».
Проверки, которые ловят ложь рано
# Смотрите ответ с разных резолверов
dig +short api.example.com @1.1.1.1
dig +short api.example.com @8.8.8.8
# Убедитесь, какую authority вы реально правите
dig NS example.com +shortИ проверьте HTTPS с health через новое имя, прежде чем отпускать старое.
Типичные failure modes
| Симптом | Частая причина |
|---|---|
| У половины мира «ок» | Stale cache + смешанные записи |
| Ошибки сертификата | Имя живое раньше, чем cert его покрывает |
| «У меня работает» | Локальный резолвер ещё на старом ответе |
Итог
DNS скучен, когда есть план. Держите план на виду, TTL — честными, а cutover — не на надежде.