Правдивые истории об ошибках в работе DNS/AD
Значительная доля обращений к AD связана с поиском определенных серверов: контроллеров домена (DC), серверов глобального каталога (Global Catalog — GC), а также, если репликация выполняется через SMTP, — почтовых серверов. Если найти один из таких серверов невозможно, не удастся «довести до сведения» AD, что именно нужно сделать. AD ищет все перечисленные серверы, опрашивая серверы DNS, поэтому в большинстве случаев сбои AD связаны с проблемами в работе DNS. По крайней мере, так показывает мой опыт работы. А большинство проблем DNS произрастают из ошибок в настройке, о которых пойдет речь в настоящей статье. Начнем с самых общих проблем, свойственных многодоменному лесу.
AD нужны сведения об инфраструктуре DNS, т. е. данные о серверах DNS в корпоративной сети. На этих серверах содержатся записи, содержащие (как минимум) местоположение серверов DC и серверов — членов домена — и, возможно, рабочих станций. Вычислительные сети используют DNS вот уже два десятка лет, т. е. гораздо дольше, чем существует AD, поэтому построение DNS для AD не должно быть очень сложной задачей. Однако большинство инфраструктур DNS проектировались с расчетом на видимость в общедоступной сети Internet, а все, естественно, хотят, чтобы настройки DNS для корпоративной AD не были видны кому бы то ни было в Internet. Следовательно, практически все структуры DNS, отображающие конкретные реализации AD, должны быть изолированы от Internet. Для этого используется техника настройки DNS, известная под названием разделение (split-brain) DNS. В результате получается конфигурация, которая соответствует требованиям, отсутствующим при несложной унифицированной установке DNS.
Сначала я создаю домен root.local, поскольку это корневой домен леса. Для этого я устанавливаю DNS на станции Windows Server 2003 или Windows 2000 и создаю зону root.local на соответствующем сервере. Поскольку домен root.local имеет ограниченное число станций и учетных записей, вполне логично, если один и тот же сервер будет сервером DNS и контроллером домена (DC). Я установил этот самый первый сервер как основной DNS-сервер для динамической зоны root.local, сообщив системе об использовании самой себя в качестве предпочтительного сервера DNS, а затем запустил Dcpromo для создания домена AD с именем root.local.
Имея два сервера 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.
Я мог бы сделать первый 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 интегрировать в AD
К сожалению, хранение доменных зон 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 зонами, все равно необходимо убедиться, что DNS-серверы произвольно выбранного домена являются также вспомогательными серверами DNS для интегрированных зон всех остальных доменов, если речь идет о Windows 2000. Или, если используется Windows 2003, требуется настроить реплицирование содержимого зон по всему лесу.
Рабочая станция или сервер, которые ссылаются на DNS-сервер вне сети, по-видимому, самая распространенная ошибка при настройке DNS. Как уже говорилось, практически всегда при реализации AD требуется, чтобы инфраструктура DNS не была видна из Internet. Естественно, Bigfirm может иметь зону DNS bigfirm.biz, которую легко найти через Internet, но зона bigfirm.biz, которая поддерживает домен AD bigfirm.biz, не должна быть доступна запросам извне. Если кто-то, подключенный к Internet по модему, воспользуется Nslookup для отправки запроса в bigfirm.biz, в ответ этот пользователь должен получить только информацию, относящуюся к публичной зоне bigfirm.biz, но не зоне, работающей на AD.
При настройке TCP/IP можно сообщить системе об IP-адресах двух серверов DNS: о предпочтительном сервере (preferred DNS server) и альтернативном сервере (alternate DNS server). Когда клиентская система инициирует DNS-запросы, сначала предпринимается попытка послать запрос по предпочтительному IP-адресу; если ответа нет, клиент пытается опросить альтернативный адрес. Через реестр или службу Microsoft DHCP Server можно настроить до шести альтернативных адресов. Предпочтительный, основной альтернативный и все остальные альтернативные серверы DNS должны быть в той же корпоративной сети, что и станция — инициатор запроса, и так для каждого компьютера в корпоративной сети.
Что еще хуже, многие испытывают затруднения при назначении предпочтительного и альтернативного серверов DNS. Какой сервер DNS должен отвечать на данный запрос? Опять-таки, поскольку серверу DNS необходимо отыскать системы в AD, предпочтительный и альтернативный серверы DNS (и все дополнительные альтернативные) всегда должны быть DNS-серверами в корпоративной сети. На самом деле, настраивая внутрикорпоративные серверы DNS на самих себя в качестве предпочтительных серверов, вы поступаете правильно, и обычно я не задаю альтернативный сервер для сервера DNS. Если на сервере DNS происходит сбой, практически всегда возникает проблема, и этот сервер не должен участвовать в процедуре разрешения имен до тех пор, пока работоспособность службы DNS не будет восстановлена.
Система Windows 2000 DNS/DC ссылается сама на себя
Для решения проблемы нужно или обновить DC до Windows 2003, на которых такая проблема уже отсутствует, или отказаться от использования интегрированных зон AD в корневом домене. И еще раз подчеркну, что описанная проблема присуща только корневому домену.
Вывод: если в корневом домене леса используются интегрированные зоны Active Directory, не стоит устанавливать ссылки на серверах DNS на самих себя. В системах на базе Windows 2003 эта проблема отсутствует.
Не так давно один читатель обратился ко мне с просьбой помочь разрешить весьма странную проблему, связанную с DNS. Один компьютер — только один! — в корпоративной сети не мог подключиться к конкретному DC. По отношению к другим контроллерам домена в сети у этого компьютера никаких проблем не возникало, все остальные станции к указанному DC тоже подключались нормально. В чем же дело?
