Сервер доменных имен (DNS) BIND на FreeBSD

Конфигурирование службы доменных имен - одна из наиболее сложных задач сетевого администрирования. Если настройка любого количества Web-серверов, даже на всех подключенных к сети компьютерах, - сравнительно простая задача, то установка сервера имен обычно делается только один раз, каким-нибудь "гуру", чьи деяния вскоре стано-вятся легендой среди сетевых администраторов. В результате получается такая конфигу-рация службы DNS, которую сложно не то что сопровождать, но даже понять. Админи-страторов, знающих все детали настройки службы DNS, намного меньше, чем тех, кто ничего в этом не понимает. В этой главе мы не пытаемся дать исчерпывающее описание службы DNS. Об этом написаны целые книги, причем достаточно толстые. Цель этой главы - научить вас настраивать FreeBSD для работы в качестве сервера имен в нескольких типичных конфигурациях.

Программных реализаций службы DNS много. Но для операционных систем UNIX, на которых работает подавляющее большинство серверов имен в Internet, обычно выбирают систему BIND, распространяемую консорциумом Internet Software Consortium (ISC).

Введение в систему BIND

Система BIND (сокращение от Berkeley Internet Name Domain) состоит из основной программы-демона (named), набора библиотек разрешения имен, позволяющих выполнять поиск имен, и ряда административных средств. Система BIND входит в состав ОС FreeBSD, хотя соответствующая служба и не включена по умолчанию.

Структура системы доменных имен

Система доменных имен (DNS) - это иерархический протокол, работающий по сети Internet аналогично протоколам маршрутизации. Несколько "корневых серверов", географически распределенных по всей сети Internet для обеспечения надежности и избыточности, поддерживается корпорацией Network Solutions, Inc. и другими организациями. Каждое доменное имя (например, somewhere.com) строится в обратном порядке, начиная с корневой зоны, причем суффикс домена - com, org, net и т.д. - определяет верхний уровень иерархии, непосредственно после точки (.), обозначающей корневую зону. После каждого из суффиксов (которые обычно называют доменами верхнего уровня - top-level domains или TLD) следуют имена доменов, определяемые обычно не корневыми серверами, а отдельными хостами DNS в сети Internet. Например, служба DNS домена somewhere.com будет администрироваться сервером в его же сети (например, сервером nsl.somewhere.com). Этот сервер является "авторитетным" хостом DNS для данного домена. Центральный реестр, также поддерживаемый корпорацией Network Solutions, содержит записи обо всех таких доменах, так что корневые серверы могут предоставлять авторитетную информацию о соответствии их имен. Эти "записи хостов" задаются при настройке нового сервера имен: в корпорацию Network Solutions или одному из непосредственно связанных с ней регистраторов посылается соответствующая форма.

Когда клиент обращается с запросом к службе DNS, он запрашивает сервер имен, сконфигурированный в ходе настройки стека протоколов TCP/IP, - обычно это сервер в той же сети, как показано на рис. 30.1. Если сервер не может ответить на запрос, он передает его серверу DNS более высокого уровня, если он доступен. Если же такого сервера нет, запрос направляется непосредственно корневым серверам.

Корневые серверы сами не поддерживают никаких авторитетных данных службы DNS. Они содержат только записи хостов (мы будем называть их записями NS), которые указывают на авторитетные серверы имен в каждом домене. Корневые серверы возвра-щают запрашивающему ответ DNS, содержащий ссылку на авторитетный сервер имен домена, к которому обращался клиент. Этот сервер, в свою очередь, возвращает запра-шиваемые данные DNS локальному серверу DNS, который передает ее клиенту.

Диаграмма поиска в системе DNS, показывающая путь от клиента на локальный сервер DNS, корневые серверы и авторитетный сервер имен

Локальный сервер DNS может сохранить результат поиска в своем кэше на период времени, указанный авторитетным сервером имен. Это ускоряет обработку запросов, позволяя локальным клиентам получать непосредственные ответы на свои запросы DNS от локального сервера, без передачи информации по Internet. Это, однако, означает, что изменения в записях DNS на авторитетном сервере DNS домена не будут доступны клиенту до завершения периода устаревания. До этого времени доступная клиенту инфор-мация DNS "заморожена" и потенциально неверна. Мы еще вернемся к проблеме кэши-рования информации и устаревания данных далее в этой главе.

Зоны

Система BIND позволяет определять зоны - логические группы IP-адресов и имен хостов, существующие на определенном уровне иерархии имен DNS. Например, com. -это зона в корневой зоне (.), а somewhere.com. - это зона, существующая в зоне com. Обратите внимание, что имена зон всегда завершаются точкой, обозначающей корне-вую зону, - это является существенным при создании собственных файлов зон! Под-домены - это зоны, управляемые отдельными серверами доменных имен; например. cluster.somewhere.com. - это зона, в которую может входить несколько машин. Факти-чески она может иметь столько дальнейших подразделов, сколько захочет сконфигури-ровать администратор. Эти зоны обеспечивают прямой поиск имен в системе DNS, или сопоставление именам IP-адресов.

Обратный поиск имен в системе DNS, или сопоставление IP-адресам имен хостов, также осуществляется по зонам. Поскольку система DNS и IP-адреса ведут свое начало от проекта ARPAnet (подробнее см. в главе 22) и не претерпели с тех пор принципиальных структурных изменений, имя зоны обратного поиска DNS имеет вид CCC.BBB.AAA.in-addr.arpa. Это имя состоит из IP-адреса, записанного в обратном порядке, с добавлением суффикса .in-addr.arpa. Например, сеть 64.41.131.* будет определяться зоной 131.41.64.in-addr.arpa.

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

Файлы и программы системы BIND

Поскольку система BIND встроена в ОС FreeBSD, не придется беспокоиться по поводу ее установки или проверки наличия необходимых файлов в соответствующих местах. Не помешает, однако, знать, какие программы задействованы в работе сервера имен и где придется изменять конфигурацию.

o /usr/sbin/named. Собственно демон сервера имен. Он прослушивает порт 53, ожидая поступления запросов поиска системы DNS.

o /usr/sbin/ndc. Программа управления демоном сервера имен. Она использует-ся для запуска, останова, перезагрузки и контроля сервера имен.

o /etc/namedb. Все файлы конфигурации и файлы текущего состояния системы BIND, включая файлы определения зон, находятся в этом каталоге (или в созданных администратором подкаталогах).

o /etc/namedb/named.conf. Основной файл конфигурации системы BIND. Из него система BIND "узнает", какими доменами управлять и как работать с каждым из них.

Включение демона сервера имен

Включение системы BIND в ОС FreeBSD - самая простая часть ее конфигурирования. Необходимо только, как и для любой другой рассмотренной ранее встроенной службы FreeBSD, добавить следующую строку в файл /etc/rc.conf:

named_enable="YES"

Если эта опция установлена, демон named автоматически запускается при загрузке операционной системы. Для запуска демона без перезагрузки используется программа ndc:

o ndc start

new pid is 12717

Теперь сервер должен работать. Но это только самое начало процесса конфигуриро-вания системы BIND.

ПРИМЕЧАНИЕ Для обеспечения максимальной производительности добавьте в файл /etc/resolv.conf строку nameserver, ссылающуюся на адрес заколыдовывания (127.0.0.1) как на основной сервер имен. Это обеспечит наиболее быстрый способ поиска имен в системе DNS на локальной машине. Убедитесь, что перед дополнительными серверами имен имеется следующая строка: search somewhere.com nameserver 127.0.0.1 nameserver 64.41.131.167

Запуск системы BIND в "песочнице"

Как утверждалось в главе 27, иногда имеет смысл (из соображений защиты) запускать определенные службы в среде, которую называют "песочницей", - отдельной структуре каталогов, не содержащей ничего лишнего, так что извне кажется, будто именно она и представляет всю файловую систему. В случае службы FTP эта структура называлась "тюрьмой измененного корневого каталога" ("chroot jail"). Фактический корневой каталог файловой системы изменялся так, что сервер и создаваемые им процессы не могли выйти за пределы отведенной им структуры каталогов выше определенной точки. Система BIND поддерживает такую же возможность, но в большинстве документации эту среду называют "песочницей" ("sandbox"), а не "тюрьмой". Принцип организации среды, однако, - тот же.

Типичное конфигурирование "песочницы" состоит в создании подкаталога sandbox в каталоге /etc/namedb и запуске демона named так, что он ограничивает себя только этим каталогом. Поэтому, если демон named будет взломан (что вполне возможно, поскольку уязвимые места в версиях системы BIND находят и по сей день), ущерб будет нанесен только соответствующему каталогу. Создайте каталог /etc/named/ sandbox и измените его владельца и права доступа так, чтобы он принадлежал непривилегированному пользователю и группе bind:

# chown -R bind:bind /etc/namedb/sandbox

# chmod -R 750 /etc/namedb/sandbox

Затем создайте подкаталоги /etc и /var/run в каталоге sandbox. Скопируйте файл /etc/localtime в каталог /etc/namedb/sandbox/etc. Сервер будет записывать во время выполнения файлы в каталог /var/run, и ему необходим файл localtime для обработки последовательных значений из файлов зон и для правильной регистрации дат.

# mkdir /etc/namedb/sandbox/etc

# ср /etc/localtime /etc/namedb/sandbox/etc

# mkdir -p /etc/namedb/sandbox/var/run

Наконец, добавьте следующую строку в файл /etc/rc.conf: named_flags="-u bind -g bind -t /etc/namedb/sandbox"

Учтите: если для управления демоном named используется программа ndc (как будет показано в этой главе) и демон работает в "песочнице", придется использовать опцию -с. Команды будут иметь следующий вид:

# ndc -с /etc/namedb/sandbox/var/run/ndc start

Учтите также, что для записи демоном named журнала в файл, последний должен быть в каталоге sandbox.

Файл конфигурации системы BIND (named.conf)

Чтобы от сервера имен был толк, убедитесь, находится ли он в нужном месте по отношению к клиентам и остальной части сети, с учетом ее топологии, и правильно ли он сконфигурирован для взаимодействия с другими серверами имен. Неправильная конфигурация сервера имен может привести к постоянному обмену информацией между ним и корневыми серверами в безуспешных попытках согласовать данные. Файл /etc/namedb/named.conf необходимо правильно построить, а для этого - хорошо понимать.

К счастью, система BIND версии 8 (включается в ОС FreeBSD в момент написания этой главы; вскоре, вероятно, ее заменит BIND версии 9) существенно упрощает многие таинственные моменты конфигурирования сервера имен, обычно присутствовавшие в первых версиях системы (до версии 4 включительно). Система BIND 8, сразу заменившая BIND 4, добавила множество возможностей конфигурирования, одновременно избавив от большого количества избыточных или плохо продуманных элементов. В листинге 30. 1 представлен простой файл named.conf, позволяющий понять используемый синтаксис и структуру файла конфигурации.

Лис тинг 30.1. П р им е р фай ла /etc/named b/named.conf /* * Пример файла конфигурации системы BIND 8 */

logging {

category lame-servers { null; }; category cname { null; };

>;

options {

directory "/etc/namedb" ; } ;

zone "somewhere.com" {

type master;

file " somewhere . com" ; }; zone "131.41. 64. in-addr.arpa" {

type master;

file "131 . 41 . 64 .in-addr.arpa" ; {;

zone "elsewhere.com" {

type slave;

file "slave/elsewhere . com" ;

masters { 113.125.2.145; }; }; zone " . " {

type hint;

fi le "named. boot" ; };

zone "0.0 .127. in-addr.arpa" { type master; file "localhost.rev"; );

Как видно из листинга, файл конфигурации состоит из нескольких блоков (или "операторов") с синтаксисом в стиле языка С, включающих подоператоры в фигурных скобках ({})

zone "O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.O.IP6. INT" { type master; file "localhost.rev"; } ;

Все поддерживаемые операторы перечислены и описаны на странице справочного руководства named.conf. Чаще всего используются операторы options, controls, logging и zone.

Комментарии в файле named.conf также задаются в стиле языка С; однострочные комментарии начинаются двумя косыми (//), а блочные комментарии имеют синтаксис: /* комментарий */. Поддерживаются также комментарии в стиле командного интерпретатора (начинающиеся символом #).

Файл named.conf, входящий в стандартную поставку ОС FreeBSD, включает как опе-раторы, представленные в листинге 30.1, так и ряд других. В нем также много справочной информации в виде комментариев, описывающих использование каждого оператора.

При любом изменении в файле named.conf или каком-либо из файлов зон (которые будут рассмотрены далее в этой главе) необходимо перезапустить демон named с помощью программы ndc:

# ndc reload

Reload initiated.

Использование перенаправляющего сервера

Возвращаясь к представленной на рис. 30.1 топологии, заметим, что перенаправляющим сервером (forwarder) называют сервер имен в сети "верхнего" уровня - сети, более близкой к корневым серверам, позволяющей запрашивать из нее информацию системы DNS. (Учтите, что доступ к серверу имен может быть ограничен, как будет показано в дальнейшем.) В качестве перенаправляющего сервера для системы FreeBSD, работающей как сервер имен домашней сети, лучше всего использовать сервер имен поставщика услуг Internet. Если ваша машина не может сама ответить на запрос DNS-информации, она запрашивает ее у корневых серверов (указанных в файле /etc/namedb/named.root). Это требует времени и передачи дополнительных пакетов по сети.

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

# nslookup www.freebsd.org ns.somewhere.com

Server: ns.somewhere.com

Address: 64.41.131.172

Non-authoritative answer: Name: freefall.freebsd.org Address: 216.136.204.21 Aliases: www.freebsd.org

Конфигурирование системы FreeBSD для обращения к одному или нескольким пере-направляющим серверам позволяет ей воспользоваться кэшем сервера имен верхнего уровня, а не извлекать авторитетные данные в ответ на каждый запрос. Недостатком (как уже было сказано) является "замороженность" данных в кэше на период, продолжительность которого задается в файле зон авторитетного сервера (этот период часто составляет несколько дней). На рис. 30.2 представлен путь DNS-запроса при использовании перенаправляющего сервера. Основную работу выполняет перенаправляющий сервер, строящий свой кэш по результатам собственных запросов и при выполнении запросов своих клиентов. Использующему его серверу DNS нижнего уровня необходимо только запросить перенаправляющий сервер, сокращая время выполнения запроса и объем передаваемой информации.

СОВЕТ

Увеличение объема передаваемой DNS-информации, часто вызываемое неправильной конфи-гурацией серверов имен, не компенсируется наличием кэширующих серверов имен. Эти пере-направляющие серверы предотвращают избыточную передачу ненужных запросов по низкоско-ростным каналам связи, например, в случаях, когда хост DNS, работающий в качестве авторитетного сервера имен для домена, подключен по низкоскоростному каналу DSL или во-обще по коммутируемой линии. Без кэширующих серверов имен каждый хост в Internet был бы вынужден посылать запросы DNS непосредственно ему. При наличии перенаправляющих сер-веров нагрузка на канал связи целевого хоста существенно уменьшается. Использование пере-направляющих серверов позволяет быть добропорядочным гражданином сетевого сообщества, а также ускорить и повысить эффективность собственных запросов.

Чтобы обеспечить использование перенаправляющего сервера, замените адрес 127.0.0.1 в блоке forwarders оператора options IP-адресом сервера имен верхнего уровня (127.0.0.1, адрес локального хоста, тут не поможет) и уберите символы ком-ментариев /* и */ в начале и конце блока.

/*

forwarders {

127.0.0.1; };

*/

Можно задавать сколько угодно перенаправляющих серверов - демон named об-ратится к каждому из них, прежде чем сдаться и запросить корневые серверы. Мож-но также убрать комментарий с оператора forward only в блоке options, чтобы демон named при обработке всех запросов обращался только к перенаправляющим серве-рам. Демон обращается за DNS-информацией к перенаправляющим серверам, пока не окажется, что они недоступны или не работают - тогда выполняются полные запросы к корневым серверам. Если установлена опция forward only, запросов к корневым серверам не будет.

Конфигурации главного и подчиненного сервера

Каждый блок зоны определяет домен или поддомен, который будет администри-роваться вашей машиной с ОС FreeBSD. Чаще всего блок зоны определяет домен вида somewhere.com:

zone "somewhere.com" { type master; file "somewhere.com"; };

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

Подоператор type может задавать значения master, slave, stub, forward или hint. Чаще всего используются значения master (главный) и slave (подчиненный); остальные - только в специальных случаях, которые мы вскоре рассмотрим.

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

Подчиненная зона (slave) - это копия главной зоны; ее файл зоны является произ-водным от файла зоны главного сервера. Подчиненные серверы могут давать авторитетные ответы на запросы DNS. Блок подчиненной зоны выглядит следующим образом:

zone "elsewhere.com" { type slave;

file "slave/elsewhere.com"; masters { 113.125.2.145; }; };

Подоператор masters содержит список главных серверов (перечисленных через точку с запятой), с которых берется информация зон. Эти серверы могут быть как авторитетными серверами главной зоны, так и неавторитетными подчиненными. Оператор file в подчиненной зоне задает имя автоматически генерируемого файла зоны, который демон named создаст после получения информации от главного сервера. В нашем примере файл elsewhere.com создается в подкаталоге /etc/namedb/slave. Такую структуру каталогов можно использовать для отделения авторитетных (главных) файлов зон от автоматически гене-рируемых (подчиненных).

СОВЕТ

При настройке подчиненной зоны на сервере выполните команду ndc reload, чтобы система BIND выполнила перенос зоны и создала новый файл зоны в заданном опера-тором file месте. В некоторых случаях файл зоны подчиненного сервера не обновляется сразу после изменения главного файла зоны, даже если выполнена команда ndc reload В этом случае просто удалите файл подчиненной зоны и повторно выполните команду ndc reload для пересоздания файла и переноса данных зоны.

Другие типы зон

Как описано в справочном руководстве по файлу named.conf, поддерживается еше три типа блоков зоны.

o stub. Зоны типа stub работают так же, как и подчиненные, но переносят с

главного сервера только записи NS - записи, задающие местонахождение

авторитетной DNS-информации для указанного домена.

o forward. Зоны типа forward можно использовать для перенаправления запросов зоны другому серверу или группе серверов. В операторе zone этого типа можно задавать блок forwarders, действующий аналогично такому же глобальному опера-тору в блоке options. Это позволяет переопределять глобальный список перенап-равляющих серверов.

o hint. Зона типа hint реально используется в единственном случае - задает началь-ный список потенциальных корневых серверов, который хранится в файле /etc/ namedb/named.root. На самом деле, это не авторитетный список корневых серве-ров, а просто список "подсказок" системе BIND, задающий серверы, на которых имеется действительный в настоящее время список корневых серверов, часто из-меняющийся в зависимости от особенностей функционирования сети.

Ограничение доступа к службе DNS

Система BIND позволяет ограничить доступ с помощью списков контроля доступа (Access Control List - ACL). Список ACL указывается в операторе acl, задающем имя списка и содержащем критерии включения хостов в список. Эти критерии могут иметь различные формы, а также быть рекурсивными; другими словами, список ACL может содержать другие списки ACL. Следующие списки контроля доступа являются встроен-ными.

o any. Разрешает доступ всем хостам.

o попе. Запрещает доступ всем хостам.

o localhost. Разрешает доступ с IP-адресов всех интерфейсов системы.

o localnets. Разрешает доступ с любого хоста сетей, к которым подключена система.

Элементами списка контроля доступа также могут быть IP-адреса (например, 111.112.113.114), адреса сетей в формате CIDR (например, 111.112.113/24), адреса с отрицанием (1111.112.113.114, что означает "любой хост кроме 111.112.113.114") или оператор key (используется для защищенных транзакций и в этой главе не рассматрива-ется). Составляя список элементов ACL, более специфичные элементы лучше указывать перед элементами, имеющими более широкий охват, поскольку список проверяется в порядке задания элементов. Если хост соответствует элементу списка, доступ с него будет разрешен, независимо от того, есть ли далее для него запрещающий элемент. Все исключения надо задавать в начале списка.

Поскольку файл named.conf читается последовательно, список контроля доступа дол-жен задаваться в файле до того, как на него будут указываться ссылки в других опера-торах. Лучше всего вынести все операторы acl в начало файла named.conf, до блока options. Вот пример простого списка контроля доступа:

acl "my_list" { localhost; localnets; another_list; !132.112.14.124; 132.112.14/24; };

запросам для соответствующей зоны) или в глобальном операторе options. Поддержи-ваются следующие операторы контроля доступа:

o allow-query { элементы_списка_адресов; ... };. Задает хосты, которым разреше-но выполнять обычные запросы DNS. Оператор allow-query можно также зада-вать в операторе zone - в этом случае он переопределяет оператор allow-query блока options. Если этот оператор не указан, запросы разрешены со всех хо-стов.

o allow-transfer { элементы_списка_адресов; ... };. Задает подчиненные серверы, которым разрешено переносить информацию зоны с данного сервера. Опера-тор allow-transfer можно также задавать в операторе zone - в этом случае он переопределяет оператор allow-transfer блока options. Если этот оператор не указан, перенос информации зоны разрешен со всех хостов.

o allow-recursion { элементы_списка_адресов; ... };. Задает хосты, которым разре-шено выполнять рекурсивные запросы через данный сервер. Если этот опера-тор не указан, рекурсивные запросы разрешены со всех хостов.

o blackhole { элементы_списка_адресов; ... };. Задает список адресов машин, от которых сервер не будет принимать запросы и которые он не будет использо-вать при разрешении запросов. На запросы с этих адресов ответов не будет.

Например, можно глобально ограничить запросы, разрешив запрашивать только членам ранее заданного списка контроля доступа my_list. Более того, можно ограничить запросы к домену somewhere.com, разрешив их делать только членам списка my_list и дополнительной сети, а также ограничить перенос информации зоны, разрешив его двум указанным подчиненным серверам. Для этого используется следующая частичная конфигурация:

options {

directory "/etc/namedb"o

allow-query { my_list; }; };

zone "somewhere.com" { type master; file "somewhere.com";

allow-query { my_list; 64.2.43/24; }; allow-transfer { 64.2.43.167; 123.15.221.3; };

Создание файла зоны

В файле зоны задаются соответствия имен хостов и IP-адресов в пределах домена или зоны. Именно в этом файле чаще всего делают ошибки при конфигурировании системы BIND, поэтому мы опишем его достаточно подробно.

Формат файла зоны (который часто называют главным файлом зоны - Master Zone File, или просто, главным файлом - Master File) весьма сложен и строг, хотя и допускает определенные послабления. "Живой" файл зоны в только что установленной системе BIND вполне понятен. Он помогает разобраться, какие виды примитивов (директив) разрешены и как они задаются, а также содержит допустимые и часто используемые сокращенные варианты директив.

Сначала давайте рассмотрим пример файла зоны, представленный в листинге 30.2, и разберем его компоненты. Обратите внимание, что в файлах зон точки с запятой (;) являются символами начала комментария.

Листинг 30.2. Пример файла зоны для домена 5omewhere.com.

$TTL 3600

somewhere.com. IN SOA stripes.somewhere.com. root.somewhere.com. (

20010610 10800 3600 604800 86400 )

Serial Refresh Retry Expire Minimum TTL

Серверы DNS

IN NS stripes.somewhere.com. IN NS spots.somewhere.com.

; Имена машин

localhost IN A 127.0.0.1

nsl IN A 64.41.131.162

ns2 IN A 64.41.131.163

mail IN A 64.41.131.167

@ IN A 64.41.131.162

; Псевдонимы

www IN CNAME @

ftp IN CNAME www.somewhere.com.

; Запись MX

@ IN MX 10 mail.somewhere.com.

Хотя это файл может показаться непонятным и не имеющим определенного формата, на самом деле, он имеет четкую структуру. Листинг 30.2 состоит из шести основных элементов:

o директива STTL;

o запись SOA (Start-of-Authority);

o блок записей NS (серверов имен);

o блок записей А (адресов);

o блок записей CNAME (каноническое имя - Canonical Name), определяющих псевдонимы;

o запись MX (Mail Exchanger).

За исключением этих директив, каждый элемент файла - это запись ресурса (Resource Record - RR), определяющая свойства имени в зоне по отношению к определенной "точке отсчета" ("origin"). Рассмотрим все представленные элементы подробно.

Директивы

Формат файла зоны допускает использование нескольких различных базовых дe-ректив. Они задают глобальные установки для всего файла. Каждая такая директива задается прописными буквами и начинается с символа доллара ($). Директивы могут задаваться в любом месте файла зоны, причем каждая последующая директива пере-определяет одноименные предыдущие.

Из всех имеющихся директив на практике используется только SORIGIN.

o SORIGIN. Синтаксис: SORIGIN <имя домена> [<комментарий>]

Значение SORIGIN будет добавляться к любому неуточненному имени в записи. Примером неуточненного имени является www; если имя www указано в записи в файле зоны, а директива SORIGIN имеет значение somewhere.com., запись будет определена как www.somewhere.com. (с завершающей точкой).

Если директива SORIGIN в файле зоны не задана, предполагается значение, совпадающее с именем зоны, заданным в операторе zone, который ссылается на файл зоны. Если имя домена в директиве не имеет завершающей точки, оно не является "абсолютным", т.е. будет добавляться к любой предшествующей строке SORIGIN. Например, следующие конструкции

$ORIGIN com.

$ORIGIN somewhere

www IN CNAME stripes

эквивалентны одной:

www.somewhere.com. IN CNAME stripes.somewhere.com.

o SINCLUDE. Синтаксис: SINCLUDE <имя файла> [<исходный домен>] [<ком-

ментарий>]

Директива SINCLUDE импортирует файл с указанным именем и обрабатывает его так, как если бы содержимое входило в файл зоны в месте указания директивы SINCLUDE. При обработке содержимого включенного файла директиве SORIGIN устанавливается значение <исходный домен>, если оно задано.

o STTL. Синтаксис: STTL <стандартное время жизни> [<комментарий>]

Директива STTL устанавливает стандартное время жизни (Time-to-Live - TTL) для любой записи, в которой значение времени жизни не задано. Эта директива используется только для записей типа отрицательного кэширования, когда система BIND запоминает факт несуществования записи на определенный период (т.е. время жизни). В записи ресурса (Resource Record - RR), поле TTL идет перед столбцом класса. В записях, представленных в листинге 30.2, оно пустое (поле IN задает класс). Эти записи наследуют значение директивы STTL (3600 се-кунд), указанное в начале листинга.

o SGENERATE. Синтаксис: SGENERATE <диапазон> <левая часть> <тип> <пра-

вая часть> [<комментарий>]

Директива SGENERATE используется для создания набора записей, отличающихся итератором, или значением шага. Другими словами, можно автоматически задать большой список записей, имена и IP-адреса которых строятся по определенной формуле.

o <диапазон>. Может иметь две формы: начало-конец или начало-конец/шаг. При использовании первой формы шаг устанавливается равным 1.

o <левая частьХ Описывает, чем будут отличаться создаваемые записи левой части. Любой одиночный символ $ в левой части заменяется значением итера-тора. Если <левая часть> представляет собой неабсолютное имя, к ней добав-ляется текущее значение директивы SORIGIN. Если в левой части ничего не надо изменять, используется символ-заместитель 0.

o <тип>. PTR, CNAME или NS.

o <правая частьХ То же, что и <левая часть>, но задает правую часть записи. Следующие директивы SGENERATE

$ORIGIN 0.0.192.in-addr.arpa.

$GENERATE 1-2 О N8 ns$.somewhere.com.

$GENERATE 1-127 $ CNAME $.0

раскрываются системой BIND в такой список:

О.О.0.192.in-addr.arpa. NS nsl.somewhere.com.

О.0.0.192.in-addr.arpa. NS ns2.somewhere.com.

1.0.0.192.in-addr.arpa. CNAME 1.0.0.0.192.in-addr.arpa.

2. 0.0.192.in-addr.arpa. CNAME 2 . 0 . 0.0.192.in-addr.arpa.

127.0.0.192.in-addr.arpa. CNAME 127.0.0.0.192.in-addr.arpa.

Записи SOA

Теперь мы добрались до первой записи ресурсов (Resource Record) в файле зоны. Это запись Start-of-Authority (SOA). Она является наиболее важной частью файла зоны, и именно ее чаще всего приходится исправлять. Основная причина - стиль ее задания не соответствует интуитивно предполагаемому. Придется рассмотреть эту запись по частям.

В листинге 30.2. представлен следующий пример записи SOA:

somewhere.com. IN SOA stripes.somewhere.com. root.somewhere.com. (

2001061000 Серийный номер

10800 Обновление

3600 Повторные попытки

604800 Устаревание

86400 ) Минимальное время жизни

Запись SOA, как и все записи, имеет следующую форму:

<имя> [<время жизни>] [<класс>] <тип> <значение>

Если указанное <имя> не абсолютно, добавляется текущее значение директивы SORIGIN. В нашем случае использовано абсолютное имя (оно завершается точкой).

Поле <время жизни> не задано, поскольку в представленном файле имеется глобаль-ная директива STTL, которая его задает. Значение IN (сокращение от "Internet") - это класс записи. Система BIND поддерживает и другие классы, но они нас в данном случае не интересуют. Если значение in указано в операторе zone в файле named.conf, это поле - избыточное, и его тоже можно не указывать.

Поле <значение> для большинства записей - достаточно простое: IP-адрес, имя хоста или символическое имя. Запись SOA, однако, намного сложнее. Она начинается с имени авторитетного сервера имен в зоне (stripes.somewhere.com). Следующий фрагмент инфор-мации - адрес электронной почты администратора домена, в котором знак @ заменен точкой. Заканчивается адрес тоже точкой. В нашем примере адрес администратора (root@somewhere.com) задан как root.somewhere.com. и будет использоваться систе-мой BIND для посылки ему уведомлений о состоянии.

ПРИМЕЧАНИЕ

Причина замены в адресе электронной почты администратора знака @ точкой состоит в том, что символ @ имеет в файле зоны специальное значение. Это сокращенная ссылка на текущее значение директивы SORIGIIM, и система BIND заменяет ее полным именем домена.

Учтите, что для успешного использования символ @ должен представлять полное имя; нельзя использовать его в качестве фрагмента, в виде www.@ или других подобных конструкций.

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

o Серийный номер. Серийный номер позволяет системе BIND следить за давно-

стью файлов зон. При каждом обновлении файла зоны необходимо увеличи-

вать серийный номер, чтобы сообщать системе BIND, что необходимо обно-

вить информацию на основе данного файла. Обычно принято использовать

для этого числа формат ГГГГММДДNN; последние две цифры предназначе-

ны для нескольких версий, созданных в течение одного дня. При внесении

изменения обновите серийный номер, указав в нем дату изменения.

ПРИМЕЧАНИЕ

При выполнении команды ndc reload для обновления информации в главном файле зоны, система BIND автоматически определит, что данные необходимо обновить, независимо от зна-чения серийного номера. Однако поддержка корректного серийного номера - хорошая привычка. Она обеспечит правильную работу в случае обновления данных подчиненной зоны вручную.

o Обновление. Это число задает (в секундах) частоту, с которой подчиненные серверы должны проверять изменение данных зоны на главном сервере. Если серийный номер главного файла изменился с момента последнего переноса информации зоны, будет выполнен новый перенос.

o Повторные попытки. Если не удается связаться с главным сервером, подчинен-ные серверы будут пытаться связаться повторно с интервалами, задаваемыми этим числом (в секундах).

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

o Минимальное время жизни. Это число задает (в секундах), сколько времени хранить в кэше "негативные " ответы (показывающие отсутствие определен-ных данных).

Записи NS

В листинге 30.2 представлены следующие примеры записей серверов имен (Name Server - NS):

; Серверы DNS

@ IN NSstripes.somewhere.com.

@ IN NS spots.somewhere.com.

Эти записи задают серверы DNS, которым разрешается давать авторитетные ответы на запросы в отношении данной зоны. Учтите, что символ @ обозначает текущее значение директивы $ORIGIN (somewhere.com.) и что имена обоих серверов завершаются точками (показывающими, что они - абсолютные).

Можно создавать записи NS для поддоменов, или зон в текущей зоне. Например, пусть имеется кластер машин в зоне cluster.somewhere.com., DNS-информация которого обслуживается отдельным сервером имен (ns.cluster.somewhere.com). Запись NS для этого сервера, разрешающая внешним хостам запрашивать у него информацию об IP-ад-ресах машин кластера, будет иметь вид:

cluster IN NS ns.cluster.somewhere.com.

Учтите, поскольку после имени cluster не указана завершающая точка, система BIND добавит к имени значение директивы SORIGIN (somewhere.com.).

Записи адреса

Запись адреса (А) используется для связи имени хоста и IP-адреса. В нашем примере имеются следующие записи:

; Имена машин

looalhost IN A 1 2 7 . 0 . 0 . 1

stripes IN A 64.41.131.162

spots IN A 64.41.131.163

mail IN A 64.41.131.167

@ IN A 64.41.131.162

Значение этих записей вполне понятно. Неуточненные имена в левой части дополняются текущим значением директивы SORIGIN, так что имени mail.somewhere.com будет соответствовать адрес 64.41.131.167. Символ @ заменяется так, что запрос адреса somewhere.com вернет значение 64.41.131.162.

Имена, определенные в записях А, называют каноническими, в отличие от псевдонимов (которые задаются записями CNAME).

Записи CNAME

Записи канонического имени (Canonical Name - CNAME) используются для создания псевдонимов. В примере, представленном в листинге 30.2, имеем:

; Псевдонимы

www IN CN AME @

ftp IN CNAME www.so mewhere.com.

Псевдоним www (который дополняется значением $ORIGIN до www.somewhere.com.) указывает на каноническое имя @, или somewhere.com. (IP-адрес которого задан в блоке А) .

Записи CNAME часто используются, поскольку не привязываются непосредственно к IP-адресам. Можно использовать записи CNAME, например, для ссылки на имена в другой зоне, которая может управляться соответствующим владельцем. Записи CNAME также позволяют сократить количество изменений в файле зоны в случае изменения IP-адресов.

Записи MX

Записи Mail Exchanger (MX) определяют, какие хосты должны использоваться для

доставки электронной почты адресатам в данной зоне. Система Sendmail (и другие

агенты передачи почты) ищет запись MX с максимальным приоритетом в зоне и

подключается к соответствующему хосту. Хосты MX домена можно найти с помощью

команды host:

# host somecompany.com

somecompany.com has address 207.114.98.18

somecompany.com mail is handled (pri=100) by mail.uu.net

somecompany.com mail is handled (pri=5) by mx-1.somecompany.com

Сначала используются записи с меньшими значениями приоритета, а затем делаются попытки подключиться к хостам с большим приоритетом, пока не удастся успешно установить соединение по протоколу SMTP. Приоритет задается как часть поля значения в записи, как в нашем примере:

; Запись MX

@ I N M X 10 mail.somewhere.com.

ПРЕДУПРЕЖДЕНИЕ

Запись MX не может ссылаться на IP-адрес. Кроме того, многие агенты передачи почты и почтовые клиенты будут сообщать об ошибках, если выявят запись MX, ссылающуюся на псевдоним (заданный записью CNAME]. Убедитесь, что записи MX ссылаются на имена, заданные отдельно в записях А!

Записи PTR

Записи указателей (PTR) по смыслу противоположны записям А или CNAME, и используются в файлах обратного просмотра зон DNS (например, 131.41.64.in-addr.arpa) для сопоставления IP-адресам доменных имен. Пример файла обратного просмотра зоны DNS представлен в листинге 30.3.

Поскольку обратный поиск в DNS возвращает только одно имя, несколько записей PTR для одного IP-адреса бесполезны и только сбивают с толку. Поэтому файлы обрат-ного просмотра обычно короче, чем соответствующие файлы прямого просмотра.

Файлы обратного просмотра зоны DNS

Файл обратного просмотра зоны DNS, задающий зону в виде I31.41.64.in-addr.arpa, используется для сопоставления имен IP-адресам. Файлы этого типа указываются в файле named.conf, и соответствующая информация распространяется подчиненным серверам точно так же, как и файлы прямого просмотра зон DNS. В листинге 30.3 представлен пример файла обратного просмотра зоны DNS.

Листинг 30.3. Пример файла обратного просмотра DNS для зоны 131.41.64.in-addr.arpa

$TTL 3600

131.41.64.in-addr.arpa. IN SOA stripes.somewhere.com. root.somewhere.com. (

2001061000 ; Серийный номер

10800 ; Обновление

3600 ; Повторные попытки

604800 ; Устаревание

86400 ) ; Минимальное время жизни

@ IN NS stripes.somewhere.com.

@ IN NS spots.somewhere.com.

164 IN PTR stripes.somewhere.com.

165 IN PTR spots.somewhere.com. 167 IN PTR mail.somewhere.com.

Обратите внимание, что вместо записей А или CNAMEN используются записи PTR. Имя, на которое указывает запись PTR, - действительное каноническое имя для соот-ветствующего IP-адреса. В файле обратного просмотра не нужна запись MX, поскольку записи MX нельзя непосредственно связывать с IP-адресами.

Создание файла зоны localhost

Для правильной работы необходимо создать специальный файл для зоны localhost (0.0.127.in-addr.arpa). В каталоге /etc/namedb имеется сценарий командного интер-претатора, помогающий создать такой файл. Этот сценарий называется make-localhost; он читает шаблон (PROTO.localhost.rev) и заполняет его введенной администратором информацией. Поскольку для сценария не установлено право на выполнение, необходимо запускать его командой sh:

# sh make-localhost

Enter your domain name: somewhere.com

Получающийся в результате файл, localhost.rev, должен выглядеть примерно так, как в листинге 30.4 (комментарии переведены на русский - прим. научи, ред.).

Листинг 30.4. Автоматически сгенерированный файл зоны localhost.rev

From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90 $FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10 15:31:40 peter Exp $

; Этот файл автоматически создается сценарием 'make-localhost1 ; в каталоге /etc/namedb.

$TTL 3600

@ IN SOA stripes.somewhere.com. root.stripes.somewhere.com. (

20010612 ; Серийный номер 3600 ; Обновление

900 ; Повторные попытки 3600000 ; Устаревание 3600 ) ; Минимальное время жизни IN NS stripes.somewhere.com. 1 IN PTR localhost.somewhere.com.

Не забудьте создать этот файл, прежде чем начнете эксплуатировать службу DNS!

Конфигурирование кэширующего сервера имен

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

Чтобы сконфигурировать кэширующий сервер имен, просто не указывайте в файле named.conf никакие операторы zone, кроме тех, что необходимы для работы самого сервера. Такая конфигурация представлена в листинге 30.5.

Листинг 30.5. Пример файла /etc/namedb/named.conf

/* * Пример конфигурации системы BIND 8 */

logging {

category lame-servers { null; } ;

category cname { null; } ; }; options {

directory "/etc/namedb";

};

zone "." {

type hint;

file "named.boot" ;

};

zone "0.0.127.in-addr.arpa" in { type master; file "localhost.rev";

}; zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" { type master; file "localhost.rev";

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

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

Обновлено: 12.03.2015