Un dia em vaig enfrontar a la tasca de donar a un dels meus clients el dret d'editar els registres PTR de la subxarxa /28 que se li assignava. No tinc automatització per editar la configuració de BIND des de l'exterior. Per tant, vaig decidir prendre una ruta diferent: delegar al client una part de la zona PTR de la subxarxa /24.
Sembla: què podria ser més senzill? Simplement registrem la subxarxa segons sigui necessari i la dirigim al NS desitjat, tal com es fa amb un subdomini. Però no. No és tan senzill (tot i que en realitat és generalment primitiu, però la intuïció no ajudarà), per això escric aquest article.
Qualsevol que vulgui esbrinar-ho per si mateix pot llegir
Qui vulgui una solució ja feta, benvingut a cat.
Per no endarrerir els que els agrada el mètode copiar-enganxar, penjaré primer la part pràctica, i després la part teòrica.
1. Pràctica. Zona delegada /28
Suposem que tenim una subxarxa 7.8.9.0/24. Hem de delegar la subxarxa 7.8.9.240/28 al client dns 7.8.7.8 (ns1.client.domain).
Al DNS del proveïdor, heu de trobar un fitxer que descrigui la zona inversa d'aquesta subxarxa. Que sigui 9.8.7.in-addr.arpa.
Comentem les entrades del 240 al 255, si n'hi ha. I al final del fitxer escrivim el següent:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240no us oblideu d'augmentar la zona de sèrie i fer-ho
rndc reloadAixò completa la part del proveïdor. Passem al client dns.
Primer, creem un fitxer /etc/bind/master/255-240.9.8.7.in-addr.arpa el contingut següent:
$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 dins anomenat.conf afegir una descripció del nostre nou fitxer:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B reinicieu el procés d'enllaç.
/etc/init.d/named restartTots. Ara pots comprovar.
#> 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.Tingueu en compte que no només es dóna el registre PTR, sinó també el CNAME. Així ha de ser. Si us pregunteu per què, benvingut al següent capítol.
2. Teoria. Com funciona.
És difícil configurar i depurar una caixa negra. És molt més fàcil si entens què passa dins.
Quan deleguem un subdomini en un domini domini, llavors escrivim una cosa com això:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Diguem a tots els que demanen que no som responsables d'aquest lloc i diem qui és el responsable. I totes les peticions de client.domini redirigeix a 7.8.7.8. Quan comprovem, veiem la següent imatge (ometrem el que hi té el client. No importa):
# host test.client.domain
test.client.domain has address 7.8.9.241Aquells. ens van informar que hi ha un registre A i la seva ip és 7.8.9.241. Sense informació innecessària.
Com es pot fer el mateix amb una subxarxa?
Perquè el nostre servidor DNS està registrat a RIPE, aleshores quan sol·liciteu una adreça IP PTR des de la nostra xarxa, la primera sol·licitud encara serà per a nosaltres. La lògica és la mateixa que amb els dominis. Però, com s'introdueix una subxarxa en un fitxer de zona?
Intentem introduir-lo així:
255-240 IN NS 7.8.7.8I... el miracle no va passar. No estem rebent cap redirecció de sol·licitud. El cas és que bind ni tan sols sap que aquestes entrades del fitxer de zona inversa són adreces IP, i encara més no entén l'entrada del rang. Per a ell, això és només una mena de subdomini simbòlic. Aquells. per vincular no hi haurà diferència entre "255-240"I"el nostre superclient". I perquè la sol·licitud vagi on ha d'anar, l'adreça de la sol·licitud hauria de ser així: 241.255-240.9.8.7.in-addr.arpa. O així si fem servir un subdomini de caràcters: 241.el nostresuperclient.9.8.7.in-addr.arpa. Això és diferent de l'habitual: 241.9.8.7.in-addr.arpa.
Serà difícil fer aquesta sol·licitud manualment. I encara que funcioni, encara no està clar com aplicar-lo a la vida real. Després de tot, a petició 7.8.9.241 El DNS del proveïdor encara ens respon, no el del client.
I aquí és on entren en joc CNAME.
Per part del proveïdor, heu de crear un àlies per a totes les adreces IP de la subxarxa en un format que reenviï la sol·licitud al DNS del client.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
и т.д.
Això és per als treballadors =).
I per als ganduls, el disseny següent és més adequat:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Ara demaneu informació a 7.8.9.241 d' 241.9.8.7.in-addr.arpa al servidor DNS del proveïdor es convertirà a 241.255-240.9.8.7.in-addr.arpa i va al client dns.
La part del client haurà de gestionar aquestes peticions. En conseqüència, creem una zona 255-240.9.8.7.in-addr.arpa. En ell, podem, en principi, col·locar entrades inverses per a qualsevol IP de tota la subxarxa /24, però només ens preguntaran sobre les que el proveïdor ens reenviï, de manera que no podrem jugar =).
Per il·lustrar-ho, tornaré a donar un exemple del contingut d'un fitxer de zona inversa des del costat del client:
$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.
És perquè utilitzem CNAME per part del proveïdor i, en resposta a una sol·licitud de dades per adreça IP, rebem dos registres, no un.
#> 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 no us oblideu de configurar correctament l'ACL. Perquè no té sentit agafar una zona PTR per a tu mateix i no respondre a ningú de fora =).
Font: www.habr.com