Методические указания к лабораторному практикуму по дисциплине




Скачать 439.47 Kb.
НазваниеМетодические указания к лабораторному практикуму по дисциплине
страница2/6
Дата публикации17.03.2013
Размер439.47 Kb.
ТипМетодические указания
odtdocs.ru > Бухгалтерия > Методические указания
1   2   3   4   5   6
^

1 Лабораторная работа № 1. Конфигурирование службы имён DNS в корпоративной сети

1.1 Цель работы


Цель данной работы – научиться конфигурировать и тестировать службу имен для корпоративной сети на основе сервера DNS bind.
^

1.2 Краткие теоретические сведения

1.2.1.1 Служба имен в Интернете


Служба доменных имён DNS является важнейшей системной службой в TCP/IP сетях. Назначение DNS – преобразование символьных имен в IP адреса и наоборот, а так же предоставление дополнительной информации о хостах и группах хостов (доменах), такой как адреса почтовых обменников, публичные ключи служб и т.п. В сети Интернет служба DNS оперирует распределённой иерархической базой данных в виде дерева имен, находящейся на множестве различных хостов. Ответственность за корректность базы данных в каждом узле дерева возлагается на администратора соответствующего домена.

В сети Интернет корнем дерева является домен “.”. Полное - абсолютное или полностью определенное, fully qualified domain name - доменное имя заканчивается точкой, обозначающей корень доменного дерева, но часто эта завершающая точка опускается. Анализ имени производится справа налево. Самая правая секция имени характеризует страну (для каждой страны мира выделен свой домен с двух символьным именем в соответствии со стандартом ISO, например, ua – Украина, ru – Россия, uk – Англия и т.п.) или характер организации (образовательная, коммерческая, правительственная и т.п.). Таим образом, домены верхнего уровня (Top Level Domains, TLD) - это хорошо известные всем домены, такие как org (бесприбыльная организация), com (коммерческая организация), gov (государственное учреждение), mil (военное предприятие или организация), edu (учебное заведение), int (международная организация), net (большая сеть) и т.д. Ответственность за TLD лежит на международной бесприбыльной организации Internet Corporation for Assigned Names and Numbers (ICANN, www.icann.org).

Ниже по дереву имен расположены домены второго и последующих уровней. В некоторых странах существуют домены, подобные исторически первым TLD, например, org.ua, gov.ua, edu.ua и т.п. В Украине для каждой области выделены двухбуквенные домены, такие как cn.ua – Чернигов, dp.ua – Днепропетровск, и т.д., хотя исторически сложившиеся домены, такие как kiev.ua, kharkov.ua, chernigov.ua, тоже поддерживаются. Маленький фрагмент интернетовской иерархии имен показан на рисунке 1. Число уровней реально больше, но обычно не превышает 5.

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

Рисунок 1 – Фрагмент иерархии имен в Интернет
За каждую зону DNS отвечает не менее двух серверов. Один из них является первичным, primary, или, в новой терминологии — master. остальные - вторичными, secondary, или slave. Первичный сервер содержит оригинальные файлы с базой данных DNS для своей зоны. Вторичные серверы получают эти данные по сети от первичного сервера и периодически запрашивают первичный сервер на предмет обновления данных. Признаком обновления данных служит увеличение серийного номера в записи SOA – см ниже. В случае, если данные на первичном сервере обновлены, вторичный сервер запрашивает "передачу зоны" ("zone transfer")- т.е. базы данных требуемой зоны. Передача зоны происходит с помощью протокола TCP, порт 53, в отличие от запросов, которые направляются на UDP/53.

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

Вторичный сервер необязательно получает данные непосредственно с первичного сервера; источником данных может служить и другой вторичный сервер. В любом случае сервер-источник данных для данного вторичного сервера называется "главным" ("master").

У каждого домена есть свои “писаные правила”, именуемые “полиси”, в соответствии с которыми можно получить имя хоста или субдомена (чаще говорят “зоны”) в данном домене. Самым простым примером таких правил могут служить полиси домена com. Если данное имя не зарегистрировано или не находится в процессе регистрации, то по уплате определенной суммы любое физическое или юридическое лицо может получить это имя от регистратора домена com.

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

Различают 3 режима работы сервера DNS:

master (primary). Данный режим используется администратором зоны, файлы баз данных ведутся вручную на этом сервере. Данный сервер является абсолютным авторитетным источником информации для данной зоны;

slave (secondary). Данный режим используется по просьбе администратора зоны, которая автоматически регулярно копируется с master сервера. Данный сервер является авторитетным источником информации для данной зоны;

hint (caching). Режим кэширования всех запросов, попадающих в определённую зону, обычно “.”, т.е. кэшируются все запросы. Такой сервер обычно используется для ускорения работы с сетью.
Для каждой зоны, обслуживаемой данным сервером, может быть выбран тот или иной режим. Обычно для зоны “.” все сервера конфигурируются по типу hint, что позволяет кешировать все запросы пользовательских рабочих станций на время жизни конкретной записи DNS. Это значительно ускоряет обработку локальных запросов.

База данных DNS для каждого домена в простейшем случае представляет собой набор текстовых файлов, которые системный администратор ведет на главном сервере имен этого домена. В этих файлах содержатся директивы синтаксического анализатора ($ORIGN, $TTL) и записи о ресурсах.
^

1.2.2 Записи ресурсов в базе данных домена


Файл любой зоны начинается с записи Start Of Authority, SOA. Эта запись является заголовочной и содержит информацию о размещении зоны, о почтовом адресе ответственного лица и о базовых временных параметрах записей данной зоны.

Файл прямой зоны содержит стандартные записи ресурсов базы данных DNS для преобразования доменных имен хостов в данной зоне в IP-адреса, определения авторитарных DNS-серверов данной зоны, определения хостов-обработчиков почты для доменных имен в данной зоне и др.

Файлы баз данных DNS состоят из стандартных записей ресурсов. В общем виде стандартная запись ресурса связывает данные определенного типа с некоторым именем и формируется по шаблону:

имя [время_жизни_записи] IN тип_записи данные

Именем является некоторое доменное имя (необязательно имя физически существующих хоста или домена). Если поле "имя" пусто, то значение этого поля берется из предыдущей записи. Данными может быть, например, IP-адрес хоста, если имя относится к хосту, или DNS-сервер домена, если имя относится к домену, и т.п.

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

Основные типы записей:

SOA (Start Of Authority) - заголовок зоны;

NS (Name Server) - сервер DNS;

A (Address) - IP-адрес для хоста;

MX (Mail Exchanger) - почтовый обменник;

CNAME (Canonical Name) - каноническое имя, псевдоним хоста;

PTR (Pointer) - указатель по обратной зоне, фактически — имя хоста;
^

1.2.3 Прямая зона DNS.


Рассмотрим примеры файлов базы данных DNS. Первой рассмотрим прямую зону для приватной части корпоративной сети, домен “stu.”, файл db.stu.
$ORIGIN .
stu 28800 IN SOA ns.stu. dnsmaster.stu. (
2005033100 ; Serial
28800 ; Refresh
7200 ; Retry
604800 ; Expire
86400 ; Time To Live)

; authoritative name servers for zone
28800 IN NS ns.stu.
28800 IN NS ns1.stu.

; mail exchangers for entire zone
28800 IN MX 10 stalker.stu.
28800 IN MX 20 cs.stu.

$ORIGIN stu.
; name servers glue records
ns IN A 192.168.0.10
ns1 IN A 192.168.0.14
;servers
dragon IN A 192.168.0.17
auth IN CNAME dragon.stu.
cs IN A 192.168.0.14
stalker IN A 192.168.0.10
www IN CNAME stalker.stu.
mail IN CNAME stalker.stu.
ftp IN CNAME stalker.stu.
www.docs IN CNAME cs.stu.
kid IN A 192.168.0.12
; workstations
ie-21-7 IN A 192.168.3.40
ie-21-8 IN A 192.168.3.41
ie-21-9 IN A 192.168.3.42
vc-105-1 IN A 192.168.66.2
Первая строка – это макрос, говорящий, что все имена далее следуют непосредственно за доменом “точка”. Таким образом, для приватной сети мы используем имена в нашем приватном дереве относительно нашего собственного корня “.”. Следует помнить, что для сервера, разрешающего одновременно и имена в корпоративной сети, и имена в интернете, имя зоны следует выбирать из 3-х символов, не совпадающих с именами TLD.

Первой записью всегда идет SOA (Start of Authority), в которой указывается имя зоны (“stu.”, или макрос @), TTL, т.е. время жизни этой записи, дальше – ключевые слова IN (Internet records) и SOA. Далее идут параметры зоны: имя основного сервера DNS, почтовый адрес администратора зоны, однако вместо символа “@” там стоит точка, поскольку @ - это ссылка на имя зоны. Сразу за открывающейся скобкой находится серийный номер данного файла, обычно в формате ггггммддNN. Серийный номер необходимо увеличивать при каждом изменении файла, что бы ведомые сервера идентифицировали изменения и обновили файлы баз данных с главного сервера. Далее следуют стандартные времена в секундах для данной зоны:

Refresh – время, по истечении которого вторичные сервера должны обновить данные с первичных серверов (zone transfer);

Retry – время, через которое вторичные сервера должны совершить повторную попытку обновления, если предыдущая попытка не удалась;

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

TTL – стандартное время жизни записей из данной зоны для кеширующих серверов.

Следующая группа записей является так же обязательной и указывает на авторитетные сервера имен для данной зоны - записи типа NS. Авторитетным является сервер, на котором информация соответствует реальному состоянию зоны, т.е. регулярно обновляется (см. выше). Крайне желательно, чтобы имена, указанные в этой секции, имели соответствующие адресные IN A записи в этой же базе данных.

Ниже следует секция почтовых обменников, т.е. записи типа MX (Mail Exchanger). Они указывают на сервера электронной почты, способные принимать почту для всего домена по протоколу SMTP. Чем меньше цифра перед именем, тем больший приоритет имеет данный почтовый сервер. Как правило, запись с наивысшим приоритетом относится к серверу, на котором почта заканчивает свой путь, а другие записи относятся к серверам-релеям, на которых почта может сохраняться некоторое время, пока основной почтовый сервер для зоны не доступен. Естественно, записи MX на релеи нельзя расставлять произвольно, поскольку релей обязательно должен быть сконфигурирован для приёма почты данного домена. При отсутствии записи MX для какого-либо доменного имени, почта, адресованная с этим доменным именем, будет доставляться непосредственно на хост, имеющий такое имя. Однако, такого хоста может не быть, в этом случае почта вернется отправителю с сообщением об ошибке.

Ниже, после макроса “$ORIGIN stu.”, задающего суффикс для всех записей ниже, следуют записи типа IN A, предназначенные для задания соответствия между именем хоста в зоне и его IP адресом.

Для задания псевдонимов хостам используется запись CNAME (Canonical Name). Псевдонимы удобны для указания на стандартные сервисы, такие как www, mail, ftp, а так же для задания псевдонимов, используемых для создания виртуальных серверов (см. www, docs).

Рассмотрим теперь файл зоны stu.cn.ua. Данная зона мало чем отличается от предыдущей зоны внешне.
$ORIGIN .
stu.cn.ua 28800 IN SOA ns.stu.cn.ua. nsmaster.stu.cn.ua(
2005033100 ; Serial
28800 ; Refresh
7200 ; Retry
604800 ; Expire
86400 ; Time To Live
)

; authoritative name servers for zone
IN NS ns.stu.cn.ua.
IN NS ns1.stu.cn.ua.
IN NS ns.cn.ua.

; mail exchangers for entire zone
IN MX 10 stalker.stu.cn.ua.
IN MX 15 cs.stu.cn.ua.
IN MX 20 relay1.cn.ua

; name servers glue records
ns.cn.ua IN A 212.86.96.10
$ORIGIN stu.cn.ua.
ns IN A 195.69.76.130
ns1 IN A 195.69.76.134
;servers
dragon IN A 195.69.76.137
auth IN CNAME dragon.stu.cn.ua.
cs IN A 195.69.76.134
stalker IN A 195.69.76.130
www IN CNAME stalker.stu.cn.ua.
mail IN CNAME stalker.stu.cn.ua.
ftp IN CNAME stalker.stu.cn.ua.
www.docs IN CNAME cs.stu.cn.ua.
; workstations
admin IN A 195.69.76.139

Конфигурация данной зоны практически повторяет предыдущую зону, однако отличие в том, что данная зона является субдоменом домена cn.ua. Значит, она должна быть делегирована в соответствующей зоне cn.ua примерно так, как показано в следующем фрагменте:
$ORIGIN cn.ua.
stu IN NS ns.stu.cn.ua.
IN NS ns1.stu.cn.ua.
IN NS ns.cn.ua.

$ORIGIN .
ns.stu.cn.ua IN A 195.69.76.130
ns1.stu.cn.ua IN A 195.69.76.134
Как видно из приведенного фрагмента, в “материнской” зоне cn.ua. находятся только записи о серверах имен для делегированной зоны stu.cn.ua. Управление остальной информационной базой зону передается на сервера ns.stu.cn.ua и ns1.stu.cn.ua.

^

1.2.4 Обратная зона DNS


Теперь рассмотрим файлы обратных зон, предназначенные для проведения обратного DNS-преобразования, т.е. "IP-адрес  в доменное имя".

Для приватных блоков адресов, таких как 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16 никаких проблем с делегированием, в общем-то, нет, поскольку эти адреса не маршрутизируются в Интернете и нужны только внутри приватной сети.
$ORIGIN .

0.168.192.IN-ADDR.ARPA. 86400 IN SOA ns.stu. dnsmaster.stu. (
2006060200
86400
14400
3600000

345600

)
86400 IN NS ns.stu.
86400 IN NS ns1.stu.

^ $ORIGIN 0.168.192.IN-ADDR.ARPA.

10 IN PTR stalker.stu.
14 IN PTR cs.stu.
17 IN PTR dragon.stu.

12 IN PTR kid.stu.
Стоит обратить внимание, что имя зоны состоит из развёрнутых по отношению к записи адреса цифр. Для адресного блока 192.168.0.0/24 имя зоны 0.168.192.IN-ADDR.ARPA. IN­ADDR.ARPA. - это специальный домен верхнего уровня, отведенный для делегирования обратных зон. В файле обратной зоны присутствует, конечно же, запись SOA, как минимум пара записей типа NS об официальных авторитетных серверах и записи типа PTR (Pointer), ставящие в соответствие адреса и имена. Обратная зона для публичных адресов 195.69.76.0/24 приведена ниже:
$ORIGIN .

76.69.195.IN-ADDR.ARPA. 86400 IN SOA ns.stu.cn.ua dnsmaster.stu.cn.ua (2004060200 86400 14400 3600000 345600 )


IN NS ns.stu.cn.ua.
IN NS ns1.stu.cn.ua.

^ $ORIGIN 0.168.192.IN-ADDR.ARPA.

10 IN PTR stalker.stu.cn.ua.
14 IN PTR cs.stu.cn.ua.
17 IN PTR dragon.stu.cn.ua.

12 IN PTR kid.stu.cn.ua.
Отличие данной зоны от предыдущей опять же только в том, что она является публичной и должна делегироваться в соответствии с правилами выдачи и регистрации IP адресов. Вкратце необходимо отметить следующее. Выдача блоков адресов потребителям производится локальными Интернет регистратурами (LIR), которые, в свою очередь, получают их от региональных регистратур. В Европе это – бесприбыльная организация RIPE (http://www.ripe.net/), финансируемая провайдерами. Основные функции региональных регистратур – координация использования IP адресов и, соответственно, маршрутизации в регионе. Для получения своего блока публичных адресов необходимо заполнить соответствующие формы RIPE и направить их вашему LIR.
^

1.2.5 Особенности размещения и конфигурирования серверов для корпоративной сети


Поскольку сервис DNS является критическим для функционирования сети, то в сети должно быть как минимум 2 сервера. Обычно размещают их так, как показано на рисунке 2. Для внутренней сети доступны оба сервера, а для внешней – только внешний сервер. Внутренний сервер является первичным для внутренних доменов и использует внешний в качестве форварда (forwarding server), поскольку напрямую не видит домен “.” . Внешний сервер в общем случае не должен отвечать на рекурсивные запросы извне, поскольку он может быть использован как платформа для DDoS атак на другие сервера.


Рисунок 2 – Расположение серверов имен в сети

^

1.2.6 Установка ПО сервера DNS


Наиболее популярным ПО, реализующим сервис DNS, является сервер bind (Berkeley Internet Name Daеmon), поддерживаемый Internet Software Consortium (http://www.isc.org). Существуют лёгкие реализации, предназначеные для работы в качестве кеширующих серверов, есть реализации, специфичные для конкретних коммерческих ОС, однако на практике лучше использовать bind, поскольку он распространяестя под лицензией GPL, т.е. вместе с исходным кодом, что гарантирует отсутсвие давно не исправляемых уязвимостей и прочих неприязностей закритого кода.

Пакет bind поставляется практически со всеми дистрибутивами Linux и xBSD.

Для работы сервера в ОС Fedora Linux не обходимо установить следующие пакеты: bind-utils – утилиты для работы с DNS и тестирования сервера, bind – собственно сервер, bind-chroot – файлы, необходимые для запуска сервера в индивидульном окружении в режиме chroot. Запуск сервера в этом режиме минимизирует потери при взломе системы через работающий сервис.

Проверить, утсновлены ли пакеты, можно командой

rpm –qa | grep bind
Если пакету не установлены, установите их командой
yum install bind-utils bind bind-chroot
При установке сервера автоматически создается конфигурация для кеширующего сервера зоны «.» и для первичных серверов локальних зон.

Для небольшого сервера на несколько мелких зон конфигурации зон обычно хранятся в текстових вайлах. В нашем случае – это /var/named/chroot/var/named/* . Для больших зон, содержащих миллионы записей, используются специальные модули хранения, которые могут сохранять данные зон в реляционных БД (PostgreSQL) либо на сервере LDAP.
^

1.2.7 Конфигурирование сервера DNS


Рассмотрим подробнее пример файла конфигурации для такого случая: наш сервер является основным для внутренней корпоративной сети 192.168.0.0 и внутреннего домена “stu.”, и кэширующим для домена “.”. Все пути, приведенные ниже, в случае работы сервера в окружении chroot, нужно понищать как относительные к /var/named/chroot. Файл конфигурации /etc/named.conf приведен ниже:
options {
directory "/etc/namedb";
forward first;
forwarders {
195.69.76.130;
};
};
// caching server for root domain
zone "." {
type hint;
file "named.root";
};


// it's not neccesary but good to resolve localhost
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "localhost.rev";

};

// private zone for our network
zone "stu" {
type master;
file "db.stu.private";
allow-transfer{
195.69.76.130;
};
allow-query{
192.168.0.0/16;
};
};
// Inverse zone for private zone stu
zone "0.168.192.IN-ADDR.ARPA" {
type master;
file "db.192.168.0";
allow-transfer{
195.69.76.130;
};
allow-query{
192.168.0.0/16;
};
};
В приведенном выше файле конфигурации все интуитивно понятно, однако стоит особо отметить, что сервер в DNS с адресом 195.69.76.130 используется как форвард и как вторичный сервер для внутренних доменов. Предложение allow-transfer используется для ограничения полной перекачки зоны только на вторичный сервер. Предложение allow-query указывает серверу, что отвечать на запросы по данным зонам можно только хостам из приведенного блока адресов.

Ниже приведена конфигурация второго сервера. Кроме того, он является первичным для публичных зон stu.cn.ua и 76.69.195.IN-ADDR.ARPA.
options {
directory "/etc/namedb";
forward first;
forwarders {
212.86.96.10;
};
};
// caching server for root domain
zone "." {
type hint;
file "named.root";
};


// it's not neccesary but good to resolve localhost
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "localhost.rev";

};

// private zone for our network
zone "stu" {
type slave;
file "db.stu.private";
master {
192.168.0.10;
};
allow-query{
192.168.0.0;
};
};
// Inverse zone for private zone stu
zone "0.168.192.IN-ADDR.ARPA" {
type slave;
file "db.192.168.0";
masters {
192.168.0.10;
};
allow-query{
192.168.0.0;
};
};


// public zone for our network
zone "stu.cn.ua." {
type master;
file "db.stu.cn.ua";
allow-transfer{
212.86.96.10;
};
};

// Inverse zone for public zone stu.cn.ua.
zone "76.69.195.IN-ADDR.ARPA" {
type master;
file "db.195.69.76";
allow-transfer{
212.86.96.10.
};
};
Заметим, что здесь появилось предложение allow-query, необходимое для того, чтобы данный сервер мог отвечать на запросы о внутренних зонах только во внутреннюю сеть. Предложение allow-transfer используется так же, как и в предыдущем случае и ограничивает полную перекачку всей зоны только серверу с адресом 212.86.96.10, который является вторичным для данной зоны. Этот же сервер используется и как форвард. Строго говоря, такой необходимости нет, но в ситуации, когда почему-то пол-Интернета не видно, а этот форвард находится в пределах досягаемости и видит весь Интернет, использование форварда оказывается оправданным.

Естественно, многие вопросы остались за пределами этого короткого обзора. Например, конфигурирование мощной системы логов сервера bind, специальные ресурсные записи и т.д.

1   2   3   4   5   6

Похожие:

Методические указания к расчетно-графической работе №2 по дисциплине...
Методические указания предназначены для аудиторной и самостоятельной работ студентов технических специальностей

Методические указания к лабораторному практикуму по дисциплине iconМетодические указания к лабораторным работам по дисциплине «Управление проектами»
Методические указания к лабораторным работам по дисциплине «Управление проектами» для студентов и слушателей факультета «Инженерный...

Методические указания к лабораторному практикуму по дисциплине iconМетодические указания к курсовому проекту по дисциплине «базы данных»
Методические указания предназначены для студентов четвертого курса специальности «Автоматизированные системы обработки информации...

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

Методические указания к выполнению расчетно- графической работы №1...
...

Методические указания к выполнению расчетно- графической работы №1...
...

Методические указания к выполнению расчетно- графической работы №1...
...

Методические указания к выполнению эскизов и рабочих чертежей деталей
Методические указания предназначены для студентов технических специальностей, выполняющих эскизы и рабочие чертежи деталей

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

Методические указания по инженерной графике «Построение сопряжений»...
Методические указания предназначены для аудиторной и самостоятельной работ студентов технических специальностей

Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
odtdocs.ru
Главная страница