Интернет-магазин OZON
- Книги
- Электроника
- DVD и видео
- Музыка
- Софт и игры
- Антиквариат
- Детский мир
- Дом и интерьер
- Спорт и отдых
- Салон красоты
- Подарки
- Ювелирные изделия
- Билеты
Установка DNS для Intranet фирмы
В некоторой фирме локальная сеть состоит из 10 сеток подразделений (192.168.1.0 – 192.168.10.0) и общей сетки 192.168.99.0, в которой располагаются общие серверы. Написать конфигурационные файлы DNS для этой фирмы в предположении: - в каждом подразделении в настоящий момент имеется по 7 ПЭВМ, - общих серверов – 4, - выход в Internet по adsl, обеспечивается не для всех подразделений.
Установка DNS для Intranet фирмы
DNS-сервис является одним из важных сервисов для нормального функционирования Internet сети. Его
основная задача состоит в определении соответствия между сетевыми адресами узлов сети и их удобочитабельными
названиями. Существует два варианта определения этого соответствия - прямое и реверсивное определение.
При прямом разрешении DNS-сервер по имени определяет и выдает сетевой адрес, а при реверсивном - по адресу
ищет соответствующее имя. Это необходимо учитывать при настройке DNS-сервиса, поскольку для осуществления данных
механизмов используются разные таблицы. В операционной системе Sun Solaris, как, в прочем, и в других UNIX-системах,
в качестве DNS-сервера используется BIND-сервер версии 8.х и выше. Хотя, нужно заметить, в Solaris-е есть возможность
использования и сервера версии 4.х. Система определяет какой версии DNS-сервер запускать по тому, какой конфигурационный
файл существует в каталоге /etc. Если используется файл - named.boot, то запускается старая версия сервиса,
а если - named.conf - то, соответственно, новая (в Solaris 9 старой версии уже нет). Лучше естественно использовать
BIND 8.х и выше. Если у вас остались конфигурационные файлы named.boot и вы хотите перевести ваш DNS-сервер на новую версию,
то можно воспользоваться скриптом /usr/sbin/named-bootconf который конвертирует конфигурационный файл BIND 4.x в BIND 8.x.
Конфигурирование BIND 8.x Конфигурирование BIND-сервера состоит из двух этапов - настройка конфигурационного
файла /etc/named.conf и создания и заполнения таблиц доменных зон.
BIND 8.х позволяет создавать 4 типа доменных зон:
master (раньше называлась - primary). Данный DNS-сервер является головным для данного домена.
slave (раньше называлась - secondary). Такие DNS-серверы хранят копии доменных зон, которые скачивают
и периодически обновляют с master-сервера.
hint (раньше называлась - cache). Кэширующий сервер. Не хранит никаких таблиц зон, а просто собирает с
объявленных root-серверов кэш резолвенных адресов.
Используется для повышения эффективности работы DNS-сервера.
stub аналог slave зоны, но в отличие от нее таблиц зоны не хранит, только NS-записи,
и просто перенаправляет запросы на объявленные DNS-сервера.
Очевидно, что вы можете настроить так ваш BIND-сервер, что он одновременно может
обслуживать несколько разных доменных зон и для одних он может быть master-ом, для
других - slave и тд. В любом случае, какие-бы типы зон вы не настраивали, две зоны
будут присутствовать у вас почти всегда - это зона hint и localhost (прямая и реверсивная).
Итак, начнем с просто кэширующего DNS-сервера. Создаем /etc/named.conf и прописываем там глобальные
параметры и те две "стандартные" зоны о которых я только что упоминал:
//Конфигурационный файл /etc/named.conf для кэширующего DNS-сервера
options {
directory "/var/named";
listen-on { 192.168.6.1; localhost; };
version "Go away!";
allow-transfer { none; };
allow-query { 192.168.6.0/24,192.168.7.0/20; localhost; };
forward first;
forwarders { 192.168.1.1; };
};
zone "localhost" in {
type master;
file "/var/named/localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "/var/named/127.0.0.zone";
allow-update { none; };
};
zone "." in {
type hint;
file "/var/named/root.hint";
};
Синтаксис этого файла очень похож на С++. Структура options - описывает глобальные параметры для сервера,
а структуры zone - описывают, соответственно, доменные зоны.
directory - указывает каталог расположения таблиц зон
listen-on - позволяет указать на какие сетевые интерфейсы будет "вешаться" демон. Тут прописываем адрес локального
интерфейса, у меня это 192.168.6.1, и не забываем указать и 127.0.0.1
version - строка, которая будет выдаваться на запрос определения версии DNS-сервера
allow-transfer - устанавливает возможность передачи зон для slave-серверов. В нашем случае трансфер запрещен.
allow-query - а этот параметр указывает кому разрешается подавать запросы к нашему серверу.
Мы прописали нашу локальную сетку 192.168.6.0 и 192.168.7.0 и 127.0.0.1
forward - этот параметр позволяет указать каким образом сервер обрабатывает запрос клиента. Я указал first - это означает что сервер сначала
перенаправит запрос выше и если не получит положительного результата, то посмотрит в своем кэше. Если указать only - то у себя смотреть не будет
forwarders - а тут вы и указываете куда перенаправлять запросы клиентов. Я указал, для примера, свой вышестоящий DNS-сервер 192.168.1.1
type - тип зоны
file - имя файла таблицы зоны
allow-update - разрешить или нет, и кому если разрешить, возможность изменения(обновления) таблицы зоны
Теперь добавим записи для master-зон: //Конфигурационный файл /etc/named.conf для master DNS-сервера
directory "/var/named";
listen-on { 192.168.6.1; localhost; };
version "Go away!";
allow-transfer { none; };
allow-query { 192.168.6.0/24,192.168.7.0/20; localhost; };
};
zone "localhost" in {
type master;
file "/var/named/localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "/var/named/127.0.0.zone";
allow-update { none; };
};
zone "." in {
type hint;
file "/var/named/root.hint";
};
zone "sun.urix.ru" in {
type master;
file "/var/named/sun.urix.zone";
};
zone "san.urix.ru" in {
type master;
file "/var/named/san.urix.zone";
};
zone "6.168.192.in-addr.arpa" in {
type master;
file "/var/named/192.168.6.zone";
};
zone "7.168.192.in-addr.arpa" in {
type master;
file "/var/named/192.168.7.zone";
};
Я добавил две структуры: "прямую" зону - sun.urix.ru и реверсивную - 6.168.192.in-addr.arpa. Удалил опции
определяющие форвард запросов и пока не разрешаю трансфер своих таблиц. Таким образом у меня получился мастер
DNS-сервер для моего домена sun.urix.ru. Теперь настроим наш BIND в случае когда у нас существуют и slave-серверы.
Сначала необходимо подправить на мастер-сервере возможность передачи таблиц зон. Для этого нужно только разрешить трансфер зон:
allow-transfer { 192.168.6.2; 192.168.6.3; };
Здесь 192.168.6.2 и 192.168.6.3 - мои slave-серверы. А теперь на slave-сервере делаем конфигурационный файл:
//Конфигурационный файл /etc/named.conf для slave DNS-сервера
options {
directory "/var/named";
listen-on { 192.168.6.2; localhost; };
version "Go away!";
allow-transfer { none; };
allow-query { 192.168.6.0/24, 192.168.7.0/24; localhost; };
};
zone "localhost" in {
type master;
file "/var/named/localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "/var/named/127.0.0.zone";
allow-update { none; };
};
zone "." in {
type hint;
file "/var/named/root.hint";
};
zone "sun.urix.ru" in {
type slave;
file "/var/named/sun.urix.zone";
masters { 192.168.6.1; };
};
zone "6.168.192.in-addr.arpa" in {
type slave;
file "/var/named/192.168.6.zone";
masters { 192.168.6.1; };
};
Все, теперь когда демон на slave-сервере будет запускаться он прочитает адрес, прописанный в masters,
и скачает таблицу зоны, а в последствии будет ее и обновлять. Несколько слов о том, как запускать и
останавливать bind-демон и где читать логи:
#/usr/sbin/in.named - так запускается демон
#pkill in.named - а так его можно "убить"
/var/log/messages - файл логов куда и демон in.named пишет свои логи.
Таблицы зон
Теперь приступаем к созданию таблиц зон. Понятно, что для slave-сервера большинство таблиц будут скачены
с master-сервера. Первым делом пропишим таблицы для localhost и зоны hint. Мы объявили, что /var/named - каталог
где помещаются таблицы - вот и идем туда и создаем необходимые таблицы.
//Файл /var/named/localhost.zone
$ttl 38400
localhost. IN SOA localhost. root.localhost. (
2004071001 ;serial
108000 ;refresh
1800 ;retry
1209600 ;expiry
604800)
localhost. IN NS solaris.sun.urix.ru.
localhost. IN NS solaris.san.urix.ru.
localhost. IN A 127.0.0.1
//Файл /var/named/127.0.0.zone
$ttl 38400
0.0.127.in-addr.arpa. IN SOA localhost. root.localhost. (
2004071001 ;serial
108000 ;refresh
1800 ;retry
1209600 ;expiry
604800)
0.0.127.in-addr.arpa. IN NS solaris.sun.urix.ru.
1.0.0.127.in-addr.arpa. PTR localhost.
//Файл /var/named/root.hint
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
Разберемся теперь в формате этих таблиц. localhost.zone и 127.0.0.zone - это прямая и реверсивная таблицы
loopback интерфейса, а файл root.hint - используется для кэширующего сервера. Эти три файла, как мы помним,
присутствуют неизменно на любом DNS-сервере. Что касается файла root.hint, то его, как правило, берут у своего
провайдера. Данные в нем периодически устаревают и меняются, поэтому выкачивать его у своего провайдера - это
самый оптимальный вариант. Но я хочу посоветовать вам упростить этот файл всего до одной-двух записей рутовых
серверов и указать их на DNS-серверы вашего провайдера. Что это даст? Дело в том, что ваш сервер при каждом
запуске и по истечении параметра TTL(time-to-live) будет обращаться ко всем серверам из этого файла и, таким
образом, создаст вам огромный трафик, хотя накопленной информации, хранящейся на сервере вашего провайдера,
вполне для вас будет достаточно. В качестве примера я написал только один адрес А-root сервера, если вы хотите
добавить еще сервера, то создайте B,C,D... и т.д. Расшифровка полей файлов зон:
2004071001 ;serial - серийный номер версии таблицы. Самый лучший формат - ГГГГММДДNN, где NN - номер изменения
таблицы за текущий день
108000 ;refresh - время в секундах, указывающее как часто необходимо проверять таблицу мастер-сервера на
необходимость update-а
1800 ;retry - время в секундах, которое сервер ожидает при ошибочном сеансе refresh-а чтобы начать его заново
1209600 ;expiry - максимальный предел в секундах времени хранения таблицы, по его истечении таблица считается
устаревшей и скачивается заново.
604800 ;ttl - параметр time-to-live. Время в секундах, которое указывает серверу сколько хранить в кэше данные
таблицы. По его истечении срвер перечитывает таблицу заново.
//Файл /var/named/sun.urix.zone
$ttl 38400
sun.urix.ru. IN SOA solaris.sun.urix.ru. root.solaris.sun.urix.ru. (
2004071001 ;serial
108000 ;refresh
1800 ;retry
1209600 ;expiry
604800)
sun.urix.ru. IN NS solaris.sun.urix.ru.
sun.urix.ru. IN MX10 solaris.sun.urix.ru.
solaris IN A 192.168.6.1
class IN A 192.168.6.10
slave IN A 192.168.6.2
www IN CNAME solaris
//Файл /var/named/192.168.6.zone
$ttl 38400
6.168.192.in-addr.arpa. IN SOA solaris.sun.urix.ru. root.solaris.sun.urix.ru. (
2004012001 ;serial
108000 ;refresh
1800 ;retry
1209600 ;expiry
604800)
6.168.192.in-addr.arpa. IN NS solaris.sun.urix.ru.
1 IN PTR solaris.sun.urix.ru.
2 IN PTR slave.sun.urix.ru.
10 IN PTR class.sun.urix.ru.
NS - указывает name-серверы для данной зоны
MX - указывает на почтовые серверы домена, очередность - 0,10,20,
A -"прямая" запись ресурса (имя-адрес)
PTR - "реверсивная" запись (адрес-имя)
CNAME - псевдоним
//Файл /var/named/san.urix.zone
$ttl 38400
san.urix.ru. IN SOA solaris.san.urix.ru. root.solaris.san.urix.ru. (
2008061601 ;serial
108000 ;refresh
1800 ;retry
1209600 ;expiry
604800)
san.urix.ru. IN NS solaris.san.urix.ru.
sun.urix.ru. IN MX10 solaris.san.urix.ru.
solaris IN A 192.168.7.1
class IN A 192.168.6.10
slave IN A 192.168.6.2
www IN CNAME solaris
//Файл /var/named/192.168.7.zone
$ttl 38400
7.168.192.in-addr.arpa. IN SOA solaris.san.urix.ru. root.solaris.san.urix.ru. (
2008051501 ;serial
108000 ;refresh
1800 ;retry
1209600 ;expiry
604800)
7.168.192.in-addr.arpa. IN NS solaris.sun.urix.ru.
1 IN PTR solaris.san.urix.ru.
2 IN PTR slave.sun.urix.ru.
10 IN PTR class.sun.urix.ru.
Точка в конце некоторых названий означает, что не нужно дописывать название доменной зоны.
Если ее не ставить, то сервер автоматически допишет название домена для которого данная таблица
и составляется. Не забывайте про это. Вот и все, если таблицы готовы, то теперь можно и запускать
ваш сервер. Как это делать мы уже рассмотрели выше.
