DIG online: как проверить DNS-запись на выбранном сервере
После изменения DNS панель хостинга показывает новый адрес, но сайт у части посетителей по-прежнему открывается со старого сервера. Общий просмотр записей подтвердит, что опубликовано сейчас, а для точной проверки нужен другой вопрос: что отвечает конкретный DNS-сервер?
DIG online на 2whois выполняет настоящий системный запрос `dig`. Вы выбираете домен, тип записи и DNS-сервер, а сервис показывает найденные значения и полный ответ команды. Устанавливать BIND или открывать терминал не нужно.
Что делает команда DIG
DIG запрашивает у DNS-сервера запись определенного типа. В обычной командной строке запрос выглядит так:
dig @8.8.8.8 monitorus.ru MXПосле символа @ указан сервер, затем имя и тип записи. Такой запрос не просит показать «весь DNS домена». Он задает один точный вопрос: какую MX-запись сервер 8.8.8.8 возвращает для monitorus.ru.
На 2whois те же три параметра находятся в форме:
- домен или IP — имя для запроса; IP используется при выборе PTR;
- тип записи — A, MX, TXT, NS, CAA, DS или другой поддерживаемый тип;
- DNS-сервер — публичный IP либо имя сервера, который должен ответить.
Если сервер не указывать, 2whois использует публичный DNS, заданный в настройках сервиса. Сейчас в форме по умолчанию стоит 8.8.8.8.
Чем DIG отличается от DNS и NSLOOKUP
Вкладка DNS подходит для первого знакомства с доменом: она собирает основные A, AAAA, MX, NS, TXT и SOA в одной таблице. Это удобно, когда еще неизвестно, где искать проблему.
NSLOOKUP online проверяет путь к записи: DNS-серверы из WHOIS, делегирование в родительской зоне и ответы авторитетных серверов. Он отвечает на вопрос, правильно ли домен подключен к DNS.
DIG нужен, когда вопрос уже сформулирован точно. Например: видит ли Google DNS новый IP, отвечает ли конкретный сервер на TXT-запрос или одинаковый ли MX возвращают два резолвера.
Как читать результат DIG
Верхняя часть результата 2whois сразу показывает сервер, тип записи, количество найденных значений и статус. Ниже можно раскрыть полный ответ команды. В нем полезны несколько строк и секций.
| Поле | Что показывает | На что смотреть |
|---|---|---|
| status | Код результата DNS-запроса | NOERROR, NXDOMAIN, SERVFAIL или REFUSED |
| QUESTION | Какой вопрос фактически отправлен | Имя, класс IN и выбранный тип записи |
| ANSWER | Найденные записи | Значение, тип и TTL каждой строки |
| AUTHORITY | Сведения об авторитетной зоне | NS или SOA, особенно при пустом ответе |
| SERVER | Кто прислал ответ | IP и порт должны соответствовать выбранному серверу |
| Query time | Время конкретного запроса | Резкий рост или тайм-аут, но не единичную разницу в миллисекундах |
Что означают статусы ответа
NOERROR и записи найдены
DNS-сервер обработал запрос, а в секции ANSWER есть одна или несколько строк нужного типа. Это обычный успешный результат.
NOERROR, но ANSWER пуст
Имя существует, однако записи выбранного типа для него нет. Например, у домена может быть A, но не быть AAAA. Такой ответ называют NODATA. Он отличается от несуществующего домена.
NXDOMAIN
Запрошенного имени не существует с точки зрения ответившей DNS-системы. Если домен только что создали или изменили делегирование, стоит сравнить несколько серверов и отдельно проверить NSLOOKUP.
SERVFAIL
Сервер не смог завершить обработку. Причиной бывает недоступность авторитетных серверов, ошибка DNSSEC или другой сбой по пути к ответу. Повтор того же запроса через другой резолвер помогает понять, локальна ли проблема.
REFUSED
Сервер получил запрос, но отказался его выполнять. Так часто отвечают DNS-серверы, которые не разрешают рекурсивные запросы посторонним клиентам.
Пример: MX и TXT для monitorus.ru
17 августа 2026 года запрос MX для monitorus.ru через Google DNS вернул одну запись:
monitorus.ru. 3600 IN MX 0 emx.mail.ru.Статус был NOERROR, TTL — 3600 секунд. Число 0 перед именем — приоритет MX, а emx.mail.ru. — почтовый сервер домена.
Тот же запрос через 1.1.1.1 показал ту же запись. Время ответа в двух конкретных проверках различалось: 142 мс у Google DNS и 15 мс у Cloudflare. По одному измерению нельзя делать вывод, что один сервис всегда быстрее другого: на результат влияют маршрут, кэш и текущая нагрузка.
TXT-запрос через 8.8.8.8 вернул четыре записи: SPF, подтверждения Google и Яндекса и отдельный служебный идентификатор. Это хороший пример того, почему тип нужно выбирать осознанно: MX показывает маршрут почты, а TXT — правила и подтверждения, хотя запрос выполняется для одного домена.
Зачем указывать конкретный DNS-сервер
Проверить распространение изменений
После замены A или MX старое значение может оставаться в кэше до окончания TTL. Выполните одинаковый запрос через несколько публичных резолверов, а затем — через авторитетные серверы домена. Если авторитетный сервер уже отдает новое значение, а публичный еще старое, вероятнее всего, нужно дождаться обновления кэша.
Найти расхождение между серверами зоны
Запросите одну запись по очереди у каждого авторитетного NS. Ответы должны совпадать по значению; TTL может немного отличаться из-за особенностей кэша только у рекурсивных серверов. Разные значения на авторитетных NS обычно указывают на несинхронизированную зону.
Проверить почту или подтверждение сервиса
Для почты запрашивают MX, SPF и другие TXT-правила. Если задача не ограничивается одной записью, используйте проверку почты домена: она связывает MX, SPF, DKIM, DMARC и дополнительные настройки в один результат.
Посмотреть записи безопасности
CAA сообщает, каким центрам разрешено выпускать сертификаты для домена. DS и DNSKEY участвуют в DNSSEC, TLSA — в DANE, SSHFP хранит отпечаток ключа SSH. DIG покажет опубликованные значения, но само наличие записи еще не доказывает правильность всей цепочки DNSSEC или настройки службы.
Какие ограничения есть у DIG online
2whois разрешает обращаться только к публичным DNS-серверам. Локальные, частные и служебные IP блокируются, чтобы форму нельзя было использовать для запросов во внутреннюю сеть сервера.
В списке нет ANY и AXFR. ANY не гарантирует выдачу всех записей и часто получает минимальный ответ, а AXFR предназначен для передачи зоны между разрешенными серверами, а не для публичной проверки. Тип version отправляет служебный запрос version.bind; многие серверы намеренно не раскрывают версию, и это нормальная настройка.
Как выполнить DIG-запрос онлайн
Откройте DIG online, введите домен, выберите тип записи и оставьте публичный DNS по умолчанию либо укажите нужный сервер. Сначала посмотрите статус и количество записей, затем раскройте результаты запроса и сверьте секции QUESTION и ANSWER.
Если ответа нет, не меняйте сразу настройки домена. Повторите тот же тип через другой резолвер, запросите авторитетный DNS и сравните результат с NSLOOKUP. Именно одинаковый вопрос к разным серверам обычно показывает, где находится проблема: в зоне, в делегировании или только в кэше.
