"Прямая" и "обратная" зоны для домена, определенного на двух адресных пулах типа х.х.х.х/24 или организация обратных зон на "суперсетях" класса C

2004 г

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

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

"Прямая" и "обратная" зоны для домена, определенного на двух адресных пулах типа х.х.х.х/24 или организация обратных зон на "суперсетях" класса C

В данном материале мы рассмотрим конфигурацию программы named при организации сервера домена, чьи хосты распределены по двум физическим IP-сетям класса C (в нотации CIDR x.x.x.x/24). Основное внимание будет уделено "обратным" зонам, т.к. "прямая" зона в этом случае не имеет существенных отличий от зоны, рассмотренной при описании небольшого корпоративного домена.

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

Предположим, что адресные пулы, которые выделены организации и ее подразделениям, представляют из себя не единое адресное пространство, а нарезку из нескольких блоков адресов. При этом эти блоки нарезаны таким образом, что адреса оказываются из разных областей, если рассматривать адресное пространство с точки зрения нотации CIDR х.х.х.х/24. Например:

192.168.0.0/24 и 192.168.10.0/24

С точки зрения описания соответствия между доменным именем и IP-адресом в "прямой" зоне здесь проблем нет:

$ORIGIN ru.
test	IN	SOA	ns.test.ru. hostmaster.test.ru (
233 3600 300 9999999 3600 )
;
IN	NS	ns.test.ru.
IN	NS	ns.privider.ru.
IN	A	192.168.10.1
IN	MX	10	mail.test.ru.
IN	MX	20	mail.provider.ru.
;
ns	IN	A	192.168.10.1
mail	IN	A	192.168.0.1
www	IN	A	192.168.10.2
ftp	IN	A	192.168.0.2

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

Конечно, есть адреса, которые нельзя мешать. Например, нельзя мешать маршрутизируемые и немаршрутизируемые адреса. Собственно, в примере мы используем именно последние (подробнее о немаршрутизируемых адресах см. RFC 1918).

Если запросить из Интернет IP-адрес по доменному имени и в ответ получить адрес из немаршрутизируемого пула, то не понятно, что с ним делать. Даже если вы сами находитесь внутри немаршрутизируемой сети полученный снаружи адрес из этой же сети, скорее всего, не является искомым адресом.

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

И так, в "прямой" зоне мы можем "мешать" адреса, но вот как поддерживать обратные соответствия? Ведь в случае "обратных" зон мы имеем дело тоже с доменными именами, хотя они и образованы инверсией IP-адресов. Разделителем в иерархии именования доменов является символ ".", следовательно, границы байтов в адресе будут соответствовать границам вложенности доменов.

Выход простой - создать две обратных зоны 0.168.192.in-addr.arpa и 10.168.192.in-addr.arpa. Выглядеть это будет примерно так:

$TTL 3600
$ORIGIN 168.192.in-addr.arpa.
10	IN	SOA	ns.test.ru. hostmaster.test.ru. (
75 3600 300 9999999 3600 )
IN	NS	ns.test.ru.
IN	NS	ns.privider.ru.
1	IN	PTR	ns.test.ru.
2	IN	PTR	www.test.ru.

И для 0.168.192.in-addr.arpa. соответственно:

$TTL 3600
$ORIGIN 168.192.in-addr.arpa.
0	IN	SOA	ns.test.ru. hostmaster.test.ru. (
75 3600 300 9999999 3600 )
IN	NS	ns.test.ru.
IN	NS	ns.privider.ru.
1	IN	PTR	ns.test.ru.
2	IN	PTR	www.test.ru.

На master сервере должно быть объявлено две "обратных" зоны. В BIND 4.x в файле named.boot это будет выглядеть примерно так:

directory			/etc/namedb


primary		test.ru			test.ru
primary localhost               localhost
primary 127.in-addr.arpa        localhost.rev
primary 10.168.192.in-addr.arpa	10.168.192.in-addr.arpa
primary	0.168.192.in-addr.arpa	0.168.192.in-addr.arpa
xfrnets		192.168.20.1&255.255.255.255
cache   .                       named.root
options no-recursion no-fetch-glue fake-iquery

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

Здесь стоит только пояснить, что в данном случае адрес 192.168.20.1 - это адрес slave сервера, которому разрешено копировать зону. Назначение остальных директив управления подробно рассмотрено в "Небольшой корпоративный домен в домене ru. Описание "прямых" зон. Описание "обратных" зон. Настройки BIND.".

Что же касается файла named.conf версий BIND 8.х и 9.х, то его содержание будет выглядеть примерно так:

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 "test.ru" {
	type master;
	file "test.ru";
	allow-transfer { 192.168.20.1; };
};
// Reverse corporative domain
zone "0.168.192.in-addr.arpa" {
	type master;
	file "0.168.192.in-addr.arpa";
	allow-transfer { 192.168.20.1; };
};
// Reverse corporative domain
zone "10.168.192.in-addr.arpa" {
	type master;
	file "10.168.192.in-addr.arpa";
	allow-transfer { 192.168.20.1; };
};

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

Здесь следует отметить, что несколько обратных зон появляются, например, и для сетей типа x.x.x.x/23. Вся штука в том, что, адресный пул, например, 192.168.0.0.23, объединяет два смежных блока 192.168.0.0/24 и 192.168.1.0/24. Соответствующих обратных зон, следовательно, будет две: 0.168.192.in-addr.arpa и 1.168.192.in-addr.arpa. Объединить их стандартным образом можно только на уровне 168.192.in-addr.arpa, но никак не ниже.

Из выше сказанного, следует, что владелец зоны 168.192.in-addr.arpa должен делегировать ответственность за управления двумя обратными зонами своему клиенту, если не хочет управлять ими самостоятельно.

Аналогичные замечания справедливы и для адресных пулов x.x.x.x/16 и для адресных пулов x.x.x.x.8, т.е. сетей классов B и A соответственно. Пространство доменных имен "обратных" зон построено с учетом старой классификации адресов, в то время, когда нотация CIDR широко еще не использовалась.

В документе RFC 1519 подробно разбирается отображение адресного пространства CIDR на "суперсети" сетей класса C, т.е. пулов адресов, которые составлены из подсетей сетей класса B и A. Провайдер в этом случае должен делегировать соответствующие обратные зоны клиентам, а те обеспечить их поддержку способом, похожим на случай 192.168.0.0/23, рассмотренный выше.

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

Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.
P. Mockapetris. RFC-1034. DOMAIN NAMES - CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
P. Mockapetris. RFC-1035. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
BIND 9 Administrator Reference Manual. (http://www.nominum.com/resources/documentation/Bv9ARM.pdf)
BIND Configuration File Guide (8.3.4) (ftp://ftp.isc.org/isc/bind/src/8.3.4/bind-doc.tar.gz)
Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot. RFC 1918. Address Allocation for Private Internets. 1996. (http://www.ietf.org/rfc/rfc1918.txt?number=1918)
Y. Rekhter, T. Li. RFC 1518. An Architecture for IP Address Allocation with CIDR. 1993. (http://www.ietf.org/rfc/rfc1518.txt?number=1518)
V. Fuller, T. Li, J. Yu, K. Varadhan. RFC 1519. Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. 1993. (http://www.ietf.org/rfc/rfc1519.txt?number=1519)

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

http://www.isc.org/products/BIND/bind8.html - страничка BIND 8.
http://www.isc.org/products/BIND/bind4.html - страничка BIND 4.9.11
http://www.acmebw.com/resources/papers/securing.pdf - Securing an Internet Name Server. CERT Coordination Center. Carnegie Mellon University. 2002. Довольно подробный и обстоятельный обзор возможных проблем безопасности серверов доменных имен с рекомендациями по их (серверов) конфигурации.

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