Установка DNS-сервера

Система DNS (Domain Name Service) является ахиллесовой пятой структуры Active Directory. Поскольку сетевые коммуникации в целях доступности осуществляются по именам (скажем, www.thg.ru), должна существовать система преобразования имён в IP-адреса — и наоборот. Прямые запросы преобразовывают имя в IP-адрес, а обратные — IP-адрес в имя.

Установка сервера DNS происходит быстро (иллюстрация выше), правда сразу он обычно не работает.

Довольно важно добавить зону обратного преобразования (Reverse Lookup Zone). Тогда DNS-сервер сможет выдавать имена на основе IP-адресов.

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

Конечно же, нам нужно ввести адресное пространство для локальной сети. В данном случае идентификатор сети будет 192.168.1.x. В качестве маски подсети выбрана 255.255.255.0, при этом сеть может содержать 254 компьютера. Этого количества будет достаточно для дома или малого офиса. Переход на маску 255.255.0.0 увеличит количество компьютеров до 64 516.

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

После подтверждения будет создана зона обратного преобразования.

Наконец, нам понадобится запись PTR на нашу подсеть 192.168.1.0.

Здесь необходимо задать полное доменное имя сервера. В нашем случае это будет testserver.testdomain.com.

Лучшим способом проверки правильной настройки DNS являются утилиты nslookup и ping. Поскольку мы планируем выходить и в Интернет, необходимо проинформировать DNS-сервер, как разрешать запросы на другие имена.

Для простоты мы просто ввели IP-адрес нашего DSL-маршрутизатора в качестве DNS forwarder. Наш сервер будет автоматически перенаправлять запросы к серверу DNS провайдера.

Настройки TCP/IP

Сейчас необходимо отрегулировать настройки TCP/IP, чтобы сервер мог работать в паре с новым сервером DNS. На этот раз в качестве основного сервера DNS мы введём IP-адрес 192.168.1.50. Мы отметили все галочки, поскольку тоже хотим работать с суффиксами DNS.

Мы можем ввести адрес сервера WINS (Windows Internet Naming Service), если будем его устанавливать. Он выбирается в пункте [Control Panel] — [Software] — [Windows Components] — [Network Services] и имеет только ряд опций по конфигурации, так что у вас не должно возникнуть каких-либо проблем.

Источник

Установка DNS службы на Windows Server 2003

Установка DNS на Windows Server 2003

Итак, сегодня мы устанавлиаем и настраиваем службу DNS (служба доменных имён) на нашем сервере под управлением Windows 2003 Server. Для чего нужна эта служба? В общем случае она производит преобразование символьного имени компьютера в его IP-адрес. Ведь компьютеры на 3-ем уровне модели OSI общаются между собой по IP-адресам. А нам, людям, привычней использовать и запоминать не числовой адрес, а простое мнемоническое символьное имя. Так вот, DNS-служба и выступает посредником между нами и сетевыми протоколами, преобразуя адреса типа SERV.MAIN.COM в 192.168.10.1.

Откроем окно “Управление сервером” и добавим новую роль:

При этом происходит поиск установленных и запущеных служб, а так же тех служб, которые мы можем добавить:

Появился список. В данный момент нас интересует служба DNS. Выбираем её, жмём Next.

Теперь нужно выбрать создаваемые зоны.

Forward – прямая зона, нужна для преобразования имени хоста в IP адрес. Рекомендовано для небольших организаций.

Reverse – обратная зона, нужна для обратного преобразования, IP адреса в имя хоста. В данный момент не критично, можно обойтись только прямой зоной, но в моём примере я делаю обе.

Создавать зону сейчас или потом? Создадим сейчас.

Зоны бывают разных типов. Primary – первичная, хранится на этом сервере. Если уже есть DNS-сервер с перивчной зоной – нужно будет создать вторичную (Secondary) и копировать записи из первичной.

Вводим имя нашей зоны. Очень важный этап, образуется как бы суффикс, который будет приписываться всем хостам в этой зоне.

Выбираем файл, в котором будут храниться записи DNS. Создавая первый сервер – создаём новый файл. Если бы мы мигрировали с сервера на сервер без потери записи DNS, то могли бы просто скопировать файл со старого сервера, и в этом окне выбрать “использовать существующий файл”.

Здесь мы разрешаем динамические обновления зоны.

Теперь занимаемся обратной зоной. Создаём её сейчас.

Выбираем пространство адресов зоны.

Создаём новый файл. Обратите внимание на обратный порядок следования октетов IP-адреса.

Надо немного подождать.

Когда всё готово, запускаем консоль управления DNS-сервером.

Нужно произвести ещё некоторые настройки! Надеюсь, всё будет понятно по скриншотам: Выбираем свойства зоны.

На вкладке Name Servers выбираем наш сервер и открываем редактирование Edit. Вписываем полное имя узла (как у нас в схеме планировалось) и присваиваем IP-адреса этому узлу.

Открываем вкладку “Передача зон” и разрешаем передавать зоны на любой сервер. Затем вкладку SOA и дописываем суффиксы к Primary server и Responsible person.

Закрываем свойства, теперь добавим новый хост (узел A). Наверное следует немного пояснить типы узлов:

• A – хост, имя которого разрешается (преобразуется) в IP-адрес.
• CNAME – алиас, то же самое, что псевдоним.
• MX – почтовый сервер.
• NS – сервер DNS.
• PTR – обратная запись (в reverse-зоне)

Итак, нам нужен A – новый хост.

Вписываем имя host и IP-адрес. Таким образом видим полное имя host.serv.main.com. – именно так в нашем плане и сказано!

Проверка работы DNS методом простого пинга

Проверяем созданую запись. Пингуем хост с серверной машины:

Проверка работы DNS с помощью NSLOOKUP

Проверяем DNS-сервер с host-машины. Для этого служит программа nslookup.

Вводим IP адрес, который нужно преобразовать в имя хоста. Сервер возвращает нам host.serv.main.com. Работает!

Друзья! Вступайте в нашу группу Вконтакте, чтобы не пропустить новые статьи! Хотите сказать спасибо? Ставьте Like, делайте репост! Это лучшая награда для меня от вас! Так я узнаю о том, что статьи подобного рода вам интересны и пишу чаще и с большим энтузиазмом!

Также, подписывайтесь на наш канал в YouTube! Видео выкладываются весьма регулярно и будет здорово увидеть что-то одним из первых!

Источник

Служба DNS в Windows Server 2003

Новые функции для работы с многодоменными лесами

В статье «Устраняем проблемы DNS», опубликованной в этом же номере, речь идет о том, как построить инфраструктуру DNS для двухдоменного леса Active Directory (AD). В ней отмечается, что, хотя DNS-серверы на базе Windows 2000 успешно работают в многодоменных лесах, некоторых функций в них все же недостает. Этот пробел можно восполнить с помощью DNS-серверов на базе Windows 2003.

В качестве простого примера в статье рассматривается лес с двумя доменами — один из них назван bigfirm.biz, а другой — bigfirm.com. В обоих доменах используется разделенная (split-brain) DNS; они должны взаимно разрешать имена и SRV-записи для поиска контроллеров домена (DC), чтобы системы и пользователи каждого домена могли быть идентифицированы в любом из них. Компания Bigfirm может выбрать один из двух подходов. Можно построить динамические зоны для каждого домена и не интегрировать их с AD. В этом случае администраторы должны проверить все DNS-серверы корпоративной сети и убедиться, что каждый из них является первичным или вторичным сервером как для зоны bigfirm.biz, так и для bigfirm.com.

Альтернативный подход — преобразовать bigfirm.biz и bigfirm.com в зоны, интегрированные с AD. Как правило, интегрированные с AD зоны — более подходящее решение для AD-зон, чем разделенная DNS. Но, к сожалению, DNS-серверы на базе Windows 2000 обмениваются DNS-информацией о зоне только с DC данной зоны. Например, если DNS-зона bigfirm.biz интегрирована с AD, то только DNS-серверы, которые одновременно являются контроллерами домена bigfirm.biz, смогут получить DNS-информацию о bigfirm.biz. Даже если изменить DNS-зону bigfirm.com, интегрировав ее с AD, DNS-серверы bigfirm.com получат информацию только о bigfirm.com, но не о bigfirm.biz, даже если оба домена находятся в одной сети. Чтобы устранить невосприимчивость DNS-серверов на базе Windows 2000 к любой AD-интегрированной информации вне своего домена, следует сделать эти DNS-серверы обычными вторичными серверами для других серверов в лесу.

Предположим, что у компании Bigfirm имеется несколько тысяч хост-машин и несколько десятков DNS-серверов. Каждый из этих DNS-серверов играет роль вторичного сервера по крайней мере в одной зоне. Поэтому каждый раз, когда в зоне происходят изменения, эту информацию приходится пересылать на все вторичные серверы компании, что создает большую нагрузку на каналы связи и процессор. Microsoft DNS не требует пересылки всей зоны при любом незначительном изменении (в отличие от некоторых старых программных решений DNS), но все же процедура пересылки данных зоны способом, описанным в документе RFC (Request for Comments), неэффективна. В случае интеграции с AD пересылка выполняется более эффективным механизмом репликации AD со сжатием трафика репликации между сайтами. В DNS-серверах Windows 2003 появились три усовершенствования по сравнению с Windows 2000: зоны-заглушки (stub zones), условная ретрансляция (conditional forwarding) и зоны, интегрированные с AD в масштабах всего леса.

Зоны-заглушки

Благодаря зонам-заглушкам программы DNS-серверов Windows 2003 формируют зоны, которые отличаются от размещаемых на стандартных первичных и вторичных DNS-серверах. В зонах на стандартных первичных и вторичных DNS-серверах содержится полный экземпляр файла зоны, а в зоне-заглушке хранится лишь минимальный файл зоны. Зона-заглушка вместо всех записей зоны хранит лишь записи Start of Authority (SOA) и Name Server (NS). Другими словами, единственная информация, которую можно получить от DNS-сервера с зоной-заглушкой для данной зоны, — это имена DNS-серверов и сведения о том, какой из них является первичным DNS-сервером зоны. IP-адрес определенной хост-машины в зоне из зоны-заглушки получить нельзя.

Чем может быть полезна зона, которая лишь сообщает, какие серверы являются серверами имен зоны? Предположим, что bigfirm.biz располагает большой зоной, содержащей тысячи записей, и разработчикам домена требуется множество DNS-серверов. Они создали первичный DNS-сервер и группу вторичных DNS-серверов. Но сетевые трассировки показывают, что DNS-серверы тратят больше времени на получение последней информации о зоне от первичного DNS-сервера (и тем самым замедляют работу первичного сервера и нагружают каналы связи), чем на рассылку ответов на запросы. Разработчики сетей должны разместить зону какого-нибудь типа для bigfirm.biz на каждом DNS-сервере сети Bigfirm, но обмен данными между первичными и вторичными серверами приводит к дополнительной трате ресурсов. Выход — в преобразовании некоторых вторичных DNS-серверов в DNS-серверы зоны-заглушки. Если эти DNS-серверы получают запрос относительно bigfirm.biz, то они не дадут ответа, но им известно, на какой сервер нужно направить запрос. Для этого не требуется проходить по всей иерархии DNS-серверов в поисках источника информации о bigfirm.biz. Затем запрашивающий DNS-сервер задает DNS-серверу зоны-заглушки вопрос относительно bigfirm.biz, и сервер зоны-заглушки передает ответ. Кроме того, серверы зоны-заглушки играют роль серверов кэширования (как практически все DNS-серверы), поэтому следующий компьютер, запросивший информацию о bigfirm.biz, получит ответ немедленно, так как сервер с зоной-заглушкой может предоставить ответ на запрос из своего кэша.

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

Условная ретрансляция

Как быть, если администраторы Bigfirm не хотят использовать DNS-серверы с зоной-заглушкой? Существует ли способ разместить в сети группу DNS-серверов, не назначая их вторичными серверами для bigfirm.biz и bigfirm.com? Да, поскольку DNS-служба Windows 2003 обеспечивает метод, называемый условной ретрансляцией.

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

Для условной ретрансляции DNS-сервер настраивается таким образом, что при поступлении запроса о конкретном домене (например, bigfirm.biz), на который у сервера нет ответа, он просит другой DNS-сервер (ретранслятор) найти ответ. Следует обратить внимание на различие: стандартная ретрансляция — это передача безответных запросов о любом домене конкретному DNS-серверу, а условная ретрансляция заставляет передавать ретранслятору только запросы о конкретном домене.

Служба DNS Windows 2003 позволяет указать сервер или серверы, которые будут отвечать на запросы о конкретном домене. Поэтому если компания Bigfirm намерена развернуть 10 вторичных DNS-серверов для bigfirm.biz и bigfirm.com и еще 100 DNS-серверов для разрешения внутренних запросов разделенной DNS bigfirm.biz и bigfirm.com, то нужно просто настроить 100 этих серверов на условную ретрансляцию всех запросов bigfirm.biz на 10 вторичных серверов.

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

Еще одна проблема, возникающая при сравнении зон-заглушек с условной ретрансляцией, связана с полномочиями. Мы предполагаем, что bigfirm.biz и bigfirm.com — единая дружная компания, но что если между подразделениями существует соперничество? В этом случае размещать зоны-заглушки для серверов bigfirm.com на серверах bigfirm.biz можно лишь с разрешения администраторов bigfirm.com. Для того чтобы серверы bigfirm.biz получали при репликации DNS информацию от серверов bigfirm.com, серверы bigfirm.com должны дать согласие на передачу этой информации при пересылке зоны. По умолчанию DNS-серверы Windows 2000 передают данные любому запросившему их серверу. Но находящиеся в зоне DNS-серверы на базе Windows 2003 по умолчанию выполняют пересылки зоны только на серверы, имеющие в этой зоне NS-записи. Поэтому, прежде чем DNS-сервер bigfirm.biz с зоной-заглушкой bigfirm.com сможет обновить информацию о зоне с DNS-сервера bigfirm.com, этот сервер bigfirm.biz должен получить NS-запись в зоне bigfirm.com. Если кто-то захочет настроить свои DNS-серверы на пересылку всех запросов для сайтов microsoft.com на мой DNS-сервер, я не смогу этому помешать. Но вряд ли кто-нибудь сделает это, так как в результате существенно замедлится процесс разрешения имен для данного лица.

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

Зоны, интегрированные с AD в масштабах всего леса

Третий метод, с использованием зон, интегрированных с AD в масштабах всего леса, расширяет возможности DNS-зон, интегрированных с AD, по сравнению с Windows 2000. DNS-зоны, интегрированные с AD, тиражируют информацию DNS между DNS-серверами, которые также должны быть контроллерами домена (DC). Но на серверах Windows 2000 интегрированная с AD информация перемещается только внутри домена; DNS-серверы bigfirm.biz не могут видеть интегрированную с AD зону bigfirm.com, а DNS-серверы bigfirm.com не видят интегрированную с AD зону bigfirm.biz.

В Windows 2003 можно создать интегрированные с AD DNS-зоны, которые выполняют репликацию не только во всем домене, но и во всем лесу. Поэтому можно сначала сформировать bigfirm.biz и bigfirm.com, как описано в статье «Устраняем проблемы DNS», со стандартными первичным и вторичным серверами. Затем, после того как будут сформированы домены и лес AD, можно просто изменить несколько параметров и настроить все DNS-серверы bigfirm.biz и bigfirm.com на хранение информации в лесу. Впоследствии процесс репликации AD обеспечит синхронизацию всех DNS-серверов. Естественно, все DC должны работать на Windows 2003 — по крайней мере, на это указывают проведенные мною эксперименты.

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

Поделитесь материалом с коллегами и друзьями

Источник