Создание в Windows Server обратной DNS-зоны с нестандартной маской

Reverse lookup-зона - полезная и нужная штука, но в случае создания оной для локальной сети - проблем не возникает. Сложнее, когда провайдер делегирует часть адресного пространства.

Привет.   Оригинальная статья написана Димой Макаровым несколько лет назад – и, увы, при смене домена и переезде иллюстрации от неё потерялись. Поэтому я (Ruslan V. Karmanov) чуть актуализовал материал, добавил дополнительный и сделал новые картинки. Материал статьи работоспособен на всех серверных версиях Windows, от 2000й до Windows 10, которая Threshold (на ней и сделаны скриншоты).   Давайте представим ситуацию, когда провайдер делегирует управление доменом клиенту. Плюс, чтобы не заморачиваться, сразу же и делегирует ему же управление обратной зоной – ну, выделил клиенту диапазон IP-адресов, и не хочет постоянно менять или исправлять записи в reverse lookup зоне. Клиент ведь может легко делать это сам – достаточно просто перенаправлять reverse lookup-запросы, которые приходят к провайдеру снаружи, но относятся к клиентскому диапазону, на клиентский DNS-сервер(а). Казалось бы, всё просто – бери да делай. Вот так например: Простой пример создания reverse lookup-зоны Но вот незадача, клиент использует 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-зону на провайдере: Создаём reverse lookup зону для делегирования подмножества IP-адресов Замечу, что размер зоны некритичен – просто штатным способом в Microsoft DNS Server мы сможем создать только зону с “классовой” маской – 8, 16 или 24 бита. Остальные параметры так же некритичны – поэтому я создал её как файл, и без динамических обновлений (забегая вперёд, динамические обновления для PTR-записей, находящихся в reverse-зонах с нестандартной маской, все равно не работают). Вот что у меня вышло: Reverse lookup зона на базе DNS Server на платформе Windows Server 2012 R2   Теперь нам надо создать в этой “провайдерской” зоне запись о том, что все запросы про адреса с 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, то результат в нашем случае таков: Делегирование субдомена в reverse-lookup зоне ОК, заготовка на сервере есть. Отдельно остановлюсь на простом и неприятном моменте. Суть в том, что никакой хитрой фильтрации запросов, уходящих в делегированные зоны, сервер Microsoft DNS не производит совсем. То есть то, что мы создали – это просто некая именованная дочерняя DNS-зона, самостоятельно перенаправлять в неё запросы сервер не будет. Чтобы он их перенаправлял, и именно в неё, и именно нужные, надо регистрировать CNAME-записи – столько, сколько будет делегированных адресов. Я создам одну такую запись и на её примере покажу, какой все они будут иметь вид: reversedns7 Т.е. это 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 даёт несколько вариантов именования, не забудьте, что во взаимодействующих серверах неплохо бы использовать одинаковые. :)   Это будет выглядеть как-то так: Создание клиентской reverse lookup-зоны Казалось бы, теперь только добавить записи. У меня получилось как-то так: Добавляем PTR-записи в reverse lookup зону Ну а теперь тестируем. Делаем это просто – берём nslookup, зацепляемся за dc1, указываем, что хотим PTR-запись, и спрашиваем адрес 10.11.12.100. Тестирование работоспособности reverse lookup для зоны с нестандартной маской Работает! Хотя странно, если бы не работало – зона как зона, делегирование как делегирование, разве что всё внутри reverse lookup.   Но, в общем, в случае использования исключительно Microsoft DNS и необходимости, допустим, делегировать на разные NS-сервера управление небольшими кусочками адресного пространства, данный способ реально рабочий. А разово создать CNAME’ы и PTR’ы – не такая и проблема, можно открыть в блокноте или WordPad файл зоны и сделать это сразу массово: Вручную добавляем записи в reverse lookup зону Главное, точки после FQDN у PTR-записей не забудьте поставить, а то клиент, запрашивающий разрешение адреса в имя, слегка удивится результату: Как не надо делать reverse lookup Не пугайтесь, кстати, что ответов несколько – PTR-то один, поэтому софт, который запрашивает именно PTR, будет нормально воспринимать эту схему, хоть в ответе и будет видеть дополнительную CNAME.   Вкратце всё. Удачного использования!

Возможно, вам будет также интересно почитать другие статьи про DNS на нашей Knowledge Base

Ruslan V. Karmanov

Зайдите на сайт под своей учётной записью, чтобы видеть комментарии под техническими статьями. Если учётной записи ещё нет - зарегистрируйтесь, это бесплатно.