Једног дана сам се суочио са задатком да једном од својих клијената дам право да уређује ПТР записе /28 подмреже која му је додељена. Немам аутоматизацију за уређивање БИНД поставки споља. Стога сам одлучио да кренем другим путем – да клијенту делегирам део ПТР зоне /24 подмреже.
Чинило би се - шта би могло бити једноставније? Једноставно региструјемо подмрежу према потреби и усмеравамо је на жељени НС, као што се ради са поддоменом. Али не. Није тако једноставно (иако је у стварности генерално примитивно, али интуиција неће помоћи), зато пишем овај чланак.
Свако ко жели да то сам схвати може да прочита
Ко жели готово решење, добродошао у кат.
Да не бих одуговлачио оне који воле цопи-пасте метод, поставићу прво практични део, а затим теоријски део.
1. Пракса. Зона делегирања /28
Рецимо да имамо подмрежу 7.8.9.0/24. Морамо делегирати подмрежу 7.8.9.240/28 на днс клијент 7.8.7.8 (нс1.цлиент.домаин).
На ДНС-у провајдера морате пронаћи датотеку која описује обрнуту зону ове подмреже. Нека буде 9.8.7.ин-аддр.арпа.
Коментаришемо уносе од 240 до 255, ако их има. И на крају датотеке пишемо следеће:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240не заборавите да повећате серијску зону и урадите
rndc reloadОво завршава део провајдера. Пређимо на клијентски днс.
Прво, направимо датотеку /етц/бинд/мастер/255-240.9.8.7.ин-аддр.арпа следећи садржај:
$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";
};Б поново покрените процес везивања.
/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.Имајте на уму да се не даје само ПТР запис, већ и ЦНАМЕ. Тако би требало да буде. Ако се питате зашто, добродошли у следеће поглавље.
2. Тхеори. Како то ради.
Тешко је конфигурисати и отклонити грешке у црној кутији. Много је лакше ако разумете шта се дешава унутра.
Када делегирамо поддомен у домену домен, онда пишемо нешто овако:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Поручујемо свима који питају да нисмо одговорни за овај сајт и кажемо ко је одговоран. И сви захтеви за клијент.домен преусмери на 7.8.7.8. Приликом провере видимо следећу слику (изоставићемо шта клијент има тамо. Није битно):
# host test.client.domain
test.client.domain has address 7.8.9.241Оне. обавештени смо да постоји такав А запис и његов ИП је 7.8.9.241. Нема непотребних информација.
Како се иста ствар може урадити са подмрежом?
Јер наш ДНС сервер је регистрован у РИПЕ-у, онда када захтевате ПТР ИП адресу са наше мреже, први захтев ће и даље бити нама. Логика је иста као код домена. Али како да унесете подмрежу у датотеку зоне?
Покушајмо да га унесемо овако:
255-240 IN NS 7.8.7.8И... чудо се није догодило. Не добијамо никакво преусмеравање захтева. Ствар је у томе што бинд чак и не зна да су ови уноси у датотеци обрнуте зоне ИП адресе, а још више не разуме унос опсега. За њега је ово само нека врста симболичког поддомена. Оне. за везу неће бити разлике између "255-240"И"наш суперклијент„. А да би захтев отишао тамо где треба да иде, адреса у захтеву треба да изгледа овако: 241.255-240.9.8.7.ин-аддр.арпа. Или овако ако користимо поддомен знакова: 241.оурсуперцлиент.9.8.7.ин-аддр.арпа. Ово се разликује од уобичајеног: 241.9.8.7.ин-аддр.арпа.
Биће тешко направити такав захтев ручно. Чак и ако функционише, још увек је нејасно како то применити у стварном животу. Уосталом, на захтев 7.8.9.241 ДНС провајдера и даље одговара нама, а не клијентовом.
И ту долазе у игру ЦНАМЕ.
На страни провајдера, потребно је да направите псеудоним за све ИП адресе подмреже у формату који ће проследити захтев клијентском ДНС-у.
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.ин-аддр.арпа и иде до днс клијента.
Клијентска страна ће морати да обради такве захтеве. Сходно томе, стварамо зону 255-240.9.8.7.ин-аддр.арпа. У њему, у принципу, можемо да поставимо обрнуте уносе за било који ИП целе /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 на страни провајдера, добијамо следеће податке као одговор на захтев: ИП адреса два уноса, не један.
#> 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. И не заборавите да правилно конфигуришете АЦЛ. Зато што нема смисла узимати ПТР зону за себе и не одговарати никоме споља =).
Извор: ввв.хабр.цом
