Iun tagon mi alfrontis la taskon doni al unu el miaj klientoj la rajton redakti PTR-rekordojn de la subreto /28 asignita al li. Mi ne havas aŭtomatigon por redakti BIND-agordojn de ekstere. Tial mi decidis preni alian vojon - delegi al la kliento pecon de la PTR-zono de la subreto /24.
Ŝajnus — kio povus esti pli simpla? Ni simple registras la subreton laŭbezone kaj direktas ĝin al la dezirata NS, kiel estas farita kun subdomajno. Sed ne. Ĝi ne estas tiom simpla (kvankam en la realo ĝi estas ĝenerale primitiva, sed intuicio ne helpos), tial mi skribas ĉi tiun artikolon.
Ĉiu, kiu volas mem eltrovi ĝin, povas legi
Kiu volas pretan solvon, bonvenon al kato.
Por ne prokrasti tiujn, kiuj ŝatas la kopi-alglui metodon, mi afiŝos unue la praktikan parton, kaj poste la teorian.
1. Praktiko. Delegita zono /28
Ni diru, ke ni havas subreton 7.8.9.0/24. Ni devas delegi la subreton 7.8.9.240/28 al dns-kliento 7.8.7.8 (ns1.client.domain).
Sur la DNS de la provizanto vi devas trovi dosieron, kiu priskribas la inversan zonon de ĉi tiu subreto. Permesu ke ĝi estu 9.8.7.in-addr.harpo.
Ni komentas enskribojn de 240 ĝis 255, se ekzistas. Kaj ĉe la fino de la dosiero ni skribas la jenon:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240ne forgesu pliigi la serian zonon kaj fari
rndc reloadĈi tio kompletigas la provizantan parton. Ni transiru al la kliento dns.
Unue, ni kreu dosieron /etc/bind/master/255-240.9.8.7.in-addr.arpa jena enhavo:
$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.
Kaj en nomita.konf aldonu priskribon de nia nova dosiero:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B rekomencu la ligprocezon.
/etc/init.d/named restartĈiuj. Nun vi povas kontroli.
#> 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.Bonvolu noti, ke ne nur la PTR-rekordo estas donita, sed ankaŭ la CNAME. Tiel devus esti. Se vi scivolas kial, do bonvenon al la sekva ĉapitro.
2. Teorio. Kiel ĝi funkcias.
Estas malfacile agordi kaj sencimigi nigran skatolon. Estas multe pli facile se vi komprenas, kio okazas interne.
Kiam ni delegas subdomajnon en domajno havaĵo, tiam ni skribas ion tian:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Ni diras al ĉiuj, kiuj petas, ke ni ne respondecas pri ĉi tiu areo kaj diras, kiu respondecas. Kaj ĉiuj petoj por kliento.domajno alidirekti al 7.8.7.8. Kontrolante, ni vidas la sekvan bildon (ni preterlasos tion, kion la kliento havas tie. Ne gravas):
# host test.client.domain
test.client.domain has address 7.8.9.241Tiuj. ni informiĝis, ke ekzistas tia A-rekordo kaj ĝia ip estas 7.8.9.241. Neniuj nenecesaj informoj.
Kiel oni povas fari la samon kun subreto?
Ĉar nia DNS-servilo estas registrita en RIPE, tiam kiam oni petas PTR-IP-adreson de nia reto, la unua peto ankoraŭ estos al ni. La logiko estas la sama kiel kun domajnoj. Sed kiel vi enigas subreton en zondosieron?
Ni provu enigi ĝin tiel:
255-240 IN NS 7.8.7.8Kaj... la miraklo ne okazis. Ni ne ricevas ajnan peton alidirekten. La afero estas, ke bind eĉ ne scias, ke ĉi tiuj enskriboj en la inversa zono-dosiero estas IP-adresoj, kaj eĉ pli ne komprenas la intervalan eniron. Por li, ĉi tio estas nur ia simbola subdomajno. Tiuj. por ligo ne estos diferenco inter "255-240"Kaj"nia superkliento". Kaj por ke la peto iru kien ĝi devas iri, la adreso en la peto devus aspekti jene: 241.255-240.9.8.7.in-addr.arpa. Aŭ tiel se ni uzas signan subdomajnon: 241.niasuperkliento.9.8.7.in-addr.arpa. Ĉi tio diferencas de la kutima: 241.9.8.7.in-addr.harpo.
Estos malfacile fari tian peton permane. Kaj eĉ se ĝi funkcias, ankoraŭ ne klaras kiel apliki ĝin en la reala vivo. Post ĉio, laŭ peto 7.8.9.241 La DNS de la provizanto ankoraŭ respondas al ni, ne tiu de la kliento.
Kaj ĉi tie ili venas en ludon CNAME.
Flanke de la provizanto, vi devas fari kaŝnomon por ĉiuj IP-adresoj de la subreto en formato, kiu plusendos la peton al la kliento DNS.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
и т.д.
Ĉi tio estas por la laborema =).
Kaj por mallaboruloj, la ĉi-suba dezajno estas pli taŭga:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Nun petu informojn ĉe 7.8.9.241 el 241.9.8.7.in-addr.harpo sur la DNS-servilo de la provizanto estos konvertita al 241.255-240.9.8.7.in-addr.arpa kaj iras al la dns-kliento.
La klienta flanko devos trakti tiajn petojn. Sekve, ni kreas zonon 255-240.9.8.7.in-addr.arpa. En ĝi, ni principe povas meti inversajn enskribojn por iu ajn ip de la tuta /24 subreto, sed ili demandos nin nur pri tiuj, kiujn la provizanto plusendas al ni, do ni ne povos ludi =).
Por ilustri, mi denove donos ekzemplon de la enhavo de inversa zono dosiero de la klienta flanko:
$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.
Estas ĉar ni uzas CNAME flanke de la provizanto, kaj responde al peto pri datumoj per IP-adreso ni ricevas du rekordojn, ne unu.
#> 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.
Kaj ne forgesu agordi la ACL ĝuste. Ĉar ne havas sencon preni PTR-zonon por vi mem kaj ne respondi al iu ajn ekstere =).
fonto: www.habr.com