Как проверить ответ dns сервера
Обновлено: 06.07.2024
Зачастую, в силу того, что информация в сети распространяется не мгновенно, привязанные к серверу домены начинают работать не сразу. Чтобы не тратить время впустую, ожидая обновления кеша DNS, желательно сразу проверить настройку вашего DNS-сервера и убедиться, что по истечении 72 часов (это максимальное время обновления глобального кеша DNS) ваш домен заработает.
Содержание
Whois
Начать диагностику следует с запроса whois:
Также следует обратить внимание на пункты "state" и "Status" (для доменов в зонах .com./.org): в поле "state" обязательно должны быть пометки REGISTERED и DELEGATED, в поле "Status" - "Ok". Для отсеивания всего лишнего из вывода whois можно использовать следующую команду:
Замечание: для доменов в зоне .com/.org следует обращать внимание только на первые две записи "Name Server".
Информация во whois может обновляться в течение трех часов, поэтому если вы уже приобрели домен, нужно некоторое время подождать. Это также касается смены NS-серверов домена.
dig +trace
dig - утилита, предоставляющая пользователю интерфейс командной строки для отправки запросов к DNS-серверам. Первый запрос, который нас интересует, - трассировка запросов к домену:
dig с NS-серверов
В этом случае мы запрашиваем информацию напрямую с NS-серверов, которые планируется использовать для указанного домена. Пример для запроса с ns1 (для ns2 запрос выглядит аналогично):
Здесь в секции ANSWER SECTION был возвращен IP, в который NS-сервер резолвит домен, при нормальной работе этот IP должны возвращать оба NS-сервера, если IP отличается от того, что вы назначили домену на основном сервере, то зона нуждается в обновлении. В ISPmanager, к примеру, это можно сделать кнопкой "Передать" в разделе "Доменные имена", если же у вас DNS-сервер настроен без использования панели, то зона, как правило, будет обновлена самостоятельно, либо по истечении TTL зоны, либо по запросу вторичного сервера имен, если используется механизм уведомлений (опция notify yes в BIND).
Также NS-сервер может вообще не ответить:
В этом случае следует убедиться, что внешний DNS-сервер доступен и на нем не заблокирован 53-й порт (если есть такая возможность).
Еще один вариант - пустой ответ:
Также при возникновении каких-либо проблем на NS-серверах следует произвести диагностику первичного DNS-сервера.
dig с первичного сервера имен
Служит для запроса информации непосредственно с сервера, на котором создан домен:
Приведенный вариант - то, как должен отвечать правильно настроенный DNS-сервер, в случае возникновения проблем следует перейти к более детальному изучению обстановки на корневом сервере имен.
Вся необходимая для диагностики информация о проблемах, возникшим в работе первичного сервера имен, содержится в логах. По умолчанию DNS-сервер пишет в системный лог /var/log/messages, однако в конфигурации может быть задано ведение логов в отдельном файле, поэтому следует свериться с конфигурацией вашего DNS-сервера. В этом разделе рассмотрены наиболее часто встречающиеся в логах ошибки.
dig возвращает пустой ответ
Пустой ответ означает то, что на VDS либо отсутствует файл зоны этого домена, либо то, что при подгрузке файла зоны возникли проблемы. Также причиной может быть отсутствие A-записи в файле зоны. Если в первом случае достаточно будет создать домен на сервере (через ISPmanager или с помощью ручной правки файла зоны, если ISPmanager отсутствует), то во втором потребуется изучить логи DNS-сервера.
Некорректные права/владелец
Первая ошибка, которую мы рассмотрим - permission denied:
Ошибка говорит о некорректных правах на файл зоны или о некорректном владельце файла:
В данном случае проблема именно с владельцем, им должен быть пользователь, от которого запущен bind:
Также следует обратить внимание на права и группу самой директории /etc/bind/:
Отсутствие A-записей для дочерних NS
Следующая ошибка в логе:
CNAME и другие записи
Еще одна достаточно распространенная ошибка:
Записи A и CNAME не могут одновременно сосуществовать для одного домена/поддомена:
После устранения всех ошибок в логе должна появиться следующая запись:
Однако, даже после этого мы можем получить пустой ответ на запрос утилитой dig. Тут вариантов не так много:
Отсутствие A-записи
По умолчанию утилита dig запрашивает именно A-запись домена, поэтому пустой ответ может означать, что эта запись отсутствует. Пример A-записи:
Тут стоит отметить, что в некоторых случаях необходимости в A-записи нет, и чтобы проверить, как отдается та или иная запись, нужно сообщить утилите dig тип запрашиваемой записи:
Замечание: для получения всех записей можно указать тип ANY, также полезным будет ключ +short, позволяющий выводить сокращенный ответ:
Запрещены запросы к DNS-серверу
В конфигурации DNS-сервера могут быть разрешены запросы только с определенных адресов (как правило, разрешаются запросы только со slave-сервера). В случае с DNS-сервером BIND это директива allow-query<>. В этом случае мы увидим в логе следующую запись:
Вариантов диагностики в этом случае два: либо временно добавить свой адрес в список разрешенных, либо делать запросы непосредственно с сервера, на котором расположен slave. Если slave настроен так, чтобы делать запросы не с основного IP на интерфейсе, утилите dig нужно будет указать ключ «-b xxx.xxx.xxx.xxx», где xxx.xxx.xxx.xxx – IP на интерфейсе, с которого разрешены запросы к master:
Connection timed out
Данный вывод говорит о том, что на сервере, с которого производится запрос информации о доменном имени, возникли проблемы. Это может быть как неработающий named, так и блокировка 53 порта с помощью файрвола.
Transfer failed
Эта ошибка говорит о том, что в конфигурации DNS-сервера запрещен трансфер зоны на адрес, с которого пришел запрос (директива allow-transfer<> в BIND). В плане диагностики проблема идентична ситуации с ограничением на запросы.
В этой статье описывается, как устранять неполадки на DNS-серверах.
Проверка IP-конфигурации
Выполните ipconfig /all команду из командной строки и проверьте IP-адрес, маску подсети и шлюз по умолчанию.
Проверьте, является ли DNS-сервер полномочным для имени, которое ищется. Если это так, см. раздел Проверка на наличие проблем с достоверными данными.
Выполните следующую команду.
Если вы получаете ответ об ошибке или истечении времени ожидания, см. раздел Проверка проблем с рекурсией.
Очистка кэша сопоставителя. Для этого выполните следующую команду в окне командной строки с правами администратора:
Или в окне администрирования PowerShell выполните следующий командлет:
Повторите шаг 3.
Проверка неполадок DNS-сервера
Журнал событий
Проверьте следующие журналы, чтобы узнать, есть ли записанные ошибки:
Тестирование с помощью запроса nslookup
Выполните следующую команду и проверьте, доступен ли DNS-сервер с клиентских компьютеров.
Если сопоставитель возвращает IP-адрес клиента, у сервера нет проблем.
Если сопоставитель возвращает ответ "сбой сервера" или "Запрос отклонен", зона может быть приостановлена или сервер может быть перегружен. Чтобы узнать, приостановлен ли он, перейдите на вкладку Общие окна свойств зоны в консоли DNS.
Если сопоставитель возвращает ответ "запрос на превышение времени ожидания сервера" или "нет ответа от сервера", возможно, служба DNS не запущена. Попробуйте перезапустить службу DNS-сервера, введя следующую команду в командной строке на сервере:
Если проблема возникает при запуске службы, сервер может не прослушивать IP-адрес, который использовался в запросе nslookup. На вкладке интерфейсы страницы свойств сервера консоли DNS администраторы могут ограничить DNS-сервер прослушиванием только выбранных адресов. Если DNS-сервер настроен для ограничения службы указанным списком настроенных IP-адресов, то возможно, что IP-адрес, используемый для связи с DNS-сервером, отсутствует в списке. Можно попробовать использовать другой IP-адрес в списке или добавить IP-адрес в список.
В редких случаях DNS-сервер может иметь расширенную конфигурацию безопасности или брандмауэра. Если сервер расположен в другой сети, доступной только через промежуточный узел (например, маршрутизатор фильтрации пакетов или прокси-сервер), DNS-сервер может использовать нестандартный порт для прослушивания и получения клиентских запросов. По умолчанию программа nslookup отправляет запросы на DNS-серверы через порт UDP 53. Поэтому, если DNS-сервер использует любой другой порт, запросы nslookup завершатся ошибкой. Если вы считаете, что это может быть проблема, проверьте, используется ли промежуточный фильтр для блокировки трафика на хорошо известных портах DNS. Если это не так, попробуйте изменить фильтры пакетов или правила портов в брандмауэре, чтобы разрешить трафик через порт UDP/TCP 53.
Проверка на наличие проблем с достоверными данными
Проверьте, является ли сервер, который возвращает неверный ответ, основным сервером для зоны (основным сервером-источником для зоны или сервером, который использует интеграцию Active Directory для загрузки зоны) или сервер, на котором размещена дополнительная копия зоны.
Если сервер является сервером-источником
Проблема может быть вызвана ошибкой пользователя при вводе пользователем данных в зону. Кроме того, это может быть вызвано проблемой, которая влияет на Active Directory репликацию или динамическое обновление.
Если на сервере размещается дополнительная копия зоны
Изучите зону на сервере-источнике (сервере, с которого этот сервер извлекает зоны).
Вы можете определить, какой сервер является сервером-источником, проверив свойства дополнительной зоны в консоли DNS.
Если на сервере-источнике указано неправильное имя, перейдите к шагу 4.
Если на сервере-источнике указано правильное имя, убедитесь, что серийный номер на сервере-источнике меньше или равен серийному номеру на сервере-получателе. Если это так, измените либо сервер-источник, либо сервер-получатель, чтобы серийный номер на сервере-источнике был больше, чем серийный номер на сервере-получателе.
На сервере-получателе выполните принудительную пересылку зоны с помощью консоли DNS или выполните следующую команду:
Изучите сервер-получатель еще раз, чтобы узнать, правильно ли передана зона. В противном случае у вас, вероятно, возникает проблема с переносом зоны. Дополнительные сведения см. в статье проблемы зонных передач.
Если зона была передана правильно, проверьте, правильно ли указаны данные. В противном случае данные в основной зоне неверны. Проблема может быть вызвана ошибкой пользователя при вводе пользователем данных в зону. Кроме того, это может быть вызвано проблемой, которая влияет на Active Directory репликацию или динамическое обновление.
Проверка проблем с рекурсией
Чтобы рекурсия работала успешно, все DNS-серверы, используемые в пути рекурсивного запроса, должны иметь возможность отвечать и пересылать правильные данные. Если это не так, рекурсивный запрос может завершиться ошибкой по одной из следующих причин:
Время ожидания запроса истекло, прежде чем его можно будет завершить.
Сервер, используемый во время запроса, не отвечает.
Сервер, используемый во время запроса, предоставляет неверные данные.
Начните устранение неполадок на сервере, который использовался в исходном запросе. Проверьте, пересылает ли этот сервер запросы на другой сервер, изучив вкладку серверы пересылки в свойствах сервера в консоли DNS. Если флажок включить серверы пересылки установлен и в списке присутствует один или несколько серверов, этот сервер перенаправляет запросы.
Если этот сервер пересылает запросы на другой сервер, проверьте наличие проблем, влияющих на сервер, на который сервер пересылает запросы. Чтобы проверить наличие проблем, см. раздел Проверка неполадок DNS-сервера. Когда этот раздел предписывает выполнить задачу на клиенте, выполните его на сервере.
Если сервер находится в работоспособном состоянии и может пересылать запросы, повторите этот шаг и проверьте сервер, на который сервер пересылает запросы.
Если этот сервер не перенаправляет запросы на другой сервер, проверьте, может ли этот сервер запрашивать корневой сервер. Для этого выполните следующую команду:
Если сопоставитель возвращает IP-адрес корневого сервера, возможно, имеется разорванное делегирование между корневым сервером и именем или IP-адресом, который вы пытаетесь разрешить. Следуйте инструкциям по тестированию неработающей процедуры делегирования , чтобы определить, где находится неработающее делегирование.
Если сопоставитель возвращает ответ "запрос на превышение времени ожидания сервера", проверьте, указывает ли корневые ссылки на работоспособность корневых серверов. Для этого используйте для просмотра текущей процедуры корневых ссылок . Если корневые ссылки указывают на работающие корневые серверы, возможно, возникла проблема с сетью или сервер может использовать расширенную конфигурацию брандмауэра, которая не позволяет арбитру конфликтов запрашивать сервер, как описано в разделе Проверка проблем DNS-сервера . Также возможно, что рекурсивное время ожидания по умолчанию слишком мало.
Тестирование неработающего делегирования
Начните тесты в следующей процедуре, запросив допустимый корневой сервер. Этот тест позволяет выполнить запрос всех DNS-серверов из корня к серверу, который тестируется для неработающего делегирования.
В командной строке на тестируемом сервере введите следующее:
Тип записи ресурса — это тип записи ресурса, для которой был выполнен запрос в исходном запросе, а полное доменное имя — полное доменное имя, для которого выполнялись запросы (заканчивающиеся точкой).
Если ответ содержит список записей ресурсов "NS" и "A" для делегированных серверов, повторите шаг 1 для каждого сервера и используйте IP-адрес из записей ресурсов "A" в качестве IP-адреса сервера.
Если ответ не содержит запись ресурса NS, делегирование будет разорвано.
Если ответ содержит записи ресурсов "NS", но нет записей ресурсов "A", введите " задать рекурсию" и выполните запрос по отдельности для записей ресурсов "a" серверов, перечисленных в записях NS. Если вы не нашли по меньшей мере один допустимый IP-адрес записи ресурса "A" для каждой записи ресурса NS в зоне, то у вас есть неработающее делегирование.
Если вы определили, что вы используете неработающее делегирование, исправьте его, добавив или обновив запись ресурса "A" в родительской зоне, используя допустимый IP-адрес для соответствующего DNS-сервера для делегированной зоны.
Просмотр текущих корневых ссылок
Запустите консоль DNS.
Добавьте или подключитесь к DNS-серверу, который не прошел рекурсивный запрос.
Щелкните правой кнопкой мыши сервер и выберите пункт Свойства.
Щелкните корневые ссылки.
Проверьте наличие базовых подключений к корневым серверам.
Если правильно настроены корневые ссылки, убедитесь, что DNS-сервер, используемый в разрешении имен с ошибками, может проверить связь с корневыми серверами по IP-адресу.
Если корневые серверы не отвечают на проверку связи по IP-адресу, IP-адреса для корневых серверов могли измениться. Однако нередко можно увидеть перенастройку корневых серверов.
Проблемы с зонными ошибками
Выполните следующие проверки:
Проверьте Просмотр событий как для основного, так и для дополнительного DNS-сервера.
Проверьте сервер источника, чтобы узнать, не отправит ли он передачу данных для безопасности.
Проверьте вкладку зонные передачи свойств зоны в консоли DNS. Если сервер ограничит передачу зоны на список серверов, например на вкладке серверы имен в свойствах зоны, убедитесь, что сервер-получатель находится в этом списке. Убедитесь, что сервер настроен на отправку зонных передач.
Проверьте наличие проблем на основном сервере, выполнив действия, описанные в разделе Проверка проблем DNS-сервера . Когда появится запрос на выполнение задачи на клиенте, выполните задачу на сервере-получателе.
Проверьте, не работает ли на сервере-получателе другая реализация сервера DNS, например BIND. Если это так, проблема может быть вызвана одной из следующих причин:
Windows сервер-источник может быть настроен для отправки быстрых зонных передач, но сервер-получатель стороннего производителя может не поддерживать быструю передачу зоны. В этом случае отключите передачу данных с помощью быстрой зоны на сервере-источнике из консоли DNS, установив флажок включить вторичные базы данных-получатели на вкладке Дополнительно свойств сервера.
если зона прямого просмотра на Windows сервере содержит тип записи (например, запись SRV), которую сервер-получатель не поддерживает, то на сервере-получателе могут возникнуть проблемы с извлечением зоны.
Проверьте, запущена ли на сервере-источнике другая реализация сервера DNS, например BIND. если да, то возможно, что зона на сервере источника включает несовместимые записи ресурсов, которые Windows не распознает.
Если на главном или вторичном сервере используется другая реализация DNS-сервера, проверьте оба сервера, чтобы убедиться, что они поддерживают одни и те же функции. сервер Windows можно проверить на консоли DNS на вкладке дополнительно страницы свойства сервера. В дополнение к полю включить вторичные получатели привязок на этой странице содержится раскрывающийся список Проверка имен . Это позволяет выбрать принудительное соответствие требованиям RFC для символов в DNS-именах.
Утилита dig позволяет отправлять на DNS-сервер запросы с заданными параметрами, чтобы узнать информацию обо всех или только о некоторых DNS-записях. Аналог dig — утилита nslookup: с её помощью тоже можно проверить DNS-записи домена.
Здесь вы можете воспользоваться онлайн-версией утилиты dig. Для этого достаточно указать нужный домен, а также дополнительные параметры (при необходимости).
— В поле «Домен» введите адрес, для которого вы хотите отобразить DNS-записи. — В выпадающем списке «Тип записи» выберите нужный тип DNS-записи (по умолчанию отображаются все доступные записи). — В поле «DNS сервер» укажите конкретный DNS-сервер, для которого вы хотите проверить DNS-записи (опционально).
Если вы хотите получить подробное отображение пути следования информации в системе DNS, отметьте галочку «С трассировкой». Для отображения информации в текстовом виде отметьте галочку «Текстовый ответ».
Проверка A-записи: чтобы узнать IPv4-адрес домена, в выпадающем списке «Тип записи» выберите «A».
Проверка AAAA-записи: для информации о IPv6-адресе домена в выпадающем списке «Тип записи» выберите «AAAA».
Проверка NS-записи: для получения онлайн-теста DNS-серверов домена в выпадающем списке «Тип записи» выберите «ANY».
Проверка MX-записи: чтобы узнать DNS MX-запись домена, в выпадающем списке «Тип записи» выберите «MX».
Проверка TXT-записи: чтобы посмотреть dig TXT-запись домена, в выпадающем списке «Тип записи» выберите «TXT».
Проверка SOA-записи: для проверки SOA-записи в выпадающем списке «Тип записи» выберите «SOA».
CNAME DNS check — чтобы узнать CNAME-запись домена, в выпадающем списке «Тип записи» выберите «CNAME».
Вам может быть интересно
Утилита dig (сокращение от «domain information groper») позволяет проверить записи DNS домена. На этой странице вы можете узнать DNS-информацию об ответах серверов имён и отобразить все основные записи домена с помощью онлайн-инструмента dig с простым графическим интерфейсом.
Но одному домену могут соответствовать несколько IP-адресов, например один — для сайта, а другой — для почтового сервера. Все взаимосвязи между доменом и IP-адресами прописаны в специальном файле на DNS-сервере — файле DNS-зоны, который содержит различные типы записей.
A-запись — хранит имя хоста и соответствующий ему адрес IPv4.
AAAA-запись — хранит имя хоста и соответствующий ему адрес IPv6.
NS-запись — предоставляет адреса DNS-серверов домена.
MX-запись — указывает SMTP-сервер электронной почты для домена.
TXT-запись — обычно содержит текстовые примечания или машиночитаемые данные, например подтверждение права собственности на сайт, подпись DKIM, идентификацию DMARC и так далее.
SOA-запись — указывает основной DNS-сервер, контактные данные администратора домена, серийный номер файлы DNS-зоны и информацию о частоте запросов, проверяющих обновления DNS-записей.
CNAME-запись — используется для псевдонимов, например, при перенаправлении адреса с «www» на адрес без «www».
Все существующие в интернете веб-ресурсы сообщаются друг с другом посредством цифровых IP -адресов, а те читабельные и дружественные пользователю адреса, которые вы видите в адресной строке браузера есть ничто иное как своего рода псевдонимы. За их преобразование в понятные компьютерам IP -адреса отвечает специальная служба, именуемая DNS . Ее настройки предоставляются интернет-провайдером, однако ничто не мешает вам их сменить, перейдя на альтернативные DNS .
Среди которых наиболее популярными являются Google Public DNS , Яндекс DNS и CloudFlare .
Замена адресов DNS не представляет сложности, но этого может оказаться недостаточно, нужно еще убедиться, что сетевой трафик действительно проходит через настроенные сервисы. К сожалению, в Windows нет очевидного способа это сделать, хотя сама возможность такой проверки поддерживается.
Перейдите в любом браузере по указанному выше адресу и нажмите кнопку «Standart test», чтобы запустить стандартный тест.
В результате в колонке ISP вы получите имя службы DNS , которую используете в данный момент.
Если оно соответствует имени установленной вами ДНС-службы, значит всё в порядке. Есть еще расширенный тест (Extended test) , но отличается он только большим количеством запросов, гарантирующим обнаружение большего числа серверов.
Примечание: перед выполнением теста отключите VPN, если его используете, поскольку тогда результаты будут отличаться.Второй способ не столь удобен и информативен.
Для проверки DNS вы можете воспользоваться встроенной консольной утилитой nslookup.
Открыв командную строку, выполните в ней сначала команду chcp 1251 , а затем команду nslookup .
Читайте также: