Основу файла обратной зоны составляют записи 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 на ряд доменов. После разделения каждый из фрагментов может быть делегирован произвольному серверу имен.

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