Постало одного разу переді мною завдання, віддати одному з клієнтів право на редагування PTR-записів відданої йому підмережі /28. Автоматизації для редагування налаштувань BIND ззовні я не маю. Тому я вирішив піти іншим шляхом – делегувати клієнтові шматок PTR-зони підмережі /24.
Здавалося б, що може бути простіше? Просто потрібним чином прописуємо підсітку і направляємо на потрібний NS як це робиться з піддоменом. Але немає. Не так все просто (хоча насправді взагалі примітивно, але інтуїція не допоможе), тому я й пишу цю статтю.
Хто захоче сам розібратися, той може почитати
Хто хоче готового рішення, ласкаво просимо під кат.
Щоб не затримувати тих, хто любить метод копіпасти, спочатку я розташую практичну частину, а потім теоретичну.
1. Практика. Делегуємо зону /28
Допустимо у нас є підсіти 7.8.9.0/24. Нам треба делегувати підсіти 7.8.9.240/28 на днс-клієнта 7.8.7.8 (ns1.client.domain).
На провайдерському дні треба знайти файл, що описує зворотну зону цієї підмережі. Нехай буде 9.8.7.в-аддр.арпа.
Записи від 240 до 255 коментуємо, якщо є. І на кінець файлу пишемо наступне:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240не забуваємо збільшити serial зони та робимо
rndc reloadНа цьому провайдерську частину закінчено. Переходимо до клієнтського дня.
Для початку створимо файл /etc/bind/master/255-240.9.8.7.in-addr.arpa такого змісту:
$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@ 1D IN SOA ns1.client.domain. root.client.domain. (
2008152607 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
@ IN NS ns1.client.domain.
@ IN NS ns2.client.domain.
241 IN PTR test.client.domain.
242 IN PTR test2.client.domain.
245 IN PTR test5.client.domain.
І в named.conf дописуємо опис нашого нового файлу:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B перезапускаємо процес bind.
/etc/init.d/named restartВсі. Тепер можна перевіряти.
#> host 7.8.9.245
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.Зверніть увагу, що віддається не тільки PTR-запис і CNAME. Так і має бути. Якщо цікаво чому, то ласкаво просимо до наступного розділу.
2. Теорія. Як це працює.
Складно налаштовувати та налагоджувати чорну скриньку. Набагато простіше, якщо розумієш, що відбувається всередині.
Коли ми делегуємо піддомен у домені домен, то пишемо щось на кшталт цього:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Ми говоримо всім, хто запитує, що за цю ділянку не відповідаємо і говоримо хто відповідає. І всі запити на client.domain редиректуються на 7.8.7.8. При перевірці ми бачимо наступну картину (опустимо, що там у клієнта. це неважливо):
# host test.client.domain
test.client.domain has address 7.8.9.241Тобто. нам повідомили, що є такий А запис та його ip 7.8.9.241. Жодної зайвої інформації.
А як те саме можна зробити з підмережею?
Т.к. наш DNS-сервер прописаний в RIPE, то при запиті IP-адреси PTR з нашої мережі, все одно перший запит буде до нас. Логіка та сама що й з доменами. Ось тільки як вписати підсіти у файл зони?
Пробуємо вписати ось так:
255-240 IN NS 7.8.7.8І… дива не сталося. Ми не отримуємо жодного перенаправлення запиту. Вся справа в тому, що bind взагалі не в курсі, що ось ці записи у файлі зворотної зони це ip-адреси і тим більше не розуміє запис діапазону. Для нього це просто символічний піддомен. Тобто. для bind не буде різниці між «255-240» та «oursuperclient«. І запит, щоб запит пішов куди треба, адреса в запиті має виглядати так: 241.255-240.9.8.7.in-addr.arpa. Або ось так, якщо ми використовуємо символьний піддомен: 241.oursuperclient.9.8.7.in-addr.arpa. Це відрізняється від звичайного: 241.9.8.7.в-аддр.арпа.
Руками такий запит зробити проблематично. А якщо і вийде, то все одно незрозуміло, як це застосувати в реальному житті. Адже на запит 7.8.9.241 нам, як і раніше, відповідає провайдерський DNS, а не клієнтський.
А ось тут у гру вступають CNAME.
На стороні провайдера потрібно зробити для всіх ip-адрес підмережі аліас у формат, який переправить запит клієнтському DNS.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
и т.д.
Це для працьовитих =).
А для лінивих більше підійде конструкція нижче:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Тепер запит інформації на адресу 7.8.9.241 з 241.9.8.7.в-аддр.арпа на днс-сервері провайдера буде перетворено на 241.255-240.9.8.7.in-addr.arpa і піде на днс-клієнта.
З боку клієнта потрібно буде опрацьовувати такі запити. Відповідно ми створюємо зону 255-240.9.8.7.in-addr.arpa. В ній ми в принципі можемо розміщувати зворотні записи для будь-яких ip всієї підмережі /24, але запитувати у нас будуть тільки про ті, які провайдер до нас переадресує, так що побалуватись не вийде =).
Для ілюстрації ще раз наведу приклад змісту файлу зворотної зони клієнта:
$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@ 1D IN SOA ns1.client.domain. root.client.domain. (
2008152607 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
@ IN NS ns1.client.domain.
@ IN NS ns2.client.domain.
241 IN PTR test.client.domain.
242 IN PTR test2.client.domain.
245 IN PTR test5.client.domain.
Ось через те, що ми з боку провайдера використовуємо CNAME, то й отримуємо у відповідь на запит даних по IP-адресі два записи, а не один.
#> host 7.8.9.245
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.
І не забувайте коректно налаштовувати ACL. Тому що безглуздо забирати собі PTR-зону і не відповідати нікому із зовнішності =).
Джерело: habr.com