4.3. Администрирование сервисов DNS и DHCP 4.3.1. Сервис DNS

Сервисом DNS, присутствующим в ОС Linux, является ПО Berkeley Internet Name Domain (BIND). В данном разделе мы рассмотрим конфигурирование данного ПО с целью организации DNS сервера.
Для настройки сервера DNS в ОС Linux необходимо установить пакеты bind, bind-utils и ответствующие им зависимости. Проще всего устанавливать сервер DNS, используя менеджер пакетов yum. В качестве основного конфигурационного файла ПО BIND использует файл /etc/named.conf, а также файл /etc/rndc.conf для управления сервером DNS при помощи утилиты rndc. База данных имен DNS содержится в каталоге /var/named и содержит файлы описания прямых и обратных зон DNS. Даные файлы имеют текстовый формат, поэтому их можно редактировать в текстовом редакторе или же использовать специальную графическую программу, запускаемую командой system-config-bind.
С руководством «BIND 9 Administrator Reference Мапиа!» можно ознакомиться в каталоге /usr/share/doc/bind-<Вермия>/arm. В данном руководстве содержится информация, начиная от фундаментальных понятий DNS и требований к ПО BIND, и заканчивая настройкой и защитой сервиса DNS.
Конфигурационный файл сервиса DNS - named.conf является основным конфигурационным файлом. Владельцем данного файла должен быть пользователь named, так как демон named запускается именно из-под этой учетной записи. Код доступа данного файла должен позволять просматривать и изменять его только пользователю named и, соответственно, пользователю root. В конфигурационном файле демона named, named.conf, задается роль (главный, подчиненный или ограниченный) сервера и определяется способ, которым сервер должен получать копию данных для каждой зоны, обслуживаемой сервером. Здесь же приводятся всевозможные параметры, такие как глобальные, связанные с работой самого демона, и локальные, применяемые только к данным DNS.
Конфигурационный файл состоит из набора инструкций, каждая из которых оканчивается точкой с запятой. Лексемы разделяются пробельными символами, к которым относится и символ новой строки. Иногда для группировки лексем применяются фигурные скобки. Формат файла довольно строгий: достаточно одной пропущенной точки с запятой, чтобы все перестало работать.
В ПО BIND имеются специальные средства проверки синтаксиса конфигурационного файла (named-checkconf) и зонных файлов (named-checkzone). Эти утилиты ищут не только синтаксические ошибки, но и очевидные пропуски. Например, утилита named-checkzone выдаст предупреждение, если в файл не включена директива $TTL (время жизни записей зоны). Комментарии допускаются везде, где могут стоять пробелы.
Каждая инструкция начинается с ключевого слова, определяющего ее тип. Может присутствовать несколько инструкций одного типа, за исключением options и logging. Отдельные инструкции, а также их части могут отсутствовать; в этом случае будут приняты установки по умолчанию.

Инструкция include используется для включения дополнительных файлов в состав файла named.conf. Данные файлы могут иметь более жесткие права доступа необходимые для более надежной защиты данных.  Параметр <имя_файла> должен  включать полный  путь к включаемому файлу:
include "<имя_файла>"
Если указан относительный путь, то он добавляется к имени каталога, заданному в параметре directory. Очень часто инструкцию include применяют для подключения файлов, содержащих ключи шифрования. Эти данные должны быть доступны только демону named. Чтобы не запрещать доступ ко всему файлу named.conf, ключи хранят в отдельных файлах, которые может читать лишь демон named.
Инструкция options задает  глобальные  параметры   конфигурации,   часть   из   которых впоследствии может быть переопределена для конкретных зон или серверов. Общий формат инструкции следующий:
options {
параметр;
параметр;
...
};

В версии BIND 9 существует около 100 параметров.
Инструкция acl содержит списки доступа в следующем формате:
асl имя_списка {
список_доступа
};

Заданное имя списка можно указывать везде, где требуется список соответствия адресов. Инструкция acl должна быть самой первой в файле named.conf, так как файл named.conf считывается один раз, поэтому списки управления доступом должны быть определены до того, как на них встретится ссылка.
В качестве параметра список_доступа могут использоваться IP-адреса хостов; IP-адреса подсетей в битовом формате записи сетевой маски; стандартные списки доступа; или диапазон IP-адресов. Например, в следующем списке доступа разрешены подсети 172.16.0.1 и 192.168.1.0, и запрещен IP-адрес 192.168.1.5:
{ 172.16.0.1/24; 192.168.1.0/24 };                                     
{ ! 192.168.1.5 };

По умолчанию существуют следующие стандартные списки доступа:

• any - соответствует всем хостам;
• localnets - соответствует всем хостам локальной сети;
• localhost - соответствует локальному хосту;
• попе - не соответствует ни одному хосту.

Сети, входящие в группу localnets, определяются адресами сетевых интерфейсов хоста с учетом сетевых масок.

Инструкция key определяет ключ шифрования, используемый для аутентификации на сервере с использованием механизма TSIG. Для создания ключа нужно указать как алгоритм шифрования, так и секретный ключ, который представлен в виде строки, закодированной в формате base64:
key идентификатор_ключа {
algorithm строка;
secret строка;
};

Идентификатор ключа должен быть определен с помощью инструкции key в файле named.conf до того, как встретится ссылка на ключ. Чтобы связать ключ с конкретным сервером, необходимо включить идентификатор ключа в список keys соответствующей инструкции server. Ключ используется как для проверки запросов, поступающих от сервера, так и для подписи ответов на эти запросы.

Инструкция trusted-keys является частью механизма аутентификации DNSSEC, описанного в документе RFC-2535. Каждая запись состоит из пяти компонентов, определяющих имя домена, флаги, протокол, алгоритм шифрования и ключ. Все это необходимо для безопасного взаимодействия с сервером имен домена. Формат инструкции следующий:
trusted-keys {
домен флаги протокол алгоритм ключ;
домен флаги протокол алгоритм ключ;
};

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

Инструкция server. Демон named способен общаться с серверами, которые не используют последнюю версию пакета BIND или просто неправильно настроены. Инструкция server сообщает демону характеристики удаленных серверов.

server IP-адрес {
bogus yes I no;               [no]
provide-ixfr yes|no;         [yes]
request-ixfr yes|no;         [yes]
edns yes I no;                [yes]
transfers число;              [2]
transfer-format one-answer|many-answers;     
[many-answers]
keys { ключ; ключ; ... };
transfer-source IP-адрес [порт]
transfer-source-v6 IР-адрес^6 [порт]
};

С помощью инструкции server можно переопределять значения глобальных конфигурационных параметров, относящихся к серверам.
Параметры transfers и transfer-format ограничивают количество одновременных входящих зонных пересылок в секунду от удаленного сервера.
В списке keys задаются идентификаторы ключей, которые ранее были определены в инструкции key для использования в сигнатурах транзакций TSIG.
Записи transfer-source предоставляют адрес (IPv4 или IPv6) интерфейса, который нужно использовать в качестве исходного адреса (порта) запросов зонной пересылки.

Инструкция masters позволяет указать один или несколько главных серверов с помощью IP-адресов и ключей шифрования. Указанное имя затем можно использовать в параметре masters инструкций zone, чтобы не повторять IP-адреса и ключи.
Данная инструкция имеет следующий синтаксис:
masters имя { IP-адрес [port номер_порта]    [key ключ];  ... };

Инструкции zone являются одной из самых главных инструкций файла named.conf. Они сообщают демону named о зонах, для которых он авторитетен, и задают параметры управления каждой зоной. Точный формат инструкции zone зависит от роли, которую демон named должен играть в отношении этой зоны. Возможными типами зон являются master, slave, hint, forward, stub и delegation-only.
Ниже показан формат инструкции zone для зоны, в которой демон named является главным сервером имен:
zone "имя_домена" {
type master;
file "путь";
};

Доменное имя в спецификации зоны всегда дается в двойных кавычках.
Зонная база данных хранится на диске в текстовом файле, доступном для редактирования. Поскольку нет соглашения об именовании этого файла, в объявлении зоны должна присутствовать директива file. Зонный файл представляет собой набор записей о DNS ресурсах и имеет специальный формат, подробно описанный в руководстве «BIND 9 Administrator Reference Manual».

zone "localhost" { // Зона прямого преобразования localhost
type master;
file "fwd/localhost"; allow-update { none; };
zone "0.0.127.in-addr.arpa" { // Зона обратного преобразования localhost
type master;
file "rev/127.0.0";
allow-update { none; };
};

Вид прямой и обратной зоны для преобразования имени локального хоста

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

$ТТ1_ 30d
; local host.
@        IN   SOA      local host, postmaster.local host. (
1998050801 ; порядковый номер
3600        ; период обновления
1800        ; интервал между попытками обновления
604800        ; интервал устаревания
3600 )        ; минимальное время жизни
NS        local host.
A       127.0.0.1

Файл прямой зоны (fwd/localhost)

Инструкция controls определяет, каким образом команда rndc будет управлять работой демона named. Эта команда может запускать и останавливать демон, выводить отчет о его состоянии, переводить демон в режим отладки и т.д. Формат инструкции controls следующий:
controls {
inet IP-адрес port номер_порта allow { список_соответствия_адресов } keys { список_ключей };
}
Если параметр ports опущен, то по умолчанию rndc будет использовать порт 953 для обмена данными с демоном named. В качестве значения параметра IP-адрес рекомендуется использовать локальный IP-адрес 127.0.0.1.

Инструкция view содержит список адресов, определяющий, кто из клиентов имеет доступ к данному представлению, а также ряд параметров, применимых ко всем зонам в представлении, и определения самих зон. DNS сервер BIND позволяет настраивать способ представления данных зоны в зависимости от IP-адреса хоста, который выполняет запрос. Синтаксис инструкции таков:
view имя_представления {
match-clients { список_соответствия_адресов };
параметр_представления;  ...
определение_зоны; ...
};

В списке match-clients перечислены клиенты представления. Представления просматриваются по порядку, поэтому инструкции view с самыми большими ограничениями доступа должны идти впереди. Зоны в разных представлениях могут иметь одинаковые имена и принимать свои данные могут из разных файлов. Представления налагают ограничение на структуру файла named.conf: если они присутствуют, то все инструкции zone должны находиться в контексте представлений.
Для создания файла named.conf можно воспользоваться файлом /usr/share/doc/bind-<версия>/sample/etc/named.conf, который представлен как образец. Таким же образом можно поступить при создании файлов зон, образцы которых находятся в каталоге /usr/share/doc/bind-<версия>/sample/var/named.

Для управления сервером DNS в состав пакета bind-utils входит утилита rndc, которая посылает команды управления, подписанные цифровой подписью, на сервер DNS. В процессе своей работы данная утилита использует файл /etc/rndc.conf, в котором содержатся необходимые параметры, такие как имя сервера DNS и имя ключа, который необходимо использовать для подписи команд. Для создания файла rndc.conf можно воспользоваться командой rndc-confgen > /etc/rndc.conf. После того, как файл rndc.conf будет создан в каталоге /etc, можно использовать утилиту rndc для управления сервером DNS.

Основным конфигурационным файлом клиента DNS является файл /etc/resolv.conf. Данный файл должен содержать минимум две записи - nameserver и search, первая из которых определяет IP-адрес сервера DNS, а вторая определяет доменное имя, которое будет добавляться при формировании клиентских запросов, не содержащих полного доменного имени:
nameserver 192.168.137.2 search linux.lab

Для того чтобы это стало возможным разрешения имен хостов через сервис DNS необходимо еще отредактировать файл /etc/nsswitch.conf, который определяет какие сервисы необходимо опрашивать для получении данных о хостах. Данный файл должен содержать следующие строки:
hosts: files,dns

В данном случае при разрешении имен хостов сначала будет просматриваться локальный файл /etc/hosts, а затем (если указанное имя не было найдено) будет выполняться запрос на DNS сервер.