Файл обратной зоны весьма схож строением с файлом named.local. Оба файла преобразуют IP-адреса в имена узлов, поэтому оба содержат записи PTR. Файл 172.16.rev в нашем случае является файлом обратной зоны для домена 16.172.in-addr.arpa.
Администратор домена создает этот файл на узле crab, а все прочие узлы, нуждающиеся в хранимой информации, обращаются к серверу crab.
$TTL 86400 Отображения адресов в имена узлов. 1.12 2.12 3.12 4.12 2.1 6 IN S0A crab.wrotethebook.com. jan.crab.wrotethebook.com. ( 2001061401 ; Порядковый номер 21600 ; Обновление 1800 ; Повтор 604800 ; Устаревание 900 ) ; TTL кэша IN NS crab.wrotethebook.com. IN NS ora.wrotethebook.com. IN NS bigserver.isp.com. IN PTR crab.wrotethebook.com. IN PTR rodent.wrotethebook.com. IN PTR horseshoe.wrotethebook.com. IN PTR Jerboas.wrotethebook.com. IN PTR ora.wrotethebook.com. IN NS linuxuser.articles.wrotethebook.com. IN NS horseshoe.wrotethebook.com.
Как и в прочих файлах зон, в качестве первой RR-записи в файле обратной зоны выступает запись SOA. Символ @ в поле имени SOA-записи является ссылкой на текущую зону. Поскольку данный файл зоны не содержит директивы $ORIGIN, явным образом задающей текущую зону, текущей зоной является домен 16.172.in-addr.arpa, обозначенный оператором zone этого файла в файле named.conf:
zone "16.172.in-addr.arpa" {
type master;
file "172.16.rev";
};
Символ @ в SOA-записи позволяет оператору zone определять домен для файла зоны. Точно такая же запись SOA используется для всех зон; она всегда ссылается на верное имя домена, поскольку ссылается на домен, опреде- ленный для текущей зоны в файле named.conf. Измените имя узла (crab.wrouthebook.com.) и почтовый адрес руководителя (jan.crab.wrotethebook.com.), и записью можно будет пользоваться в любом файле зоны.
NS-записи, следующие за SOA-записью, определяют серверы имен домена. Как правило, серверы имен перечисляются сразу после SOA-записи с пустыми полями имен. Вспомните, что пустое поле имени означает, что запись находится в области действия последнего упомянутого доменного имени. Таким образом, последующие NS-записи относятся к тому же домену, что и запись SOA.
Основу файла обратной зоны составляют записи PTR, поскольку они используются для преобразования адресов в имена узлов. Записи PTR в нашем примере обеспечивают преобразование адреса в имя для узлов 12.1, 12.2, 12.3, 12.4 и 2.1 сети 172.16. Поскольку значения в полях имен PTR-записей не заканчиваются точкой, они интерпретируются относительно текущего домена. Например, значение 3.12 интерпретируется как 3.12.16.172.in-addr.arpa. В поле данных PTR-записи содержится абсолютное имя узла, что предотвращает интерпретацию имени в качестве относительного для текущего имени домена и потому оканчивается точкой. Используя информацию в этой PTR-заниси, named преобразует 3.12.16.172.in-addr.arpa в horseshoe.wrotethebook.com.
Последние две строки файла содержат дополнительные NS-записи. Как любой другой домен, inaddr.arpa может содержать поддомены. Две последние NS-записи реализуют как раз создание поддомена; они указывают узлы hor seshoe и linuxuser в качестве серверов имен для поддомена 6.16.172.in-addr.arpa. Любой запрос, касающийся информации поддомена 6.16.172.in-addr.arpa, перенаправляется к этим серверам. NS-записи, указывающие на серверы поддомена, должны быть размещены в домене более высокого уровня, прежде чем к поддомену можно будет обращаться.
Доменные имена - не то же самое, что IP-адреса, и структура этих сущностей различна. Когда IP-адрес преобразуется в доменное имя in-addr.arpa, четыре байта адреса интерпретируются в качестве четырех компонентов одного имени. В действительности IP-адрес - это 32 последовательных бита, а не четыре отдельных байта. Подсети разделяют адресное пространство IP, а маски подсетей - побитовые, то есть не ограничены рамками отдельных байтов. Ограничение поддоменов рамками байтов делает их менее гибкими, чем подсети, которые эти поддомены должны поддерживать. В нашем примере домен in-addr.arpa делегирует поддомен по границе байта, то есть каждый байт адреса считается самостоятельным «именем». Таков простейший механизм делегирования обратных поддоменов, но в отдельных случаях он может оказаться недостаточно гибким.
Приведенный ранее пример использования директивы $GENERATE позволяет сделать делегирование обратных доменов более гибким. Директива $GENERATE создала CNAME-записи, отображающие диапазон адресов домена in-addr.arpa в другой домен, с более гибкими правилами для доменных имен. Доменные имена in-addr.arpa должны состоять из четырех числовых полей, соответствующих четырем байтам IP-адреса, и строки in-addr.arpa. Мы связали эти имена с более длинными и более гибкими именами посредством директивы $GENERATE. Вот еще один (более серьезный) пример работы $GENERATE: полей, соответствующих четырем байтам IP-адреса, и строки in-addr.arpa.
$ORIGIN 30.168.192.in-addr.arpa. $GENERAT£ 0-63 $ CNAME $.1ST64 SGENERATE 63-127 $ CNAME S.2ND64 SGENERATE 128-191 $ CNAME S.3RD64 SGENERATE 192-255 $ CNAME $.4TH64
Эти четыре команды $GENERATE выполняют отображение 256 численных имен домена 30.168.192.in-addr.arpa в четыре других домена, по 64 численных имени в каждом. Когда удаленный сервер запрашивает PTR-запись для 52.30.168.192.in-addr.arpa, он получает уведомление, что каноническое имя этого узла - 52.lst64.30.168.192.in-addr.arpa, и что следует запрашивать запись-указатель этого узла у сервера домена lst64.30.168.192.in-addr.arpa. По сути дела, директива $GENERATE позволяет разделить один домен 30.168. 192.in-addr.arpa на ряд доменов. После разделения каждый из фрагментов может быть делегирован произвольному серверу имен.
Делегирование поддоменов может усложнить работу с обратными доменами. Однако в большинстве случаев файл обратной зоны проще, чем файл прямого отображения зоны.
