Возникли неполадки с Active Directory (AD)? Вероятнее всего, что на самом деле это проблема DNS. Не можете зарегистрироваться с учетной записью электронной почты, Twitter или Facebook? Скорее всего, и это проблема DNS. Выявление связанных с DNS неполадок — шаг номер два в диагностике практически любой сетевой проблемы, однако их устранение подобно стрельбе по движущейся мишени из-за постоянного изменения ситуации. Мы уже не раз обсуждали основы диагностики неисправностей DNS, поэтому сегодня я предлагаю выйти за рамки азов и по-новому взглянуть на известную проблему. .

Выключите 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.

Используйте сетевой монитор

О сетевом мониторе знает каждый, но большинство пользователей боятся с ним работать — и совершенно напрасно. Сетевой монитор собирает и отображает данные обо всех входящих и исходящих сетевых пакетах, позволяя анализировать каждый бит, проходящий через сетевой адаптер. Изначально Netmon кажется профессиональным инструментом, однако в какой-то мере он даже больше подходит для рядового специалиста, поскольку позволяет применить старый афоризм: «Трудно распознать больного, если не знаешь, как выглядит здоровый». Поэтому, если Netmon работает на вашей работающей системе, сохраните собранные данные, чтобы потом, если возникнет проблема, сравнить их с другой информацией.

Я замечал, что простое упоминание Netmon повергает некоторых пользователей в трепет, поэтому даю краткое руководство по Netmon и DNS для начинающих. Приведу пример, в котором сервер DNS на базе Server 2008 R2 выполняет разрешение адресов DNS. Поставим серверу задачу проверить связь с доменом bigfirm.com (то есть ping www.bigfirm.com) и собрать сведения о сетевом трафике с помощью Netmon. В результате получим массу в основном не относящихся к делу данных, из которых необходимо выбрать крупицы полезных сведений.

Первым делом установим сетевой монитор. Программа доступна для свободной загрузки по ссылке www.microsoft.com/downloads/en/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f. Запуская Netmon, щелкнем правой клавишей и выберем «Запуск от имени администратора». При первом запуске программа спросит, желаете ли вы использовать Microsoft Update. Проигнорируем этот вопрос и увидим экран приветствия (экран 1). В нижней левой секции укажем отслеживаемый трафик. Позиции isatap и Teredo нас не интересуют, поэтому снимаем отметку этих флажков. Оставим лишь отметку флажка «Подключение по локальной сети». Параметр «P-Mode» игнорируем. Откроем вкладку New capture в верхней левой секции.

 

Экран 1. Экран приветствия Network Monitor

Окно сбора данных, показанное на экране 2, — одна из причин нежелания администраторов работать с Netmon. Для упрощения закроем панели Network Conversation слева и Hex Details в нижнем правом углу. Оставим лишь Display Filter, Frame Summary и Frame Details.

 

Экран 2. Экран сбора данных Network Monitor

Открываем командную строку, затем нажимаем на зеленый треугольник рядом с клавишей Start в окне Netmon. Ждем запуска Netmon, возвращаемся в командную строку и вводим следующую команду:

ping -n 1 www.bigfirm.com

После выполнения команды Ping возвращаемся в окно Netmon и нажимаем на синий квадрат рядом с клавишей Stop. Поздравляю с первым сбором данных! В нижней части окна Netmon указано количество зафиксированных сетевых пакетов. В зависимости от темпа вашей работы и загрузки сети вы можете получить от десятка до сотни фреймов данных. Независимо от количества, эти данные выглядят беспорядочно. Чтобы «отделить зерна от плевел», создадим фильтр дисплея.

Чтобы оставить только данные о трафике, относящемся к DNS, вводим DNS в текстовое поле «Display Filter» и нажимаем «Применить». Результат показан на экране 3. В данном примере мы видим только шесть пакетов, представляющих интерес. Столбцы «Process», «Time Offset» и «TimeDateLocalAdjusted» я удалил за ненадобностью.

 

Экран 3. Просмотр трафика, относящегося к DNS

Эти шесть пакетов данных показывают, как сервер DNS находит практически любой узел в любом домене. com. Сначала ваш локальный сервер DNS запрашивает у корневого сервера адрес узла www.bigfirm.com (пакет 6, примечание Query for www.bigfirm.com…), на что корневой сервер отвечает рекомендацией обратиться к одному из серверов DNS для зоны .com (пакет 7, примечание Response — Success). Затем ваш сервер DNS запрашивает адрес хоста www.bigfirm.com у сервера DNS зоны. com (пакет 8) и на этот раз получает рекомендацию запросить сервер DNS домена bigfirm.com (пакет 9). Запросив адрес хоста www.bigfirm.com у сервера DNS домена bigfirm.com (пакет 10), ваш сервер DNS наконец получает желаемый ответ (пакет 11). Заметим, что отслеживание взаимодействия сторон облегчают столбцы Source и Destination: мой локальный сервер DNS — 19.168.1.125; корневой сервер — 192.203.230.10; сервер DNS.com — d.gtld-servers; сервер DNS для bigfirm.com — web2.minasi.com. Безусловно, это анализ высокого уровня.

Для просмотра иерархии пакетов щелкаем на первом отфильтрованном фрейме и смотрим на панель Frame Details. На экране 4 показана иерархия пакетов, на языке Netmon называемая «фреймом». Этот фрейм включает пакет Ethernet, который, в свою очередь, содержит пакет IPv4. Внутри IPv4 — пакет UDP (это может быть TCP, но большая часть трафика DNS использует UDP), а внутри последнего — актуальный запрос DNS. Сводная информация каждого уровня содержит указание адресов, портов и размера (длины). Для спуска на следующий уровень щелкаем по знаку «плюс» и разворачиваем фрейм DNS, как показано на экране 5. Уровень детализации информации Netmon говорит сам за себя. Мы видим, что это — запрос (а не ответ), вопрос (запись узла для www.bigfirm.com) и дополнительная запись, о которой будем говорить ниже.

 

Экран 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, я бы потратил много часов в попытках устранить возможные причины.

Откажитесь от Nslookup и пользуйтесь DIG

Основное средство диагностики DNS в Windows — это, безусловно, Nslookup. Но знаете ли вы о том, что приверженцы UNIX уже на протяжении ряда лет имеют отличную альтернативу — программу поиска информации о домене DIG? Программа DIG не встроена в Windows, но ее легко найти, и она станет прекрасным дополнением к вашему инструментарию для обслуживания DNS.

Загрузить DIG можно с сайта организации Internet Systems Consortium (www.isc.org/downloads), на котором доступна последняя версия BIND (сегодня это BIND 9.7.2-P3). BIND — это открытая и наиболее распространенная реализация сервера DNS.

Теперь создайте папку на жестком диске своей системы, добавьте ее в переменную среды PATH и скопируйте файлы из архива BIND в эту папку. Если хотите, можете удалить все из этой папки, кроме файлов DLL, dig.exe и dig.html (файл справки DIG). Поскольку мы не работаем с BIND, лишние файлы нам не нужны.

Основной синтаксис DIG выглядит следующим образом:

dig record-to-query-for [@dnsserver]
   [querytype] [+option1, +option2…]

Таким образом, запрос

dig bigfirm.com ns @192.168.1.125

указывает программе DIG запросить у DNS-сервера по адресу 192.168.1.125 все записи сервера имен для bigfirm.com. На экране 6 показан ответ на этот запрос. Отметим более высокий уровень детализации выходных данных DIG, чем у Nslookup.

 

Экран 6. Ответ на запрос DIG

Спустимся вниз к двум строкам, которые начинаются с ->>HEADER<<-. Здесь можно увидеть информацию заголовка DNS, по сути взятую из фрейма и несколько переформатированную. Данные status указывают на неудачно выполненный запрос из-за несуществующей записи (NXDOMAIN), наличие некой ошибки в настройках на сервере (SERVFAIL), отсутствие ошибок (NOERROR) либо несостоятельность запроса (например, запрос о несуществующем типе записи (FORERR)).

Далее в заголовке DNS видим флаги. Важная особенность DIG — возможность установки флагов с определенными значениями в заголовок DNS при формировании запроса. Так, например, при добавлении параметра +norecurse, программа DIG установила бы флаг, предписывающий серверу DNS выполнить лишь первый шаг в разрешении bigfirm.com, что в данном случае вернуло бы только корневые серверы.

Параметр +trace продвигает процесс на один шаг дальше, заставляя DIG вывести на печать все действия в момент нахождения сервера DNS для bigfirm.com. Этот инструмент очень полезен всем, кто работает с AD, поскольку требования безопасности вынуждают нас использовать наши иерархии DNS, обслуживающие Active Directory, за рамками общедоступной иерархии, что может привести к многочисленным ошибкам в настройках, выявить которые поможет параметр +trace. Поместите DIG на флэш-накопитель USB и запускайте эту программу на проблемной системе с параметром +trace, чтобы найти запись узла для контроллера домена (DC). Это действие во многих случаях прольет свет на источник проблемы. Попробуйте DIG, и я ручаюсь, что к Nslookup вы больше не вернетесь.

Включите EDNS

Завершим тему, с которой я постоянно сталкиваюсь и по которой мне постоянно задают вопросы. Я обнаружил, что механизмы расширения для DNS (EDNS) обвиняют в том, что они делают серверы DNS на базе Server 2008 R2 неспособными к разрешению общих доменных имен Интернета, поэтому EDNS следует выключать. На самом же деле EDNS — не новый компонент, и обвиняется несправедливо. Как в случае со многими основными протоколами Интернета, наши требования к DNS переросли исходные спецификации 1983 года (RFC 882), вынуждая регулирующие органы Интернета изыскивать средства для «втискивания» новых возможностей в тесное и жестко регламентированное пространство.

Под «жестким регламентом» DNS я понимаю зависимость этой службы от малого числа однобитовых флагов, указывающих на необходимость рекурсии для данного запроса, способность данного сервера DNS к рекурсивному поиску и т. д. Исходные запросы RFC оставляют пространство лишь для семи флагов, из которых лишь один не используется. Думаете решить проблему DNS путем добавления полезного нового флага? Очень жаль, но на сегодня «в гостинице мест нет».

Проблема ограниченного пространства вытекает из ограничений на максимальный размер пакета UDP в 512 байт (а связь по UDP предпочтительна, учитывая быстроту этого протокола и большой объем трафика DNS). Эта 512-байтовая граница была установлена спецификациями RFC 883 (1983 г.) и 1035 (1987 г.) и основана на сетевых реалиях 1980-х, которые теперь неприменимы. Замечали ли вы, что очень мало доменов в Интернете имеют более 13 серверов DNS? Даже чрезвычайно перегруженный работой корневой домен объявляет о наличии 13 серверов DNS, даже если реально он ведет 236 серверов и использует кластеризацию, чтобы заставить большое количество выглядеть небольшим. Это вызвано тем, что, объявив о более чем 13 серверах, пришлось бы создавать пакет больше 512 байт и перейти на гораздо более медленный TCP.

Итак, мы нуждались в большем количестве флагов и более крупных пакетах, но при этом не желали расширять DNS, порождая мировую проблему совместимости. Решением стала спецификация RFC 2671 от 1999 г. и механизмы расширения для DNS (EDNS). В EDNS был реализован разумный способ, позволяющий неизменно растущей популяции серверов DNS (с поддержкой EDNS) понимать, взаимодействуют ли они с серверами, также поддерживающими EDNS (и поэтому пользующимися преимуществами большего числа флагов и большего пространства), либо с серверами без таковой поддержки (и в этом случае они остаются в рамках ограничений, существовавших до появления RFC 2671, что позволяет избежать проблем совместимости).

Когда запросившая сторона с поддержкой EDNS запрашивает у респондента запись DNS, отвечающая сторона составляет ответ в стандартном формате DNS, но добавляет запись под названием «запись OPT». Запись OPT отличается от более знакомых записей DNS, таких как A, MX, NS, SOA и CNAME, и ее нельзя увидеть в файле зоны. Она больше напоминает обмен секретной информацией, о которой знают только серверы с поддержкой EDNS. Это лишь небольшое количество данных, добавляемых к запросу.

К примеру, предположим, что сторона-инициатор с поддержкой EDNS запрашивает у сервера DNS запись A для системы PC1 в зоне bigfirm.com. При отсутствии поддержки EDNS, эта сторона просто запросила бы запись A у респондента. В противоположность этому, при наличии поддержки EDNS запрос содержит также запись OPT с указанием значения 4000. Значение 4000 указывает на возможность обработки пакета UDP размером до 4000 байт. Респондент без поддержки EDNS не распознает запись OPT и просто проигнорирует ее, отвечая лишь на знакомый тип запроса о записи A без выдачи сообщения об ошибке (тем самым поддерживая обратную совместимость). Респондент с поддержкой EDNS ответит на запрос о записи A и на запрос OPT. Ответ OPT также содержит число, указывающее размер пакета UDP, который респондент способен обрабатывать. Таким образом, если запрашивающая сторона отсылает запрос OPT=4096, а респондент возвращает ответ OPT=1280, то запрашивающая сторона знает, во-первых, что респондент поддерживает EDNS, а во-вторых, что можно использовать пакеты UDP большего размера, но не более 1280 байт.

Возможен ли сбой этого процесса? Представим, что сервер Server 2008 R2 с поддержкой EDNS запрашивает другой сервер с поддержкой EDNS, и они договариваются использовать пакет UDP большего размера, чем 512 байт. Пакет такого размера может оказаться разбитым на куски (что практически исключено для 512-байтовых пакетов), а многие недорогие маршрутизаторы с преобразованием сетевых адресов NAT отклоняют фрагментированные пакеты. Больше того, некоторые брандмауэры имеют правила безопасности, согласно которым «DNS и UDP, чей размер больше 512 байт, скорее всего, вредоносны, поэтому их следует отклонять». В любом случае результат одинаковый: неудачный результат разрешения имен.

Лучшее решение — выяснить, какой транзитный участок вызвал проблему, но это не всегда возможно. Другой вариант решения — просто указать серверу Server 2008 R2 более не отсылать запросы OPT, тем самым исключая инициирование транзакций EDNS. Для этого в окне командной строки с повышенными привилегиями введите следующую команду:

dnscmd/config/enableednsprobes 0

После этой команды перезагрузка не требуется, а эффект от ее выполнения отменяется заменой 0 на 1. Единственным результатом этой команды является исключение для Server 2008 R2 возможности общения EDNS. Если сервер DNS обращается к серверу Server 2008 R2 с запросом, содержащим пакет OPT, сервер Server 2008 R2 уместным образом отвечает в манере, принятой EDNS, поэтому исключите наличие у ваших маршрутизаторов и брандмауэров на выходе фильтров, уничтожающих большие пакеты UDP от службы DNS.

Технология EDNS — не новая для Windows Server и поддерживается уже начиная с Windows Server 2003. Единственное изменение в Server 2008 R2 — включение механизмов EDNS по умолчанию. EDNS также не является неким экзотическим протоколом. Напротив, как показывает анализ трафика в Интернете, по меньшей мере 85% серверов DNS всех типов поддерживают эту технологию и применяют ее с пользой. Было бы жаль лишить службу DNS в Server 2008 R2 преимуществ EDNS, поэтому лучше внесите небольшие изменения в настройки маршрутизатора, прежде чем запретить своему серверу DNS использовать EDNS.

Планируйте заранее

Неполадки DNS — ощутимая проблема, но она легко решается путем выполнения некоторых организационных действий и использования передовых инструментальных средств и новшеств. Попробуйте применить что-либо из того, о чем вы узнали из этой статьи, и вы будете готовы к преодолению неприятных ситуаций, если таковые возникнут.

Марк Минаси (www.minasi.com/gethelp) — старший редактор журнала Windows IT Pro, сертифицированный системный инженер по продуктам Microsoft