Мониторинг сайтов · 6 мин · обновлено 2026-09-17

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

Запись нового поддомена уже появилась на авторитетных DNS-серверах, но рекурсивный резолвер всё ещё возвращает NXDOMAIN. Разбираем, как отличить отрицательный кэш от ошибки зоны и что делать безопасно.

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

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

Что такое отрицательный DNS-кэш

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

По RFC 2308 отрицательный ответ содержит SOA зоны, а время его хранения определяется меньшим из TTL записи SOA и поля MINIMUM в SOA. Когда этот срок истекает, резолвер должен запросить данные заново.

Важно различать два ответа:

NXDOMAIN — не существует само запрошенное имя;
NOERROR с пустым разделом Answer — имя существует, но у него нет записи запрошенного типа, например A.

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

Проверка по шагам

1. Зафиксируйте точное имя и тип записи

Проверяйте полный адрес без сокращений: new.example.com. Уточните, что должно быть опубликовано: A, AAAA или CNAME. Отдельно проверьте опечатку, лишнюю точку в панели и автоматическое добавление имени зоны DNS-провайдером.

Сначала узнайте авторитетные серверы:

dig example.com NS +short

Не начинайте с очистки браузера: пока неизвестно, опубликована ли запись в самой зоне, это только скроет причину.

2. Опросите каждый авторитетный NS напрямую

Запросите нужный тип у каждого сервера из списка:

dig @ns1.example.net new.example.com A +norecurse
dig @ns2.example.net new.example.com A +norecurse

Исправное состояние — одинаковый положительный ответ на всех авторитетных NS. Если один сервер уже видит запись, а другой отвечает NXDOMAIN, это не отрицательный кэш клиента, а рассинхронизация зоны. Сравните SOA serial на каждом NS и проверьте передачу зоны или публикацию у DNS-провайдера.

Если все авторитетные серверы возвращают NXDOMAIN, ищите ошибку в самой конфигурации: запись создана не в той зоне, имя введено неверно, изменения не опубликованы либо домен делегирован на другие NS.

3. Сравните рекурсивные резолверы

Теперь спросите локальный резолвер и несколько независимых публичных резолверов:

dig new.example.com A
dig @1.1.1.1 new.example.com A
dig @8.8.8.8 new.example.com A

Картина «авторитетный NS отвечает A, один рекурсивный резолвер отвечает NXDOMAIN» указывает на отрицательный кэш именно на этом пути. Если публичные резолверы уже отвечают правильно, а ошибка осталась на одном компьютере, проверьте локальный DNS-кэш, браузерный DNS-кэш, VPN и DNS over HTTPS.

Не называйте любое различие «распространением DNS». Этот ярлык не показывает, где находится старый ответ: в авторитетной зоне, у рекурсивного резолвера или на устройстве.

4. Посмотрите SOA и оставшийся TTL

Чтобы увидеть код ответа и служебный раздел, выполните:

dig @RESOLVER new.example.com A +noall +comments +answer +authority

При закэшированном отрицательном ответе в разделе Authority обычно присутствует SOA. Число TTL перед полями SOA уменьшается по мере жизни записи в кэше и помогает оценить, когда резолвер сможет запросить имя заново. Не путайте его с TTL новой A- или CNAME-записи: положительной записи в кэше этого резолвера ещё нет.

5. Отделите DNS от HTTPS

После положительного DNS-ответа проверьте сам адрес:

curl -I https://new.example.com/

Если имя уже разрешается, но браузер показывает ошибку сертификата, редирект на другой хост или код 4xx/5xx, отрицательный DNS-кэш больше не является основной причиной. Дальше проверяйте сертификат для нового имени, конфигурацию виртуального хоста, CDN и приложение.

Как трактовать результат

| Авторитетные NS | Рекурсивный резолвер | Вывод | |---|---|---| | Все отвечают NXDOMAIN | NXDOMAIN | Запись не опубликована или создана не в той зоне | | Отвечают по-разному | Ответы различаются | Рассинхронизация зоны или ошибка передачи | | Все отдают запись | Часть отвечает NXDOMAIN | Отрицательный кэш у конкретных резолверов | | Все отдают запись | Все отдают запись | Ищите локальный кэш либо проблему HTTPS и приложения |

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

Что делать безопасно

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

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

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

Ограничения проверки

dig +trace полезен для просмотра пути делегирования, но он обходит обычный рекурсивный путь пользователя и сам по себе не покажет кэш его провайдера. Устройство также может использовать DNS over HTTPS, VPN или корпоративный резолвер вместо сервера из системных настроек.

В DNSSEC-зонах резолверы могут дополнительно использовать доказательства отсутствия имён из NSEC или NSEC3. Поэтому при расхождении результатов важно сохранить полный ответ с кодом, SOA и DNSSEC-данными, а не только строку с IP.

Практический следующий шаг

Повторите три проверки в одном порядке: каждый авторитетный NS, проблемный рекурсивный резолвер, затем HTTPS по новому имени. Эта последовательность показывает, нужно ли исправлять зону, ждать TTL или переходить к веб-серверу.

Web-Puls помогает регулярно проверять публичный URL после появления записи. Если авторитетные и рекурсивные ответы расходятся и нужно разобрать DNS-цепочку без изменений наугад, отправьте заявку на профессиональную диагностику.