Создание и трансферты зоны
Новые зоны добавляются тогда, когда создается новое или расширяется существующее пространство имен DNS. При создании нового пространства имен новая (первичная) зона соответствует домену второго уровня (например, shazbot.com). При расширении существующего пространства имен новая зона соответствует одному из дочерних доменов (например, sales.shazbot.com). Для создания новой зоны, работая с консолью DNS, необходимо в меню “Действия” выбрать пункт “Зона прямого поиска” и отметить опцию “Новая зона”. В результате мастер установки поможет создать новую зону. Зона обратного сопоставления “Revers look up Zone” позволяет в случае необходимости определить доменное имя сетевого узла по его IP-адресу. Необходимость создания новой зоны обратного сопоставления может возникнуть, если в состав существующей ИС добавляется новая подсеть. Процедура создания зоны обратного сопоставления совпадает с процедурой создания обычной зоны. Однако при работе с консолью DNS здесь необходимо вместо зоны прямого поиска выбрать зону обратного поиска. Прежде чем создать зону обратного сопоставления, необходимо разобраться в принципе ее работы, иначе появляется риск нарушения работы всей информационной системы. Трансферт зоны позволяет передавать информацию с главного сервера на подчиненные. Это необходимо в двух случаях: 1) когда первичный сервер имен, обнаруживающий изменение в зоне, передает уведомление об этих изменениях всем вторичным серверам, на оповещения которых он настроен; 2) когда на вторичном сервере имен начинает работать служба DNS или истекает интервал обновления, длительность которого определяется в записи SOA (start of authority) зоны. При возникновении одного из перечисленных условий вторичный сервер имен предлагает главному серверу сопоставить свой локальный номер файла зоны с серийным номером файла мастера. Если с момента последнего запроса номер файла-зоны изменился, вторичный сервер предлагает главному серверу выполнить трансферт зоны. Можно также выполнить добавочный трансферт зоны. В процессе добавочного трансферта подчиненный сервер просит у главного передать ему только часть записей, хранящихся в файле зоны главного сервера. Такая возможность позволяет уменьшить объем данных, передаваемых между серверами DNS в процессе трансферта зоны. Добавочный трансферт осуществляется только в случае, если оба сервера являются серверами Windows 2000/2003. Если хотя бы один из них не является сервером Windows 2000/2003, выполняется стандартный (полный) трансферт зоны.
Для осуществления трансферта сервер DNS использует журнал зоны, в который заносятся все изменения, произошедшие в зоне. Используя эти сведения, главный сервер может определить, насколько увеличился серийный номер его файла зоны с момента последнего трансферта. Если файл зоны, расположенный на подчиненном сервере, слишком устарел (различие в номерах файлов зон главного и подчиненного серверов значительно), выполняется стандартный трансферт зоны. Алгоритм процедуры трансферта состоит из следующих этапов. 1. Возникает ситуация, в которой требуется выполнить обновление информации о зоне на подчиненном сервере. Это может быть либо уведомление, поступающее от первичного сервера, либо завершение интервала обновления, длительность которого определена в файле зоны подчиненного сервера. 2. Подчиненный сервер посылает запрос на выполнение добавочного трансферта главному серверу. В запросе содержится серийный номер из записи SOA, хранящейся в файле зоны подчиненного сервера, а также указывается, что предпочтительней выполнить добавленный трансферт.
3. Главный сервер сравнивает серийный номер из собственной записи SOA с серийным номером, полученным от подчиненного сервера. 4. Если в результате сравнения выясняется, что копия файла зоны, хранящегося на подчиненном сервере, лишь немногим отличается от файла главного сервера, осуществляется добавочный трансферт. Главный сервер определяет, какие именно изменения необходимо внести в файл зоны подчиненного сервера, и передает их. 5. Если главный сервер приходит к выводу, что копия файла зоны, хранящегося на подчиненном сервере, слишком устарела, он передает подчиненному серверу весь файл зоны целиком в составе стандартного трансферта. Записи о ресурсах Запись SOA Наименьшей единицей информации в базе данных DNS является запись о ресурсе. Файл зоны состоит из множества записей о ресурсах, каждый из которых либо определяет соответствие между IP-адресом и именем сетевого узла, либо настраивает параметры функционирования DNS, либо содержит информацию о работающих в сети службах. Запись SOA (начало авторитета) является первой записью файла зоны. В качестве примера рассмотрим следующую запись SOA. Shazbot.com. IN SOA argus.shazbot.com. alyosha.exchange. shazbot.com.( 1 ; серийный номер, то есть номер последней ревизии 3600 ; обновление следует выполнить с периодом один час 600 ; повторная попытка обновления должна быть выполнена через 10 минут 86400 ; интервал истечения срока полномочий (информация считается устаревшей спустя один день) 3600) ; минимальное время жизни (TTL) составляет один час. Рассмотрим подробнее каждый из разделов записи SOA. Shazbot.com – имя домена, для которого данный файл зоны является авторитетным. IN – означает Internet (то есть именование элементов сети соответствует стандартному классу записей DNS). SOA – тип записи. argus.shazbot.com. – имя первичного сервера имен зоны. alyosha.exchange.shazbot.com. – адрес компьютера, за которым работает администратор зоны. Чтобы передать сообщение администратору зоны, необходимо первую слева точку адреса компьютера администратора заменить символом @. Адрес электронной почты будет иметь вид: alyosha@exchange.shazbot.com. Если, например, замечена попытка взлома вашей системы безопасности, инициатор которой расположен в домене shazbot.com, использование указанного в записи SOA адреса администратора поможет связаться с ним и проконсультироваться по данному вопросу.
Серийный номер (serial number) – счетчик, который увеличивается на единицу каждый раз, когда выполняется обновление данных в зоне. Этот параметр используется в процессе репликации (трансферта) зоны между главным и подчиненным сервером DNS. Интервал обновления (refresh) – это параметр, определяющий частоту, с которой вторичный сервер имен домена обращается к главным серверам с запросом по поводу обновления файла зоны. Интервал повторения попытки (retry) – период времени (в секундах), через который подчиненный сервер будет повторять попытки связаться с главным сервером в случае, если по истечении обычного интервала обновления связь установить не удалось. Интервал истечения срока полномочий (expire) – если подчиненный сервер не может вступить в контакт с главным сервером по истечении содержащегося в данном поле количества секунд, подчиненный сервер полностью перестает обслуживать запросы на разрешение имен для данной зоны. Минимальный срок жизни (time to live) – указывает время, в течение которого сервер DNS сохраняет информацию о запросах DNS в локальном кэше. Запись NS Аббревиатура NS – означает Name Server (сервер имен). Записи этого типа служат для определения серверов DNS, принадлежащих домену. Пример записи: shazbot.com. IN NS argus.shazbot.com. Записи А и CNAME Запись А (adderss) и CNAME (Canonicol Name) – каноническое имя используется для определения соответствия между IP-адресом и доменным именем. Запись типа А является основным источником информации о таких соответствиях. Именно в записи А содержатся сведения, необходимые для того, чтобы определить IP-адрес, соответствующий доменному имени, который интересует клиента. Если сетевой узел обладает несколькими разными адресами (например, на компьютере установлено несколько сетевых карт или одной сетевой карте соответствует несколько IP-адресов), в базу данных DNS вносятся несколько записей типа А, относящихся к одному и тому же доменному имени, но содержащих разные IP-адреса. Однако, как правило, одному доменному имени соответствует одна запись А. Например, если сетевой узел kusanagi.shazbot.com. обладает разными несколькими IP-адресами, в базе данных DNS могут содержаться следующие записи типа А.
kusanagi.shazbot.com. IN A 204.181.180.40 kusangi.shazbot.com. IN A 204.181.176.17 akira.shazbot.com. IN A 204.181.180.40 Запись типа CNAME (записи-псевдонимы) предназначены для регистрации нескольких разных доменных имен, указывающих на один и тот же IP-адрес. Запись CNAME не содержит в себе IP-адреса. Вместо этого она указывает на запись типа А. Рассмотрим пример двух записей типа CNAME, указывающих на одну из записей типа А из предыдущего примера: www IN CNAME acira.shazbot.com. ftp IN CNAME acira.shazbot.com. Этот фрагмент демонстрирует ситуацию, в которой для одного сервера регистрируются два дополнительных псевдонима. В результате сервер может функционировать как FTP сервер (FTP - основанный на IP-адресации протокол передачи данных между компьютерами) и как Web-сервер (WWW-сервер). В принципе в базу данных DNS можно внести несколько записей типа А, указывающих один и тот же IP-адрес. Но для исключения возможных проблем корректнее вместо нескольких записей типа А внести в базу одну А запись, а псевдонимы регистрировать при помощи записей типа CNАМЕ. Запись PTR Запись типа PTR (Pointer – указатель) используется для обработки инверсных запросов DNS. Инверсный запрос передается клиенту в случае, если клиент желает узнать доменное имя сетевого узла исходя из IP-адреса этого узла. Запись типа PTR выполняет функцию, обратную записи типа А. Программный модуль, осуществляющий грамматический разбор файла зоны, в процессе обработки запроса PTR читает IP-адрес сетевого узла подобно чтению доменного имени. В результате обработки IP-адреса клиенту возвращается доменное имя сетевого узла, содержащегося в последнем поле записи PTR. Например, запись PTR для IP-адреса 204.181.180.40 имеет вид: 40.180.181.204. in-addr.arpa. IN PTR acira.shazbot.com. При этом система определяет, что сетевой узел 40 входит в состав сети с номером 180.181.204. Направление обработки доменного имени не совпадает с направлением обработки IP-адреса. Например, при обработке доменного имени аcira.shazbot.com система сначала определяет, что сетевой узел принадлежит корневому домену, далее устанавливает, что имя входит в состав домена com. Затем определяется, что сетевой узел является членом домена shazbot и в последнюю очередь устанавливается, что сетевой узел обладает именем acira. Обработка IP-адреса выполняется в обратном направлении. Сначала обрабатывается левая часть, которая идентифицируется номером сети, затем анализируется номер сетевого узла. В записи PTR для того чтобы соответствовать порядку обработки фрагментов доменного имени, порядок обработки октетов IP-адреса меняется на противоположный (левый фрагмент записывается справа, а правый – слева).
Записи MX и SRV Запись типа MX (Mail Exchanger – обмен почтой) служит для перенаправления почты, поступающей в домен, сетевому узлу, который выполняет функции почтового сервера домена. Рассмотрим пример записей типа MX: mail.shazbot.com. IN MX 10 nikita.shazbot.com. mail.shazbot.com. IN MX 20 olga.shazbot.com. Запись типа MX позволяет администраторам устанавливать уровень приоритета для каждого из серверов, а также настраивать маршрут к одному серверу через другой. При этом подразумевается, что осуществить прием почты могут оба сервера. Чем меньше значение приоритета, тем предпочтительнее использование сервера. В приведенном примере это означает, что почта в первую очередь будет направлена серверу с именем nikita.shazbot.com. Если данный сервер недоступен, то почта будет перенаправляться серверу olga.shazbot.com. Запись SRV (указатель на службу) используется для обнаружения служб, работающих в сети. В рабочей среде Active Directory записи типа SRV используются для обнаружения контроллеров доменов, а также определения местоположения других служебных серверов. Каждая SRV-запись представляет собой DNS-псевдоним службы, записанный в формате UDP (User Datagram Protocol – протокол семейства TCP/IP): Service.Protocol. DnsDomainName, где Service – название службы (например: ldap, kerberos.); Protocol – протокол, при помощи которого клиенты могут подключиться к данной службе (например: TCP, UDP); DnsDomainName – DNS-имя домена, к которому принадлежит сервер. Рассмотрим пример записи DNS-псевдонима службы LDAP-сервера (LDAP – упрощенный протокол доступа к каталогам), принадлежащего домену khsu.khakassia.ru, к которому пользователи могут подключиться при помощи протокола TCP: _ldap.tcp.ksu.khakassia.ru. Система SRV-записей также создает домены нижних уровней (субдомены): 1) _msds – вспомогательный домен, который используется для группировки ресурсных записей о серверах, выполняющих специфические роли (сервера глобального каталога или основного сервера контроллера). Такая запись позволяет осуществить поиск серверов, основываясь не на имени службы, а на роли, которую искомый сервер выполняет. Например для поиска сервера, играющего роль основного контроллера домена, служба DNS будет использовать ресурсную запись, принадлежащую вспомогательному домену _msds вида: _Service._Protocol. Dctype._DnsDomainName, в которой параметр Dctype определяет роль сервера (например: pds, Primary Domain Controller (основной контроллер домена) – сервер, на котором расположена база данных диспетчера учетных записей; dc, Domain Controller (контроллер домена); gc, Global Catalog (глобальный каталог) – содержит выборочную информацию обо всех объектах дерева или леса домена). Например, для сервера, выполняющего функции контроллера домена и принадлежащего к домену khsu.khakassia.ru, будет создан DNS-псевдоним: _ ldap._tcp.dc.khsu._msdcs.khakassia.ru; 2) _sites – домен, используемый для группировки ресурсных записей, отражающих физическую структуру сети (с точки зрения узловой иерархии). Этот домен играет роль контейнера для других доменов, имена которых соответствуют именам узлов. Псевдонимы записываются в следующем формате: _Service._Protocol.SiteName._sites.DnsDomainName. При этом значение параметра SiteName представляет собой имя соответствующего узла. Для узла Abakan псевдоним службы может выглядеть следующим образом: _kerberos._tcp.Abakan._sites.khsu.khakassia.ru. Ресурсная запись SRV связывает DNS-псевдоним службы с доменным именем некоторого хоста. Просматривая ресурсные типа А, DNS-сервер разрешает доменное имя в некоторый IP-адрес.
Воспользуйтесь поиском по сайту: ©2015 - 2024 megalektsii.ru Все авторские права принадлежат авторам лекционных материалов. Обратная связь с нами...
|