С помощью какой утилиты можно выявить проблемы связанные с разрешением dns имен
Рассмотрим, как упростить разрешение имен с помощью двух средств диагностики DNS, по своим достоинствам значительно превосходящих Nslookup. Проведем углубленный анализ реализованных в Windows Server 2008 R2 новых механизмов расширения для DNS (EDNS), несправедливо обвиняемых в том, что они являются причиной неполадок в работе DNS
Возникли неполадки с Active Directory (AD)? Вероятнее всего, что на самом деле это проблема DNS. Не можете зарегистрироваться с учетной записью электронной почты, Twitter или Facebook? Скорее всего, и это проблема DNS. Выявление связанных с DNS неполадок — шаг номер два в диагностике практически любой сетевой проблемы, однако их устранение подобно стрельбе по движущейся мишени из-за постоянного изменения ситуации. Мы уже не раз обсуждали основы диагностики неисправностей DNS, поэтому сегодня я предлагаю выйти за рамки азов и по-новому взглянуть на известную проблему. .
Проверка проблем с рекурсией
Чтобы рекурсия работала успешно, все DNS-серверы, используемые в пути рекурсивного запроса, должны иметь возможность отвечать и пересылать правильные данные. Если это не так, рекурсивный запрос может завершиться ошибкой по одной из следующих причин:
Время ожидания запроса истекло, прежде чем его можно будет завершить.
Сервер, используемый во время запроса, не отвечает.
Сервер, используемый во время запроса, предоставляет неверные данные.
Начните устранение неполадок на сервере, который использовался в исходном запросе. Проверьте, пересылает ли этот сервер запросы на другой сервер, изучив вкладку серверы пересылки в свойствах сервера в консоли DNS. Если флажок включить серверы пересылки установлен и в списке присутствует один или несколько серверов, этот сервер перенаправляет запросы.
Если этот сервер пересылает запросы на другой сервер, проверьте наличие проблем, влияющих на сервер, на который сервер пересылает запросы. Чтобы проверить наличие проблем, см. раздел Проверка неполадок DNS-сервера. Когда этот раздел предписывает выполнить задачу на клиенте, выполните его на сервере.
Если сервер находится в работоспособном состоянии и может пересылать запросы, повторите этот шаг и проверьте сервер, на который сервер пересылает запросы.
Если этот сервер не перенаправляет запросы на другой сервер, проверьте, может ли этот сервер запрашивать корневой сервер. Для этого выполните следующую команду:
Если сопоставитель возвращает IP-адрес корневого сервера, возможно, имеется разорванное делегирование между корневым сервером и именем или IP-адресом, который вы пытаетесь разрешить. Следуйте инструкциям по тестированию неработающей процедуры делегирования , чтобы определить, где находится неработающее делегирование.
Если сопоставитель возвращает ответ "запрос на превышение времени ожидания сервера", проверьте, указывает ли корневые ссылки на работоспособность корневых серверов. Для этого используйте для просмотра текущей процедуры корневых ссылок . Если корневые ссылки указывают на работающие корневые серверы, возможно, возникла проблема с сетью или сервер может использовать расширенную конфигурацию брандмауэра, которая не позволяет арбитру конфликтов запрашивать сервер, как описано в разделе Проверка проблем DNS-сервера . Также возможно, что рекурсивное время ожидания по умолчанию слишком мало.
Применение утилиты командной строки DNSCMD
Утилита DNSCMD, по сути, представляет собой командную версию доступной в консоли ММС оснастки DNS. Она устанавливается в виде части предлагаемой в Windows Server 2008 R2 роли DNS Server (DNS-сервер) и позволяет администраторам создавать зоны, изменять записи и выполнять другие важные административные операции в командной строке. Полный список всех поддерживаемых ею опций можно просмотреть по команде DNSCMD /?.
Используйте сетевой монитор
О сетевом мониторе знает каждый, но большинство пользователей боятся с ним работать — и совершенно напрасно. Сетевой монитор собирает и отображает данные обо всех входящих и исходящих сетевых пакетах, позволяя анализировать каждый бит, проходящий через сетевой адаптер. Изначально Netmon кажется профессиональным инструментом, однако в какой-то мере он даже больше подходит для рядового специалиста, поскольку позволяет применить старый афоризм: «Трудно распознать больного, если не знаешь, как выглядит здоровый». Поэтому, если Netmon работает на вашей работающей системе, сохраните собранные данные, чтобы потом, если возникнет проблема, сравнить их с другой информацией.
Экран 1. Экран приветствия Network Monitor |
Окно сбора данных, показанное на экране 2, — одна из причин нежелания администраторов работать с Netmon. Для упрощения закроем панели Network Conversation слева и Hex Details в нижнем правом углу. Оставим лишь Display Filter, Frame Summary и Frame Details.
Экран 2. Экран сбора данных Network Monitor |
Открываем командную строку, затем нажимаем на зеленый треугольник рядом с клавишей Start в окне Netmon. Ждем запуска Netmon, возвращаемся в командную строку и вводим следующую команду:
После выполнения команды Ping возвращаемся в окно Netmon и нажимаем на синий квадрат рядом с клавишей Stop. Поздравляю с первым сбором данных! В нижней части окна Netmon указано количество зафиксированных сетевых пакетов. В зависимости от темпа вашей работы и загрузки сети вы можете получить от десятка до сотни фреймов данных. Независимо от количества, эти данные выглядят беспорядочно. Чтобы «отделить зерна от плевел», создадим фильтр дисплея.
Чтобы оставить только данные о трафике, относящемся к DNS, вводим DNS в текстовое поле «Display Filter» и нажимаем «Применить». Результат показан на экране 3. В данном примере мы видим только шесть пакетов, представляющих интерес. Столбцы «Process», «Time Offset» и «TimeDateLocalAdjusted» я удалил за ненадобностью.
Экран 3. Просмотр трафика, относящегося к DNS |
Экран 4. Просмотр сведений о фрейме |
Экран 5. Развернутый фрейм DNS |
В детальных сведениях для следующего фрейма DNS видим, что корневой сервер возвращает список 13 серверов DNS зоны. com, тем самым предлагая вашему серверу DNS запросить сервер DNS для зоны. com. Сервер DNS запрашивает серверы DNS зоны. com и проходит по всей иерархии, пока наконец не получает ответ.
Как эта информация поможет выявить проблему DNS? Как раз недавно один из моих серверов DNS просто прекратил отвечать на запросы DNS. Дело осложнялось еще и тем, что данные рабочего журнала сервера DNS показали, что он не получал никаких запросов. Мог ли брандмауэр блокировать трафик DNS? Быстрее всего это удалось выяснить с помощью Netmon. Данные сетевого монитора показали, что сетевой адаптер принимал запросы DNS от других систем (были зафиксированы фреймы), ни на один из которых мой сервер DNS не ответил. Я был уверен, что проблема связана не с DNS, а, скорее всего, с маршрутизацией или IP. Проблему решило выключение службы RRAS. Вероятно, некое исправление «сломало» мои серверы VPN, реализованные на основе RRAS, и каким-то образом «просочилось» в стек IP. Без полезных сведений, полученных по результатам трассировки Netmon, я бы потратил много часов в попытках устранить возможные причины.
Проверка на наличие проблем с достоверными данными
Проверьте, является ли сервер, который возвращает неверный ответ, основным сервером для зоны (основным сервером-источником для зоны или сервером, который использует интеграцию Active Directory для загрузки зоны) или сервер, на котором размещена дополнительная копия зоны.
Контрольный список устранения неполадок
Записи DNS отсутствуют в зоне DNS
Эта проблема может быть вызвана одной из следующих причин:
Очистка DNS неправильно
Если записи DNS отсутствуют в зонах DNS, наиболее распространенной причиной является очистка. Даже Windows компьютеры со статично назначенными серверами будут регистрировать свои записи каждые 24 часа. Проверьте, являются ли интервалы NoRefresh и Refresh слишком низкими. Например, если эти значения являются "менее чем за 24 часа", вы потеряете записи DNS.
Запись host "A" удаляется при смене IP-адреса
Иногда запись "A" удаляется на исходном DNS-сервере после регистрации записи "A" на недавно настроенном IP-адресе сервера DNS (Active Directory Integrated DNS). С точки зрения пользователя все, что зависит от разрешения имен, нарушено. При смене IP-адреса сервера DNS в клиенте клиент отправляет обновление SOA для удаления записи "A" со старого DNS-сервера. Затем отправляется еще одно обновление для регистрации записи "A" на новый DNS-сервер.
Проблема возникает в зонах, интегрированных в Active Directory. Проблемы возникают при смене IP-адреса DNS Server на клиенте. При изменениях IP-адреса клиент отправляет запрос на регистрацию на новый сервер и отправляет запрос на удаление на старый сервер. Поскольку оба сервера уже синхронизированы, регистрация не будет происходить. Однако запись "A" удаляется на старом сервере, а затем удаляется на обоих серверах из-за Active Directory.
Эта проблема возникает, если определен вариант 81 и присутствуют интерфейсы ISATAP или 6to4. Обновление протокола динамического обновления DNS неправильно задает TTL до 0. Это вызывает удаление записей для регистрации записей IPv6.
Обновление протокола динамического обновления DNS до существующих записей не удается
Обновление протокола динамического обновления DNS с существующими записями не удается, и эти записи удаляются процессом очистки в качестве записей в возрасте.
Преобразование активной динамической аренды в резервацию удаляет записи "A" и PTR для этого клиента
Такое поведение является особенностью данного продукта. Записи DNS ("A" или PTR) автоматически обновляются во время следующего запроса клиента на обновление DHCP.
Проблемы с клиентской стороны
Выключите WINS
Когда говорят о проверке DNS, под этим подразумевают проверку всей инфраструктуры разрешения имен, что включает локальные широковещательные пакеты от NetBIOS, WINS и компонент «Сетевое обнаружение», пришедший на смену «Сетевому окружению» вместе с Windows Vista, не говоря уже о файлах HOSTS и LMHOSTS. Неудивительно, что поиск неполадок в разрешении имен так сложен! Если бы в вашем доме часть электроэнергии с напряжением 80 В поставлялась телефонной компанией, другая часть — телеграфной компанией в виде постоянного тока, а оставшаяся часть приходила от традиционного поставщика электроэнергии, и вы бы никогда не знали точно, какой вид энергии питает ваш блендер, компьютер или, к примеру, аппарат искусственного дыхания, это сделало бы диагностику неработающих устройств чрезвычайно затруднительной. Упростите разрешение имен, и искать причину неисправностей станет легче.
Перед выключением WINS следует протестировать конфигурацию сети без этой службы (включая настройку параметра «NetBIOS через TCP/IP» в свойствах TCP/IP). Думаю, вас удивит ничтожное количество или даже полное отсутствие элементов, по-прежнему нуждающихся в WINS, хотя это зависит от степени новизны вашей клиентской и серверной операционных систем. Для Windows 2000 Server выключение WINS — неудачная идея; для Windows Server 2003 и Windows XP — задача выполнимая, но время от времени доставляющая много хлопот; а для Vista и более новых версий — совершенно безопасная. Следует, однако, понимать, что даже если операционная система способна обойтись без NetBIOS, то для приложений это может оказаться невозможным. Я слышал, что некоторые приложения для защиты от вредоносных программ нуждаются в NetBIOS, хотя мне такая ситуация незнакома. Если WINS нужна для какого-либо приложения, рассмотрите возможность использования зоны GlobalNames в Server 2008, способной помочь DNS взять на себя часть функций WINS.
Просмотр текущих корневых ссылок
Запустите консоль DNS.
Добавьте или подключитесь к DNS-серверу, который не прошел рекурсивный запрос.
Щелкните правой кнопкой мыши сервер и выберите пункт Свойства.
Щелкните корневые ссылки.
Проверьте наличие базовых подключений к корневым серверам.
Если правильно настроены корневые ссылки, убедитесь, что DNS-сервер, используемый в разрешении имен с ошибками, может проверить связь с корневыми серверами по IP-адресу.
Если корневые серверы не отвечают на проверку связи по IP-адресу, IP-адреса для корневых серверов могли измениться. Однако нередко можно увидеть перенастройку корневых серверов.
Диагностика разрешения имен (nslookup, dig)
Разобравшись с сетевой связностью и маршрутизацией приходим к следующему этапу — разрешение доменных имен. В большинстве случаев в работе с удаленными сервисами мы не используем IP-адреса, а указываем доменные имена удаленных ресурсов. За перевод символических имен в IP-адреса отвечает служба DNS — это сеть серверов, которые содержат актуальную информацию о соответствии имен и IP в пределах доверенных им доменных зон.
Способы выяснения какой DNS-сервер использует наш сервер различаются в зависимости от используемой версии и дистрибутива ОС Linux. Например, если ОС используется Network Manager для управления сетевыми интерфейсами (CentOS, RedHat и др.), может помочь вывод команды nmcli:
Скриншот №7. Команда nmcli
В настройках сетевого интерфейса, в разделе DNS configuration, мы увидим IP-адрес сервера. В Ubuntu 18.04 и выше, использующих Netplan, используем команду systemd-resolve --status:
Скриншот №8. Команда 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
После успешной установки сделаем тестовые запросы:
Скриншот №9. Тестовые запросы
Скриншот №10. Подтверждение корректной работы
Аналогичный запрос утилитой nslookup выдает более компактный вывод, но вся нужная сейчас информация в нем присутствует.
Скриншот №11. Отправка тестового запроса 1
Скриншот №12. Отправка тестового запроса 2
Если имена разрешаются публичным DNS-сервером корректно, а установленным по умолчанию в ОС нет, вероятно, есть проблема в работе этого DNS-сервера. Временным решением данной проблемы может быть использование публичного DNS-сервера в качестве сервера для разрешения имен в операционной системе. В том случае, если разрешение имен не работает ни через локальный, ни через публичный DNS сервер — стоит проверить не блокируют ли правила файрвола отправку на удаленный порт 53 TCP/UDP пакетов (именно на этом порту DNS-серверы принимают запросы).
Часто используемые параметры:
Как обычно, полный набор опций и параметров для указанных утилит можно найти во встроенной справке операционной системы, используя команду man.
В этой статье описывается, как устранять неполадки на DNS-серверах.
Избегайте регистрации нежелательной карты сетевого интерфейса в DNS
Если карта сетевого интерфейса настроена для регистрации адреса подключения в DNS, клиентская служба DHCP/DNS зарегистрирует запись в DNS. Нежелательные сетевые карты должны быть настроены не для регистрации адреса подключения в DNS.
- В сетевых подключениях откройте свойства нежелательной сетевой карты, откройте свойства TCP/IP, выберите AdvancedDNS > , а затем скройте адрес регистра этих подключений в поле DNS.
- В левой области откройте консоль сервера DNS, выделяем сервер и выберите ActionProperties > . На вкладке Интерфейсы выберите прослушивать только следующие IP-адреса. Удалите нежелательный IP-адрес из списка.
- На странице Свойства зоны выберите вкладку Сервер имен . Помимо FQDN контроллера домена, вы увидите IP-адрес, связанный с контроллером домена. Удалите нежелательный IP-адрес, если он указан.
- После этого удалите существующую запись нежелательного хозяйского "A" контроллера домена.
Запрос запроса DNS может быть неоформен, если сервер DNS передает запрос недоставным переадрежимателям или корневым подсказкам. Выполните следующие действия, чтобы устранить эту проблему:
- Откройте консоль DNS на DNS-сервере и проверьте, можно ли дотянуться до переадтрансаторов или условных переадителей. Если некоторые из переадителей недоступны, удалите их.
- Если DNS-серверу не требуется использовать forwarders и Root Hints, откройте консоль DNS на DNS-сервере, откройте окно свойства сервера, выберите Advanced и включим повторную рекурсию Отключения . (Это также отключает forwarders.)
Откажитесь от Nslookup и пользуйтесь DIG
Основное средство диагностики DNS в Windows — это, безусловно, Nslookup. Но знаете ли вы о том, что приверженцы UNIX уже на протяжении ряда лет имеют отличную альтернативу — программу поиска информации о домене DIG? Программа DIG не встроена в Windows, но ее легко найти, и она станет прекрасным дополнением к вашему инструментарию для обслуживания DNS.
Теперь создайте папку на жестком диске своей системы, добавьте ее в переменную среды PATH и скопируйте файлы из архива BIND в эту папку. Если хотите, можете удалить все из этой папки, кроме файлов DLL, dig.exe и dig.html (файл справки DIG). Поскольку мы не работаем с BIND, лишние файлы нам не нужны.
Основной синтаксис DIG выглядит следующим образом:
Таким образом, запрос
Одна из важнейших подсистем, отвечающая за связь любого сервера с внешним миром — сетевая. Через сетевые интерфейсы поступают запросы от удаленных систем и через эти же интерфейсы направляются ответы, что позволяет налаживать коммуникацию и предоставлять/получать сервисы. В связи с этим особенно важно уметь производить диагностику и мониторинг сети хотя бы на базовом уровне, чтобы выявлять проблемы и вносить корректировки в конфигурацию в случае необходимости.
Для операционных систем семейства Linux написано множество утилит, помогающих в диагностике и мониторинге. Познакомимся с наиболее часто используемыми из них.
Тестирование неработающего делегирования
Начните тесты в следующей процедуре, запросив допустимый корневой сервер. Этот тест позволяет выполнить запрос всех DNS-серверов из корня к серверу, который тестируется для неработающего делегирования.
В командной строке на тестируемом сервере введите следующее:
Тип записи ресурса — это тип записи ресурса, для которой был выполнен запрос в исходном запросе, а полное доменное имя — полное доменное имя, для которого выполнялись запросы (заканчивающиеся точкой).
Если ответ содержит список записей ресурсов "NS" и "A" для делегированных серверов, повторите шаг 1 для каждого сервера и используйте IP-адрес из записей ресурсов "A" в качестве IP-адреса сервера.
Если ответ не содержит запись ресурса NS, делегирование будет разорвано.
Если ответ содержит записи ресурсов "NS", но нет записей ресурсов "A", введите " задать рекурсию" и выполните запрос по отдельности для записей ресурсов "a" серверов, перечисленных в записях NS. Если вы не нашли по меньшей мере один допустимый IP-адрес записи ресурса "A" для каждой записи ресурса NS в зоне, то у вас есть неработающее делегирование.
Если вы определили, что вы используете неработающее делегирование, исправьте его, добавив или обновив запись ресурса "A" в родительской зоне, используя допустимый IP-адрес для соответствующего DNS-сервера для делегированной зоны.
Применение утилиты командной строки TRACERT
Утилита TRACERT является ценным источником информации, позволяющим получить представление о пути, который проходит DNS-запрос при его пересылке по сети.
с отказом. После этого исходная система увеличит TTL-значение на 1 и отправит пакет снова. На этот раз пакет пройдет через первый маршрутизатор, но получит отказ от второго. Таким образом этот процесс продолжается до тех пор, пока пакет не достигнет своего места назначения. Из этого становится совершенно очевидно, что данная утилита предоставляет простой, но очень эффективный способ для просмотра пути, который DNS-запрос проходит при его передаче через Интернет.
Проблемы с зонными ошибками
Выполните следующие проверки:
Проверьте Просмотр событий как для основного, так и для дополнительного DNS-сервера.
Проверьте сервер источника, чтобы узнать, не отправит ли он передачу данных для безопасности.
Проверьте вкладку зонные передачи свойств зоны в консоли DNS. Если сервер ограничит передачу зоны на список серверов, например на вкладке серверы имен в свойствах зоны, убедитесь, что сервер-получатель находится в этом списке. Убедитесь, что сервер настроен на отправку зонных передач.
Проверьте наличие проблем на основном сервере, выполнив действия, описанные в разделе Проверка проблем DNS-сервера . Когда появится запрос на выполнение задачи на клиенте, выполните задачу на сервере-получателе.
Проверьте, не работает ли на сервере-получателе другая реализация сервера DNS, например BIND. Если это так, проблема может быть вызвана одной из следующих причин:
Windows сервер-источник может быть настроен для отправки быстрых зонных передач, но сервер-получатель стороннего производителя может не поддерживать быструю передачу зоны. В этом случае отключите передачу данных с помощью быстрой зоны на сервере-источнике из консоли DNS, установив флажок включить вторичные базы данных-получатели на вкладке Дополнительно свойств сервера.
если зона прямого просмотра на Windows сервере содержит тип записи (например, запись SRV), которую сервер-получатель не поддерживает, то на сервере-получателе могут возникнуть проблемы с извлечением зоны.
Проверьте, запущена ли на сервере-источнике другая реализация сервера DNS, например BIND. если да, то возможно, что зона на сервере источника включает несовместимые записи ресурсов, которые Windows не распознает.
Если на главном или вторичном сервере используется другая реализация DNS-сервера, проверьте оба сервера, чтобы убедиться, что они поддерживают одни и те же функции. сервер Windows можно проверить на консоли DNS на вкладке дополнительно страницы свойства сервера. В дополнение к полю включить вторичные получатели привязок на этой странице содержится раскрывающийся список Проверка имен . Это позволяет выбрать принудительное соответствие требованиям RFC для символов в DNS-именах.
Это решение предназначено для устранения неполадок сценариев системы доменных имен (DNS). Устранение неполадок DNS можно разбить на серверные и клиентские проблемы.
Проверка IP-конфигурации
Выполните ipconfig /all команду из командной строки и проверьте IP-адрес, маску подсети и шлюз по умолчанию.
Проверьте, является ли DNS-сервер полномочным для имени, которое ищется. Если это так, см. раздел Проверка на наличие проблем с достоверными данными.
Выполните следующую команду.
Если вы получаете ответ об ошибке или истечении времени ожидания, см. раздел Проверка проблем с рекурсией.
Очистка кэша сопоставителя. Для этого выполните следующую команду в окне командной строки с правами администратора:
Или в окне администрирования PowerShell выполните следующий командлет:
Повторите шаг 3.
Выключите WINS
Когда говорят о проверке DNS, под этим подразумевают проверку всей инфраструктуры разрешения имен, что включает локальные широковещательные пакеты от NetBIOS, WINS и компонент «Сетевое обнаружение», пришедший на смену «Сетевому окружению» вместе с Windows Vista, не говоря уже о файлах HOSTS и LMHOSTS. Неудивительно, что поиск неполадок в разрешении имен так сложен! Если бы в вашем доме часть электроэнергии с напряжением 80 В поставлялась телефонной компанией, другая часть — телеграфной компанией в виде постоянного тока, а оставшаяся часть приходила от традиционного поставщика электроэнергии, и вы бы никогда не знали точно, какой вид энергии питает ваш блендер, компьютер или, к примеру, аппарат искусственного дыхания, это сделало бы диагностику неработающих устройств чрезвычайно затруднительной. Упростите разрешение имен, и искать причину неисправностей станет легче.
Перед выключением WINS следует протестировать конфигурацию сети без этой службы (включая настройку параметра «NetBIOS через TCP/IP» в свойствах TCP/IP). Думаю, вас удивит ничтожное количество или даже полное отсутствие элементов, по-прежнему нуждающихся в WINS, хотя это зависит от степени новизны вашей клиентской и серверной операционных систем. Для Windows 2000 Server выключение WINS — неудачная идея; для Windows Server 2003 и Windows XP — задача выполнимая, но время от времени доставляющая много хлопот; а для Vista и более новых версий — совершенно безопасная. Следует, однако, понимать, что даже если операционная система способна обойтись без NetBIOS, то для приложений это может оказаться невозможным. Я слышал, что некоторые приложения для защиты от вредоносных программ нуждаются в NetBIOS, хотя мне такая ситуация незнакома. Если WINS нужна для какого-либо приложения, рассмотрите возможность использования зоны GlobalNames в Server 2008, способной помочь DNS взять на себя часть функций WINS.
Тестирование с помощью запроса 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.
Диагностика сетевой связности (ping, arp, traceroute)
В данной статье мы будем опираться на использование протокола IP версии 4. Согласно стандартам, определяющим работу этого протокола, каждое устройство, подключенное к сети, должно иметь как минимум IP-адрес и маску подсети — параметры, которые позволяют уникально идентифицировать устройство в пределах определенной сети. В такой конфигурации устройство может обмениваться сетевыми пакетами с другими устройствами в пределах той же самой логической сети. Если к этому набору параметров добавить адрес шлюза по умолчанию — наш сервер сможет связываться с хостами, находящимися за пределами локального адресного пространства.
В случае каких-либо сетевых проблем в первую очередь проверяем, не сбились ли настройки сетевого интерфейса. Например, команды ip addr или ifconfig выведут IP-адрес и маску сети:
Скриншот №1. Проверки настроек сетевого интерфейса
В выводе команды виден перечень сетевых интерфейсов, распознанных операционной системой. Интерфейс lo — это псевдоинтерфейс (loopback). Он не используется в реальных взаимодействиях с удаленными хостами, а вот интерфейс с именем ens192 — то, что нам нужно (именование сетевых интерфейсов различается в разных ветках и версиях ОС Linux). IP-адрес и маска сети, назначенные этому интерфейсу, указаны в поле inet — /24 после адреса обозначают 24-битную маску 255.255.255.0.
Теперь проверим, указан ли шлюз по умолчанию. Команды ip route или route покажут имеющиеся маршруты:
Скриншот №2. Проверка маршрута
В таблице маршрутизации мы видим, что имеется маршрут по умолчанию (обозначается либо ключевым словом 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 и проверим результат:
Скриншот №4. Команда arp –n
Команда выведет список IP-адресов (так как был использован аргумент –n), и соответствующие им MAC-адреса хостов, находящиеся в одной сети с нашим сервером. Если в этом списке есть IP, который мы пытаемся пинговать, и соответствующий ему MAC, значит сеть работает и, возможно, ICMP-пакеты, которые использует команда ping, просто блокируются файрволом (либо со стороны отправителя, либо со стороны получателя). Подробнее об управлении правилами файрвола рассказано здесь и здесь.
Часто используемые параметры:
- arp –n — вывод содержимого локального arp-кэша в числовом формате. Без этой опции будет предпринята попытка определить символические имена хостов;
- arp –d адрес — удаление указанного адреса из кэша. Это может быть полезно для проверки корректности разрешения адреса. Чтобы убедиться, что в настоящий момент времени адрес разрешается корректно, можно удалить его из кэша и снова запустить ping. Если все работает правильно, адрес снова появится в кэше.
Если все предыдущие шаги завершены корректно, проверяем работу маршрутизатора — запускаем ping до сервера за пределами нашей сети, например, 8.8.8.8 (DNS-сервис от Google). Если все работает корректно, получаем результат:
Скриншот №5. Проверка работы маршрутизатора
Скриншот №6. Утилита traceroute
Первым маршрутизатором на пути пакета должен быть наш локальный шлюз по умолчанию. Если дальше него пакет не уходит, возможно проблема в конфигурации маршрутизатора и нужно разбираться с ним. Если пакеты теряются на дальнейших шагах, возможно, есть проблема в промежуточной сети. А, возможно, промежуточные маршрутизаторы не отсылают ответные пакеты. В этом случае можно переключиться на использование другого протокола в traceroute.
Часто используемые опции:
- traceroute –n — вывод результата в числовом формате вместо символических имен промежуточных узлов;
- traceroute –I — использование ICMP-протокола при отслеживании маршрута. По умолчанию используются UDP-датаграммы;
- traceroute –s адрес— указать адрес источника для исходящего сетевого пакета;
- traceroute –i интерфейс— указать сетевой интерфейс, с которого будут отправляться пакеты.
Журнал событий
Проверьте следующие журналы, чтобы узнать, есть ли записанные ошибки:
Проблемы на стороне сервера
- Конфигурация IP
- DNS-сервер
- Авторитетные данные
- Повторение
- Перенос зоны
Общие проблемы и решения
Event ID 4004 и event ID 4013
Сервер DNS не смог открыть Active Directory. Этот DNS-сервер настроен на использование данных службы каталогов и не может работать без доступа к каталогу. DNS-сервер будет ждать запуска каталога. Если DNS-сервер запущен, но соответствующее событие не было в журнале, то DNS-сервер по-прежнему ожидает запуска каталога.
Чтобы устранить эту проблему, см. в выпуске Устранение неполадок AD DS и перезапуск службы DNS Server
Еще одним важным инструментом для поиска и устранения проблем, связанных с преобразованием имен в DNS, является утилита IPCONFIG, которая также используется для устранения наиболее распространенных проблем с TCP/IP. В отношении DNS утилита IPCONFIG позволяет выполнять несколько важных операций. Эти операции инициируются из командной строки указанием соответствующих параметров, которые описаны ниже.
- ipconfig /f lushdns. При возникновении проблем с кэшем на стороне клиента его содержимое может быть сброшено за счет применения флага f lushdns. Этот флаг позволяет удалить все помещенные ранее в кэш запросы, которые может хранить клиент, и особенно полезен в случае, если на сервере имен только что поменялись IP-адреса и у каких-то клиентов теперь из-за этого возникают трудности с подключением к нему.
- ipconfig /regis terdns. Флаг registerdns заставляет клиента динамически перерегистрировать себя в DNS, если данная зона поддерживает динамические обновления.
- ipconfig /displaydns. Этот флаг является очень интересным, но мало кому известным. Он позволяет отобразить содержимое клиентского кэша и помогает в выявлении определенных проблем с отдельными записями.
Если сервер является сервером-источником
Проблема может быть вызвана ошибкой пользователя при вводе пользователем данных в зону. Кроме того, это может быть вызвано проблемой, которая влияет на Active Directory репликацию или динамическое обновление.
Проверка неполадок DNS-сервера
Если на сервере размещается дополнительная копия зоны
Изучите зону на сервере-источнике (сервере, с которого этот сервер извлекает зоны).
Вы можете определить, какой сервер является сервером-источником, проверив свойства дополнительной зоны в консоли DNS.
Если на сервере-источнике указано неправильное имя, перейдите к шагу 4.
Если на сервере-источнике указано правильное имя, убедитесь, что серийный номер на сервере-источнике меньше или равен серийному номеру на сервере-получателе. Если это так, измените либо сервер-источник, либо сервер-получатель, чтобы серийный номер на сервере-источнике был больше, чем серийный номер на сервере-получателе.
На сервере-получателе выполните принудительную пересылку зоны с помощью консоли DNS или выполните следующую команду:
Изучите сервер-получатель еще раз, чтобы узнать, правильно ли передана зона. В противном случае у вас, вероятно, возникает проблема с переносом зоны. Дополнительные сведения см. в статье проблемы зонных передач.
Если зона была передана правильно, проверьте, правильно ли указаны данные. В противном случае данные в основной зоне неверны. Проблема может быть вызвана ошибкой пользователя при вводе пользователем данных в зону. Кроме того, это может быть вызвано проблемой, которая влияет на Active Directory репликацию или динамическое обновление.
Читайте также:
- Когда изобрели механический компьютер
- Это тот кто не любит не доверяет или не хочет использовать технологии особенно компьютеры
- Finereader ошибка в пакете безопасности
- Определите максимальную глубину цвета в битах на пиксель которую можно использовать при фотосъемке
- Документ или фальсификация факт и его компьютерная трактовка