Nekega dne sem se soočil z nalogo, da eni od svojih strank podelim pravico do urejanja zapisov PTR podomrežja /28, ki mu je bilo dodeljeno. Nimam avtomatizacije za urejanje nastavitev BIND od zunaj. Zato sem se odločil ubrati drugo pot - odjemalcu delegirati del območja PTR podomrežja /24.
Zdi se - kaj bi lahko bilo preprostejše? Enostavno registriramo podomrežje po potrebi in ga usmerimo na želeno NS, kot je to storjeno s poddomeno. Vendar ne. Ni tako preprosto (čeprav je v resnici na splošno primitivno, vendar intuicija ne bo pomagala), zato pišem ta članek.
Kdor želi sam ugotoviti, lahko bere
Kdor želi že pripravljeno rešitev, vabljen v kat.
Da ne bom odlašal tistim, ki jim je všeč metoda copy-paste, bom najprej objavil praktični del, nato pa še teoretični del.
1. Vadite. Delegirana cona /28
Recimo, da imamo podomrežje 7.8.9.0/24. Podomrežje moramo delegirati 7.8.9.240/28 na odjemalca dns 7.8.7.8 (ns1.client.domain).
V DNS ponudnika morate najti datoteko, ki opisuje obratno območje tega podomrežja. Naj bo 9.8.7.in-addr.harf.
Komentiramo vnose od 240 do 255, če so. In na koncu datoteke zapišemo naslednje:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240ne pozabite povečati serijske cone in storiti
rndc reloadS tem je ponudnikov del zaključen. Preidimo na dns odjemalca.
Najprej ustvarimo datoteko /etc/bind/master/255-240.9.8.7.in-addr.arpa naslednjo vsebino:
$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.
In v named.conf dodajte opis naše nove datoteke:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B znova zaženite postopek povezovanja.
/etc/init.d/named restartVse. Zdaj lahko preverite.
#> 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.Upoštevajte, da ni podan le zapis PTR, ampak tudi CNAME. Tako bi moralo biti. Če se sprašujete zakaj, potem dobrodošli v naslednjem poglavju.
2. Teorija. Kako deluje.
Črno skrinjico je težko konfigurirati in odpraviti napake. Veliko lažje je, če razumeš, kaj se dogaja notri.
Ko delegiramo poddomeno v domeni domena, potem zapišemo nekaj takega:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Vsakemu, ki vpraša, povemo, da nismo odgovorni za to stran in povemo, kdo je odgovoren. In vse zahteve za client.domain preusmeri na 7.8.7.8. Pri preverjanju vidimo naslednjo sliko (izpustili bomo, kaj ima stranka tam. Ni pomembno):
# host test.client.domain
test.client.domain has address 7.8.9.241Tisti. smo bili obveščeni, da obstaja tak zapis A in da je njegov ip 7.8.9.241. Brez nepotrebnih informacij.
Kako je mogoče isto stvar narediti s podomrežjem?
Ker je naš strežnik DNS registriran v RIPE, potem bo pri zahtevi za naslov IP PTR iz našega omrežja prva zahteva še vedno poslana nam. Logika je enaka kot pri domenah. Toda kako vnesete podomrežje v consko datoteko?
Poskusimo ga vnesti takole:
255-240 IN NS 7.8.7.8In ... čudež se ni zgodil. Ne prejemamo nobenih preusmeritev zahtev. Bind sploh ne ve, da so ti vnosi v datoteki obratnega območja naslovi IP, še več, ne razume vnosa obsega. Zanj je to le nekakšna simbolična poddomena. Tisti. za povezovanje ne bo razlike med "255-240"In"naša superstranka". In da bi zahteva prišla tja, kamor mora iti, bi moral naslov v zahtevi izgledati takole: 241.255-240.9.8.7.in-addr.arpa. Ali takole, če uporabimo poddomeno znakov: 241.oursuperclient.9.8.7.in-addr.arpa. To se razlikuje od običajnega: 241.9.8.7.in-addr.harf.
Ročno bo težko narediti takšno zahtevo. In tudi če deluje, še vedno ni jasno, kako ga uporabiti v resničnem življenju. Konec koncev, na zahtevo 7.8.9.241 Ponudnikov DNS še vedno odgovarja nam, ne naročnikov.
In tukaj pridejo do izraza CNAME.
Na strani ponudnika morate narediti vzdevek za vse IP naslove podomrežja v obliki, ki bo posredovala zahtevo odjemalcu DNS.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
и т.д.
To je za pridne =).
In za lene je primernejši spodnji dizajn:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Zdaj zahtevajte informacije na 7.8.9.241 z dne 241.9.8.7.in-addr.harf na strežniku DNS ponudnika bo pretvorjen v 241.255-240.9.8.7.in-addr.arpa in gre do odjemalca dns.
Stran odjemalca bo morala obravnavati takšne zahteve. V skladu s tem ustvarimo cono 255-240.9.8.7.in-addr.arpa. Vanj načeloma lahko postavimo povratne vnose za katerikoli ip celotnega podomrežja /24, vendar nas bodo spraševali le po tistih, ki nam jih posreduje ponudnik, tako da se ne bomo mogli izigravati =).
Za ponazoritev bom še enkrat podal primer vsebine datoteke povratne cone s strani odjemalca:
$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, ker na strani ponudnika uporabljamo CNAME in kot odgovor na zahtevo po podatkih po naslovu IP prejmemo dva zapisa, ne enega.
#> 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.
In ne pozabite pravilno konfigurirati ACL. Ker nima smisla vzeti cono PTR zase in ne odgovarjati nikomur od zunaj =).
Vir: www.habr.com