> >

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

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

//cdn.atraining.ru/i/at300x300.jpg300300

Привет.
 
Оригинальная статья написана Димой Макаровым несколько лет назад – и, увы, при смене домена и переезде иллюстрации от неё потерялись. Поэтому я (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.
 
Вкратце всё. Удачного использования!

Автор

@
info@atraining.ruAdvanced Training
//cdn.atraining.ru/i/at300x300.jpg300300

Полезные статьи

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


  • Статья поправлена, картинки возвращены.