[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive]
Свободные мысли о свободном софте
[an error occurred while processing this directive]
Logo CitForum CITForum на CD Форумы Газета Море(!) аналитической информации!
[an error occurred while processing this directive]
[an error occurred while processing this directive]
[an error occurred while processing this directive]
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive]

22.07.2019

Google
WWW CITForum.ru
[an error occurred while processing this directive]

Новости мира IT:

Архив новостей

[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive]
Пятнадцатая техническая конференция «Корпоративные базы данных-2010»
Москва, 22–23 апреля
С Новым годом!

Генеральный спонсор
Техническая конференция
Корпоративные базы данных – 2008
Москва, 24–25 апреля
При поддержке РФФИ

Спонсор
[an error occurred while processing this directive] [an error occurred while processing this directive]
На правах рекламы
2004 г

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

Материалы книги П.Б. Храмцова
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

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

[an error occurred while processing this directive]
[an error occurred while processing this directive]
[an error occurred while processing this directive] [an error occurred while processing this directive]

Планирование сроков проекта и вопросы осуществления лидерством проекта рассматриваются на сайте по управлению проектами.

[an error occurred while processing this directive]
[an error occurred while processing this directive]
[an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive]

Размещение рекламы — тел. +7 495 6608306, ICQ 232284597

[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive]

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

Последние комментарии:

Что мы знаем об iPhone 4G? (7)
16 июля, 20:25

Подписка на новости CITForum.ru

Новые публикации:

7 июля

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

  • Рекурсивные запросы в Oracle

  • Жесткий диск WD10EARS с сектором 4 КБ. Подготовка к эксплуатации в Linux.

    Обзоры журнала Computer:

    Газета:

  • Московские пробки - исследование IBM

  • От Osborne до iPad: эволюция портативных компьютеров

    19 мая

  • Прозрачный механизм удаленного обслуживания системных вызовов

  • Система моделирования Grid: реализация и возможности применения

    Газета:

    Майкл Стоунбрейкер:

  • Ошибки в системах баз данных, согласованность "в конечном счете" и теорема CAP

  • Дискуссия по поводу "NoSQL" не имеет никакого отношения к SQL

    29 апреля

  • Материалы конференции "Корпоративные Базы Данных-2010"

  • Разные облики технологии баз данных (отчет о конференции)

    14 апреля

  • MapReduce: внутри, снаружи или сбоку от параллельных СУБД?

  • Научные вызовы технологиям СУБД

    Обзоры журнала Computer:

    31 марта

  • Рационализация согласованности в "облаках": не платите за то, что вам не требуется

  • Взаимные блокировки в Oracle

  • Архитектура среды тестирования на основе моделей, построенная на базе компонентных технологий

  • Объектное представление XML-документов

    Газета:

  • Microsoft для российских разработчиков: практика с элементами фундаментальности

    10 марта

  • HadoopDB: архитектурный гибрид технологий MapReduce и СУБД для аналитических рабочих нагрузок

  • Классификация OLAP-систем вида xOLAP

  • BGP. Три внешних канала. Балансировка исходящего и входящего трафиков

    Газета:

  • Что мы знаем об iPhone 4G?

    17 февраля

  • MapReduce и параллельные СУБД: друзья или враги?

  • Объектно-ориентированное программирование в ограничениях: новый подход на основе декларативных языков моделирования данных

  • Системологический подход к декомпозиции в объектно-ориентированном анализе и проектировании программного обеспечения

    Газета:

  • Эволюция Wine

    3 февраля

  • Дом на песке

  • Реальное переосмысление "формальных методов"

  • Интервью с Найджелом Пендзом

    Газета:

  • iPad. Первый взгляд на долгожданный планшет от Apple

  • Я не верю в iPad [an error occurred while processing this directive]

    20 января

  • SQL/MapReduce: практический подход к поддержке самоописываемых, полиморфных и параллелизуемых функций, определяемых пользователями

  • Данные на лету: как технология потокового SQL помогает преодолеть кризис

    Обзоры журнала Computer:

    2 декабря

  • Сергей Кузнецов. Год эпохи перемен в технологии баз данных

    18 ноября

  • Генерация тестовых программ для подсистемы управления памятью микропроцессора

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

    Все публикации >>>


    [an error occurred while processing this directive]
  • [an error occurred while processing this directive] [an error occurred while processing this directive]
    Купить сотовые телефоны в М.Видео
    Отличные цены на сотовые телефоны. Бесплатная доставка. Заказ в интернет-магазине и по телефону (495) 644-28-51
    www.mvideo.ru [an error occurred while processing this directive]

    Регистрация доменов в зонах .ru, .com, .net. Компания Rusonyx.

    IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    [an error occurred while processing this directive]
    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 6608306, ICQ 232284597 Пресс-релизы — pr@citforum.ru
    Послать комментарий
    Информация для авторов

    Редакция раздаёт котят!

    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2009 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...
    [an error occurred while processing this directive]


    [an error occurred while processing this directive] [an error occurred while processing this directive] реклама:
    Производство и продажа серверов | забронировать гостиницу Санкт Петербурга | платный хостинг | IBM Rational. Аналитика и инструменты
    [an error occurred while processing this directive] [an error occurred while processing this directive]