Устала аднойчы перада мной задача, аддаць аднаму з кліентаў права на рэдагаванне 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.у-addr.arpa.
Запісы ад 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.
І ў наз.канф дапісваем апісанне нашага новага файла:
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, то пры запыце 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.у-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.у-addr.arpa на днс-серверы правайдэра будзе пераўтвораны ў 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