Egy alkalommal azzal a feladattal néztem szembe, hogy egy ügyfélnek átadjam a jogot a PTR-rekordok szerkesztésére a neki odaítélt /28-as alhálózatban. Nincs automatizálásom a BIND beállításainak külső szerkesztésére, ezért egy másik megoldás mellett döntöttem — delegálni az ügyfélnek a /24-es alhálózat PTR-zónájának egy részét.
Azt gondolnánk, hogy mi lehet ennél egyszerűbb? Csak beírjuk az alhálót a megfelelő módon, és az szükséges NS-re irányítunk, ahogyan azt a szubdomain esetében tesszük. De nem, nem olyan egyszerű (bár valójában elég primitív, de az intuíció nem segít), ezért írom ezt a cikket.
Aki szeretné magától megérteni, olvashatja.
Aki kész megoldást szeretne, az üdvözölve van az alábbiak alatt.
Annak érdekében, hogy ne tartsam fel azokat, akik szeretik a másolás-beillesztés módszert, először közzéteszem a praktikus részt, és utána a elméletit.
1. Gyakorlat. Delegáljuk a /28-as zónát.
Tegyük fel, hogy van egy alhálózatunk. 7.8.9.0/24. Az alhálózatot kell delegálnunk 7.8.9.240/28 a dns-ügyfélnek 7.8.7.8 (ns1.client.domain).
A szolgáltató DNS-nél meg kell keresni a fájlt, ami az alhálózat fordított zónáját írja le. Legyen ez 9.8.7.in-addr.arpa.
A 240 és 255 közötti rekordokat kommenteljük ki, ha vannak. A fájl végére az alábbiakat írjuk:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240ne feledkezzünk meg a zóna sorozatszámának növeléséről, és csináljuk
rndc reloadEzzel a szolgáltató rész véget ért. Áttérünk az ügyféldns-re.
Először létre kell hoznunk a fájlt /etc/bind/master/255-240.9.8.7.in-addr.arpa a következő tartalommal:
$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@ 1D IN SOA ns1.client.domain. root.client.domain. (
2008152607 ; sorozatszám
3H ; frissítés
15M ; újrapróbálkozás
1W ; lejárati idő
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.
És a named.conf be kell írnunk a új fájlunk leírását:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};A B újraindítja a bind folyamatot.
/etc/init.d/named restartKész. Most már ellenőrizhetjük.
#> 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.Figyeljen arra, hogy nemcsak a PTR-rekord, hanem a CNAME is visszaadásra kerül. Így is kell lennie. Ha érdekli, hogy miért, akkor üdvözlet a következő fejezetben.
2. Elmélet. Hogyan működik ez.
Nehéz beállítani és hibakeresni egy fekete dobozt. Sokkal egyszerűbb, ha tudjuk, mi történik belül.
Amikor delegáljuk a szubdomaint egy domaine belül domain, akkor valami ilyesmit írunk:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Minden érdeklődőnek azt mondjuk, hogy ezért a részlegért nem vagyunk felelősek, és megmondjuk, ki felelős. Az összes kérés a client.domain 7.8.7.8-ra irányul. Ellenőrzéskor a következő képet látjuk (nehogy figyelmen kívül hagyjuk, mi van az ügyfélnél, ez lényegtelen):
# host test.client.domain
test.client.domain has address 7.8.9.241Tehát értesítették, hogy van egy A rekord, és annak az IP címe 7.8.9.241. Semmi felesleges információ.
De hogyan lehet ugyanezt megtenni egy alhálózattal?
Mivel a DNS-szerverünk a RIPE-ban van bejegyezve, ezért amikor a IP cím PTR lekérdezésére kerül sor a mi hálózatunkból, az első kérés úgyis hozzánk érkezik. A logika ugyanaz, mint a domainek esetében. Csak az a kérdés, hogyan kell beírni az alhálózatot a zónafájlba?
Próbáljuk meg így beírni:
255-240 IN NS 7.8.7.8És... a csoda nem történt meg. Nem kapunk semmiféle irányítást a kérésre. Az egész az, hogy a bind egyáltalán nem tud a visszafelé zónafájlban lévő rekordokról, és főleg nem érti a tartománybejegyzést. Számára ez egyszerűen egy szimbolikus aldomain. Tehát a bind számára nem lesz különbség a "255-240és a "oursuperclient" és a kérés ahhoz, hogy a kérdés oda menjen, ahova kell, a kérésben lévő címnek így kell kinéznie: 241.255-240.9.8.7.in-addr.arpa. Vagy így, ha szimbolikus aldomaint használunk: 241.oursuperclient.9.8.7.in-addr.arpa. Ez különbözik a szokásos formátumtól: 241.9.8.7.in-addr.arpa.
Saját kezükkel ilyen kérdést nehéz megoldani. Ha pedig sikerül, akkor is kérdéses, hogyan lehet ezt a valós életben érvényesíteni. Mert a kérdésünkre 7.8.9.241 továbbra is a szolgáltató DNS-e válaszol, és nem az ügyfél DNS-e.
Na, itt lépnek játékba a CNAME.
A szolgáltató oldalán az alhálózat összes IP-címéhez alias-t kell létrehozni, amely átkonvertálja a kérdéseket az ügyfél DNS-ére.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
stb.
Ez a szorgalmasaknak =).
A lustábbaknak a következő konstrukció lesz jó:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Most az információ kérésének a címe 7.8.9.241 a 241.9.8.7.in-addr.arpa a szolgáltató DNS-szerverén átalakul 241.255-240.9.8.7.in-addr.arpa és átmegy az ügyfél DNS-ére.
Az ügyfél oldalán ezeket a kéréseket kell feldolgozni. Ennek megfelelően létrehozunk egy zónát 255-240.9.8.7.in-addr.arpa. Ebben elvileg visszafelé rekordokat helyezhetünk el bármilyen IP címhez az egész alhálózatra /24, de csak azokról fognak kérdezni, amelyeket a szolgáltató továbbít nekünk, szóval nem fogunk tudni játszadozni =).
A példa kedvéért még egyszer bemutatom az ügyfél oldalán lévő visszafelé zónafájl tartalmát:
$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@ 1D IN SOA ns1.client.domain. root.client.domain. (
2008152607 ; sorozatszám
3H ; frissítés
15M ; újrapróbálkozás
1W ; lejárati idő
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.
Amiatt, hogy a szolgáltatóként CNAME-t használunk, ezért válaszul két bejegyzést kapunk az adatok lekérdezésére. IP-cím nem egyet.
#> 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. Ne feledkezz meg az ACL helyes beállításáról sem. Mert értelmetlen a PTR-zónát megszerezni, ha senkinek sem válaszolsz kívülről =).
Forrás: habr.com
