Правдивые истории об ошибках в работе DNS/AD

В сети возникли проблемы с Active Directory (AD)? Для некоторых контроллеров домена репликация не выполняется, и они не получают обновления AD? Часть пользователей увидели на своих мониторах сообщение об ошибке No domain controller found? Dcpromo по непонятным причинам выдает сбой? Если все это так, возможно, причина проблем не в AD, а в DNS.

Значительная доля обращений к AD связана с поиском определенных серверов: контроллеров домена (DC), серверов глобального каталога (Global Catalog — GC), а также, если репликация выполняется через SMTP, - почтовых серверов. Если найти один из таких серверов невозможно, не удастся «довести до сведения» AD, что именно нужно сделать. AD ищет все перечисленные серверы, опрашивая серверы DNS, поэтому в большинстве случаев сбои AD связаны с проблемами в работе DNS. По крайней мере, так показывает мой опыт работы. А большинство проблем DNS произрастают из ошибок в настройке, о которых пойдет речь в настоящей статье. Начнем с самых общих проблем, свойственных многодоменному лесу.

На внутреннем сервере DNS отсутствуют копии со всех доменов леса

AD нужны сведения об инфраструктуре DNS, т. е. данные о серверах DNS в корпоративной сети. На этих серверах содержатся записи, содержащие (как минимум) местоположение серверов DC и серверов — членов домена — и, возможно, рабочих станций. Вычислительные сети используют DNS вот уже два десятка лет, т. е. гораздо дольше, чем существует AD, поэтому построение DNS для AD не должно быть очень сложной задачей. Однако большинство инфраструктур DNS проектировались с расчетом на видимость в общедоступной сети Internet, а все, естественно, хотят, чтобы настройки DNS для корпоративной AD не были видны кому бы то ни было в Internet. Следовательно, практически все структуры DNS, отображающие конкретные реализации AD, должны быть изолированы от Internet. Для этого используется техника настройки DNS, известная под названием разделение (split-brain) DNS. В результате получается конфигурация, которая соответствует требованиям, отсутствующим при несложной унифицированной установке DNS.

Самое важное требование заключается в том, что каждый сервер DNS внутри корпоративной сети должен иметь локальные копии информации DNS, — на языке DNS это звучит как «иметь файл зоны DNS»- для каждого домена леса. Предположим, я посчитал, что обойдусь одним-единственным локальным доменом с названием bigfirm.biz. Но если исходить из того, что предприятие будет расширяться, для подстраховки я создам не один, а два домена: bigfirm.biz и пустой корневой домен леса с названием root.local. Каждой копии AD требуется зона DNS, поэтому мне понадобятся зоны с именами root.local и bigfirm.biz.

Сначала я создаю домен root.local, поскольку это корневой домен леса. Для этого я устанавливаю DNS на станции Windows Server 2003 или Windows 2000 и создаю зону root.local на соответствующем сервере. Поскольку домен root.local имеет ограниченное число станций и учетных записей, вполне логично, если один и тот же сервер будет сервером DNS и контроллером домена (DC). Я установил этот самый первый сервер как основной DNS-сервер для динамической зоны root.local, сообщив системе об использовании самой себя в качестве предпочтительного сервера DNS, а затем запустил Dcpromo для создания домена AD с именем root.local.

Теперь я устанавливаю второй сервер как вспомогательный DNS-сервер для root.local и снова сообщаю системе об использовании самой себя в качестве предпочтительного сервера DNS. С помощью настроек вспомогательному серверу сообщается о необходимости забрать обновленные данные о зоне root.local с основного сервера DNS. Затем с помощью Dcpromo системе предписывается сделать то же самое для второго DC. Поскольку иметь только один DC для домена - неважно, каких он размеров, - большая ошибка.

Имея два сервера DNS/DC для root.local, я настроил корневой домен леса. Однако я не считаю, что все контроллеры домена должны быть серверами DNS. В домене, где имеется более двух серверов, часть серверов делают серверами DC, часть - серверами DNS, на усмотрение администратора. Предположим, что вместо этого я решил создать огромный домен root.local в однодоменном лесу. В этом случае мне понадобится только настроить все последующие серверы DNS как вспомогательные для домена root.local и извлечь их копии зоны root.local из root.local самого первого сервера DNS, который работает как основной DNS-сервер root.local. Кроме того, необходимо убедиться, что все компьютеры, которые я собираюсь сделать членами домена root.local, ссылаются на сервер DNS, который является или основным, или одним из вспомогательных для root.local.

Пока все идет отлично. Теперь займемся вторым доменом, bigfirm.biz. Как и в случае с root.local, я устанавливаю сервер с DNS, создаю динамическую зону bigfirm.biz, задаю на сервере ссылку на предпочтительный сервер DNS — на самого себя — и запускаю Dcpromo. Но Dcpromo выдаст ошибку, поскольку служба DNS на первом (и единственном) DNS-сервере bigfirm.biz не может найти зону root.local. Единственный способ помочь серверу DNS отыскать данную зону - записать локальную копию этой зоны на жесткий диск или попробовать отыскать ее в Internet на каком-нибудь сервере. Самый первый сервер DNS bigfirm.biz не имеет локальной копии зоны и, по самой сути построения, никогда не отыщет сервер DNS с зоной root.local в общедоступном Internet. Мне бы не хотелось, чтобы кто-то знал что-либо о моем файле зоны.

Я мог бы сделать первый DNS-сервер bigfirm.biz вспомогательным сервером для root.local, и тогда Dcpromo прекрасно бы справилась со своей задачей. Но в этом случае домены моего леса не нашли бы друг друга. Системы, ссылающиеся на серверы DNS, которые также являются контроллерами домена в root.local, будут не в состоянии отыскать контроллеры домена bigfirm.biz, так как серверы root.local не имеют локальной копии зоны bigfirm.biz. Что еще хуже, я мог бы создать еще больше серверов DNS в зоне bigfirm.biz и вспомнить о том, что их надо прописать как вспомогательные для зоны bigfirm.biz, но при этом забыть сделать их вспомогательными для root.local. Это было бы ошибкой, поскольку записи DNS, которые идентифицируют все значимые серверы глобального каталога GC домена, присутствуют только в зоне DNS для корневого домена леса. Следовательно, любые системы домена вне корня леса будут не в состоянии найти GC. Чтобы решить эту проблему, я должен скопировать зоны bigfirm.biz и root.local на каждый сервер DNS внутри корпоративной сети.

Вывод: каждый сервер DNS в сети компании должен быть или основным, или вспомогательным сервером DNS для каждого домена леса.

О предположении, что все автоматически заработает, если зоны DNS интегрировать в AD

Разговоры об основных и вспомогательных зонах DNS относятся к эпохе до появления Windows 2000, не так ли? Мне могут возразить, что более эффективно интегрировать зоны DNS в Active Directory. И это справедливо, ведь интеграция в Active Directory часто используется для получения сведений об инфраструктуре DNS.

К сожалению, хранение доменных зон root.local и bigfirm.biz в виде интегрированных зон AD (Active Directory-integrated zone) не решит проблемы серверов DNS в root.local, которые не смогут найти контроллеры домена и серверы DNS в bigfirm.biz, и наоборот. Интегрированные зоны AD в Windows 2000 совместно используют зонную информацию, относящуюся только к контроллерам данного домена. Получается, что если я построил root.local и bigfirm.biz вместе с интегрированными зонами AD, то DNS-серверы root.local будут иметь информацию только о root.local, а DNS-серверы bigfirm.biz - только о bigfirm.biz. И все равно мне придется зайти на каждый сервер DNS в root.local и прописать его как вспомогательный DNS-сервер для bigfirm.biz, а для каждого DNS-сервера в bigfirm.biz указать, что он также является вспомогательным DNS-сервером для root.local.

По умолчанию интегрированные зоны AD Windows 2003 точно так же реплицируют свою DNS-информацию, только на DC своего домена. Однако DNS Windows 2003 предоставляет возможность настроить репликацию интегрированных зон AD на все серверы DNS в лесу.

Вывод: даже если в лесу есть несколько доменов с интегрированными в AD зонами, все равно необходимо убедиться, что DNS-серверы произвольно выбранного домена являются также вспомогательными серверами DNS для интегрированных зон всех остальных доменов, если речь идет о Windows 2000. Или, если используется Windows 2003, требуется настроить реплицирование содержимого зон по всему лесу.

Рабочие станции и серверы ссылаются на сервер DNS вне корпоративной сети

Рабочая станция или сервер, которые ссылаются на DNS-сервер вне сети, по-видимому, самая распространенная ошибка при настройке DNS. Как уже говорилось, практически всегда при реализации AD требуется, чтобы инфраструктура DNS не была видна из Internet. Естественно, Bigfirm может иметь зону DNS bigfirm.biz, которую легко найти через Internet, но зона bigfirm.biz, которая поддерживает домен AD bigfirm.biz, не должна быть доступна запросам извне. Если кто-то, подключенный к Internet по модему, воспользуется Nslookup для отправки запроса в bigfirm.biz, в ответ этот пользователь должен получить только информацию, относящуюся к публичной зоне bigfirm.biz, но не зоне, работающей на AD.

Следовательно, любая система, которая нуждается в доступе в AD-домен bigfirm.biz, должна адресовать свои запросы на один из серверов DNS, которые «засекречены»: DNS-серверов корпоративной сети. На них содержится копия приватной зоны bigfirm.biz, т. е. зоны, обслуживающей AD. Опрос сервера DNS, на котором нет копии зоны, обслуживающей AD, приведет к тому, что вопрос типа «Какие имена присвоены контроллерам домена Bigfirm?» сервер DNS переадресует в Internet. И если DNS настроен корректно, ни один публичный сервер DNS не сможет ответить на этот вопрос.

При настройке TCP/IP можно сообщить системе об IP-адресах двух серверов DNS: о предпочтительном сервере (preferred DNS server) и альтернативном сервере (alternate DNS server). Когда клиентская система инициирует DNS-запросы, сначала предпринимается попытка послать запрос по предпочтительному IP-адресу; если ответа нет, клиент пытается опросить альтернативный адрес. Через реестр или службу Microsoft DHCP Server можно настроить до шести альтернативных адресов. Предпочтительный, основной альтернативный и все остальные альтернативные серверы DNS должны быть в той же корпоративной сети, что и станция — инициатор запроса, и так для каждого компьютера в корпоративной сети.

К каким неполадкам могут привести ошибки в настройке DNS в этом месте? Когда настраиваются предпочтительные и альтернативные серверы DNS, кто-то может настроить свои системы так, что предпочтительный сервер DNS действительно будет корпоративным сервером, но для альтернативного сервера будет указан адрес IP сервера DNS в Internet - часто это бывает DNS-сервер Internet-провайдера компании. Такой сценарий порождает трудноразрешимую проблему: когда предпочтительный сервер DNS отвечает на запрос клиента о данных AD, клиент ответ получает, но когда клиент опрашивает альтернативный сервер, тот ничем не может помочь. И получается, что в один момент клиент может получить данные AD, а в другой - нет. Такая ошибка периодически возникает.

Что еще хуже, многие испытывают затруднения при назначении предпочтительного и альтернативного серверов DNS. Какой сервер DNS должен отвечать на данный запрос? Опять-таки, поскольку серверу DNS необходимо отыскать системы в AD, предпочтительный и альтернативный серверы DNS (и все дополнительные альтернативные) всегда должны быть DNS-серверами в корпоративной сети. На самом деле, настраивая внутрикорпоративные серверы DNS на самих себя в качестве предпочтительных серверов, вы поступаете правильно, и обычно я не задаю альтернативный сервер для сервера DNS. Если на сервере DNS происходит сбой, практически всегда возникает проблема, и этот сервер не должен участвовать в процедуре разрешения имен до тех пор, пока работоспособность службы DNS не будет восстановлена.

Вывод: независимо от того, сколько серверов DNS прописано в системе, все они должны находиться в корпоративной сети. И когда настраиваются корпоративные DNS-серверы, ссылаться они должны на самих себя.

Система Windows 2000 DNS/DC ссылается сама на себя

Только что я рассказывал о том, что надо настраивать серверы DNS со ссылкой на самих себя, но можно столкнуться с ситуацией, когда Active Directory реализована на базе Windows 2000, а корневой домен леса сконфигурирован как интегрированный в AD. Чтобы сервер DNS стал хостом интегрированной зоны AD для корневого домена леса, этот сервер DNS обязательно должен быть сервером DNS и DC корневого домена. Далее, если настроить все системы DNS/DC со ссылкой на самих себя в качестве предпочтительных серверов DNS, возникнет проблема, известная под названием островная DNS (island DNS): каждый из таких серверов DNS утратит всю информацию обо всех остальных серверах DNS, кроме самого себя.

Для решения проблемы нужно или обновить DC до Windows 2003, на которых такая проблема уже отсутствует, или отказаться от использования интегрированных зон AD в корневом домене. И еще раз подчеркну, что описанная проблема присуща только корневому домену.

А вот как еще можно выйти из затруднительного положения: решите для себя, какой сервер DNS будет для вас мастер-сервером DNS. Затем укажите на мастер-сервере, что предпочтительным сервером DNS для него будет он сам. И наконец, установите на всех остальных серверах DNS ссылки на мастер-сервер DNS как предпочтительный сервер. Также можно настроить альтернативные серверы DNS для всех остальных серверов DNS, кроме мастера, но никогда не следует задавать ссылки на самих себя на серверах DNS/DC.

Вывод: если в корневом домене леса используются интегрированные зоны Active Directory, не стоит устанавливать ссылки на серверах DNS на самих себя. В системах на базе Windows 2003 эта проблема отсутствует.

Устаревший файл HOSTS не позволяет отыскать сервер

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

Я проанализировал целый список возможных причин и решений, но все безрезультатно. И к сожалению, вынужден был признать, что больше никаких идей нет. Несколько недель спустя читатель прислал мне письмо с решением своей задачи: файл HOSTS!

В каталоге winntsystem32driversetc (для систем Windows 2000) или windowssystem32drivers (для Windows XP и Windows 2003) хранится текстовый файл HOSTS (файл без расширения). До появления DNS файлы HOSTS отвечали на вопросы типа: «Какой адрес IP у станции с таким-то именем?» HOSTS - это обычный текстовый файл с перечнем адресов IP и имен компьютеров, а также строк комментариев, начинающихся с символа «решетка» (#). В настоящее время HOSTS практически не используется и остается в системе на случай какой-нибудь непредвиденной ситуации; однако во всех реализациях стека TCP/IP, с которыми мне довелось столкнуться, файл HOSTS все еще поддерживается. Возможно, в нем имеется всего лишь одна запись — 127.0.0.1 localhost, что позволяет системе распознать имя localhost как самое себя. Адрес IP 127.0.0.1 — это специальный диагностический адрес IP, и сигнал localhost позволяет системе опросить себя.

Предположим, однако, что у нас есть DC dc4.bigfirm.biz с адресом 192.168.4.2. Если послать запрос на сервер DNS с указанием IP-адреса dc4.bigfirm.biz, получим ответ 192.168.4.2. А теперь предположим, что кто-то на своей станции указал в HOSTS «10.0.0.5 dc4.bigfirm.biz». Всякий раз, когда система пытается разрешить имя dc4.bigfirm.biz, данная станция будет получать два ответа: 192.168.4.2 с DNS и 10.0.0.5 с HOSTS. Кто победит? HOSTS. Фактически клиентская система сначала опрашивает HOSTS, и если получает ответ, то этим и ограничивается. По какой-то причине читатель создал в HOSTS запись для злополучного DC, но указал для него неверный IP-адрес.

Вывод: даже когда одна станция дает сбой при поиске определенного сервера, а все остальные - нет, следует просмотреть содержимое файла HOSTS на неисправной станции.

Dcpromo не работает

Вот типичная ситуация: читатель создал AD с одним DC, этот DC прекрасно работает, но читатель не может ни включить в домен AD хотя бы одну рабочую станцию, ни запустить Dcpromo на другом сервере для добавления второго DC. Очевидно, что проблема в Dcpromo.

Dcpromo проверяет, существует ли в сети достаточная для нормальной работы AD инфраструктура DNS, т. е. выполняется поиск зоны, чье имя соответствует имени созданной AD, проверяется способность зоны выполнять динамическую DNS-регистрацию и выясняется, были ли соблюдены все перечисленные условия до установки DNS.

Это хороший ход, и я очень доволен, что разработчики Microsoft при написании Dcpromo предусмотрели эту проверку. Но, к сожалению, Microsoft «улучшила» свое детище и пошла еще дальше - позволила Dcpromo установить DNS самостоятельно. Никогда не позволяйте Dcpromo устанавливать DNS! Dcpromo не устанавливает для самого первого DC ссылку на самого себя, не сообщает пользователю о необходимости установить ссылки на серверы DNS в корпоративной сети для всех систем во внутренней сети и вообще не пытается как-то сообщить о проблемах, озвученных в данной статье.

Вывод: если Dcpromo сообщает, что DNS установлена некорректно, самое лучшее - остановить Dcpromo и еще раз проверить всю инфраструктуру DNS. Нельзя создавать AD поверх неверно развернутой DNS.

Избавим AD от ненужных проблем

DNS обеспечивает выполнение простой задачи: связывает имена станций с их IP-адресами. AD накладывает на DNS дополнительную обязанность - хранение списка контроллеров домена и серверов глобального каталога. Но за обманчивой простотой формулировки этих задач скрывается их огромная важность. Без DNS Active Directory просто не будет работать. Следует постоянно помнить о наиболее общих причинах неправильной настройки DNS, и можно будет создать инфраструктуру DNS, свободную от ошибок.

Марк Минаси — редактоp Windows NT Magazine MCSE и автор книги «Mastering Windows NT Server 4.0» (издательство Sybex). С ним можно связаться по адресу: mark@minasi.com

Неразбериха с DNS: история со счастливым концом

Дуглас Спиндлер

Я занимаюсь технологическим консалтингом в Сан-Франциско. Однажды я получил вызов с просьбой о помощи: мой клиент столкнулся с периодически возникающей проблемой при определении местонахождения локальных ресурсов. Он полагал, что его проблема кроется в сети, однако не был в этом уверен. Клиент был в панике. Речь шла не о рядовой юридической конторе - это была высокотехнологичная фирма, с гордостью заявлявшая, что в ней число поверенных больше, чем общее число сотрудников во многих компаниях. Я взялся помочь.

Диспозиция

Компания использовала BIND 9.2.3 Linux в качестве основного сервера DNS. Фирма относительно недавно развернула Active Directory (AD) на Windows Server 2003 и потихоньку добавляла в каталог пользователей и принтеры. Мне рассказали, что некоторые пользователи внезапно обнаружили, что не могут печатать. Другие пользователи просто жаловались на медленную работу сети.

Когда я приехал, сотрудник ИT-службы встретил меня и проводил в конференц-зал, где тут же началось обсуждение проблемы. На вопросы о производившихся изменениях, добавлении нового оборудования и программного обеспечения мне ответили отрицательно: «Нет, ничего не менялось». Единственной крупицей информации, которую мне удалось добыть, были сведения о том, что в процессе миграции пользователей и принтеров в AD были дополнительно усилены некоторые меры безопасности. Но, как меня заверили, это не могло оказать какого-либо влияния на возможность печатать документы.

Диагностика

Я начал с того, что стал тестировать с помощью ping некоторые из имеющихся принтеров по известным IP-адресам. Ничего. Тогда с помощью полностью определенных имен Fully Qualified Domain Names (FQDN) я попытался проверить те же самые принтеры через Linux DNS, затем через DNS/AD Windows 2003. Результат получился интересным: в зависимости от того, какой использовался сервер DNS, некоторые из IP-адресов принтеров не удавалось разрешить. Быстрый анализ файлов журналов DNS на станциях Linux выявил сотни ежедневных ошибок, которые на выходных сходили на нет. Ага! Это уже кое-что!

Я мог бы воспользоваться и другими утилитами для проведения дополнительных тестов, но то, что мне действительно было нужно, — это инструмент, который позволил бы заглянуть в содержимое сетевых пакетов. Большинство диагностических программ не предоставляло необходимой информации и могло только завести меня в тупик. Чтобы быстро обнаружить причину происходящего, мне нужен был анализаторов сетевых протоколов с возможностями лингвистического анализа содержимого передаваемых пакетов, что дало бы возможность добраться до самой сути проблемы.

Сетевое расследование

Поначалу я решил воспользоваться Microsoft Netmon, но версия, включенная в состав Windows 2003, позволяла только захватывать пакеты, отправляемые и принимаемые данным сервером. Поэтому я решил задействовать коммерческий анализатор, который позволил бы перехватить весь трафик. Бесплатные анализаторы сетевых протоколов доступны в Internet. Например, Ethereal по адресу http://www.ethereal.com. Если бы под рукой оказался Microsoft Systems Management Server (SMS), можно было бы воспользоваться полной версией Netmon, которая перехватывала весь сетевой трафик.

Я настроил анализатор для перехвата пакетов между сервером Linux DNS, прописанным как Start of Authority (SOA), и сервером Windows 2003 DNS, также прописанным как SOA. Я хотел посмотреть результаты проведения двух тестов: передачу данных между зонами (трансфер зоны) с Linux на Windows и трансфер зоны в обратную сторону - с Windows на Linux. Сначала я выполнил кросс-пересылку на хосты Linux, потом выдержал паузу и инициировал трансфер зоны на системы Windows, а затем приступил к анализу результатов.

В результате тщательной проверки файла трассировки обнаружилось, что хост Linux, успешно установив соединение с системой Windows, выдавал ошибку при выполнении трансфера зоны и со временем отключался от системы. Просмотрев пакеты при трансфере зоны от Windows к Linux, я увидел те же самые результаты.

Серверы успешно устанавливали соединение через TCP-порт 53 при трансфере зоны TCP/IP, но не могли передать DNS-данные и в конце концов отключались друг от друга. При инспектировании пакетов обнаружилась проблема аутентификации: иногда возникал неправильный отклик на пакет. Но ведь передача данных DNS не требует аутентификации, правда?

Как уже отмечалось ранее, сотрудники ИT внесли в свое время некоторые изменения в настройки безопасности. В конце концов, я получил более подробную информацию: чтобы воспрепятствовать фальшивому трансферу зоны, администратор Linux активизировал DNS Security extensions protocol (DNSSEC) на серверах Linux DNS. DNSSEC, описание которого приведено в Internet Engineering Task Force (IETF) Request for Comments (RFC) 2535, использует открытый и закрытый ключи. Windows 2003 DNS не в полном объеме поддерживает DNSSEC, поэтому мы решили удалить внесенные изменения и снова попытались поработать. Проблема была решена! Компания находилась в процессе миграции на Windows 2003 и AD, поэтому было предложено полностью поменять платформы и сделать сервер Windows 2003 основным сервером DNS.

Объяснение решения

По умолчанию рабочие станции Windows настроены на регистрацию своих адресов в DNS. Соответствующий флажок можно найти на вкладке DNS при настройке TCP/IP Properties, Advanced TCP/IP Settings. Упомянутые сотни ошибок в файлах журналов DNS на станциях Linux возникали из-за того, что рабочие станции пытались зарегистрироваться в DNS как в динамической DNS (DDNS). А поскольку Linux был настроен на DNSSEC, запросы рабочих станций блокировались, а это забивало журнал сообщениями об ошибках и порождало лишний сетевой трафик.

Мой клиент был очень доволен, что проблему удалось решить за полдня. В конце концов, для этой высококлассной юридической фирмы время означало деньги: час работы фирмы стоил около 25 тыс. долл., ее конечный продукт воплощался на бумаге. Своим решением я сэкономил клиенту 100 тыс. долл. И несомненно, ИT-персонал фирмы получил более ясное представление о том, как работает схема безопасности Windows DNS, и особенно DNSSEC.