Как проверить DNS-запись через dig и правильно прочитать ответ

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

Запрос проверяет записи IPv4. Для IPv6 выполните отдельную проверку:

Имя основной страницы и имя с дополнительным поддоменом могут иметь разные записи. Не переносите вывод одной проверки на все адреса сайта.

В полном ответе важны статус, секция ответа, TTL и сервер, к которому обращалась утилита. Статус отсутствующего имени отличается от успешного ответа без записей запрошенного типа. Например, отсутствие IPv6-записи не означает, что у имени нет IPv4-адреса.

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

Фрагмент ответа на запрос A:

У того же имени запрос CNAME вернул NOERROR, но без записей запрошенного типа. Фрагмент полного ответа:

В секции AUTHORITY была запись SOA. Сочетание статуса, отсутствия подходящих ответов и SOA позволило распознать NODATA: для запрошенного типа данных нет. Одного ANSWER: 0 недостаточно — такой ответ нужно отличить от перенаправления к другим DNS-серверам. Наличие A-записей у этого же имени уже подтверждено предыдущим запросом.

Третий запрос к заведомо недействительному имени вернул:

Все три вызова dig завершились с кодом 0, включая NXDOMAIN. Код процесса подтверждает получение DNS-ответа в этих вызовах; вывод «имя существует и нужная запись найдена» нужно делать по статусу и секциям, а не по одному $? или пустому +short.

Когда контекст известен, ответ можно сократить, оставив комментарии и записи:

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

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

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

Даже правильный адрес не подтверждает, что веб-сервер принимает соединения и отдаёт нужный виртуальный хост. После DNS отдельно проверяют соединение, сертификат и ответ приложения. И наоборот: открытая по IP страница не доказывает правильность DNS и маршрутизации доменного имени.

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

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

After migrating a site, one computer opens the new version while another opens the old one. The cause may be DNS, but first you must obtain a verifiable response: which name is being queried, which record type is needed, and which server returned the result. A brief "domain not working" is too vague for diagnostics.

The query checks IPv4 records. For IPv6, perform a separate check:

The main page name and the name with an additional subdomain may have different records. Do not transfer the output of one check to all site addresses.

In a full response, the status, answer section, TTL, and the server the utility contacted are important. The status for a non-existent name differs from a successful response with no records of the requested type. For example, the absence of an IPv6 record does not mean the name lacks an IPv4 address.

A request processing error is also not equivalent to a non-existent domain. It may be related to zone maintenance, DNSSEC validation, or the unavailability of a dependency. To draw correct conclusions, preserve the full status rather than just an empty string from the shortened mode.

Fragment of the response to an A query:

The same name queried for a CNAME returned NOERROR, but without records of the requested type. Fragment of the full response:

The AUTHORITY section contained an SOA record. The combination of status, the absence of matching answers, and the SOA record allowed recognition of NODATA: there are no records of the requested type. An ANSWER count of 0 is insufficient; such a response must be distinguished from a referral to other DNS servers. The presence of A records for this same name was already confirmed by the previous query.

The third query to a known invalid name returned:

All three dig calls completed with exit code 0, including NXDOMAIN. The process code confirms that a DNS response was received in these calls; the output 'name exists and the required record was found' must be determined by status and sections, not by a single $? or an empty +short output.

When the context is known, the response can be shortened, leaving only comments and records:

This option is convenient for comparison but does not replace full diagnostics for an unknown error. If you need to check another DNS server, use it only with a clear reason and authorized access. Public and corporate resolvers may return different DNS data. For an internal corporate zone, use the organization's authorized resolver: the response from a public server does not replace verification within the corporate network.

TTL is tied to the response caching time. Reducing the value in the zone does not instantly erase previously cached responses in all caches. Therefore, when migrating, you must consider settings before the change, not promise all users an immediate switch at a specific second.

Example: two resolvers return different addresses after a record change. Record their responses, time, and TTL, then compare them with the zone's authoritative data. The difference may be due to caching, but also to different settings or geographic responses. Without these details, you cannot confidently identify the cause.

Even a correct address does not confirm that the web server accepts connections and serves the intended virtual host. After DNS resolution, the connection, certificate, and application response must be checked separately. Conversely, a page accessible via IP does not prove correct DNS or domain name routing.

To submit to support, save the name, record type, status, resolver address, and check time. After making changes, repeat the query in the same environment. This data set helps distinguish zone errors from cache issues and problems occurring entirely outside DNS.

When comparing responses, preserve the case of the presentation separately from the meaning of the name and pay attention to the alias chain. The final address may refer to the CNAME target rather than being a direct record of the original name.