Привет.
Оригинальная статья написана
Димой Макаровым несколько лет назад – и, увы, при смене домена и переезде иллюстрации от неё потерялись. Поэтому я (
Ruslan V. Karmanov) чуть актуализовал материал, добавил дополнительный и сделал новые картинки. Материал статьи работоспособен на всех серверных версиях Windows, от 2000й до Windows 10, которая Threshold (на ней и сделаны скриншоты).
Давайте представим ситуацию, когда провайдер делегирует управление доменом клиенту. Плюс, чтобы не заморачиваться, сразу же и делегирует ему же управление обратной зоной – ну, выделил клиенту диапазон IP-адресов, и не хочет постоянно менять или исправлять записи в reverse lookup зоне. Клиент ведь может легко делать это сам – достаточно просто перенаправлять reverse lookup-запросы, которые приходят к провайдеру снаружи, но относятся к клиентскому диапазону, на клиентский DNS-сервер(а). Казалось бы, всё просто – бери да делай. Вот так например:

Но вот незадача, клиент использует Windows Server, а подсеть клиента – не классовая, а, допустим, /26. Т.е. маска – VLSM-ная. В штатном интерфейсе создать такую зону не получится никак. Давайте смоделируем эту ситуацию и посмотрим, что можно сделать.
Для организации тестового полигона воспользуемся Microsoft Windows Server 2012 R2 со всеми обновлениями на январь 2015 года. Нам понадобится 2 сервера. Первый –
dc1 мы будем считать провайдером. IPv4 адрес у него будет
192.168.160.1 / 24
. Второй,
dc2, будем считать NS-сервером клиента, которому провайдер делегирует кусочек адресного пространства. IPv4 адрес
192.168.160.2 / 24
.
Будем считать, что AS провайдера содержит сеть
10.11.12.0 / 24, а клиенту необходимо делегировать обработку второй четвертинки этой сети – т.е.
10.11.12.64 / 26.
Создадим reverse lookup-зону на провайдере:

Замечу, что размер зоны некритичен – просто штатным способом в Microsoft DNS Server мы сможем создать только зону с “классовой” маской – 8, 16 или 24 бита. Остальные параметры так же некритичны – поэтому я создал её как файл, и без динамических обновлений (забегая вперёд, динамические обновления для PTR-записей, находящихся в reverse-зонах с нестандартной маской, все равно не работают). Вот что у меня вышло:

Теперь нам надо создать в этой “провайдерской” зоне запись о том, что все запросы про адреса с
10.11.12.64 по
10.11.12.127 (именно так, ведь это с точки зрения DNS будет просто диапазоном адресов, а не сетью, поэтому никакой спец.обработки адреса сети и широковещательного адреса не планируется) будут передаваться на сервер
dc2.
Через штатный механизм (MMC-оснастку DNS Server и меню New Delegation…) создаём в reverse lookup-зоне
12.11.10.in-addr.arpa новое делегирование. Его параметры будут следующими – NS-сервер, на который будут перенаправляться запросы –
dc2, а вот имя делегируемой зоны мы можем выбрать различное. Microsoft обычно предлагает что-то вида:
последний октет ID подсети–
количество бит в маске подсети
или
последний октет ID подсети/
количество бит в маске подсети
Мне нравится первый вариант, потому что всё ж слэш – он не входит в любимые всеми DNS-серверами символы, а минус – вполне.
Так как мы договорились отдавать клиенту вторую четвертинку сети
10.11.12.0 / 24, а это
10.11.12.64 / 26, то результат в нашем случае таков:

ОК, заготовка на сервере есть. Отдельно остановлюсь на простом и неприятном моменте. Суть в том, что никакой хитрой фильтрации запросов, уходящих в делегированные зоны, сервер Microsoft DNS не производит совсем. То есть то, что мы создали – это просто некая именованная дочерняя DNS-зона, самостоятельно перенаправлять в неё запросы сервер не будет. Чтобы он их перенаправлял, и именно в неё, и именно нужные, надо регистрировать CNAME-записи – столько, сколько будет делегированных адресов. Я создам одну такую запись и на её примере покажу, какой все они будут иметь вид:

Т.е. это CNAME, указывающий на то, что если кто-то запросит reverse lookup и этот запрос попадёт на наш “провайдерский” сервер, то сервер сообразит, что это – что-то внутри зоны
10.11.12.0 / 24, а раз reverse lookup, то ищем запрашиваемый
10.11.12.100 внутри имеющейся на сервере зоны
12.11.10.in-addr.arpa. Искомое будет иметь полный вариант написания вида
100.12.11.10.in-addr.arpa, заметьте – ни про какое делегирование или Хитрую Логику Отбора Запросов речи нет, данную запись просто будут искать в зоне, не найдут – отправят отказ. Так вот, чтобы её находили, нужно создать alias (CNAME, говоря по-DNS’овскому), который укажет, что если кто-то ищет запись
100.12.11.10.in-addr.arpa, то на самом деле ему надо выдать
100.64-26.12.11.10.in-addr.arpa. Как понимаете, получив такой ответ, цепочка разрешения имени продолжится, уже штатно обработав запись о существовании делегирования на зону
64-26.12.11.10.in-addr.arpa внутри зоны
12.11.10.in-addr.arpa. И вот тогда запрос уйдёт по цепочке делегирования зон дальше, на
dc2, где и будет обработан.
Такие вот костыли.
Выше я упоминал, что при reverse-lookup зонах с не-классовой маской не работает динамическая регистрация PTR. Думаю, теперь понятно, что удивительно, если бы она в таком механизме работала.
Т.е. – провайдеру надо не только прописать делегирование на сервер клиента некоей зоны со спец.названием – ему надо ещё прописать пачкой все хосты как CNAME’ы, чтобы перенаправлять нормальные запросы в эту специфичную дочернюю зону (в нашем случае
64-26, это 64 CNAME’а).
Теперь переключаемся на клиента. На нём надо будет создать зону (опять же с настройками по-умолчанию, reverse lookup, IPv4), которая будет называться так же, как и предполагает сервер – т.е. так как Microsoft даёт несколько вариантов именования, не забудьте, что во взаимодействующих серверах неплохо бы использовать одинаковые. :)
Это будет выглядеть как-то так:

Казалось бы, теперь только добавить записи. У меня получилось как-то так:

Ну а теперь тестируем. Делаем это просто – берём nslookup, зацепляемся за
dc1, указываем, что хотим PTR-запись, и спрашиваем адрес 10.11.12.100.

Работает! Хотя странно, если бы не работало – зона как зона, делегирование как делегирование, разве что всё внутри reverse lookup.
Но, в общем, в случае использования исключительно Microsoft DNS и необходимости, допустим, делегировать на разные NS-сервера управление небольшими кусочками адресного пространства, данный способ реально рабочий. А разово создать CNAME’ы и PTR’ы – не такая и проблема, можно открыть в блокноте или WordPad файл зоны и сделать это сразу массово:

Главное, точки после FQDN у PTR-записей не забудьте поставить, а то клиент, запрашивающий разрешение адреса в имя, слегка удивится результату:

Не пугайтесь, кстати, что ответов несколько – PTR-то один, поэтому софт, который запрашивает именно PTR, будет нормально воспринимать эту схему, хоть в ответе и будет видеть дополнительную CNAME.
Вкратце всё. Удачного использования!