Проектирование инфраструктуры DNS

🕛 19.01.2009, 20:35

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

Исследование существующей инфраструктуры DNS

Первый шаг в проектировании инфраструктуры DNS должен состоять в исследовании уже имеющейся инфраструктуры DNS. В большинстве случаев служба DNS в Active Directory должна взаимодействовать с имеющейся инфраструктурой DNS. Это может означать просто конфигурирование ретранслятора в существующем сервере DNS, использование имеющегося DNS-сервера как основного для Active Directory или отсутствие развертывания DNS в Windows Server 2003. Active Directory требует, чтобы работала служба DNS, однако, существует несколько вариантов ее развертывания.

Исследуя существующую инфраструктуру DNS, сделайте следующее.
* Задокументируйте все DNS-имена доменов, используемые в настоящее время в пределах компании. Сюда входят имена, использующиеся в интернете, а также внутренние имена. * Задокументируйте все дополнительные имена, которые компания зарегистрировала в структурах власти интернета. Часто компания использует в интернете только имя .com, можно также зарегистрировать и другие имена домена высшего уровня типа .net или .org. Вы могли бы использовать одно из этих имен домена для вашего внутреннего пространства имен. * Задокументируйте существующую конфигурацию серверов DNS. Эта документация должна включать типы DNS-серверов, в настоящее время развернутых в сети (например DNS-серверы на базе Windows, BIND - Berkeley Internet Name Domain или Lucent VitalQIP). Кроме того, конфигурация DNS должна содержать информацию о ретрансляторах, о делегировании зон и о конфигурации основных и дополнительных серверов.

Проектирование пространства имен

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

Внутреннее и внешнее пространства имен DNS

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

Использование одного и того же пространства имен в качестве внутреннего и внешнего пространства

Некоторые компании захотят использовать одно и то же имя DNS и внутри, и снаружи. В этом случае компания должна зарегистрировать только одно DNS-имя в интернете. Например, на рисунке 5-5 показано, что компания Contoso могла бы использовать Contoso.com и внутри, и вне компании.

Рис. 5-5. Использование единственного пространства имен DNS

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

Главное преимущество использования единого внутреннего и внешнего пространства имен состоит в том, что оно обеспечивает согласование для конечного пользователя. Пользователь всегда использует одно имя домена для подключения к общей сети. Адрес SMTP пользователя и основное пользовательское имя (UPN) будут использовать одно и то же имя домена в качестве публичного веб-сайта. Когда пользователю нужно обратиться к доступным ресурсам, он может использовать одно имя и внутри, и снаружи (хотя он может обращаться к разным серверам). Другое преимущество использования единого пространства имен состоит в том, что надо регистрировать только одно DNS-имя.

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

Использование различного внутреннего и внешнего пространства имен

Большинство компаний использует различные внутренние и внешние пространства имен. Например, компания могла бы использовать Contoso.com как внешнее пространство имен и имя Contoso.net или ADContoso.com для внутреннего пространства имен (см. рис. 5-6).

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

Рис. 5-6. Использование отдельных, внутреннего и внешнего, пространств имен

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

Варианты проекта пространства имен

Фактические имена, которые вы выбираете для своего пространства имен DNS, будут в значительной степени определяться текущей инфраструктурой DNS. Если у вас нет установленной инфраструктуры DNS (такой сценарий встречается в сетях Windows NT), и если вы уже зарегистрировали имя домена, которое хотите использовать для Active Directory, ваш проект будет довольно простым. Однако если инфраструктура DNS уже имеется и вы должны взаимодействовать с этой средой, то проектирование DNS усложняется.

Если инфраструктуры DNS не существует, имеются одно или несколько имен домена второго уровня, уже зарегистрированных для вашей компании, то проектировать пространство имен DNS несложно. Вы можете выбрать зарегистрированное имя домена второго уровня в качестве имени корневого домена, а затем делегировать дочерние имена домена для дополнительных доменов в том же самом дереве или дополнительные имена доменов второго уровня для дополнительных деревьев в лесу (см. рис. 5-7).

Рис. 5-7. Проект пространства имен DNS в отсутствие инфраструктуры DNS

Практический опыт. Внутреннее и внешнее пространства имен

Вопрос использования внутреннего пространства имен, отличного от внешнего, может вызвать дискуссии в компании. В некоторых случаях лучше использовать различные пространства имен, но владельцы компании могут оказывать сильное сопротивление использованию чего-либо, отличного от пространства имен интернета. Часто причина для этого - торговая марка; некоторые компании потратили годы и миллионы долларов, создавая торговую марку, которую клиенты хорошо знают, вебсайты компании и адреса SMTP для всех пользователей отражают это пространство имен. Некоторые компании имеют признанные обществом идентификаторы при наличии несколько деловых подразделений в пределах компании, каждое из которых обладает собственной торговой маркой. В большинстве случаев деловые пользователи не хотят показывать внешнему миру имя, отличное от их распознаваемого имени компании. Хорошая новость состоит в том, что вы можете использовать различные внутреннее и внешнее пространства имен, а внешне поддерживать только одно пространство имен. Например, Contoso мог бы использовать Contoso.net как внутреннее пространство имен и Contoso.com как публичное пространство имен. Внутреннее пространство имен может быть полностью скрыто от всех, кроме сетевых администраторов. Адреса SMTP для пользователей могут быть alias@contoso.com, а веб-серверы могут использовать веб-индекс Contoso.com. Если нужно, то UPN для пользователей может быть сконфигурирован как alias@contoso.com, несмотря на использование другого внутреннего пространства имен.

На рисунке 5-7 показано, как серверы DNS сконфигурированы по этому сценарию. DNS-сервер Contoso.com является официальным (authoritative) для своего домена и содержит записи делегирования на NAmerica.Contoso.com и Europe.Contoso.com, а также условные ретрансляторы и сокращенные зоны для домена Fabrikam.com. DNS-сервер Fabrikam.com является официальным для своей зоны и содержит условные ретрансляторы и сокращенные зоны для Contoso.com. Чтобы разрешать адреса интернета, серверы корня дерева должны быть сконфигурированы с ретранслятором, указывающим на сервер в интернете, или с корневыми ссылками интернета.

Проектирование DNS усложнится, если у вас есть внутренняя инфраструктура DNS. В этом случае существуют три варианта для объединения с текущей инфраструктурой. Первый вариант состоит в использовании только текущей инфраструктуры DNS для Active Directory, включая имя домена. Например, Contoso может использовать Contoso.net как свое внутреннее пространство имен, а DNS-серверы BIND - для обеспечения службы DNS. Компания может взять Contoso.net как имя домена Active Directory и продолжать использовать текущие серверы DNS (при условии, что они поддерживают SRV-записи указателей служб). В качестве альтернативы компания может использовать то же имя домена, но переместить службу DNS на DNS-сервера, на которых выполняется Windows Server 2003. В любом случае требуется очень небольшая реконфигурация DNS-серверов. Серверы DNS могут продолжать использовать те же самые ретрансляторы или корневые ссылки для разрешения имен в интернете.

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

Второй вариант при наличии инфраструктуры DNS состоит в выборе различных DNS-имен для доменов Active Directory. Например, Contoso может использовать Contoso.net как текущее внутреннее пространство имен DNS и развернуть домены Active Directory, использующие AD.Contoso.net как имя домена (см. рис. 5-8).

В этом случае DNS-сервер разворачивается как основной сервер имен для AD.Contoso.net с записями делегирования для NAmerica.AD. Contoso.net и Europe.AD.Contoso.net. Этот DNS-сервер может быть тем же самым DNS-сервером, который является официальным сервером для Contoso.net, или можно развернуть дополнительный DNS-сервер. Если вы развертываете дополнительный DNS-сервер для домена Active Directory, необходимо сконфигурировать ретрансляторы и корневые ссылки для него.

В третьем варианте при наличии инфраструктуры DNS домен Active Directory является дочерним доменом от внутреннего пространства имен. Например, Contoso мог бы создавать поддомен AD.Contoso.net как домен Active Directory (см. рис. 5-9). В этом случае DNS-сервер для Contoso.net может быть сконфигурирован с записью делегирования для домена AD.Contoso.net. DNS-сервер AD.Contoso.net может быть сконфигурирован с записью ретранслятора, указывающего на DNS-сервер Contoso.net.

Наиболее сложный проект DNS, с которым вы когда-либо столкнетесь, возникнет в случае, если компания решит скомбинировать все способы объединения DNS с внутренним пространством имен. Например, на рисунке 5-10 показано, что компания, возможно, уже использует Contoso.net и Fabrikam.net как внутренние пространства имен. Решив развернуть Active Directory, компания может добавить дочерние домены под существующие, а также создать новое дерево доменов NWTraders.net. С помощью сконфигурированных ретрансляторов и корневых ссылок DNS-серверы могут разрешать любые имена DNS в организации.

Рис. 5-8. Конфигурирование DNS для использования отличающегося внутреннего пространства имен

Рис. 5-9. Конфигурирование DNS путем добавления поддомена к существующему внутреннему пространству имен

Однако это пространство имен DNS не определяет иерархию Active Directory. В примере на рисунке 5-10 домен AD.Contoso.net может быть корневым доменом Active Directory с дочерними доменами NAmerica.AD.Contoso.net и Europe.AD.Contoso.net и доменами AD.Fabrikam.net и NWTraders.net, использующимися в качестве корневых доменов для дополнительных деревьев в лесу Active Directory.

Рис. 5-10. Конфигурирование DNS путем добавления дочерних доменов к существующим доменам

Интеграция с существующей инфраструктурой DNS

Практически все большие компании уже имеют установленную инфраструктуру DNS. Во многих случаях DNS используется для разрешения имен серверов UNIX или для обеспечения потребности пользователей в услугах DNS для доступа в интернет. Иногда услуги DNS обеспечиваются DNS-серверами BIND, выполняющимися на UNIX-серверах. Поскольку существует зависимость Windows NT от имен NetBIOS и от

службы имен интернета для Windows (WINS), в противоположность именам хостов и DNS, многие Windows-администраторы мало касаются службы DNS. Ситуация изменилась с выпуском Active Directory систем Windows 2000 и Windows Server 2003. В главе 3 говорилось о том, что Windows Server 2003 требуется служба DNS для того, чтобы клиенты могли находить контроллеры домена. Поэтому критическим моментом при обсуждении проекта Active Directory становится вопрос о размещении службы DNS.

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

Есть два варианта интеграции для случая, когда должна поддерживаться текущая BIND инфраструктура DNS. Первый вариант состоит в том, чтобы использовать DNS-сервера не от Microsoft и располагать на этих серверах необходимую для Active Directory информацию зон DNS. Такая возможность, конечно, существует. Единственное требование для DNS - сервер должен поддерживать записи SRV. Вы, вероятно, захотите, чтобы серверы DNS также поддерживали динамические обновления (особенно, если вы планируете регистрировать все IP адреса клиентов в DNS) и дополнительные (incremental) зонные передачи. Если текущая инфраструктура использует BIND серверы DNS, серверы BIND 8.1.2 поддерживают записи SRV и динамические обновления. Сервер BIND 8.2.1 поддерживает дополнительные зонные передачи. Если вы используете одну из этих версий BIND, то вы можете продолжать использование DNS-серверов BIND. (Если вы используете DNS-серверы Lucent VitalQIP, то версии 5.2 и более поздние совместимы с BIND 8.2.2.)

Практический опыт. Выбор сервера DNS

Вопрос о том, использовать ли DNS-серверы системы Windows Server 2003 или DNS-серверы не от компании Microsoft, может вызвать горячую дискуссию и не привести к удовлетворительному результату. Большие компании в течение многих лет пользовались DNS-серверами BIND, DNS-администраторы грамотны, опытны и не хотят переходить к службе DNS на платформе Microsoft. Они выражают беспокойство по поводу стабильности, надежности и безопасности службы DNS на серверах Microsoft.

Один из подходов к решению этого вопроса состоит в следующем: на самом деле не имеет значения, чем обеспечивается DNS-служба. Пока DNS-серверы поддерживают записи SRV, Active Directory Windows Server 2003 может работать с любым сервером DNS. Критичным является то, что служба DNS всегда должна быть доступной. Если она перестанет работать в рабочее время, клиенты или серверы не смогут найти контроллера домена Active Directory. Поэтому вопрос можно поставить так: «Какой DNS-сервер обеспечит надежность, необходимую для работы Active Directory?».

Длинные дискуссии относительно надежности различных серверов, похоже, не отражают сути дела. Никакой сервер в единственном числе никогда не может быть полностью надежен, поэтому вопрос надо переформулировать так: «Какой DNS-сервер обеспечит наилучшие варианты для устранения выделенных точек отказа и распределения доступных служб между несколькими серверами?». Серверы Windows Server 2003 реализуют превосходные варианты для обеспечения надежности за счет нескольких серверов, особенно если используются интегрированные зоны Active Directory. С помощью этих зон каждый DNS-сервер может иметь перезаписываемую копию информации DNS. Интегрированные зоны Active Directory также реализуют безопасные обновления.

Многие компании решили оставаться с DNS-серверами BIND, и эти серверы обеспечили требуемые функциональные возможности без каких-либо проблем. Некоторые компании решили переместить основной DNS в DNS-серверы Microsoft и сохранить DNS-серверы BIND как дополнительные серверы имен. Любая из этих конфигураций будет работать до тех пор, пока DNS-серверы доступны, и не имеет значения, какой вариант использует компания.

Второй вариант объединения DNS Windows Server 2003 с BIND состоит в развертывании обоих типов DNS. Многие компании используют DNS-серверы BIND как основной сервер имен для внутреннего пространства имен. Например, компания Contoso может использовать BIND при разрешении имен для Contoso.com. Если она решит развертывать Active Directory и использовать DNS-сервер на базе Windows Server 2003, существует множество вариантов. Если компания Contoso захочет использовать Contoso.com как DNS-имя Active Directory, она может переместить основную зону на DNS-сервер на базе Windows Server 2003 и поддерживать DNS сервер BIND в качестве дополнительного сервера имен. Или DNS-сервер на базе Windows Server 2003 мог бы стать дополнительным сервером имен к DNS-серверу BIND.

Примечание. Вы можете использовать DNS-серверы BIND и DNS-серверы на базе Windows Server 2003 для одного и того же пространства имен. Оба DNS-сервера могут работать как основной или дополнительный сервер имен, содержащие зонную информацию друг для друга. Однако если вы планируете использовать интегрированные зоны Active Directory, то DNS-зона BIND должна быть сконфигурирована как дополнительная зона. Интегрированная зона Active Directory не может быть дополнительной зоной.

Компания Contoso может развертывать Active Directory, используя доменные имена, отличные от тех, которые уже используются на DNS-серверах BIND. Например, имя Contoso.net может использоваться как DNS-имя Active Directory. В этом случае DNS-серверы на базе Windows Server 2003 могут быть сконфигурированы как официальные серверы для Contoso.net, а серверы BIND - как официальные серверы для Contoso.com. DNS-серверы на базе Windows Server 2003 могут быть сконфигурированы с условным ретранслятором на DNS-сервер BIND для Contoso.com. Домен Active Directory можно развернуть также с использованием AD.Contoso.com в качестве имени домена. В этом случае DNS-серверы BIND Contoso.com будут сконфигурированы с записью делегирования, направляющей любой поиск для домена AD.Contoso.com на DNS Windows Server 2003. Серверы DNS системы Windows Server 2003 могут быть сконфигурированы с ретранслятором, указывающим на DNS-сервер BIND.

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