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

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

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

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

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

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

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

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

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

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

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

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

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

After migrating a site, one computer loads the new version while another loads 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" message is too vague for diagnostics.

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

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

A full response requires the status, response section, TTL, and the server the utility contacted. The status for a missing 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 missing domain. It may relate to zone maintenance, DNSSEC validation, or dependency unavailability. To draw correct conclusions, preserve the full status rather than just an empty string from the abbreviated mode.

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. A public resolver cannot see an internal corporate zone any more than a corporate resolver can.

TTL relates to the response caching time. Reducing the value in the zone does not instantly erase previously cached responses across all caches. Therefore, during a migration, you must account for settings before the change, rather than promising all users an immediate switch at a specific second.

Example: two resolvers return different addresses after a record change. Record their responses, timestamps, and TTLs, then compare them with the zone's authoritative data. The discrepancy may stem from caching, but also from different configurations 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, you must separately verify the connection, the certificate, and the application response. Conversely, a page accessible via IP does not prove the correctness of DNS or the domain name routing.

To submit a ticket to support, save the name, record type, status, resolver address, and check timestamp. After making changes, repeat the query in the same environment. This data set helps distinguish a zone error from a cache issue or a problem entirely outside DNS.

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