Лабораторная работа №2

Настройка и администрирование службы DNS

Цель работы: Изучение одной из основных служб контроллера домена – службы DNS (Domain Name Service). Приобретение навыков по установке службы, настройке ее компонентов.

Краткие сведения из теории.

Процесс установки контроллера домена несколько отличается для случая развертывания нового домена и добавления дополнительного контроллера в существующий домен. При организации нового домена прежде чем устанавливать сервер, Active Directory и связанные с ним службы, важно разработать реализацию DNS (Domain Naimed Server), которая бы соответствовала как вашей системе разрешения имен, так и требованиям Active Directory. DNS необходим Active Directory как для разрешения имен, так и для определения пространства имен, так как доменные имена в Windows 2003 базируются на соглашении об именовании DNS. Как следствие, любой сервер, на который вы устанавливаете Active Directory, должен иметь в своих настройках протокола TCP/IP указание на сервер DNS, который необходимо установить и настроить предварительно. Если вы не сделаете это заранее, то инсталляция Active Directory автоматически создаст для вас структуру DNS, которая, возможно, не будет соответствовать вашим пожеланиям. Рассмотрим основные аспекты службы DNS, которые необходимы для успешного внедрения службы как для разрешения имен, так и для поддержки Active Directory.

Первая концепция, которую необходимо запомнить, это использование DNS для разрешения имен узлов (нахождение соответствующего узлу IP-адреса) или разрешения FQDN (Fully Qualified Domain Name – полностью определенное имя домена) в его IP-адрес. FQDN представляет имя узла в виде доменного имени системы. Например:

www.2000trainers.com
или более подходящее для локальной сети  - user1.ipnet.i5.ru

В этом примере имя узла – левая часть полного имени, а именно www или user1. Имена узлов также могут разрешаться при помощи файла HOSTS, который является статическим текстовым файлом и находится в папке %systemroot%\system32\drivers\etc на локальном компьютере. Не стоит путать DNS c WINS, которая ставит в соответствие Netbios имени соответствующий IP-адрес (также имеется текстовый эквивалент данной службы, файл LMHOSTS).

Служба DNS хранит большое число записей ресурсов различного типа, кроме простой записи хоста, т.н. «А» записи. Наиболее используемые типы записей, которые можно встретить в файле зоны, рассмотрены ниже:

SOA – представляет из себя запись ресурса начальной записи зоны, и предоставляет информацию о зоне, включая сведения о том, какой сервер является основным, кто отвечает за административный контакт, как часто файл базы данных проверяется на наличие изменений, серийный номер базы данных, значение времени жизни, и т.д.

A – представляет уникальный адрес узла в сети, сопоставляя его имя IP-адресу.

NS – обозначает доменное имя и связанное с ним FQDN сервера имен, который является полномочным для домена.

MX – обозначает, что данный узел является почтовой службой (сервером почты или сервером пересылки) для определенного домена.

PTR – предоставляет возможность для обратного просмотра (сопоставляет IP-адресу узла его FQDN). Это позволяет находить имя узла, связанное с IP-адресом. Записи PTR находятся в файле reverse lookup zone (зоны обратного просмотра).

SRV – сопоставляет отдельные службы одному или нескольким узлам и наоборот. Например, записи могут обозначать сервер как сервер Глобального Каталога, контроллер домена и т.д.

Вторая концепция, с которой вы должны быть знакомы – эта концепция Зоны. Зона – это область пространства имен DNS, которая функционирует как административная единица. То есть группа серверов ответственна (имеет полномочие) за записи, относящиеся к некоторому домену или поддомену. Можно говорить о зонах как об областях ответственности. Например, можно создать зону для домена ipnet.i5.ru и создать 2 сервера, которые будут отвечать (будут полномочны) за хранение записей для данной зоны. Можно затем создать другую зону для поддомена market. ipnet.i5.ru и будет 2 других сервера, которые будут отвечать (будут полномочны) за эту другую зону. Однако зона может включать в себя несколько доменов, если они лежат в прилегающих друг к другу пространствах имен. Например, 2000trainers.com и asia.2000trainers.com могут являться частями одной зоны и иметь несколько серверов, отвечающих за хранение записей, относящихся к обоим доменам. Если посылается запрос на этот DNS сервер для поиска записи ресурса, находящегося в 2000 trainers.com или asia.2000trainers.com, этот DNS сервер сможет ответить на запрос, так как он будет полномочен для зоны, в которую включены оба домена.

Главной причиной для того, чтобы иметь несколько зон, является разделение административной ответственности, так же как и задача пересылки зон. Например, если есть один DNS администратор в Москве и один в Санкт-Петербурге. Тогда применение двух зон может быть оправданным. Другими словами, если есть только одна зона, тогда все DNS сервера (возможно, их два в Москве и два в Санкт-Петербурге) будут вынуждены участвовать в передаче зоны для получения обновлений. Это может вызвать недопустимый уровень трафика по линиям WAN.

Существует 5 основных типов серверов DNS. Это основные, вторичные, интегрированные в Active Directory, серверы пересылки и кэширующие серверы. Каждый из типов описан ниже:

Основной сервер DNS – основным сервером DNS является сервер, который полномочен для зоны. По существу это означает, что в зоне есть сервер, на котором можно производить изменения в базе данных зоны.

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

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

Кэширующий только – кэширующий сервер DNS не является полномочным для зоны. Как следствие, он только получает клиентские запросы, получает запросы других серверов DNS, кэширует результаты и посылает ответы клиентам. По умолчанию кэширующий сервер DNS пересылает все запросы, ответы на которые не найдены в его кэше, корневому серверу DNS.

Сервер пересылки DNS – серверы DNS могут быть настроены так, что будут пересылать запросы, которые не могут разрешить, к какому-либо определенному серверу. Такие серверы называются forwarder (сервер пересылки). Серверы пересылки могут впоследствии обрабатывать запросы, вместо других серверов DNS. Это позволяет уменьшить время обработки некоторых запросов по поиску узлов (в Интернете, например), т.к. сервер пересылки обрабатывает запросы и кэширует результат, который потом возвращается к компьютеру, сделавшему запрос. Это может улучшить и скорость и производительность.

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

Записи для служб – в реализации DNS в Windows 2003 поддерживаются записи для такого важного типа ресурсов, как записи служб (часто упоминаемые как SRV записи). Записи служб позволяют клиентам запрашивать DNS-поиск для систем, на которых запущены определенные службы, такие как Глобальный Каталог (который обозначается как GC-запись).

Динамическая DNS – в традиционных реализациях DNS все записи было необходимо создавать и изменять вручную на DNS сервере, что могло отнимать огромное количество времени. Реализация DNS в Windows 2003 называется Dynamic DNS или DDNS. В данной реализации клиенты имеют возможность автоматически обновлять свои записи, которые главным образом используются в среде, где клиенты подключаются к серверу DHCP для получения IP-адресов. Windows server 2003 является не единственной OС фирмы Microsoft, которая поддерживает динамическое обновление. Можно настроить сервер DHCP в Windows 2003 так, что он сможет обновлять DNS на стороне клиентов, что позволяет клиентам, работающим под другими (не-Windows 2003) OС, обновлять информацию о себе в DNS. Динамическая DNS также очень удобна для контроллеров домена, которые также могут автоматически регистрировать записи своих сервисов, в противном случае, все это было бы необходимо делать вручную.

Безопасное динамическое обновление – если DNS зона является интегрированной в Active Directory, то Windows 2003 позволяет вам использовать нечто, что называется безопасным динамическим обновлением. Заметьте, что простые динамические обновления могут быть потенциально опасными, потому что любой клиент может быть зарегистрирован в DNS, так как динамический DNS только отвечает на запросы, но не аутентифицирует их. Если установлено безопасное динамическое обновление, только пользователь или система, которые имеют соответствующие разрешения на связанных ACL (access control list – списках управления доступом) для зоны, могут добавлять записи в DNS. По умолчанию группа аутентифицированных пользователей имеет необходимые разрешения. Клиентские системы сначала предпринимают попытку использовать обычный запрос по умолчанию и, если он будет отвергнут, безопасное обновление.

Добавочная передача зоны – реализация NT 4 DNS поддерживала только AXFR, или полную передачу зоны. При этой конфигурации каждый раз, когда основной сервер имен осуществлял передачу зоны вторичному серверу, файл базы данных зоны передавался целиком, даже если в нем произошло единичное изменение. Windows 2003 поддерживает IXFR или добавочную (инкрементную) передачу зоны. В данной реализации, только изменения передаются в ходе передачи зоны, вместо передачи всего файла базы данных зоны.

Интеграция с Active Directory – Windows 2003 продолжает поддерживать традиционную реализацию по схеме основной/вторичный сервера DNS, использовавшуюся в предыдущих версиях Windows server. В данном сценарии, изменения в файле зоны могут быть сделаны только на основном сервере, так как только он содержит редактируемую копию файла зоны. В Windows 2003 вводится новая концепция – DNS, интегрированная в Active Directory. В этой реализации файл зоны DNS и связанная с ним информация хранится как объект в Active Directory вместо того, чтобы находиться в папке DNS на жестком диске. Эта интеграция позволяет любому контроллеру домена, на котором запущена служба DNS, делать изменения в базе данных DNS, при этом изменения в зоне реплицируются как часть процесса репликации Active Directory. Это также позволяет сделать службу DNS более отказоустойчивой. В традиционной среде DNS, если основной сервер имен выходит из строя, все динамические изменения в DNS становятся невозможными, так как редактируемая копия зоны недоступна. В службе DNS, интегрированной в Active Directory, все DNS сервера могут осуществлять обновления. Заметьте, что традиционные сервера DNS могут продолжать существовать в такой среде – они могут быть вторичными и использовать сервер DNS, интегрированный в Active Directory, как основной сервер для получения файла зоны.

Для Active Directory в Windows 2003 требуется, чтобы служба DNS функционировала нормально. Безусловным требованием является поддержка службой DNS записей служб – SRV.

Нужно понимать, что означают различные записи служб SRV и связанные с ними поддомены, которые вы можете найти (или которые потребуется создать) в реализации службы DNS для поддержки Active Directory. Windows 2003 использует записи служб в DNS для того, чтобы определять местоположение контроллеров домена в конкретном домене, контроллеров домена расположенных на том же сайте, серверов Глобального Каталога, центров распределения ключей и т.д. Записи служб используют стандартный формат для записей, пример которого приведен ниже:

_service._protocol.name ttl class SRV priority weight port target

_service – представляет имя службы, которая запущена на контроллере домена, такая как ldap (для контроллера домена), gc (для сервера Глобального Каталога), kerberos (для центра распределения ключей) и т.д.

_protocol – определяет, какой транспортный протокол используется, например TCP или UDP.

Name – определяет имя домена, связанное с записью, например ipnet.i5.com.

Ttl – определяет время жизни записи в секундах.

Class – определяет значение класса записи DNS, практически всегда это IN для Интернета.

Priority – определяет уровень приоритета для сервера. Клиент пытается контактировать с сервером, у которого минимальный уровень приоритета.

Weight (вес) – является функцией выравнивания нагрузки. Если несколько серверов имеют одинаковый приоритет, клиент выбирает запись SRV с наибольшим весом.

Port – определяет номер порта, на котором установлена данная служба.

Target (цель) – определяет FQDN узла, на котором запущена служба.

Таким образом, контроллер домена с FQDN dc1.ipnet.i5.ru, который является сервером Глобального Каталога, будет иметь следующую запись этого сервиса:

_gc._tcp.ipnet.i5.ru 600 IN SRV 0 100 3268 dc1.ipnet.i5.ru

Контроллеры домена регистрируют записи своих служб, когда запускается их служба Netlogon. Следовательно, останавливая и вновь запуская службу Netlogon на контроллере домена, можно тем самым добиться перерегистрации всех SRV записей. Рассмотрим различные поддомены, которые создаются в домене в ходе реализации службы Windows 2003 DNS. В домене создаются четыре главные поддомена:

_msdcs – этот поддомен используется для того, чтобы дать возможность пользователям находить контроллеры домена, которые предоставляют специфические службы, запущенные под Windows 2003.

_sites – этот поддомен используется для того, чтобы дать возможность пользователям находить контроллеры домена, которые предоставляют специфические службы в конкретном сайте.

_tcp – этот поддомен содержит список служб, которые используют протокол ТСР для взаимодействия.

_udp - этот поддомен содержит список служб, которые используют протокол UDP для взаимодействия.

Записи служб и их содержание могут контролироваться при помощи как оснастки DNS MMC (Microsoft Menegment Console), так и запросов DNS, которые выполняются утилитой nslookup.exe. Синтаксис запроса сервера DNS для получения перечня всех записей служб для данного домена показан ниже:

C:\Nslookup

>ls –t SRV ipnet.i5.ru

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

Для начала работы по созданию новой зоны потребуется уже существующий домен (пусть это будет домен ipnet.i5.ru) и компьютер, с установленной на нем OС Windows server 2003. Конфигурирование зоны потребует установки на сервер службы DNS при помощи мастера.

 

Щелкните на ссылке «Добавить или удалить роль» и следуйте инструкциям мастера установки. В окне «Установка и удаление программ» выберите сетевые службы

 

 

В составе служб выберите DNS

 

 

После того, как вы сделаете это, откройте оснастку DNS и вы увидите следующее окно:

 

По умолчанию сервер будет действовать как кэширующий сервер, просто пересылая запросы корневому серверу, когда ответ на запрос не может быть найден в его кэше. Однако для поддержки Active Directory должна быть создана зона, которая будет правомочной для создаваемого домена Active Directory. Щелкнем правой кнопкой мыши на forward lookup zone (Зоны прямого просмотра) и выберем New Zone (Создать новую зону). При этом запустится мастер создания новой зоны. Существует три вида зон, которые могут быть созданы:

 

Заметьте, что опция для интегрированной в Active Directory зоны недоступна до тех пор, пока Active Directory не будет установлена. Если вы добавляете контроллер в существующий домен, то есть возможность выбора - standard secondary (дополнительная зона) или standart primary - создание основной зоны. Основная зона может быть впоследствии преобразована в интегрированную в Active Directory, как мы увидим чуть позднее. Наилучшим выбором будет создание основной зоны, что впоследствии даст возможность организовать полноценный резервный DNS сервер. Зона должна обязательно иметь название, поэтому выберете например имя ipnet.i5.ru, что вызовет создание файла зоны, который будет называться ipnet.i5.ru.dns.

 

Перед созданием зоны выдается предупреждающее сообщение

 Новая зона создается в поддиректории Зоны прямого просмотра:

 

 

После создания зоны удостоверьтесь, что на вкладке TCP/IP свойств сервера, который вы хотите повысить до контроллера домена, имеется запись для этого, вновь созданного, сервера DNS (это может быть одна и та же система). Также заметьте, что свойства зоны доступны для изменения настроек, таких как тип зоны (который может быть изменен, после установки Active Directory), поддержка динамических обновлений (отключенная по умолчанию), SOA (Запись ресурса начальной записи зоны), Серверы имен, WINS и передачи зоны, как показано на рисунке, расположенном ниже:

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

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

Также нужно иметь ввиду, что зона может включать в себя несколько доменов только в том случае, когда они имеют связанные пространства имен. Если вы захотите, чтобы один сервер DNS поддерживал домены, называемые kaf.operzone.ru и ipnet.i5.ru, то вы вынуждены будете создать две отдельные зоны. Однако, для доменов ipnet.i5.ru и market.ipnet.i5.ru вам будет достаточно одной зоны.

Хоть это и не является обязательным для поддержки Active Directory, все же будет правильным всегда создавать reverse lookup zones (зон обратного поиска) для всех зон прямого поиска, так как они помогают осуществлять обратное разрешение IP-адресов в имена узлов. Имена зон обратного поиска записываются в формате, в котором часть IP-адреса, соответствующая подсети узла, представляется в обратном порядке и на конце добавляется имя домена обратного поиска. Например, доменное имя для зоны обратного поиска, которая поддерживает сеть 192.168.0.0. будет представлена в виде 168.192. in-addr.arpa. Вы также можете задать динамические обновления для этой зоны для того, чтобы обратные записи добавлялись автоматически. Создайте зону обратного просмотра точно так же, как и прямого просмотра и введите адрес сети в появившемся окне

 

В окне динамического обновления задайте возможность такого обновления

В итоге будут получены две зоны прямого и обратного просмотра:

После установки DNS сервера и организации зон следует проверить правильность настроек и работоспособность DNS сервера. Есть три основных средства для выявления неисправностей серверов DNS, о которых необходимо знать. Первое из них – это вкладка «наблюдение» свойств сервера DNS, показанная на рисунке, расположенном ниже:

 

Этот инструмент позволяет посылать запросы серверу DNS для того, чтобы убедиться, что он функционирует нормально. Простой запрос посылается только к данному серверу и его выполнение оценивается как «Пройден» или «Отказ». Рекурсивный запрос, при котором сервер DNS будет опрашивать другие сервера DNS для получения ответа, тоже будет оценен в виде «Пройден» или «Отказ». Для выполнения запроса нужно нажать кнопку «Тест». Этот инструмент может применяться для тестирования DNS на регулярной основе, если вы определите интервал выполнения теста.

Ведение журнала DNS (logging) может быть также использовано для целей выявления неисправностей, так как он записывает все главные события DNS. Настройка ведения журнала выполняется на вкладке Logging свойств сервера DNS, а все накопленные данные сохраняются в текстовом файле, который называется dns.log и хранится в папке %systenroot%\system32\dns на сервере. Заметьте, что чрезмерное увлечение регистрацией событий может негативно повлиять на производительность сервера и поэтому должна использоваться только в целях выявления неисправностей.

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

nslookup [-option...] [host-to-find | -[server]]

Если в командной строке задать параметр host-to-find, то nslookup будет работать в неинтерактивном режиме. Если аргументы не заданы или первый аргумент — дефис (-), то nslookup будет работать в интерактивном режиме. При необходимости с помощью аргумента -server можно указать другой DNS-сервер, где server — IP-адрес запрашиваемого DNS-сервера. В противном случае nslookup будет по умолчанию обращаться к DNS-серверу, который задается в файле /etc/resolv.conf.

Параметры nslookup можно изменить тремя способами. Во-первых, можно задать параметры в командной строке вместе с командой nslookup. Во-вторых, можно указать их в интерактивной командной строке nslookup с помощью команды set. И в-третьих, можно создать в своем рабочем каталоге $HOME файл.nslookuprc и указать в нем желаемые параметры, по одному на строку. Список параметров, которые можно использовать с командой nslookup, приведен в таблице.

 

Параметры nslookup
Параметр	Описание
all	Выводит текущие значения параметров
class	Устанавливает класс DNS (по умолчанию = IN)
[no]debug	Включает/выключает режим отладки (по умолчанию =nodebug)
[no]d2	Включает/выключает режим полной отладки (по умолчанию =nod2)
domain=name	Устанавливает доменное имя по умолчанию name
srchlist=name1/ name2...	Изменяет домен по умолчанию на name1 и производит поиск по списку name1/name2...
[no]defname	Добавляет доменное имя по умолчанию к компоненту запроса
[no]search	Добавляет доменные имена в списке к имени хоста (по умолчанию =search)
port=value	Изменяет номер порта TCP/UDP (по умолчанию = 53)
querytype=value	Изменяет тип запрашиваемой записи (по умолчанию = А)
type=value	То же, что и querytype.
[no]recurse	Указывает серверу имен запросить другие серверы для получения ответа (по умолчанию = recurse)
retry=number	Устанавливает число повторов запроса при неудачном ответе (по умолчанию = 4)
root=host	Изменяет имя корневого сервера на хост с именем host (по умолчанию = ns.internic.net)
timeout=number	Изменяет интервал времени ожидания ответа на значение, равное number (по умолчанию = 5 сек)
[no]vc	Всегда использовать виртуальную цепочку (по умолчанию = novc)
[no]ignoretc	Игнорировать ошибки при урезании пакета (по умолчанию = noignoretc)

В следующем листинге показан пример сеанса nslookup, во время которого запрашивается информация о хосте www.linux.org. На запрос с установленными по умолчанию параметрами для указанного имени просто возвращается соответствующий ему IP-адрес. В нашем примере демонстрируется изменение параметров с целью поиска почтовых серверов для данного домена.

 

1 [katie@shadrach katie]$ nslookup2 Default Server: ns1.isp.net3 Address: 10.0.0.145 > www.linux.org6 Server: ns1.isp.net7 Address: 10.0.0.189 Non-authoritative answer:10 Name: www.linux.org11 Address: 198.182.196.561213 > set type=MX14 > www.linux.org15 Server: ns1.isp.net16 Address: 10.0.0.11718 Non-authoritative answer:19 www.linux.org preference =20, mail exchanger = router.invlogic.com20 www.linux.org preference =30, mail exchanger = border-ai.invlogic.com21 www.linux.org preference =10, mail exchanger = mail.linux.org2223 Authoritative answers can be found from:24 linux.org nameserver = NS0.AITCOM.NET25 linux.org nameserver = NS. invlogic. com26 router.invlogic.com internet address = 198.182.196.127 border-ai.invlogic.com internet address = 205.134.175.25428 mail.linux.org internet address = 198.182.196.6029 NS0.AITCOM.NET internet address = 208.234.1.3430 NS.invlogic.com internet address = 205.134.175.25431 > exit32 [katie@shadrach katie]$

 

В строке 5 формируется запрос для хоста с именем www.linux.org. В строках 6 и 7 показан DNS-сервер, который обрабатывает данный запрос, а в строках 9–11 отображается, что сервер выдает неавторитетный ответ об IP-адресе. Очевидно, что кто-то уже обращался к этому же хосту и его IP-адрес хранился в кэше локального DNS-сервера. В строке 13 устанавливается параметр, с помощью которого запрашивается информация о почтовых серверах для данного домена. В строках 18–30 отображается информация, полученная от DNS-сервера. Строки 18–21 являются по сути разделом ответа пакета DNS, который сигнализирует о том, что ответ не является авторитетным, и далее показывает три почтовых сервера, ответственных за доставку электронной почты на хост www.linux.org. В строках 23–30 показан авторитетный ответ и дополнительная информация из пакета DNS. Так, строки 23–25 показывают два авторитетных DNS-сервера для домена linux.org, в которых содержаться исходные записи о www.linux.org. В строках 26–30 отображается дополнительная информация об IP-адресах хостов, содержащихся в ответах.

Последовательность выполнения работы:

1. Установка DNS сервера.

· Запустите мастер установки DNS сервера и следуйте инструкциям мастера как описано выше.

· После установки сервера DNS в меню программ|администрирование появится команда запуска оснастки «DNS».

2. Создайте зону прямого просмотра и настройте параметры зоны, как описано выше. После задания параметров нужно уметь объяснить параметры настройки.

3. Создайте зону обратного просмотра и настройте параметры зоны. Нужно уметь объяснить параметры настройки.

4. Проверьте работоспособность DNS сервера на простых и рекурсивных запросах как описано выше.

5. С помощью утилиты nslookup определить:

· IP адрес www.mail.ru

· Имена и адреса почтовых серверов для www.mail.ru

· Местонахождение службы DHCP в собственном домене.