Примеры конфигурации пакета BIND
Категория: Система доменных имен | Автор: admin | 30-04-2010, 02:16 | Просмотров: 3491

После детального знакомства с файлом named.conf настало время рассмотреть ряд готовых примеров. В следующих разделах мы опишем три типичные конфигурации:

  • домашний компьютер студента, работающего в Linux;
  • кафедральный сервер, в котором применяется трехуровневая иерархия переадресации;
  • сервер компании, занимающейся Web-хостингом и обслуживающей около 2000 зон.

 

Домашний Linux компьютер

 

Робби Браун, студент, имеет дома Linux-систему, предоставляющую услуги DNS для его домена synack.net, а также для доменов нескольких его друзей. В системе выполняется пакет BIND 8.2.2-Р5. Содержимое файла named.conf представлено ниже. Мы добавили к нему ряд комментариев.

Конфигурация системы студента довольно проста. Параметры в основном имеют стандартные значения: сервер является рекурсивным, файлы находятся в привычных каталогах, записи базы данных реплицируются по одной за раз, взаимодействие происходит через порт 53 и т.д. Изменения наблюдаются лишь в настройках отдельных зон. Например, зона synack.net допускает пересылки только к одному узлу и не разрешает динамические обновления.

Описываемый сервер имен является главным для двух доменов: synack.net и xinetd.org. Он также выступает в качестве подчиненного сервера для доменов teich.net и rmtai.com, принадлежащих двум друзьям Робби. Раздел файла named.conf, посвященный журнальной регистрации, является нестандартным, что неудивительно, так как Робби все же студент факультета вычислительной техники. Включен режим отладки на уровне 3 и созданы оригинальные каналы (за основу взят образец файла конфигурации, входящий в комплект поставки BIND).

 

 

/* Файл named.conf, gw.synack.net */

 

options {

directory "/var/named";

pid-file "/var/named/named.pid";

};

 

zone "synack.net" {

type master;

file "synack.forw";

allow-transfer { 198.11.19.15;   };

};

 

zone "xinetd.org" {

type master;

file "xinetd.forw";

allow-transfer { 198.11.19.15;  };

};

 

zone "1.168.192.in-addr.arpa" {

type master;

     file "named.rev";  // обратный поиск, для частных адресов

};

 

zone "." {

type hint;

file "cache.db";

};

 

zone "teich.net" {

type slave;

file "teich.net.sec";

masters { 216.103.220.218;  };

};

 

zone "rmtai.com"  {

type slave;

file "rmtai.com.sec";

masters ( 216.103.220.218;   };

};

// Определяются три канала регистрации событий (важные сообщения

// системы Syslog, отладочные сообщения умеренной степени

// детализации, сообщения о загрузке зонной базы данных), а затем

// за ними закрепляются категории.

 

logging {

    channel syslog_errors {

syslog locall;

severity error;

};

channel moderate_debug {

severity debug 3;           // отладка уровня 3

file "foo";                  // запись в файл foo

print-time yes;             // вывод меток времени

print-category yes;              // вывод названия категории

print-severity yes;              // вывод уровня серьезности

};

 

channel no_info_messages {

syslog 1оса12;

severity notice;

};

 

category parser {

syslog_errors;

default_syslog;

};

 

category lame-servers { null;   };  // сообщения данной категории

  // не регистрируются

category load { no_info_messages;  };

category default {

default_syslog;

moderate_debug;

};

};  // конец инструкции logging

 

 

 

В этой конфигурации отсутствует зона обратного преобразования для узла localhost. Соответствующая привязка должна быть сделана в файле /etc/hosts.

 

Кафедральный сервер

 

На факультете вычислительной техники университета штата Колорадо применяются кэширующие серверы в каждой подсети. При отсутствии нужных данных в кэше запрос переадресуется на один из подчиненных серверов. Последние, в свою очередь, контактируют с главным сервером, который связывается с внешними серверами от их имени. На каждом переадресующем сервере установлен параметр forward first. Ниже приведены все три конфигурационных файла: для кэширующих серверов, подчиненных серверов и главного сервера. На всех серверах выполняется пакет BIND 8.

Кэширующий сервер удобен для подсети, где нужен локальный сервер, но нет необходимости управлять зонной базой данных. Все, что требуется, — это создать файл named.conf и файл "подсказок", а также организовать запуск демона named на этапе начальной загрузки. В конфигурационном файле не создаются локальные зоны — только зона корневых "подсказок" и зона обратного преобразования для узла localhost.

 

 

// Файл конфигурации BIND 8.2 — кэширующий сервер

// Глобальные параметры

options {

directory "/var/named";

named-xfer "/usr/local/sbin/named-xfer";  // только в BIND 8

// создаем большой кэш благодаря главному и подчиненным серверам

forwarders {

128.138.243.151;   // узел mroe

128.138.243.140;   // узел anchor

128.138.243.137;   // узел moet

128.138.243.138;   // узел vulture

128.138.236.20;    // узел piper

};

forward first;

query-source address * port 53;

};

 

// Сообщения системы Syslog регистрируются от имени средства 1оса13; // сообщения о неправильно настроенных серверах не регистрируются logging {

channel syslog_info {

syslog lоса13;

severity info;

};

category lame-servers ( null;   ); category default { syslog_info;   };

 

// Кэш корневых серверов

zone "." {

type hint;

file "named.cache";

 

// Главный сервер зоны обратного поиска для узла localhost

zone "0.0.127.in-addr.arpa" {

type master;

file "localhost";

notify no;

};

 

 

 

В конфигурационном файле подчиненных серверов определяется зона прямого преобразования cs.colorado.edu и группа зон обратного преобразования, из которых мы показали только две. В данном примере маски зон обратного преобразования не проходят по границе байтов (суффикс адреса в основном равен /26), но поскольку все четыре подсети находятся под единым административным контролем и описаны в одном файле, специальное применение записи CNAME (описана в следующем параграфе) не требуется.

 

 

// Файл конфигурации BIND 8.2 — подчиненный сервер

options {

directory "/var/named";

named-xfer "/usr/local/sbin/named-xfer";  // только в BIND 8

forwarders { 128.138.243.151;   };        // главный сервер

forward first;

query-source address * port 53;

allow-transfer { none;  };

};

 

// Параметры регистрации, описания зоны корневых "подсказок" и зоны

// обратного преобразования для узла localhost такие же,  как и

// в случае кэширующего сервера, поэтому они здесь не показаны.

// Подчиненные зоны

zone "cs.colorado.edu" {

type slave;

file "forward/cs.colorado.edu";

masters { 128.138.243.151;  };

};

 

zone "250.138.128.in-addr.arpa" {

type slave;

file "reverse/250.138.128";

masters { 128.138.243.151;   };

};

 

zone "245.138.128.in-addr.arpa" {

type slave;

file "reverse/245.138.128";

masters { 128.138.243.151;   };

};

//  ... описания множества зон обратного преобразования опущены

 

 

 

Следующий конфигурационный файл принадлежит серверу, который является для домена cs.colorado.edu главным и переадресующим одновременно, т.е. через него проходят все локальные запросы. Это позволяет построить большой кэш, но в то же время представляет собой нарушение правила гласящего, что нельзя смешивать авторитетные и кэширующие серверы.

В данном файле посредством параметра topology задается приоритет локальных серверов. Некоторые серверы не указаны в списке делегирования родительского домена: они оповещаются об изменениях благодаря наличию параметра also-notify.

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

Если для всех зон обратного преобразования применяется один и тот же файл, то записи можно организовать по адресам сетей, а в начале каждой секции ставить директиву $ORIGIN, чтобы заново идентифицировать стандартный домен. Подробнее об этом рассказывается при описании записи DNAME в следующем параграфе.

 

 

# Файл конфигурации BIND 8.x — главный сервер домена cs.colorado.edu

# $Id: named.conf, v 1.28 2000/01/12 00:20:34 root Exp $

acl CUnets {

128.138/16;  198.11.16/24;  204.228.69/24;  127.0.0.1;

};

 

# Глобальные параметры

options {

directory "/var/named";

named-xfer "/usr/local/sbin/named-xfer"; # только в BIND 8

notify yes;

also-notify {

128.138.192.205;    # suod

128.138.244.9;      # riker

128.138.243.70;     # squid

128.138.241.12;     # goober

128.138.244.100;    # av-server

128.138.202.19;     # nago

};

 

query-source address * port 53;

topology { localhost;  localnets; CUnets;  };

 

# Параметры регистрации,  описания зоны корневых "подсказок" и зоны

# обратного преобразования для узла localhost такие же, как и прежде,

# поэтому они здесь не показаны.

 

# Факультет вычислительной техники

zone "cs.colorado.edu” {

type master;

file "forward/cs.colorado.edu";

};

 

# Записи для зоны обратного преобразования  (128.138.Х.Х)

zone "250.138.128.in-addr.arpa"  {

type master;

file "reverse/250.138.128";

};

zone "245 .138.128.in-addr.arpa"  {

type master;

file "reverse/245.138.128";

};

#... описания множества зон обратного преобразования опущены

 

# Подчиненные зоны

zone "colorado.edu"  {      # домен верхнего уровня

type slave;,

file "secondary/colorado.edu";

allow-transfer { none;  };

masters {  128.138.240.1;   };

};

 

zone "openbsd.org"  {       # проект OpenBSD

type slave;

file "secondary/openbsd.org";

masters {  199.45.131.58;   };

};

 

zone "233.in-addr.arpa"  { # экспериментальный домен групповых адресов

type slave;

file "secondary/233.in-addr.arpa";

masters { 128.223.32.35;   };

};

# описания многих зон опущены

 

 

 

Сервер компании, занимающейся Web-хостингом

 

Наш следующий пример — компания, занимающаяся Web-дизайном и Web-хостингом. Она предоставляет своим клиентам сервис DNS. Главному серверу приходится обслуживать почти 2000 зон, причем для половины из них он является главным, а для половины — подчиненным. Большинство зонных файлов не очень велики (обычно 10—30 Кбайт, самый большой — 160 Кбайт), но их слишком много. Сервер — это компьютер SPARC 20, работающий под управлением SunOS 4.1.3 и BIND 8.2.2-Р5. У него два сетевых интерфейса и 512 Мбайт оперативной памяти.

Ниже приведены лишь небольшие фрагменты конфигурационного файла. Объявления подчиненных зон не показаны; они аналогичны объявлениям главных зон, за исключением типа зоны и директив master, указывающих, где брать зонные данные. Зона корневых "подсказок" и зона обратного преобразования для узла localhost также удалены из листинга; они такие же, как и в предыдущих примерах.

Из-за наличия большого числа зон, информация о многих из которых загружается с внешних серверов, журнальные файлы полны сообщений "zone expired" (зонная база данных устарела) и "not authoritative for zone" (не авторитетен для зоны). Просто многие организации не успевают вовремя обновлять свои базы данных DNS.

 

 

// Главный сервер компании XOR

 

options {

directory "/var/domain";

query-source address 192.225.33.1 port 53;

also-notify 192.108.21.2;

};

 

// Внутренние зоны прямого преобразования компании XOR

zone "xor.com" {

type master;

file "xor.com";

};

 

zone "creative.xor.com"  {

type master;

file "creative.xor.com";

};

 

// ... другие внутренние зоны не показаны

 

// Зоны обратного преобразования компании XOR

zone "21.108.192.in-addr.arpa"  {

type master;

file "xor.rev";

};

 

zone "2.168.192.in-addr.arpa"  {

type master;

file "backlan-2.rev";

};

 

// ... другие зоны обратного преобразования не показаны

// Клиентские зоны прямого преобразования

//====================================================================

// Общественная больница города Боулдер setup:01/21/2000

//====================================================================

zone "boulderhospital.com" {

type master;

file "boulderhospital.com";

};

 

zone "boulderhospital.org" {

type master;

file "boulderhospital.com";

};

 

// Описания примерно 1750 зон не показаны.

 



 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page