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

Материалы книги П.Б. Храмцова
iнфоцентр

Небольшой корпоративный домен в домене ru. Описание "прямых" зон. Описание "обратных" зон. Настройки BIND.

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

В первую очередь определимся с термином "корпоративный домен". Мы его используем здесь для обозначения домена второго уровня, т.е. все, что имеет имя типа name.ru - это корпоративный домен.

Строго говоря, это неправильно. Например, msk.ru - это географический домен, а pp.ru - это домен персональных доменов, он относится к типу доменов общего пользования (лучше было бы сказать "общего назначения"). Корпоративный домен - это домен компании.

Если бы домены государственных учреждений или высших учебных заведений размещались бы в доменах типа gov.ru и edu.ru, то можно было бы отдельно говорить как о тех, так и о других, хотя принципиального различия между процедурами поддержки таких доменов нет. Однако, наши учреждения регистрируют свои домены, как домены второго уровня, т.е. не используют домены общего пользования.

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

Мы оставляем также за пределами данного материала саму процедуру регистрации домена. Она достаточно подробно описана на сайтах независимых регистраторов, например, http://www.nic.ru/dns/service/how.html. Заметим только, что до того, как начать регистрацию домена нужно сконфигурировать и запустить все необходимые для поддержки домена серверы доменных имен. Это нужно сделать для того, чтобы при делегировании домена регистратор мог проверить их работоспособность.

Разбирать настройку сервера BIND (named) мы будем на примере домена vega.ru, который охватывает сеть класса С (194.226.43.0/24). При этом master сервер зоны мы разместим в этой же IP-сети, а поповоду slave сервера мы заключим соответствующее соглашение с администрацией сервера ns.relarn.ru.

Согласно правилам регистрации доменов второго уровня, как минимум, два сервера доменных имен авторитативных для зоны vega.ru нам необходимо иметь. При чем серверы должны подключаться к Интернет независимо.

Описание "прямой" и "обратных" зон

Сначала разберемся с файлами описания зон, которые будет поддерживать наш сервер. Они идентичны за небольшим исключением (параметры записи SOA и $TTL) для различных версий BIND.

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

$TTL 3600
@	IN	SOA	vega-gw.vega.ru. hostmaster.vega.ru. (
			101	;serial number
			86400	;refresh
			3600	;retry
			3888000	;expire
			3600	;minimum
			)
;	Name server
	IN	NS		vega-gw.vega.ru.
	IN	NS		ns.relarn.ru.
	IN	A		194.226.43.1
	IN	MX	0	vega-gw.vega.ru.
	IN	MX	10	ns.relarn.ru.
;
vega-gw	IN	A		194.226.43.1
	IN	MX	0	vega-gw
	IN	MX	10	ns.relarn.ru.
www	IN	CNAME		vega-gw
ftp	IN	CNAME		vega-gw
gopher	IN	CNAME		vega-gw
;
dos1	IN	A		194.226.43.2
dos2	IN	A		194.226.43.3
; The rest of the net should be presented below.

Символ "@" ссылается на имя зоны (vega.ru) из файла конфигурации named. Директива управления $TTL в BIND 4.x не применяется, и ее лучше для этой версии сервера не использовать. Время жизни записей описания ресурсов в кэше сервера будет определяться в BIND 4.x не директивой управления $TTL, а параметром minimum в записи SOA. В BIND 8.х и 9.х этот параметр используется для определения времени кэширования негативных ответов других серверов, поэтому для времени кэширования записей описания ресурсов по умолчанию нужно задавать директиву управления $TTL.

Из записи SOA следует, что master сервером домена является хост vega-gw.vega.ru, а администратор сервера имеет адрес hostmaster.vega.ru. Кроме того, среди серверов доменных имен, авторитативных для зоны vega.ru (записи NS), указан сервер ns.relarn.ru. Однако, адресной записи для этого доменного имени в описании зоны нет, т.к. его можно найти в зоне relarn.ru.

В BIND 4.x имело смысл прописывать адресную запись ns.relarn.ru, т.к. сервер вернул бы ее в дополнительной секции отклика. BIND 8.х и 9.х игнорируют такого сорта записи, поэтому мы в нашем примере ее не указываем. Собственно, мы поступаем в соответствие с рекомендациями RFC 1912.

Наш домен небольшой. Предполагается, что в нем совсем мало машин. Администрация сети не может себе позволить разносить сервисы по разным хостам. По этой причине почтовые ящики для vega.ru будут располагаться на сервере доменных имен. Точнее этот хост будет знать, как почту доставлять, т.к. он является почтовым шлюзом с наибольшим приоритетом для домена vega.ru. Об этом говорят записи MX, которые следуют сразу за адресной записью в начале описания зоны.

Сама адресная запись в начале описания зоны призвана назначить для имени зоны IP-адрес, чтобы такие сервисы, как World Wide Web, например, приводили на корпоративную страничку не только по www.vega.ru, но и по vega.ru.

Далее следует адресная запись, которая определяет IP-адрес для master сервера зоны. За ней определены почтовые шлюзы, которые знают, как на этот сервер доставлять почту, и синонимы сервисов (ftp,www,gopher), которые размещены на этом же хосте. Вслед за сервисами размещаются записи адресов для всех остальных хостов зоны.

Здесь следует заметить, что довольно часто вместо CNAME для описания сервисов используют адресные записи. В принципе, это позволяет найти адрес для имени сразу, но, если будет проверяться обратное соответствие, а в "обратной" зоне будет описано каноническое имя, то имена не совпадут, и сервис может отказать клиенту, который запрашивает сервис, в обслуживании.

Еще одно важное замечание касается начала описания зоны. В нашем описании у SOA записи в качестве имени зоны стоит символ "@". Он позволяет сослаться на имя зоны из файла конфигурации named.

Имя зоны в SOA всегда должно содержать какое-либо имя. Иначе все остальные записи окажутся просто бесполезными. Описание зоны можно было начать и по другому:

$TTL 3600
$ORIGIN ru.
vega	IN	SOA	vega-gw.vega.ru. hostmaster.vega.ru. (
			101	;serial number
			86400	;refresh
			3600	;retry
			3888000	;expire
			3600	;minimum
			)

Это описание также будет указывать на зону vega.ru. Слово "vega" будет расширяться до "vera.ru" по умолчанию.

Существует еще одно имя, которое стоит обсудить в контексте описания прямой зоны. Это имя localhost. В нашем случае - это localhost.vega.ru.

Рассмотрим сначала такой пример:

> host localhost.ru.
localhost.ru has address 195.68.136.26
localhost.ru mail is handled (pri=100) by mx2.elcomsoft.com
localhost.ru mail is handled (pri=200) by mx1.elcomsoft.com
>

Из примера следует, что в зоне ru есть хост с адресом localhost.ru. На самом деле это побочное явление того, что существует зона localhost:

> host -t soa localhost.ru.
localhost.ru start of authority ns1.localhost.ru noc.elcomsoft.com(
                        2001040300      ;serial (version)
                        14400   ;refresh period
                        3600    ;retry refresh this often
                        604800  ;expiration period
                        3600    ;minimum TTL
                        )
>

Если теперь посмотреть адрес localhost.nic.ru, например, то мы получим локальную петлю:

> host localhost.nic.ru.
localhost.nic.ru has address 127.0.0.1
>

Такая настройка "прямой" зоны является типовой, а точнее являлась типовой:

> host localhost.demos.ru.
localhost.demos.ru has address 127.0.0.1
> host localhost.relcom.ru.
localhost.relcom.ru has address 127.0.0.1
> host localhost.msk.ru.
localhost.msk.ru has address 127.0.0.1
> host localhost.spb.ru.
localhost.spb.ru has address 127.0.0.1
> host localhost.rambler.ru.
localhost.rambler.ru has address 127.0.0.1
> host localhost.yandex.ru.
localhost.yandex.ru has address 127.0.0.1
>

Современные провайдеры уже поступают иначе:

> host localhost.mail.ru. Host not found. > host localhost.localhost.ru. Host not found. > host localhost.lenta.ru. Host not found. > host localhost.runet.ru. Host not found. >

Приведенный пример показывает, что в соответствующих зонах хоста с именем localhost просто нет. При этом сами зоны прекрасно функционируют. Если бы запросить зоны vega.ru на предмет наличия в ней соответствия IP-адреса доменному имени localhost.vega.ru, то отклик программы host был бы таким же, как и в последнем примере.

На самом деле, это отголоски дискуссии по поводу имени localhost, которая велась в конце 90-х. В конце концов, в 1996 году вышел документ RFC 1912, в котором этот вопрос был прояснен. Более того, в RFC 2606 для localhost был зарезервирован специальный домен верхнего уровня localhost.

И все-таки, для чего и каким образом используется имя localhost при обращении к системе доменных имен? Ответ на этот вопрос является определяющим при конфигурации локального сервера доменных имен для работы с этим именем.

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

Обратиться к системе DNS можно, используя два типа имен: полностью определенные имена (FQDN) и частично определенные имена. В первом случае имя кончается символом ".", т.к. у корневого домена имени нет. Во втором случае имя точкой не кончается.

Если программа обращается к приложению на той же машине, где она сама исполняется, то в качестве имени машины может быть указано FQDN, т.е. "localhost.", или "localhost", т.е. неполное имя.

На данном этапе в дело вступает библиотека resolver. Все будет теперь определяться тем алгоритмом, который реализует эта библиотека при построении FQDN.

С полностью определенным именем все понятно. Локальный сервер начнет искать домен верхнего уровня localhost. Согласно RFC 2606 такой домен должен существовать, и состоит из одной записи, которая имени "localhost." ставит в соответствие адрес 127.0.0.1.

А вот с неполным именем такой ясности нет. Если файл resolv.conf на хосте, где исполняется прикладная программа, составлен стандартным образом, т.е. там только указан сервер доменных имен и имя домена, в который входит хост, то сначала имя localhost будет расширено именем локального домена из resolv.conf, а уж только после этого определено, как имя "localhost." (см. материал "Resolver. Типовые настройки.").

Если на хосте в resolv.conf вместо директивы domain применяется директива search, то процедура поиска может увеличиться на несколько дополнительных подстановок.

Совершенно очевидно, что хочется получить адрес 127.0.0.1 как можно быстрее, и это возможно, если имя типа localhost.domain.ru будет тоже указывать на 127.0.0.1. Быстрее будет потому, что соответствие будет найдено сразу в локальном домене, и обращение к корневым серверам не потребуется. Конечно, это возможно организовать только в том случае, когда имя типа localhost.domain.ru не используется по каком-либо другому назначению.

Таким образом, для ускорения поиска в прямую зону принято вводить запись вида:

$TTL 3600
@		IN	SOA	vega-gw.vega.ru hostmaster.vega.ru (
				101	;serial number
				86400	;refresh
				3600	;retry
				3888000	;expire
				3600	;minimum
					)
;	Name server
		IN	NS		vega-gw.vega.ru.
		IN	NS		ns.relarn.ru.
		IN	A		194.226.43.1
		IN	MX	0	vega-gw.vega.ru.
		IN	MX	10	ns.relarn.ru.
;
localhost	IN	A	127.0.0.1
;
vega-gw		IN	A	194.226.43.1

Мы представили пример с окружением, чтобы было понятно, куда обычно вставляют эту адресную запись в прямой зоне.

Вообще говоря, это нерекомендованная практика. RFC 1912 Рекомендует создать отдельно зону localhost:

$TTL 1D
localhost.	IN	SOA	vega-gw.vega.ru. hostmaster.vega.ru. (
				101		;serial number
				86400		;refresh
				3600		;retry
				3888000	;expire
				3600	;minimum
				)
localhost.	IN	NS	vega-gw.vega.ru.
localhost.	IN	A	127.0.0.1

Соответственно, эта зона должна быть прописана и в файле настройки named.

Идея с наличием этой зоны достаточно прозрачна. Сервер при обращении за адресом хоста "localhost." не будет обращаться к корневым серверам, т.к. сам знает этот адрес.

Однако, если зона localhost не будет прописана на локальном сервере, который выполняет рекурсивные запросы прикладных программ, корневой сервер должен вернуть правильный адрес, т.к. в DNS, согласно RFC 2606, эта зона должна поддерживаться, как домен верхнего уровня localhost.

Если же допустить, что по какой-либо причине корневые серверы недоступны, а зона localhost не прописана, то тогда программа все равно получит правильный адрес, т.к. в этом случае система перейдет от поиска адреса в DNS к поиску адреса в файле hosts, а там по умолчанию 127.0.0.1 закреплен за именем localhost.

Теперь обратим внимание на зону 0.0.127.in-addr.arpa. она является обратной для зоны localhost. Эта зона всегда прописывается на серверах доменных имен:

$TTL 1D
0.0.127.in-addr.arpa.	IN	SOA	vega-gw.vega.ru paul.vega.ru (
					101		;serial number
					86400		;refresh
					3600		;retry
					3888000	;expire
					3600		;minimum
					)
			IN	NS	vega-gw.vega.ru.
;	Localhost declaration
1			IN	PTR	localhost.

Назначение этой зоны заключается в ответах на запросы поиска доменного имени для IP-адреса 127.0.0.1. Согласно RFC 1912 имя это должно быть "localhost.". Довольно часто на "старых" доменах можно встретить указание на имя типа localhost.domain.ru.

В RFC 1912 определены еще две обратных зоны, которые рекомендуется иметь на сервере доменных имен, но которые обычно не настраивают. О них даже нет упоминания в широко распространенных по сети рекомендациях по настройке серверов доменных имен. Это зоны 255.in-addr.arpa и 0.in-addr.arpa.

Назначение этих зон состоит в том, чтобы избежать трансляции случайных запросов имен соответствующих IP-адресов на серверы, обслуживающие корневую зону.

Содержание файлов описания этих зон одинаковое: только SOA и NS записи:

$TTL	1D
255.in-addr.arpa.	IN	SOA	vega-gw.vega.ru paul.vega.ru (
					101		;serial number
					86400		;refresh
					3600		;retry
					3888000	;expire
					3600		;minimum
					)
			IN	NS	vega-gw.vega.ru.

Для 0.in-addr.arpa в поле имени зоны нужно "255" заменить на "0".

На самом деле, эффективность с точки зрения времени поиска адресов и имен в зонах "петли" может быть очень высокой, если установить большое время в управляющей директиве $TTL. В этом случае адрес попадает в кэш и может жить там "вечно".

На самом деле все зоны кроме зоны vega.ru должны быть настроены на любом сервере доменных имен, в том числе и на сервере, выполняющем только функции кэширующего сервера. Обычно же на кэширующем сервере ограничиваются только описанием зоны 0.0.127.in-addr.arpa (см. матерал "Настройка кэширующего сервера доменных имен. Примеры описания зон и файлов конфигурации BIND. Запуск и проверка работоспособности."), что оправдано, т.к. зона localhost должна быть прописана на корневых серверах. Кроме того, существует еще файл hosts.

Мы написали "должна быть прописана" не зря. На самом деле на момент написания этого текста она там прописана не была:

> /usr/local/bin/dig localhost.


; <<>> DiG 9.2.1 <<>> localhost.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57298
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0


;; QUESTION SECTION:
;localhost.                     IN      A


;; AUTHORITY SECTION:
.    538   IN    SOA   A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM.
 2002112700 1800 900 604800 86400


;; Query time: 2 msec
;; SERVER: 144.206.192.10#53(144.206.192.10)
;; WHEN: Wed Nov 27 22:16:56 2002
;; MSG SIZE  rcvd: 102


>

И это, не смотря на то, что документ RFC 2606, в котором декларируется организация такой зоны, вышел в 1999 году. Таким образом, зону localhost прописывать все же надо.

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

Теперь перейдем к рассмотрению файлов конфигурации named. Будем рассматривать настройку named по версиям программного обеспечения. Сначала рассмотрим BIND 4.x, а потом BIND 8.x и BIND 9.x.

Настройка BIND 4.x для поддержки небольшого корпоративного домена

Сначала мы рассмотрим случай, когда наш сервер должен будет только обслуживать запросы к зоне своей ответственности vega.ru. Это означает, что он не должен обрабатывать рекурсивные запросы.

Программа named, установленная на машине шлюзе будет иметь следующую конфигурацию, которая задается файлом named.boot:

;
;	Zone vega.ru data base files.
;
directory			/etc/namedb


primary vega.ru                 vega.ru
primary localhost               localhost
primary 127.in-addr.arpa        localhost.rev
primary 43.226.194.in-addr.arpa vega.rev
cache   .                       named.root

В этом файле директивой directory определено, что директория расположения описания файлов зоны vega.ru - /etc/namedb. Это стандартная директория для BIND. Первая директива primary определяет файл описания "прямой" зоны домена vega.ru - файл vega.ru, размещенный в директории /etc/namedb (/etc/namedb/vega.ru). Вторая директива primary определяет описание зоны localhost.

Кроме "прямых" зон описаны еще две обратных зоны 127.in-adrr.arpa и 43.226.194.in-addr.arpa. Первая определяет обратное соответствие между адресом 127.0.0.1 и именем localhost, а вторая множество обратных соответствий для сети 194.226.43.0.

Последней директивой указан файл начальной загрузки cache. Точка, символ "." в качестве первого аргумента указывает на описание корневой зоны.

Теперь нам нужно отключить рекурсию. Это делается при помощи директивы options:

;
;	Zone vega.ru data base files.
;
directory			/etc/namedb


primary vega.ru                 vega.ru
primary localhost               localhost
primary 127.in-addr.arpa        localhost.rev
primary 43.226.194.in-addr.arpa vega.rev
cache   .                       named.root
options	no-recursion

Вообще говоря, опция no-recursion обычно употребляется вместе с опцией no-fetch-glue. Это позволяет запретить серверу искать адреса серверов доменных имен при конструировании отклика с секцией дополнительных данных. Например, искать и заносить в эту секцию адресные записи для серверов доменных имен, которые посылаются в ответах (refferal) на запросы к зонам, для которых данный сервер не является авторитативным. Это позволяет избежать лишнего трафика, а также "отравления" кэша нашего сервера.

;
;	Zone vega.ru data base files.
;
directory			/etc/namedb


primary vega.ru                 vega.ru
primary localhost               localhost
primary 127.in-addr.arpa        localhost.rev
primary 43.226.194.in-addr.arpa vega.rev
cache   .                       named.root
options no-recursion no-fetch-glue fake-iquery

В примере кроме no-fetch-glue мы добавили еще одну опцию - fake-iquery. Она позволяет правильно обрабатывать инверсные запросы (не путать с запросами к обратным зонам). Инверсные запросы считаются атавизмом и не поддерживаются в современных версиях DNS серверов, но обрабатывать их нужно корректно. Если не указывать опцию обработки этих запросов, то сервер будет сообщать об ошибке, что неправильно.

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

Следует ограничить число хостов, которым дозволено копировать зону:

;
;	Zone vega.ru data base files.
;
directory			/etc/namedb


primary vega.ru                 vega.ru
primary localhost               localhost
primary 127.in-addr.arpa        localhost.rev
primary 43.226.194.in-addr.arpa vega.rev
xfrnets	194.226.65.0
cache   .                       named.root
options no-recursion no-fetch-glue fake-iquery

В данном случае мы определили возможность копирования зоны только для хостов из сети, где расположен наш slave сервер. В принципе, можно определить хост точно. Для этого следует применить маску:

xfrnets		194.226.65.3&255.255.255.255

Сразу видно, что синтаксис "старый". Сейчас написали бы 194.226.65.3/32.

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

В большинстве случаев применения BIND эти функции совмещают. Севрер является авторитативным сервером корпоративного домена и одновременно выполняет функции кэширующего сервера для хостов корпоративной сети.

Очевидным изменением файла настройки named в этом случае будет отказ от запрета на рекурсию:

;
;	Zone vega.ru data base files.
;
directory			/etc/namedb


primary vega.ru                 vega.ru
primary localhost               localhost
primary 127.in-addr.arpa        localhost.rev
primary 43.226.194.in-addr.arpa vega.rev
xfrnets	194.226.65.0
cache   .                       named.root
forwarders	194.226.65.3
options	fake-iquery

Кроме отказа от рекурсии в в этом файле конфигурации появилась еще одна директива - forwarders. Она инструктирует сервер в том смысле, чтобы он отправлял запросы, на которые не может ответить сам, на сервер 144.226.65.3.

Таким образом, наш сервер не только обрабатывает рекурсивные запросы, но и сам их порождает, пытаясь воспользоваться "знаниями" другого сервера доменных имен. Естественно, что на том сервере нам должны разрешить себя вести подобным образом.

Теперь рассмотрим как настраивается сервер версий BIND 8.x и 9.x для выполнения точно таких же функций.

Настройка BIND 8.x и BIND 9.x для поддержки небольшого корпоративного домена

Во-первых, здесь мы будем иметь дело с файлом named.conf, который располагается по умолчанию либо в каталоге /etc (BIND 9.x), либо /etc/namedb (BIND 8.x). Во-вторых, формат директив этого файла конфигурации совершенно иной, чем в BIND 4.х.

Сначала рассмотрим сервер, который не поддерживает рекурсивных запросов, но обслуживает запросы к зоне своей ответственности:

options {
	directory	"/etc/namedb";
	allow-query	{any;};
	recursion no;
	fake-iquery yes;
	fetch-glue no;
	use-id-pool yes;
};
//Root server hints
zone "." { type hint; file "named.root"; };
// Forward Loopback
zone "localhost" {
	type master;
	file "localhost";
};
// Reverse Loopback
zone "0.0.127.in-addr.arpa" {
	type master;
	file "localhosr.rev";
};
// Corporative domain
zone "vega.ru" {
	type master;
	file "vega.ru";
	allow-transfer { 194.226.65.3; };
};
// Reverse corporative domain
zone "43.226.194.in-addr.arpa" {
	type master;
	file "43.226.194.in-addr.arpa";
	allow-transfer { 194.226.65.3; };
};

Директива options задает опции, значение которых распространяется на все зоны, поддерживаемые данным сервером. Опция directory определяет место расположения файлов описания зон. Опция allow-query разрешает обслуживать запросы от всех клиентов Интернет. Такое значение в данном случае позволяет отвечать на запросы к зонам ответственности сервера. Опция recursion отменяет обслуживание любых рекурсивных запросов. Далее следуют опции имитации обслуживания инверсных запросов (fake-iquery), отмены поиска дополнительной информации для ответов рефералов (referrals, опция fetch-glue, в BIND 9.х не нужна, т.к. реализована по умолчанию), и опция противодействия спуфингу (use-id-pool в BIND 9.x не нужна, т.к. реализована по умолчанию).

Далее идет описание корневой зоны. Тип зоны указан как hint (буквально "подсказка"). Зона содержит информацию об именах и адресах серверов,обслуживающих корневую зону DNS.

За описанием корневой зоны следуют описания зон "петли" (localhost и 0.0.127.in-addr.arpa). Сервер определен для этих зон как master зоны. Ни каких дополнительных опций в описании конфигурации этих зон нет.

За ними следует описание настроек named для управления корпоративной зоной (vega.ru). Здесь мы ограничили число хостов, которые могут копировать зону slave сервером зоны. Если необходимо, то здесь можно расположить и другие хосты, которым будет разрешено копировать зону из соображений разгрузки master сервера, например.

Последней указаны настройки named для работы с "обратной" корпоративной зоной. Эти настройки ничем не отличаются от настроек "прямой" зоны.

Теперь мы расширим функциональность нашего сервера и разрешим ему обслуживать рекурсивные запросы. Но только пусть эти запросы будут исходить из корпоративной сети. Если мы просто разрешим рекурсию в директиве options:

options {
	directory	"/etc/namedb";
	allow-query	{any;};
	recursion yes;
	fake-iquery yes;
	fetch-glue no;
	use-id-pool yes;
};

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

Для того, чтобы разрешить рекурсию только "своим" хостам, следует воспользоваться директивой allow-recursion:

options {
	directory	"/etc/namedb";
	allow-query	{any;};
	recursion no;
	fake-iquery yes;
	fetch-glue no;
	use-id-pool yes;
	allow-reqursion { 194.226.43/24;};
};

В данном случае рекурсия разрешена только хостам из сети 194.226.43.0. Для всех остальных она запрещена опцией recursion.

Вообще говоря, из всех зон, которыми управляет наш сервер, для всего остального мира интересны только корпоративные зоны: прямая зона vega.ru и "обратная" зона 43.226.194.in-addr.arpa. Поэтому, если строго следовать назначению нашего сервера - обслуживать по максимуму корпоративную сеть и по необходимому минимуму весь остальной мир, мы должны несколько изменить настройки.

В первую очередь разделим весь мир на "своих" и "чужих". Это делается при помощи директивы acl (access control list):

acl "vega-net" {
	194.226.43/24;
};
acl "vega-friend" {
	194.226.65/24;
};
options {
	directory	"/etc/namedb";
	allow-query	{vega-net;};
	recursion no;
	fake-iquery yes;
	fetch-glue no;
	use-id-pool yes;
};

Два списка контроля доступа содержат пулы адресов корпоративной сети и сети slave сервера. Первый список мы применяем в директиве options. Разрешаем серверу обрабатывать запросы только от "наших" хостов (allow-query).

Опции директивы options распространяются на все зоны нашего сервера, поэтому, если мы хотим какую-либо из них обслуживать иначе, то должны в ее конфигурацию ввести изменения. Иначе мы обслуживаем зоны vega.ru и 43.226.194.in-addr.arpa:

// Corporative domain
zone "vega.ru" {
	type master;
	file "vega.ru";
	allow-query {any; };
	allow-transfer { vega-friend; };
};
// Reverse corporative domain
zone "43.226.194.in-addr.arpa" {
	type master;
	file "43.226.194.in-addr.arpa";
	allow-query {any; };
	allow-transfer { vega-friend; };
};

В описании этих зон мы применили список доступа vega-friend и только для этих зон разрешили обслуживание любых нерекурсивных запросов.

В принципе, можно было обойтись и без списков доступа, но в данном случае мы просто преследовали цель продемонстрировать способ их применения. Корпоративная сеть может быть развернута не на одной сети класса C, для дружественных сетей можно разрешить не только копирование зоны, но и удаленное ее (зоны) обновление. В этом случае списки увеличатся в объеме, и их копирование в разные части файла конфигурации может привести к нежелательным ошибкам.

Кроме того, при изменениях корпоративной сети и дружественных сетей вносить изменения придется только в списки управления доступом, а не в разбросанные по всему файлу описания. Использование списков управления (контроля) доступа - это более правильный стиль.

В BIND 9.х есть еще один механизм для определения различного поведения сервера при обслуживании запросов - "views". В материалах CERT для управления рекурсией приведена, например, такая конфигурация:

// Corporative domain
view "internalview" {
match-clients { internal; };
	recursion yes;
};
// Internet
view "externalview" {
match-clients { any; };
	recursion no;
};

Слово "internal" - это имя списка доступа, а слово "any" обозначение любого хоста Интернет.

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

Рекомендованная литература:

1. Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.
2. P. Mockapetris. RFC-1034. DOMAIN NAMES - CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
3. P. Mockapetris. RFC-1035. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
4. D. Eastlake, A. Pantiz. RFC 2606. Reserved Top Level DNS Names. 1999.(http://www.ietf.org/rfc/rfc2606.txt)
5. D. Barr. RFC 1912. Common DNS Operational and Configuration Errors. 1996. (http://www.ietf.org/rfc/rfc1912.txt?number=1912)
6. BIND 9 Administrator Reference Manual. (http://www.nominum.com/resources/documentation/Bv9ARM.pdf)
7. BIND Configuration File Guide (8.3.4) (ftp://ftp.isc.org/isc/bind/src/8.3.4/bind-doc.tar.gz)

Полезные ссылки:

1. http://www.isc.org/products/BIND/bind8.html - страничка BIND 8.
2. http://www.isc.org/products/BIND/bind4.html - страничка BIND 4.9.11
3. http://www.acmebw.com/resources/papers/securing.pdf - Securing an Internet Name Server. CERT Coordination Center. Carnegie Mellon University. 2002. Довольно подробный и обстоятельный обзор возможных проблем безопасности серверов доменных имен с рекомендациями по их (серверов) конфигурации.
4. http://www.ietf.org/proceedings/02jul/I-D/draft-ietf-dnsop-dontpublish-unreachable-03.txt - хотя на документы этого типа и не принято ссылаться, т.к. они имеют силу только в течение полугода, но в этом файле содержится вразумительное описание мотивации создания зоны localhost и адресных записей в зоне корпоративного домена типа localhost.domain.ru

Назад Оглавление Вперед