С помощью какой утилиты можно выявить проблемы связанные с разрешением dns имен
Обновлено: 05.07.2024
Еще одним важным инструментом для поиска и устранения проблем, связанных с преобразованием имен в DNS, является утилита IPCONFIG, которая также используется для устранения наиболее распространенных проблем с TCP/IP. В отношении DNS утилита IPCONFIG позволяет выполнять несколько важных операций. Эти операции инициируются из командной строки указанием соответствующих параметров, которые описаны ниже.
- ipconfig /f lushdns. При возникновении проблем с кэшем на стороне клиента его содержимое может быть сброшено за счет применения флага f lushdns. Этот флаг позволяет удалить все помещенные ранее в кэш запросы, которые может хранить клиент, и особенно полезен в случае, если на сервере имен только что поменялись IP-адреса и у каких-то клиентов теперь из-за этого возникают трудности с подключением к нему.
- ipconfig /regis terdns. Флаг registerdns заставляет клиента динамически перерегистрировать себя в DNS, если данная зона поддерживает динамические обновления.
- ipconfig /displaydns. Этот флаг является очень интересным, но мало кому известным. Он позволяет отобразить содержимое клиентского кэша и помогает в выявлении определенных проблем с отдельными записями.
Применение утилиты командной строки TRACERT
Утилита TRACERT является ценным источником информации, позволяющим получить представление о пути, который проходит DNS-запрос при его пересылке по сети.
с отказом. После этого исходная система увеличит TTL-значение на 1 и отправит пакет снова. На этот раз пакет пройдет через первый маршрутизатор, но получит отказ от второго. Таким образом этот процесс продолжается до тех пор, пока пакет не достигнет своего места назначения. Из этого становится совершенно очевидно, что данная утилита предоставляет простой, но очень эффективный способ для просмотра пути, который DNS-запрос проходит при его передаче через Интернет.
Применение утилиты командной строки DNSCMD
Утилита DNSCMD, по сути, представляет собой командную версию доступной в консоли ММС оснастки DNS. Она устанавливается в виде части предлагаемой в Windows Server 2008 R2 роли DNS Server (DNS-сервер) и позволяет администраторам создавать зоны, изменять записи и выполнять другие важные административные операции в командной строке. Полный список всех поддерживаемых ею опций можно просмотреть по команде DNSCMD /?.
Одна из важнейших подсистем, отвечающая за связь любого сервера с внешним миром — сетевая. Через сетевые интерфейсы поступают запросы от удаленных систем и через эти же интерфейсы направляются ответы, что позволяет налаживать коммуникацию и предоставлять/получать сервисы. В связи с этим особенно важно уметь производить диагностику и мониторинг сети хотя бы на базовом уровне, чтобы выявлять проблемы и вносить корректировки в конфигурацию в случае необходимости.
Для операционных систем семейства Linux написано множество утилит, помогающих в диагностике и мониторинге. Познакомимся с наиболее часто используемыми из них.
Диагностика сетевой связности (ping, arp, traceroute)
В данной статье мы будем опираться на использование протокола IP версии 4. Согласно стандартам, определяющим работу этого протокола, каждое устройство, подключенное к сети, должно иметь как минимум IP-адрес и маску подсети — параметры, которые позволяют уникально идентифицировать устройство в пределах определенной сети. В такой конфигурации устройство может обмениваться сетевыми пакетами с другими устройствами в пределах той же самой логической сети. Если к этому набору параметров добавить адрес шлюза по умолчанию — наш сервер сможет связываться с хостами, находящимися за пределами локального адресного пространства.
В случае каких-либо сетевых проблем в первую очередь проверяем, не сбились ли настройки сетевого интерфейса. Например, команды ip addr или ifconfig выведут IP-адрес и маску сети:
В выводе команды виден перечень сетевых интерфейсов, распознанных операционной системой. Интерфейс lo — это псевдоинтерфейс (loopback). Он не используется в реальных взаимодействиях с удаленными хостами, а вот интерфейс с именем ens192 — то, что нам нужно (именование сетевых интерфейсов различается в разных ветках и версиях ОС Linux). IP-адрес и маска сети, назначенные этому интерфейсу, указаны в поле inet — /24 после адреса обозначают 24-битную маску 255.255.255.0.
Теперь проверим, указан ли шлюз по умолчанию. Команды ip route или route покажут имеющиеся маршруты:
В таблице маршрутизации мы видим, что имеется маршрут по умолчанию (обозначается либо ключевым словом default, либо адресом 0.0.0.0). Все пакеты, предназначенные для внешних сетей, должны направляться на указанный в маршруте адрес через обозначенный сетевой интерфейс.
Синтаксис команды ping IP/имя опции:
Скриншот №3. Синтаксис команды
В данном случае видим, что на оба сетевых пакета, отправленных на адрес нашего шлюза по умолчанию, получены ответы, потерь нет. Это значит, что на уровне локальной сети со связностью все в порядке. Помимо количества полученных/потерянных сетевых пакетов мы можем увидеть время, которое было затрачено на прохождение запроса и ответа – параметр RTT (Round Trip Time). Этот параметр может быть очень важен при диагностике проблем, связанных с нестабильностью связи и скоростью соединения.
Часто используемые параметры:
- ping –c количество — указать количество пакетов, которое будет отправлено адресату (по умолчанию пакеты отправляются до тех пор, пока пользователь не прервет выполнение команды. Этот режим можно использовать, чтобы проверить стабильность сетевого соединения. Если параметр RTT будет сильно изменяться в ходе проверки, значит где-то на протяжении маршрута есть проблема);
- ping –s количество — указать размер пакета в байтах. По умолчанию проверка производится малыми пакетами. Чтобы проверить работу сетевых устройств с пакетами большего размера, можно использовать этот параметр;
- ping –I интерфейс — указать сетевой интерфейс, с которого будет отправлен запрос (актуально при наличии нескольких сетевых интерфейсов и необходимости проверить прохождение пакетов по конкретному сетевому маршруту).
В случае, если при использовании команды ping пакеты от шлюза (или другого хоста, находящегося в одной локальной сети с сервером-отправителем) в ответ не приходят, стоит проверить сетевую связность на уровне Ethernet. Здесь для коммуникации между устройствами используются так называемые MAC-адреса сетевых интерфейсов. За разрешение Ethernet-адресов отвечает протокол ARP (Address Resolution Protocol) и с помощью одноименной утилиты мы можем проверить корректность работы на этом уровне. Запустим команду arp –n и проверим результат:
Команда выведет список IP-адресов (так как был использован аргумент –n), и соответствующие им MAC-адреса хостов, находящиеся в одной сети с нашим сервером. Если в этом списке есть IP, который мы пытаемся пинговать, и соответствующий ему MAC, значит сеть работает и, возможно, ICMP-пакеты, которые использует команда ping, просто блокируются файрволом (либо со стороны отправителя, либо со стороны получателя). Подробнее об управлении правилами файрвола рассказано здесь и здесь.
Часто используемые параметры:
- arp –n — вывод содержимого локального arp-кэша в числовом формате. Без этой опции будет предпринята попытка определить символические имена хостов;
- arp –d адрес — удаление указанного адреса из кэша. Это может быть полезно для проверки корректности разрешения адреса. Чтобы убедиться, что в настоящий момент времени адрес разрешается корректно, можно удалить его из кэша и снова запустить ping. Если все работает правильно, адрес снова появится в кэше.
Если все предыдущие шаги завершены корректно, проверяем работу маршрутизатора — запускаем ping до сервера за пределами нашей сети, например, 8.8.8.8 (DNS-сервис от Google). Если все работает корректно, получаем результат:
Первым маршрутизатором на пути пакета должен быть наш локальный шлюз по умолчанию. Если дальше него пакет не уходит, возможно проблема в конфигурации маршрутизатора и нужно разбираться с ним. Если пакеты теряются на дальнейших шагах, возможно, есть проблема в промежуточной сети. А, возможно, промежуточные маршрутизаторы не отсылают ответные пакеты. В этом случае можно переключиться на использование другого протокола в traceroute.
Часто используемые опции:
- traceroute –n — вывод результата в числовом формате вместо символических имен промежуточных узлов;
- traceroute –I — использование ICMP-протокола при отслеживании маршрута. По умолчанию используются UDP-датаграммы;
- traceroute –s адрес— указать адрес источника для исходящего сетевого пакета;
- traceroute –i интерфейс— указать сетевой интерфейс, с которого будут отправляться пакеты.
Диагностика разрешения имен (nslookup, dig)
Разобравшись с сетевой связностью и маршрутизацией приходим к следующему этапу — разрешение доменных имен. В большинстве случаев в работе с удаленными сервисами мы не используем IP-адреса, а указываем доменные имена удаленных ресурсов. За перевод символических имен в IP-адреса отвечает служба DNS — это сеть серверов, которые содержат актуальную информацию о соответствии имен и IP в пределах доверенных им доменных зон.
Способы выяснения какой DNS-сервер использует наш сервер различаются в зависимости от используемой версии и дистрибутива ОС Linux. Например, если ОС используется Network Manager для управления сетевыми интерфейсами (CentOS, RedHat и др.), может помочь вывод команды nmcli:
В настройках сетевого интерфейса, в разделе DNS configuration, мы увидим IP-адрес сервера. В Ubuntu 18.04 и выше, использующих Netplan, используем команду systemd-resolve --status:
Используемый сервер также будет указан в настройках интерфейса, в разделе DNS Servers. В более старых версиях Ubuntu потребуется проверить содержимое файлов /etc/resolve.conf и /etc/network/interfaces. Если сервер не указан, воспользуйтесь статьей для ОС Ubuntu 18.04 или CentOS, чтобы скорректировать настройки.
Проверить работу сервиса разрешения имен нам помогут утилиты nslookup или dig. Функционально они почти идентичны: G-вывод утилиты dig содержит больше диагностической информации и гибко регулируется, но это далеко не всегда нужно. Поэтому используйте ту утилиту, которая удобна в конкретной ситуации. Если эти команды недоступны, потребуется доставить пакеты на CentOS/RedHat:
yum install bind-utils
sudo apt install dnsutils
После успешной установки сделаем тестовые запросы:
Аналогичный запрос утилитой nslookup выдает более компактный вывод, но вся нужная сейчас информация в нем присутствует.
Скриншот №11. Отправка тестового запроса 1
Скриншот №12. Отправка тестового запроса 2
Если имена разрешаются публичным DNS-сервером корректно, а установленным по умолчанию в ОС нет, вероятно, есть проблема в работе этого DNS-сервера. Временным решением данной проблемы может быть использование публичного DNS-сервера в качестве сервера для разрешения имен в операционной системе. В том случае, если разрешение имен не работает ни через локальный, ни через публичный DNS сервер — стоит проверить не блокируют ли правила файрвола отправку на удаленный порт 53 TCP/UDP пакетов (именно на этом порту DNS-серверы принимают запросы).
Часто используемые параметры:
Как обычно, полный набор опций и параметров для указанных утилит можно найти во встроенной справке операционной системы, используя команду man.
Одной из самых частых ошибок связанных с подключением к интернету в Windows, является ошибка: "DNS-сервер не отвечает". При этом, пропадает доступ к интернету. На значке подключения скорее всего будет желтый треугольник, а в браузере, при попытке открыть сайт, вы скорее всего увидите ошибку "Не удается найти DNS-адрес", "err name not resolved ", или что-то в этом роде. Проблема эта вызвана сбоем в работе DNS-сервера, который отвечает за перенаправленные IP-адреса на домен. Если говорить о причинах возникновения этой ошибки, то виновником может быть как сам компьютер, так и маршрутизатор, или оборудование на стороне провайдера.
Сама ошибка "DNS-сервер не отвечает" появляется в результате диагностики сетей Windows. Запустить диагностику очень просто. Достаточно нажать правой кнопкой мыши на значок подключения к интернету, и выбрать "Диагностика неполадок".
Иногда, может появляться ошибка: "Параметры компьютера настроены правильно, но устройство или ресурс (DNS-сервер) не отвечает".
Вот такие ошибки. Если вы не знаете что делать, то сейчас мы рассмотрим несколько эффективных советов, которые должны помочь избавится от данных ошибок. В итоге, интернет на вашем компьютере заработает, и сайты начнут открываться. Решения будут одинаковыми для Windows 10, Windows 8, и Windows 7.
Для начала, я советую выполнить несколько простых решений. Есть шанс, что они помогут, и вам не придется разбираться с более сложными настройками.
- Если у вас интернет подключен через роутер, или модем (по Wi-Fi, или по кабелю) , и вы наблюдаете ошибку "DNS-сервер не отвечает", то попробуйте просто перезагрузить роутер. Отключите питание роутера где-то на минуту, и включите обратно. Не важно какой у вас роутер, TP-Link, D-link, ASUS, или еще какой-то.
- Перезагрузите свой компьютер, или ноутбук. В данном случае не важно, интернет у вас идет через роутер, или кабелем напрямую от провайдера. Просто выполните перезагрузку.
- Если интернет подключен через роутер, то проверьте, работает ли интернет на других устройствах. Нет ли там ошибки с ответом DNS-сервера.
- При подключении через маршрутизатор, если есть возможность, можно подключить интернет напрямую к компьютеру. Для проверки.
- Постарайтесь вспомнить, после чего появилась ошибка DNS, и проблемы с доступом к интернету. Может после смены каких-то настроек, или установки программ.
Если эти советы не помогли, то попробуйте применить решения, о которых я напишу ниже.
Проверяем службу DNS-клиент
Прежде чем что-то менять, я рекомендую посмотреть, работает ли служба "DNS-клиент". Нажмите на клавиатуре сочетание клавиш Win + R. В появившемся окне введите команду services.msc, и нажмите Ok.
В новом окне ищем службу "DNS-клиент", нажимаем на нее правой кнопкой мыши, и выбираем "Свойства".
Тип запуска должен быть "Автоматически". И если у вас кнопка "Запустить" будет активной, то нажмите на нее. Дальше: "Применить" и "Ok".
Если служба у вас была отключена, и вы ее включили, то после перезагрузки компьютера интернет должен заработать.
Меняем настройки DNS-серверов в свойствах подключения
Дальше мы проверим настройки DNS-серверов в свойствах подключения, через которое компьютер подключен к интернету. Если там прописаны какие-то адреса, то можно попробовать выставить автоматическое получение, либо прописать DNS-адреса от Google. Этот способ очень часто позволяет избавится от ошибки "DNS-сервер не отвечает".
Нам нужно открыть окно со всеми подключениями. Для этого можно нажать правой кнопкой мыши на значок подключения к интернету, и выбрать "Центр управления сетями. ". Дальше переходим в "Изменение параметров адаптера".
Дальше правой кнопкой мыши нажимаем на то подключение, через которое вы подключены к интернету (к роутеру) , и выбираем "Свойства". Если подключение по Wi-Fi, то это подключение "Беспроводная сеть", если по кабелю, то "Ethernet" (Подключение по локальной сети) .
У меня, например, проблема с DNS при подключении по Wi-Fi сети через роутер.
В новом окне выделите "IP версии 4 (TCP/IPv4)", и нажмите "Свойства". Если в новом окне у вас прописан какой-то DNS-сервер, то можно попробовать выставить автоматическое получение адресов, и проверить подключение к интернету после перезагрузки компьютера.
Но чаще всего помогает следующее: ставим переключатель возле "Использовать следующие адреса DNS-серверов", и прописываем DNS от Google:
Нажимаем "Ok" и перезагружаем компьютер.
Такое решение помогает очень часто. Если у вас проблема с получение DNS на всех устройствах, которые подключены через один роутер, то эти адреса можно прописать в настройках роутера, тогда они будут применяться для всех устройств. Как правило, сделать это можно в настройках вашего роутера, в разделе "Интернет", или "WAN". Где задаются параметры для подключения к провайдеру.
Для примера, покажу как это сделать на роутере TP-Link:
Не забудьте сохранить настройки.
Очищаем кэш DNS и другие сетевые параметры
Нужно просто запустить командную строку, и по очереди выполнить несколько команд, которые выполнять очистку кэша DNS-адресов, и других сетевых настроек. Этот способ подойдет как для Windows 10, так и для Windows 7 (8).
Командную строку нужно запустить от имени администратора. Если у вас Windows 10, то просто нажмите правой кнопкой мыши на меню пуск, и выберите "Командная строка (администратор)". В Windows 7, в поиске можно набрать "cmd", нажать правой кнопкой на "cmd" в результатах поиска, и выбрать "Запустить от имени администратора".
По очереди копируем и выполняем такие команды:
ipconfig /flushdns
ipconfig /registerdns
ipconfig /renew
ipconfig /release
В Windows 10 можно еще попробовать выполнить сброс сетевых настроек. Это практически то же самое.
После этого перезагрузите компьютер.
Обновление: отключаем или удаляем антивирус Avast
В комментариях Сергей написал, что ему помогло только удаление антивируса Avast. Если у вас установлен именно этот антивирус, то возможно он стал причиной того, что DNS-сервер перестал отвечать.
По своему опыту могу сказать, что антивирус Avast очень часто вмешивается в сетевые настройки Windows, из-за чего появляются разные проблемы с подключением к интернету. То интернет перестает работать после удаления антивируса, то ошибка DNS, или сетевой адаптер не имеет допустимых параметров настройки IP.
Можно попробовать для начала полностью остановить работу антивируса. Если это не решит проблему, то удалить его. Можно переустановить его, только без дополнительных модулей. Как это сделать, я писал в статье по ссылке выше (о решении проблемы с параметрами IP) .
Если вы все проделали правильно, но Windows по прежнему пишет что DNS-сервер не отвечает, то у меня есть еще пару советов:
Обязательно напишите, если у вас получилось избавится от этой ошибки. Напишите какой способ помог. Может у вас сработало какое-то другое решение, которого нет в статье. Ну и оставляйте свои отзывы в комментариях.
Что бы понять насколько мощна данная утилита взгляните на рисунок 10.
Я уже приводил пример использования данной утилиты, смотрите здесь. Но давайте еще раз проделаем с ней некоторые манипуляции и посмотрим что она нам скажет.
Еще одна полезная команда это DnsCmd <сервер DNS> /Statistics. Скриншот данной команды не привожу так как он очень большой но саму команду опшем подробней.
Параметр statistics команды DnsCmd дает нам возможность получить большой объем информации о сервере DNS, включая:
- отправленные и полученные запросы;
- типы полученных запросов (A, MX, NS, PTR);
- попытки передачи зон и частота успешных попыток;
- ссылки на WINS;
- статистику динамических обновлений (безопасные обновления, типы записей);
- статистику производительности записи.
Данная команда выводит очень большой объем информации которая более полезна в разработке, чем при диагностике, однако, при диагностике следует уделять внимание ошибкам, после чего попытаться решить проблему на основе полученной информации.
Полный синтаксис команды DnsCmd с параметром /statistics такой:
Как ведите из полного синтаксиса команды сам параметр /statistics имеет определенные опции. Эти опции описаны в таблице 1
При первом запуске команды DnsCmd с параметром /statistics не указывайте значение параметра id и обратите внимание на категории, которые необходимы для решения проблем DNS сервера. Таким образом, при последующих попытках запуска утилиты объем выдаваемой информации будет намного меньшим.
Потом данный файл можно открыть в любом текстовом редакторе.
NETDIAG
Общий вид утилиты со всеми ее параметрами смотрите рисунок 16.
Как видно из рисунка 16 весьма внушительная утилита. Утилита Netdiag.exe использует следующий синтаксис.
netdiag [/q] [/v] [/l] [/debug] [/d: имя_домена ] [/fix] [/dcaccountenum] [/test: имя_теста ] [/skip: имя_теста ]
Параметры команды netdiag описаны в таблице 3.
Когда утилита netdiag запускается без параметров то запускаются и все возможные тесты которыми владеет данная утилита а именно:
Autonet - Проверка автоматического частного IP-адреса (APIPA)Bindings - Проверка привязок
Browser - Проверка перенаправителя и обозревателя
DcList - Проверка списка контроллеров домена
DefGw - Проверка основного шлюза
DNS-Проверка DNS
DsGetDc - Проверка обнаружения контроллера домена
IpConfig - Проверка конфигурации IP-адреса
IpLoopBk - Проверка обратной связи с помощью команды ping IP-адрес
IPSec - Проверка безопасности протокола IP (IPSec)
IPX - Проверка протокола IPX (Internetwork Packet Exchange)
Kerberos - Проверка протокола Kerberos
Ldap -Проверка Облегченного протокола доступа к каталогам LDAP (Lightweight Directory Access Protocol)
Member - Проверка членства в домене
Modem - Диагностическая проверка модема
NbtNm - Проверка NetBIOS через TCP/IP (NetBT)
Ndis - Проверка запросов сетевой платы
NetBTTransports - Проверка транспортов NetBT
Netstat - Проверка информации Netstat
NetWare - Проверка NetWare
Route - Проверка таблицы маршрутизации
Trust - Проверка отношений доверия
WAN -Проверка конфигурации глобальной сети (WAN)
WINS - Проверка работы служб WINS (Windows Internet Naming Services)
Winsock - Проверка Winsock
Чтобы назначить выполнение нескольких тестов, поставьте пробел между каждым элементом /test: имя_теста . Обратите внимание, что тесты, которые не были пропущены, будут выполняться.
Чтобы проверить все сетевые настройки наберите в командной строке netdiag /fix и у вас на экране должно появится окно с описанием все ваших сетевых настроек (скриншот не привожу - большой). Для проверки DNS наберите в командной строке netdiag /test:DNS (что нас и интересует в данном контексте). Примерный результат команды смотрите на рисунке 17.
Чаща всего утилиту чаще всего используют с параметром NetDiag /q. Утилитой NetDiag мы еще будем пользоваться, а пока думаю что достаточно о ней.
DNSlint
Утилита DNSlint так же позволяет определить большой круг задач (проблем) диагностики службы DNS . Что бы посмотреть все параметры данной утилиты наберите dnslint /?. Скриншот не привожу, так как очень большой, но вкратце - она имеет три основные функции:
dnslint /ql - (проверка определенных пользователем записей на сервере DNS),
dnslint /ad - (проверка записей, относящихся к активному домену [Active Domain]) и
dnslint /d - (проверка "неверного делегирования").
На рисунке 19 показан, правда не полностью - только часть, сгенерированного HTML отчета утилитой dnslint что было запущена с параметрами показанных на рисунке 18.
Кажется основные утилиты по управлению, мониторингу и устранения проблем службы DNS я описал. Если что забыл напомните.
DNS-сервер фактически является приложением, которое работает на отдельном физическом сервере или совместно с другими серверами и обрабатывает все запросы, содержащие доменные имена.
Как только вы зарегистрировали доменное имя, оно начинает обслуживаться DNS-сервером, и любое обращение к домену по имени проходит через него. С момента привязки доменного имени к DNS-серверу может пройти до 72 часов, чтобы домен начал работать. Если по истечении этого срока домен не заработал или возникла ситуация, когда работающий домен перестал отвечать на запросы, проведите быструю диагностику DNS.
С чего начать?
Используйте утилиту whois для первичной диагностики DNS. Актуально для Linux-систем.
В примере показан корректный вывод ответа на whois, который в большинстве случаев должен быть именно таким.
Для получения краткой информации о домене используйте команду whois с параметрами:
Используйте утилиту dig для обращения из командной строки к серверу DNS. Выполните трассировку маршрута пакетов к DNS-серверу командой:
Опросите конкретный DNS-сервер, обслуживающий ваш домен, командой
Секция ANSWER SECTION содержит IP-адрес, возвращенный DNS-сервером. Этот IP должен совпадать с тем, который вы назначали домену. Если он отличается, обновите доменную зону или подождите, пока она обновится автоматически. Все DNS-серверы должны возвращать один и тот же IP-адрес для домена.
Ошибка “Connection timed out”
Проверьте, доступен ли DNS-сервер и открыт ли на нем 53 порт.
Опросите первичный сервер имен командой
При правильной работе DNS должен выводиться корректный IP-адрес домена.
Решение основных проблем с DNS
Описание всех возникших проблем DNS-сервера читайте в лог-файле DNS, который по умолчанию находится по следующему пути: /var/log/messages. Расположение может быть изменено в зависимости от настроек вашего сервера. Через ISPmanager лог-файл можно просмотреть через “Менеджер файлов”.
Далее описаны наиболее часто возникающие проблемы DNS, которые можно обнаружить командой dig или в лог-файле.
Пустой ответ на команду dig
Под пустым ответом на команду dig понимается отсутствие секции ANSWER в выводе.
Как правило, причинами такого ответа могут быть:
Если у вас нет панели управления ISPmanager, проверьте, есть ли файл зоны домена, вручную.
Удостоверьтесь, что на сервере для вашего домена корректно созданы А-записи. Зайдите в ISPmanager в раздел “Домены” -> “Доменные имена”. Выделите домен и нажмите кнопку “Записи”.
Среди ресурсных записей найдите А-запись и удостоверьтесь, что каждая запись содержит значение IP-адрес сервера, на котором расположен домен. В обратном случае исправьте несоответствия или создайте записи заново.
Если вы не используете панель управления ISPmanager, выполните проверки вручную на сервере. Пример А-записи в конфигурационном файле named.conf:
Ошибка “Permission denied”
Также проверьте права на саму папку /etc/bind/ командой:
Следующий результат указывает на то, что директория доступна пользователям root и bind:
Ошибка “No address records (A or AAAA)”
Следующие строки в лог-файле DNS означают, что ресурсная А-запись отсутствует для дочернего NS:
Ошибка “CNAME and other data”
Следующие строки в лог-файле DNS означают, что для одного домена прописаны одновременно А и CNAME ресурсные записи:
Конфликт вызывает запись вида:
Оставьте только одну необходимую запись.
Ошибка “Query denied”
Следующие строки в лог-файле DNS означают, что ваш запрос к DNS-серверу запрещен:
А таком случае DNS-сервер возможно настроен так, что запросы к нему разрешены только от дочернего DNS (slave).
Ошибка “Transfer failed”
Следующие строки в лог-файле DNS означают, что в конфигурации DNS запрещен трансфер на данный IP-адрес зоны домена:
Команда dig указывает на эту ошибку следующим ответом:
Ошибка в синтаксисе
Если вы случайно допустили синтаксическую ошибку в конфигурации файла доменной зоны, то в ответе на команду dig появятся не ожидаемые вами обозначения. Например,
Читайте также: