Еднажды се изправих пред задачата да дам на един от клиентите правото да редактира PTR записките на предоставената му подсет /28. Нямам автоматизация за редактиране на настройките на BIND от разстояние. Затова реших да поема по друг път — да делегирам на клиента част от PTR зоната на подсет /24.
На пръв поглед — какво би могло да е по-просто? Просто определяме подсетта и я насочваме към необходимия NS, както се прави с поддомейн. Но не е така. Не е всичко толкова лесно (въпреки че всъщност е примитивно, но интуицията не помага), затова пиша тази статия.
Който иска да се справи сам, може да прочете
Който иска готово решение, заповядайте под статията.
За да не забавям тези, които обичат метода копи-пейст, първо ще публикувам практическата част, а след нея теоретичната.
1. Практика. Делегираме зона /28
Да предположим, че имаме подсет 7.8.9.0/24. Трябва да делегираме подсет 7.8.9.240/28 на dns клиента 7.8.7.8 (ns1.client.domain).
На провайдерския DNS трябва да намерим файла, описващ обратната зона на тази подсет. Нека бъде 9.8.7.in-addr.arpa.
Записите от 240 до 255 коментираме, ако има. И в края на файла пишем следното:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240не забравяйте да увеличите сериала на зоната и да направите
rndc reloadС това частта на провайдера приключи. Преминаваме към клиентския DNS.
Първо ще създадем файл /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";
};Б перезапускаме процеса на 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. Теория. Как работи.
Трудно е да се настройва и отстранява неизправности в черна кутия. Много по-лесно е, когато разбираш какво се случва вътре.
Когато делегираме поддомен в домейн domain, пишем нещо подобно на това:
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, при запросе PTR IP-адреса из нашей сети первичный запрос всё равно будет к нам. Логика та же, что и с доменами. Вопрос только в том, как записать подсеть в файл зоны?
Пытаемся записать вот так:
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.in-addr.arpa.
Ручное выполнение такого запроса будет затруднительно. А если и получится, то всё равно непонятно, как это применить на практике. Ведь на запрос 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.in-addr.arpa на DNS-сервере провайдера будет преобразован в 241.255-240.9.8.7.in-addr.arpa и уйдет на DNS-клиента.
Со стороны клиента нужно будет обрабатывать такие запросы. Соответственно, мы создаем зону 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
