DNS - ДОМЕННАЯ СЛУЖБА ИМЕН
Часть 2. Конфигурирование сервера DNS
Дополнительные возможности BIND

Этот пункт основан на BIND версии 8.

Уведомление об изменении базы данных

Обычно для того, чтобы выяснить, не изменились ли данные на первичном сервере, вторичный сервер опрашивает первичный через определенные промежутки времени (см. выше запись типа SOA).

В BIND существует возможность уведомить вторичный сервер о том, что данные на первичном сервере изменились. Для этого первичный сервер посылает вторичному сообщение-запрос специального типа "NOTIFY", получение которого подтверждается вторичным сервером также посылкой специального сообщения. После этого вторичный сервер производит обычную операцию: запрашивает с первичного сервера запись SOA, проверяет серийный номер и, если он увеличился, производит передачу данных зоны. Заметим, что само по себе сообщение "NOTIFY" не является командой на передачу данных, а служит лишь сигналом произвести досрочную проверку того, надо ли обновлять данные.

В BIND-8 механизм уведомления по умолчанию включен. Для его выключения (для всех зон, обслуживаемых сервером) подается директива в разделе options:

options {
				notify no;
};

zone "vvsu.ru" {
			type master;
			file "vvsu.hosts";
			notify no;
};

Динамические изменения в базе данных

BIND-8 поддерживает механизм динамического редактирования базы данных зоны (dynamic update, RFC 2136) хостами, авторизованными для выполнения этой операции. Это значит, что по запросу от такого хоста записи в базе данных DNS могут создаваться и удаляться "на лету" - естественно, сообщения update должны отправляться серверу, отвечающему (authoritative) за данную зону (при этом неважно, первичный этот сервер или вторичный; вторичные сервера перенаправят сообщение первичному).

Механизм динамического редактирования базы данных используется, в основном, серверами DHCP. После выдачи динамического IP-адреса DHCP-сервер должен зарегистрировать его в DNS. Функции, формирующие сообщения update, встроены внутрь ПО DHCP-сервера.

Программа nsupdate (обычно /usr/sbin/nsupdate) позволяет выполнить динамическое редактирование вручную. Ниже приводится списко команд nsupdate, дающий такде представление о возможностях механизма динамического редактирования.

prereq yxrrset доменное_имя тип_записи [данные]

последующие команды update будут выполнены, если существует запись указанного типа для указанного доменного имени [с указанными данными, если они есть]

prereq nxrrset доменное_имя тип_записи [данные]

последующие команды update будут выполнены, если НЕ существует запись указанного типа для указанного доменного имени [с указанными данными, если они есть]

prereq yxdomain доменное_имя

последующие команды update будут выполнены, если указанное доменное имя существует

prereq nxdomain доменное_имя

последующие команды update будут выполнены, если указанное доменное имя НЕ существует

update delete доменное_имя [тип_записи] [данные]

если указано только доменное имя, удаляет всю информацию об этом имени; если указан еще и тип записи, удаляет все записи указанного типа для данного доменного имени; если указаны все 3 параметра удаляет соответствующую запись

update add доменное_имя TTL тип_записи данные

добаляет указанную запись в базу данных зоны; обратите внимание, что параметр TTL (время жизни) обязателен

Пример:

%nsupdate
> prereq yxrrset specialmail.vvsu.ru. mx
> update delete specialmail.vvsu.ru. mx
> update add  specialmail.vvsu.ru. 500 mx 10 maria.vvsu.ru.
> update add  specialmail.vvsu.ru. 500 mx 50 wildcat.vvsu.ru.
>

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

zone "vvsu.ru" {
          type master;
          file "vvsu.hosts";
          allow-update { 212.16.195.99; 212.16.195.100; };
};

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

Форвардеры

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

Для организации работы DNS по схеме с форвардерами требуется указать список форвардеров в разделе options конфигурационного файла (естественно, на серверах, которые форвардерами НЕ являются); для самих форвардеров никаких модификаций не требуется.

options {
          forwarders {212.16.195.98; 212.16.195.4; };
};

Если ни один форвардер не отвечает, сервер произведет обычную обработку запроса. Такое поведение можно запретить - т.е. запретить посылать запросы любым другим серверам, кроме форвардеров:

options {
          forwarders {212.16.195.98; 212.16.195.4; };
		  forward-only;
};

Вопросы безопасности

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

Список хостов, запросы от которых обслуживаются сервером, устанавливается в конфигурационном файле с помощью директивы allow-query. Эта директива может быть помещена в раздел той или иной зоны, тогда ее действие распространяется на запросы данных этой зоны. Если директива allow-query помещена в раздел options, ее действие распространяется на все запросы, кроме тех зон, что имеют собственную директиву allow-query.

options {
          allow-query {212.16.195.0/24; 212.16.197.0/24; };
};
zone "up.vvsu.ru" {
          type slave;
          file "vvsu.up.hosts";
          masters { 212.16.196.130; };
          allow-query {212.15.196.128/25 ; };
};

Список хостов, на которые разрешено пересылать содержимое баз данных зон, формируется аналогично с помощью директивы allow-transfer. Естественно, что в этот список должны входить вторичные DNS-серверы. (Примечание. Команда nslookup ls имя_домена также вызывает пересылку базы данных зоны.)

options {
          allow-transfer {212.16.195.98; }; # без маски - значит, адрес хоста
};
zone "up.vvsu.ru" {
          type master;
          file "vvsu.up.hosts";
          allow-transfer {212.15.196.128/25 ; };
};

Замечание. Вторичные серверы DNS могут также осуществлять передачу другому хосту базы данных запрошенной зоны. (Например, вторичный сервер может выступать в качестве источника данных для других вторичных серверов.) Поэтому для обеспечения полной секретности при передаче баз данных зон требуется на вторичных серверах, которые никому не должны передавать базу данных, указать allow-transer { none; }:

zone "up.vvsu.ru" {
          type slave;
          file "vvsu.up.hosts";
          masters { 212.16.196.130; };
          allow-transfer {none ; };
};

Запрет отправлять запросы DNS-серверу 10.0.0.2:

server 10.0.0.2 {
     bogus yes;
};