Новую DNS-запись добавили, а NXDOMAIN остался: разбираем отрицательный кэш

Для нового стенда заранее проверили адрес, получили NXDOMAIN, затем добавили запись. Авторитетный DNS уже отвечает правильно, но рабочий резолвер по-прежнему утверждает, что имени нет. Положительная запись получила TTL в минуту, и инженер ждёт минуту без результата. Причина в том, что старый отрицательный ответ живёт по другим параметрам.

Прочитайте ответ целиком

dig @192.0.2.53 review.example.org A
dig @ns1.provider.example review.example.org A +norecurse
dig @ns1.provider.example example.org SOA +norecurse

В первом ответе смотрите статус и секцию AUTHORITY. NXDOMAIN означает отсутствие запрошенного имени. У существующего имени может отсутствовать только запись выбранного типа: это другой отрицательный результат, часто называемый NODATA. Поэтому при проверке IPv4 не делайте вывод о полном отсутствии имени только по пустой секции ANSWER.

Для стандартного отрицательного кэширования существенна SOA зоны. Время хранения определяется с учётом TTL записи SOA и поля MINIMUM. В уже полученном отрицательном ответе резолвер показывает оставшийся срок, а не TTL только что созданной A-записи. Быстрое создание имени не обязано немедленно отменять прежний NXDOMAIN.

Убедитесь, что источник исправлен

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

Допустим, авторитетный ответ содержит новую A-запись, а резолвер выдаёт NXDOMAIN с SOA и оставшимся TTL 240. Через минуту отрицательный TTL уменьшился примерно на минуту. Это согласуется с ожидающим кэшем. Новый TTL положительной записи в 60 секунд здесь ещё не участвует: резолвер пока не запросил её заново.

Не создавайте цепочку переименований стенда в попытке «пробить DNS». Каждое новое имя запускает отдельную историю кэшей и усложняет диагностику. Плановый запуск проще организовать так: сначала опубликовать записи, проверить их непосредственно у авторитетных серверов, после этого отдавать имя пользователям.

Верните предсказуемость проверке

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

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

Для отчёта сохраните первоначальный статус, SOA из отрицательного ответа и последующий положительный ответ источника. Эти данные объясняют задержку точнее, чем фраза «DNS распространяется», и позволяют спланировать следующий запуск стенда без повторения ситуации.

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

Ещё по теме

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