Описание "прямой" и "обратных" зон
Сначала разберемся с файлами описания зон, которые будет поддерживать наш сервер. Они идентичны за небольшим исключением (параметры записи 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
И это, не смотря на то, что документ RFC 2606, в котором декларируется организация такой зоны, вышел в 1999 году. Таким образом, зону localhost прописывать все же надо.
На самом деле мы не описали еще одну зону, которую необходимо иметь для запуска named - зону описания корневых серверов. Она описывается обычно в файле named.root, который совпадает в точности с аналогичным файлом, описанном в материале "Настройка кэширующего сервера доменных имен. Примеры описания зон и файлов конфигурации BIND. Запуск и проверка работоспособности.".
Теперь перейдем к рассмотрению файлов конфигурации named. Будем рассматривать настройку named по версиям программного обеспечения. Сначала рассмотрим BIND 4.x, а потом BIND 8.x и BIND 9.x.
