DNS после изменения записи: сравниваем авторитетный сервер и резолвер

Адрес сайта изменили, но часть клиентов продолжает подключаться к прежнему серверу. Совет «подождать DNS» слишком неточен: ошибочная запись может оставаться на одном авторитетном сервере, а корректная — лежать в кэше резолвера с ещё не истёкшим TTL. Эти ситуации требуют разных действий и сроков.

Найдите источник записи

dig example.org NS
dig @ns1.provider.example app.example.org A +norecurse
dig @ns2.provider.example app.example.org A +norecurse

Имена серверов условные. Возьмите NS своей зоны и проверьте каждый обслуживающий её сервер. У ответа авторитетного сервера обычно будет флаг AA. Если получена делегация, отказ либо ответ не от нужной зоны, уточните цепочку: запрос к случайному DNS-серверу не превращает его в источник истины.

При изменении имени через CNAME проверьте и псевдоним, и конечную запись. У них отдельные TTL, а конечный адрес может находиться в другой зоне. Иначе вы сравните одинаковый CNAME и пропустите устаревший адрес его цели. Сохраните всю секцию ANSWER, чтобы не потерять этот переход.

Сравните ответ клиентского резолвера

dig @192.0.2.53 app.example.org A
dig @192.0.2.53 app.example.org AAAA

Используйте резолвер проблемного клиента. Публичный резолвер удобен как независимое наблюдение, но не объясняет ответ внутри корпоративной сети. Запишите адреса и оставшийся TTL. Если авторитетные серверы согласованы, а рекурсивный отдаёт прежнее значение, разница может соответствовать штатному кэшированию.

Например, оба авторитетных сервера уже показывают новый адрес, а корпоративный резолвер возвращает старый с оставшимися 180 секундами. Повторный запрос через минуту с меньшим TTL поддерживает гипотезу кэша. Если срок снова увеличился и адрес остался старым, исследуйте источники, пересылку запросов и возможные внутренние зоны.

Уменьшение TTL после изменения записи не сокращает срок жизни уже закэшированного ответа. Резолвер получил предыдущий TTL раньше. Для планового переезда низкий TTL устанавливают заранее, выдерживают прежний срок и только затем переключают адрес. После завершения миграции срок можно вернуть к обычному значению.

Выберите правильное действие

Если авторитетные серверы расходятся, проверьте публикацию зоны у провайдера и согласованность экземпляров. Ожидание клиентских кэшей не исправит источник неправильных данных. Если источники верны, оцените срок кэша и сохраните прежний сервер доступным на переходный период, когда это предусмотрено планом миграции.

Если dig показывает новый адрес, а приложение использует старый, переходите к собственному кэшу приложения. Долго живущее соединение тоже может оставаться на старом сервере без нового DNS-запроса. Повторное редактирование зоны здесь лишь добавит неопределённость.

Проверка завершена, когда вы можете показать, какие данные опубликованы, кто возвращает старое значение и почему оно ещё допустимо либо ошибочно. Такая запись превращает неопределённое ожидание в управляемый этап миграции.

Освойте DNS как часть сопровождения приложения. Программа Linux и Bash для DevOps-инженеров включает сеть, DNS и HTTP на учебном сервере. Откройте её, чтобы отработать переход от различающихся ответов к конкретному действию и понятной записи для команды.

Ещё по теме

• Сверить два инвентаря через comm: новые, исчезнувшие и общие записи
• Проверяем новый сервер до переключения DNS: curl --resolve с настоящим именем