DNS-сервер

     Обновление  с несколькими главными серверами  и расширенные средства безопасности, базирующиеся на возможностях Active Directory.

       В модели стандартного сохранения  зон обновления DNS выполняются на  основе модели с единственным  главным сервером. В такой модели  единственный удостоверяющий DNS-сервер  зоны обозначается как основной  источник для зоны.

       Это сервер содержит главную  копию зоны в файле на локальном  диске. В этой модели основной  сервер зоны представляет единственную  фиксированную точку отказа. Если  этот сервер недоступен, запросы  на обновление зоны от DNS-клиентов  не обрабатываются.

       При сохранении зон, интегрированных  в службу каталогов, динамические  обновления DNS выполняются с использованием  модели с несколькими главными  серверами.

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

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

       Кроме того, при использовании  зон, интегрированных в службу  каталогов, можно с помощью  списков управления доступом  защитить объект-контейнер dnsZone в  дереве каталогов. Это средство  обеспечивает дифференцированный  доступ к зоне или к конкретной  записи ресурса в зоне.

       Например, список управления доступом  для записи ресурса в зоне  можно ограничить так, чтобы  разрешить динамические обновления  только указанному компьютеру  клиента или группе безопасности, например, группе администраторов  домена. Это средство безопасности  недоступно для стандартных основных  зон.

       Необходимо отметить, что при  преобразовании зоны к типу  интегрированной в службу каталогов  настройка по умолчанию для  обновлений зоны изменяется и  разрешаются только безопасные  обновления. Кроме того, при использовании  списков управления доступом  на объектах Active Directory, относящихся  к DNS, списки управления доступом  могут применяться только к  службе DNS-клиент.

     Репликация  и синхронизация зон с новыми контроллерами домена выполняется  автоматически при каждом добавлении нового контроллера в домен Active Directory.

       Хотя службу DNS можно выборочно  удалять с контроллеров домена, зоны, интегрированные в службу  каталогов, всегда сохраняются  на каждом контроллере домена. В результате сохранение и управление зонами не является дополнительным ресурсом. Кроме того, способы синхронизации информации, сохраняемой в службе каталогов, обеспечивают повышение быстродействия по сравнению со стандартными способами сохранения обновлений зон, которые могут потенциально потребовать передачи зоны целиком.

     За  счет сохранения баз данных зон DNS в Active Directory имеется возможность рационализировать  репликацию баз данных в сети.

       Когда пространство имен DNS и домены Active Directory сохраняются и реплицируются  независимо, необходимо обеспечить  планирование и администрирование  каждого из них в отдельности.  Например, при одновременном использовании  стандартного сохранения зон  DNS и службы каталогов Active Directory необходимо обеспечить структуру,  реализацию, тестирование и управление  для двух различных топологий  репликации баз данных. Одна топология  требуется для репликации данных  из каталогов между контроллерами  домена, а другая топология может  потребоваться для репликации  баз данных зон между DNS-серверами.

       Это приведет к дополнительным  трудностям при планировании  и разработке структуры сети  с учетом ее естественного  роста. За счет интеграции сохранения  информации DNS появляется возможность  унифицировать вопросы управления  и репликации для DNS и Active Directory, объединяя их в единое административное  целое.

     Репликация  каталогов выполняется быстрее  и эффективнее, чем стандартная  репликация DNS.

       Поскольку репликация Active Directory выполняется  на уровне отдельных свойств,  распространяются только необходимые  изменения. При этом для зон,  интегрированных в службу каталогов,  используется и отправляется  меньший объем данных.

     Active Directory может использовать любую стандартную, законченную реализацию службы DNS. Для примера можно задействовать DNS-сервер, входящий в Windows 2000 Server, поскольку его модули согласованы друг с другом (хранение и репликация зон и т. п.), ведь необходимо, чтобы выбранный DNS-сервер соответствовал последним стандартам. Например, для Active Directory нужен DNS-сервер, поддерживающий записи типа SRV. Записи подобного типа (SRV records), в соответствии с RFC 2052, позволяют клиентам находить нужные сетевые службы. В Active Directory служба LDAP каждого домена Windows 2000 представлена некоторой SRV-записью службы DNS. Такая запись содержит DNS-имя контроллера этого домена, по которому клиенты Active Directory могут находить IP-адрес компьютера-контроллера домена. После того как нужный контроллер обнаружен, для доступа к данным Active Directory, хранящихся на нем, клиент может использовать протокол LDAP.

     Windows 2000 Server поддерживает также службу динамического именования хостов, Dynamic DNS. В соответствии с RFC 2136 служба Dynamic DNS расширяет протокол DNS, позволяя модифицировать базу данных DNS со стороны удаленных систем. Например, при подключении некоторый контроллер домена может сам добавлять SRV-запись для себя, освобождая администратора от такой необходимости.

     Следует добавить, что DNS-сервер, используемый вместе с Active Directory, должен лишь поддерживать SRV-записи и символы подчеркивания в именах, наличие Dynamic DNS не строго обязательно: такое требование только облегчает работу с сетью. Этот факт очень важен при развертывании Windows 2000 в гетерогенных сетях, где имеются DNS-серверы на других платформах.

     Таким образом, мы можем отметить для себя несколько преимуществ использования  зон DNS, которые интегрированы с Active Directory:

Интегрированные зоны позволяют выполнять безопасные обновления. То есть, если зона DNS интегрирована  в AD DS, то в ней вы можете настроить  только использование безопасных обновлений, тем самым обеспечив возможность управления пользователями и компьютерами организации, которые могут обновлять записи ресурсов в Active Directory;

Процесс передачи зон заменяется репликацией  доменных служб Active Directory. В связи  с тем, что информация зон сохраняется  не в текстовый файл, а в Active Directory, репликация таких данных выполняется  посредствам стандартного процесса репликации доменных служб Active Directory. То есть, сама репликация выполняется  на уровне атрибутов и касается лишь изменений данных зоны, тем самым  экономя полосу пропускания и, соответственно, сжимая ваш трафик;

Интегрированные зоны обеспечивают дополнительную безопасность. Так как зоны DNS сохраняются непосредственно  в Active Directory, для защиты объекта dnsZone в каталоге используются списки контроля доступа, обеспечивая гранулированный  доступ к зоне;

Интегрированные зоны позволяют создавать для  серверов DNS конфигурацию Multi-Master. С  использованием зон, интегрированных  в Active Directory, каждый DNS-сервер получает копию информации домена с правом записи, чтобы изменения данных зоны можно было вносить во всех организациях, что нельзя реализовать с серверами DNS без AD DS.

3. Планирование и администрирование DNS

3.1 Планирование

     После того как для каждой модели будут  выбраны домены Active Directory, вам необходимо спроектировать инфраструктуру DNS, так  как каждое доменное имя является частью именного пространства DNS. Полагаю, что вам не нужно объяснять, что  для локализации ресурсов в сети доменных служб Active Directory используется система доменных имен (Domain Name System, DNS), так как службы Active Directory не могут  функционировать без стабильной конфигурации DNS. По сути, DNS является распределенной базой данных, которая предоставляет  пространство имен и которая хранит все сведения, необходимые для  того, чтобы любой пользователь организации  мог свободно подключаться к компьютерам  и другим IP-сетям, используя понятные и легко запоминающиеся имена. Без ее стабильной инфраструктуры у доменных служб не будет возможности выполнять репликацию среди контроллеров домена в сети, а такие серверы, как Microsoft Exchange Server не смогут отправлять электронную почту. Поэтому можно сделать такой вывод, что проектирование инфраструктуры DNS является не менее важным этапом эффективного построения доменных служб в организации, причем, ключевым моментом является определение, где нужно локализовать домены Active Directory в текущем именном пространстве. Именно благодаря службе разрешения имен DNS, доменные службы Active Directory предоставляют для пользователей возможность без проблем находить все контроллеры доменов, а также контроллерам доменов обмениваться друг с другом сведениями. В большинстве случаев проект пространство имен для Active Directory разрабатывается проектировщиком службы каталогов совместно хозяином DNS. Сразу хотелось бы отметить, что большинство организаций имеют одно именное пространство как внутри организации Active Directory, так и в Интернете, и в итоге, в Интернете регистрируется лишь одно DNS-имя. Желательно, чтобы такие имена существовали отдельно от зарегистрированного доменного имени организации.

     Проектирование  инфраструктуры доменных имен в Active Directory, прежде всего, стоит начинать с анализа  текущей инфраструктуры предприятия. То есть, если в организации уже  имеется инфраструктура DNS, то нужно в нее интегрировать пространство Active Directory. Если же в организации не развернута инфраструктура DNS, то предстоит тщательно спроектировать и развернуть новую инфраструктуру доменных имен специально для поддержки доменных служб Active Directory.

     Рассмотрим  несколько вариантов.

Использования одного именного пространства состоит в обеспечении комфортной работы для конечных пользователей организации. Другими словами, любой пользователь для всех подключений в корпоративной сети вашей организации применяет только одно доменное имя и если такому пользователю нужно, скажем, получить доступ к веб-сайту организации извне, он сможет это сделать, используя свое корпоративное UPN имя при подключении. Вполне очевидно, что основные недостатки использования одного именного пространства связаны с безопасностью и административной нагрузкой. При использовании одного имени пространства внутри и вне организации, администратору приходится управлять двумя различными зонами с одним доменным именем, что крайне неудобно.

     Важно понимать, что любое отличие доменных имен означает, что внутри организации  используется другое именное пространство. Пример использования разных именных  пространств внутри и вне организации  обычно выглядит следующим образом: компанія Biopharmaceutics Ltd может использовать как внешнее именное пространство имя Biopharmaceutics.com, а такое имя как Biopharmaceutics.corp для внутреннего пространства имен. Чаще всего внутреннее именное  пространство принято выбирать из соображений  безопасности для предотвращения публикации внутреннего именного пространства в сети Интернет. Помимо всех преимуществ, у разных именных пространств  есть один недостаток – вашей организации  придётся регистрировать дополнительные DNS имена, что, правда, не обязательно, но крайне желательно, так как если другая организация зарегистрирует незанятое вами именное пространство, ваши пользователи больше не смогут локализовать ресурсы вашей интрасети в  Интернете.

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

     Давно известно, что после того как компьютер с операционной системой Windows присоединяется к домену, он сам себе присваивает имя. Такое имя состоит из имени компьютера и DNS-имени домена Active Directory, которое называется полным доменным именем (FQDN). Но не все знают, что если у компьютера уже есть другое доменное имя DNS, которое было либо зарегистрировано службой DHCP-сервера или было статически введенное в DNS-зону, то полное доменное имя будет отличаться от зарегистрированного ранее имени и к такому имени далее можно будет подключаться по любому из этих двух имен.

      Если  же в организации, в которой проектируется  именное пространство для доменных служб Active Directory, уже присутствует инфраструктура DNS, то процесс проектирования немного  усложняется. В этом случае необходимо основываться на проекте в соответствии, по меньшей мере, с тремя основными факторами, которые описываются далее.

     В первом случае, вы можно использовать текущую инфраструктуру, включая доменное имя для доменных служб Active Directory. То есть, при настройке серверов DNS, с целью разрешения имен Интернета обычно применяются серверы пересылки или конфигурируются DNS-серверы с использованием корневых подсказок. В свою очередь, серверы пересылки предусматривают высокий уровень безопасности, так как внутренний DNS-сервер можно настроить для пересылки на один или несколько внешних серверов DNS, а корневые подсказки гарантируют высокий уровень избыточности, так как они исключают вероятность сбоев. В этом случае вам потребуется небольшая реконфигурация существующей инфраструктуры DNS-серверов. Например, вы можете для компании Biopharmaceutics применить именное пространство Biopharmaceutics.corp, обеспечив данное именное пространство в качестве доменного имени служб Active Directory, а существующие ранее DNS серверы оставить без изменений.

     Во  втором случае, при проектировании инфраструктуры DNS для Active Directory, вы можете вынести домены AD DS дочерними доменами существующего внутреннего пространства имен, тем самым не затронув имеющуюся  инфраструктуру. То есть, в случае существующего  именного пространства Biopharmaceutics.com, вы можете создать дочерний домен corp. Biopharmaceutics.com.

     Третий  случай заключается в выборе другого DNS имени для доменов Active Directory. Данная ситуация называется несвязанным пространством  имен. В том случае, если используется несвязанное пространство имен, в  котором доменные имена служб Active Directory значительно отличаются от основного  суффикса DNS, используемого клиентом, интеграция доменных служб со службой DNS значительно усложняется.