Jednog dana sam se suočio sa zadatkom da jednom od svojih klijenata dam pravo da uređuje PTR zapise /28 podmreže koja mu je dodeljena. Nemam automatizaciju za uređivanje BIND postavki izvana. Stoga sam odlučio da krenem drugim putem - da klijentu delegiram dio PTR zone /24 podmreže.
Čini se - šta može biti jednostavnije? Jednostavno registrujemo podmrežu prema potrebi i usmjeravamo je na željeni NS, kao što se radi sa poddomenom. Ali ne. Nije tako jednostavno (iako je u stvarnosti općenito primitivno, ali intuicija neće pomoći), zato pišem ovaj članak.
Svako ko želi sam da shvati, može pročitati
Ko želi gotova rješenja, dobrodošli u kat.
Kako ne bih odugovlačio one koji vole copy-paste metodu, objavit ću prvo praktični dio, a zatim teoretski dio.
1. Vježbajte. Zona delegiranja /28
Recimo da imamo podmrežu 7.8.9.0/24. Moramo delegirati podmrežu 7.8.9.240/28 na dns klijenta 7.8.7.8 (ns1.client.domain).
Na DNS-u provajdera morate pronaći datoteku koja opisuje obrnutu zonu ove podmreže. Neka bude 9.8.7.in-addr.harp.
Komentiramo unose od 240 do 255, ako ih ima. I na kraju fajla pišemo sledeće:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240
ne zaboravite povećati serijsku zonu i učinite
rndc reload
Ovim se završava dio provajdera. Pređimo na klijentski dns.
Prvo, napravimo datoteku /etc/bind/master/255-240.9.8.7.in-addr.arpa sljedeći sadržaj:
$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.
I unutra named.conf dodajte opis našeg novog fajla:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};
B ponovo pokrenite proces povezivanja.
/etc/init.d/named restart
Sve. Sada možete provjeriti.
#> 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.
Imajte na umu da se ne daje samo PTR zapis, već i CNAME. Tako bi trebalo da bude. Ako se pitate zašto, dobrodošli u sljedeće poglavlje.
2. Teorija. Kako radi.
Teško je konfigurirati i otkloniti greške u crnoj kutiji. Mnogo je lakše ako shvatite šta se dešava unutra.
Kada delegiramo poddomen u domenu područje, onda pišemo nešto ovako:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8
Poručujemo svima koji pitaju da nismo odgovorni za ovu stranicu i kažemo ko je odgovoran. I svi zahtjevi za client.domain preusmjeriti na 7.8.7.8. Prilikom provjere vidimo sljedeću sliku (ono što klijent ima izostavićemo. Nije bitno):
# host test.client.domain
test.client.domain has address 7.8.9.241
One. obaviješteni smo da postoji takav A zapis i njegov IP je 7.8.9.241. Nema nepotrebnih informacija.
Kako se ista stvar može uraditi sa podmrežom?
Jer naš DNS server je registrovan u RIPE-u, onda kada zatražite PTR IP adresu sa naše mreže, prvi zahtjev će i dalje biti nama. Logika je ista kao i kod domena. Ali kako uneti podmrežu u datoteku zone?
Pokušajmo to unijeti ovako:
255-240 IN NS 7.8.7.8
I... čudo se nije dogodilo. Ne primamo nikakav zahtjev za preusmjeravanje. Stvar je u tome što bind čak i ne zna da su ovi unosi u datoteci obrnute zone IP adrese, a još više ne razumije unos raspona. Za njega je ovo samo neka simbolična poddomena. One. za bind neće biti razlike između "255-240"I"naš superklijent". A da bi zahtjev otišao tamo gdje treba, adresa u zahtjevu bi trebala izgledati ovako: 241.255-240.9.8.7.in-addr.arpa. Ili ovako ako koristimo poddomenu karaktera: 241.oursuperclient.9.8.7.in-addr.arpa. Ovo se razlikuje od uobičajenog: 241.9.8.7.in-addr.harp.
Biće teško podnijeti takav zahtjev ručno. Čak i ako djeluje, još uvijek je nejasno kako ga primijeniti u stvarnom životu. Uostalom, na zahtjev 7.8.9.241 DNS provajdera i dalje odgovara nama, a ne klijentovom.
I tu oni stupaju u igru CNAME.
Na strani provajdera, morate napraviti alias za sve IP adrese podmreže u formatu koji će proslijediti zahtjev klijentskom DNS-u.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
и т.д.
Ovo je za vredne =).
A za lijene, dizajn u nastavku je prikladniji:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240
Sada zatražite informacije na 7.8.9.241 из 241.9.8.7.in-addr.harp na DNS serveru provajdera će biti konvertovano u 241.255-240.9.8.7.in-addr.arpa i ide do dns klijenta.
Klijentska strana će morati da obradi takve zahtjeve. Shodno tome, kreiramo zonu 255-240.9.8.7.in-addr.arpa. U njemu možemo, u principu, postaviti obrnute unose za bilo koji ip cijele /24 podmreže, ali će nas pitati samo za one koje nam provajder prosljeđuje, pa se nećemo moći igrati =).
Za ilustraciju, još jednom ću dati primjer sadržaja datoteke obrnute zone sa strane klijenta:
$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.
To je zato što koristimo CNAME na strani provajdera, a kao odgovor na zahtjev za podacima po IP adresi primamo dva zapisa, a ne jedan.
#> 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.
I ne zaboravite ispravno konfigurirati ACL. Jer nema smisla uzimati PTR zonu za sebe i ne odgovarati nikome izvana =).
izvor: www.habr.com