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

Новый поддомен уже добавлен в DNS, но часть пользователей по-прежнему получает ответ «имя не существует». Повторное сохранение той же записи обычно не объясняет расхождение. Резолвер мог запомнить прежний отрицательный ответ — ещё до появления записи. Сначала нужно сравнить ответ авторитетного сервера с ответом резолвера, которым пользуется проблемная сторона.

Инструкция относится к установленной утилите dig из BIND 9.18; синтаксис сверён с документацией 9.18.41 на 27 сентября 2026 года. Нужен обычный доступ к командной строке Linux и разрешённые DNS-запросы к выбранным серверам. Права администратора для этих запросов не требуются. Стендового воспроизведения отрицательного кэша здесь не проводилось. Команды только запрашивают DNS; они не меняют зону и не очищают кэш.

Ответ со статусом NXDOMAIN означает, что запрошенного имени не существует в контексте полученного ответа. Успешный статус NOERROR без записи нужного типа — другая ситуация. Например, отсутствие AAAA ещё не говорит об отсутствии A. Ошибка SERVFAIL также не доказывает отрицательное кэширование отсутствующего имени: она требует отдельного разбора.

Для проверки понадобятся три значения. NAME — полное имя, заканчивающееся точкой; RESOLVER_IP — адрес резолвера проблемного клиента; AUTH_IP — адрес авторитетного сервера нужной зоны. Это заглушки: замените их своими значениями до запуска. Адрес авторитетного сервера уточните у администратора зоны. Не выбирайте произвольный публичный резолвер для внутренней корпоративной зоны.

dig @RESOLVER_IP NAME A +noall +comments +answer +authority

Здесь A задаёт тип записи, +noall убирает выводимые по умолчанию секции, а следующие параметры возвращают комментарии с заголовком ответа, секцию ответа и секцию авторитетных данных. В заголовке найдите статус. В секции AUTHORITY отрицательного ответа ищите запись SOA. Сохраните весь результат, время с часовым поясом и адрес, который подставили в команду.

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

dig @AUTH_IP NAME A +norecurse +noall +comments +answer +authority

Параметр +norecurse снимает запрос рекурсии. Проверьте признак авторитетного ответа aa в заголовке: одного адреса сервера недостаточно, чтобы считать результат ответом нужной зоны. Если получена отсылка, отказ или ответ без нужного признака, сравнение пока не завершено. У зоны может быть несколько авторитетных серверов; расхождение между ними нужно выяснить отдельно.

Допустим, авторитетные серверы уже возвращают новую запись, а выбранный резолвер — NXDOMAIN с записью SOA. Это совместимо с сохранённым отрицательным ответом. Но сравнение имеет смысл только для одного имени, типа записи и одной области видимости DNS. Разные корпоративные представления зоны способны законно давать разные ответы.

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

У отрицательного ответа тоже есть срок хранения. Согласно RFC 2308, при формировании такого ответа берётся меньшее из двух значений: TTL записи SOA и её поля MINIMUM. В кэшированном ответе TTL уменьшается по мере хранения. Поэтому TTL новой положительной записи нельзя использовать как таймер ранее сохранённого отрицательного ответа.

Учебный расчёт: TTL записи SOA равен 900 секундам, поле MINIMUM — 300. Исходный срок отрицательного ответа составит 300 секунд. Если конкретный резолвер сохранил его 120 секунд назад, в простой модели без повторного получения ответа останется около 180 секунд. Запись, созданная минуту назад с TTL 60 секунд, сама по себе не уменьшит эти 180 секунд.

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

После ожидаемого истечения срока повторите запрос тем же способом. Появление записи у выбранного резолвера подтверждает изменение его ответа. Затем проверьте приложение: браузер с собственным DNS, корпоративный агент или контейнер могут использовать иной путь. Исправный ответ одной утилиты не доказывает доступность сайта, сертификата и приложения.

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

The new subdomain has already been added to DNS, but some users still receive an "name does not exist" response. Re-saving the same record usually does not explain the discrepancy. The resolver may have cached the previous negative response before the record appeared. First, compare the authoritative server's response with the resolver's response used by the problematic party.

This instruction applies to the installed utility dig from BIND 9.18; syntax verified against documentation 9.18.41 as of September 27, 2026. Standard Linux command-line access and permitted DNS queries to selected servers are required. Administrator privileges are not needed for these queries. No testbed reproduction of negative caching was performed here. The commands only query DNS; they do not modify the zone or clear the cache.

A response with status NXDOMAIN means the requested name does not exist in the context of the received response. A successful status NOERROR without a record of the required type is a different situation. For example, the absence of AAAA does not necessarily indicate the absence of A. An error SERVFAIL also does not prove negative caching of a missing name; it requires separate analysis.

Three values are required for verification. NAME is the full name ending with a dot; RESOLVER_IP is the resolver address for the problematic client; AUTH_IP is the authoritative server address for the required zone. These are placeholders: replace them with your own values before running. Confirm the authoritative server address with the zone administrator. Do not select an arbitrary public resolver for an internal corporate zone.

dig @RESOLVER_IP NAME A +noall +comments +answer +authority

Here, A sets the record type, +noall removes the sections output by default, and the following parameters return the response header comments, the answer section, and the authoritative data section. Find the status in the header. In the AUTHORITY section of the negative response, look for the SOA record. Save the entire result, the timestamp with time zone, and the address you substituted into the command.

The query performs a network operation and may contact the resolver cache or trigger further name resolution. A few manual queries are sufficient; continuous polling is not required. The timeout is not NXDOMAIN: if the server does not respond or access is denied, stop and verify access using standard methods.

dig @AUTH_IP NAME A +norecurse +noall +comments +answer +authority

The +norecurse parameter disables recursion. Check the authoritative answer flag aa in the header: a single server address is insufficient to treat the result as an answer for the target zone. If a referral, refusal, or an answer lacking the required flag is received, the comparison is not yet complete. A zone may have multiple authoritative servers; discrepancies between them must be investigated separately.

Suppose the authoritative servers already return the new record, while the selected resolver returns NXDOMAIN with record SOA. This is consistent with a cached negative response. However, comparison is meaningful only for a single name, record type, and one DNS scope. Different corporate views of the zone can legally provide different answers.

If an authoritative server itself returns NXDOMAIN, waiting for the client cache to clear will not fix the missing record in the zone view being checked. Provide the administrator with exactly this result, not a request to "speed up DNS updates".

Negative responses also have a time-to-live. According to RFC 2308, when forming such a response, the smaller of two values is taken: the TTL of the SOA record and its MINIMUM field. In a cached response, the TTL decreases over time. Therefore, the TTL of a new positive record cannot be used as a timer for a previously stored negative response.

Sample calculation: the TTL of the SOA record is 900 seconds, and the MINIMUM field is 300. The initial negative response time-to-live will be 300 seconds. If a specific resolver stored it 120 seconds ago, in a simple model without re-fetching the response, about 180 seconds will remain. A record created a minute ago with a TTL of 60 seconds does not reduce those 180 seconds on its own.

This is an example of a mechanism, not a guarantee of recovery time for all users. Two resolvers might have received a negative response at different times; an application may access via a different path. From a single snapshot, it is unknown when a specific cache received the response. If you repeat the request, compare the same server and note the elapsed time.

After the expected expiration time, repeat the request using the same method. The appearance of a record at the selected resolver confirms a change in its response. Then check the application: a browser with its own DNS, a corporate agent, or a container may use a different path. A correct response from one utility does not prove the availability of the site, the certificate, or the application.

To report the issue, provide the exact name and type, the addresses of the queried servers, the timestamps, the status codes, and the SOA record from the negative response. Transmit internal names and addresses only via an authorized channel. This set of data distinguishes a delay caused by a known cache from a zone error and avoids the need to start diagnostics by clearing everything indiscriminately.