Eräänä päivänä minun edessäni oli tehtävä antaa yhdelle asiakkaalleni oikeus muokata hänelle osoitetun /28-aliverkon PTR-tietueita. Minulla ei ole automaatiota BIND-asetusten muokkaamiseen ulkopuolelta. Siksi päätin valita toisen reitin - delegoida asiakkaalle osan /24-aliverkon PTR-vyöhykkeestä.
Vaikuttaa siltä - mikä voisi olla yksinkertaisempaa? Rekisteröimme aliverkon tarpeen mukaan ja ohjaamme sen haluttuun NS:ään, kuten tehdään aliverkkotunnuksen kanssa. Mutta ei. Se ei ole niin yksinkertaista (vaikka todellisuudessa se on yleensä primitiivistä, mutta intuitio ei auta), siksi kirjoitan tämän artikkelin.
Jokainen, joka haluaa selvittää sen itse, voi lukea
Kuka haluaa valmiin ratkaisun, tervetuloa kissaan.
Jotta en viivytä copy-paste-menetelmästä pitäviä, julkaisen ensin käytännön osan ja sitten teoreettisen osan.
1. Harjoittele. Delegoiva vyöhyke /28
Oletetaan, että meillä on aliverkko 7.8.9.0/24. Meidän on delegoitava aliverkko 7.8.9.240/28 dns-asiakkaalle 7.8.7.8 (ns1.client.domain).
Palveluntarjoajan DNS:stä sinun on löydettävä tiedosto, joka kuvaa tämän aliverkon käänteisen vyöhykkeen. Anna sen olla 9.8.7.arpa.
Kommentoimme merkintöjä 240-255, jos sellaisia on. Ja tiedoston loppuun kirjoitamme seuraavaa:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240älä unohda lisätä sarjavyöhykettä ja tee
rndc reloadTämä täydentää palveluntarjoajan osan. Siirrytään asiakkaan dns:ään.
Ensin luodaan tiedosto /etc/bind/master/255-240.9.8.7.in-addr.arpa seuraava sisältö:
$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.
Ja sisään nimetty lisää kuvaus uudesta tiedostostamme:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B käynnistä sidontaprosessi uudelleen.
/etc/init.d/named restartKaikki. Nyt voit tarkistaa.
#> 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.Huomaa, että PTR-tietueen lisäksi myös CNAME on annettu. Näin sen pitäisi olla. Jos mietit miksi, niin tervetuloa seuraavaan lukuun.
2. Teoria. Kuinka se toimii.
Mustan laatikon konfigurointi ja virheenkorjaus on vaikeaa. Se on paljon helpompaa, jos ymmärtää, mitä sisällä tapahtuu.
Kun delegoimme aliverkkotunnuksen verkkotunnuksessa verkkotunnuksen, sitten kirjoitamme jotain näin:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Kerromme kaikille kysyville, että emme ole vastuussa tästä sivustosta ja kerromme kuka on vastuussa. Ja kaikki pyynnöt asiakas.verkkotunnus uudelleenohjaus osoitteeseen 7.8.7.8. Tarkistaessamme näemme seuraavan kuvan (jätämme pois mitä asiakkaalla on siellä. Ei väliä):
# host test.client.domain
test.client.domain has address 7.8.9.241Nuo. meille ilmoitettiin, että on olemassa tällainen A-tietue ja sen ip on 7.8.9.241. Ei turhaa tietoa.
Kuinka sama voidaan tehdä aliverkon kanssa?
Koska DNS-palvelimemme on rekisteröity RIPE:hen, jolloin pyytäessämme PTR IP-osoitetta verkostamme, ensimmäinen pyyntö tulee silti meille. Logiikka on sama kuin verkkotunnuksissa. Mutta kuinka syötät aliverkon vyöhyketiedostoon?
Yritetään kirjoittaa se näin:
255-240 IN NS 7.8.7.8Ja... ihme ei tapahtunut. Emme saa mitään uudelleenohjauspyyntöä. Asia on siinä, että bind ei edes tiedä, että nämä käänteisvyöhyketiedoston merkinnät ovat IP-osoitteita, ja vielä enemmän ei ymmärrä aluemerkintää. Hänelle tämä on vain jonkinlainen symbolinen aliverkkotunnus. Nuo. sidonnan välillä ei ole eroa "255-240"Ja"superasiakkaamme". Ja jotta pyyntö menisi minne sen pitääkin, pyynnön osoitteen tulee näyttää tältä: 241.255-240.9.8.7.in-addr.arpa. Tai näin, jos käytämme merkkialiverkkotunnusta: 241.superclient.9.8.7.in-addr.arpa. Tämä eroaa tavallisesta: 241.9.8.7.arpa.
Tällaisen pyynnön tekeminen manuaalisesti on vaikeaa. Ja vaikka se toimisi, on silti epäselvää, kuinka sitä sovelletaan tosielämässä. Loppujen lopuksi pyynnöstä 7.8.9.241 Palveluntarjoajan DNS vastaa edelleen meille, ei asiakkaan.
Ja tässä ne tulevat peliin CNAME.
Palveluntarjoajan puolella sinun on tehtävä alias kaikille aliverkon IP-osoitteille muodossa, joka välittää pyynnön asiakkaan DNS:lle.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
и т.д.
Tämä on ahkeralle =).
Ja laiskoille alla oleva malli on sopivampi:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Pyydä nyt tietoja osoitteessa 7.8.9.241 ja 241.9.8.7.arpa palveluntarjoajan DNS-palvelimella muunnetaan muotoon 241.255-240.9.8.7.in-addr.arpa ja menee dns-asiakkaalle.
Asiakaspuolen tulee käsitellä tällaiset pyynnöt. Tämän mukaisesti luomme vyöhykkeen 255-240.9.8.7.in-addr.arpa. Siinä voimme periaatteessa sijoittaa käänteisiä merkintöjä mille tahansa koko /24-aliverkon IP-osoitteelle, mutta he kysyvät meiltä vain niistä, jotka palveluntarjoaja välittää meille, joten emme voi leikkiä =).
Havainnollistaakseni annan jälleen kerran esimerkin käänteisen vyöhykkeen tiedoston sisällöstä asiakaspuolelta:
$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.
Tämä johtuu siitä, että käytämme CNAME:ia palveluntarjoajan puolella, ja vastauksena IP-osoitteeseen perustuviin tietopyyntöihin saamme kaksi tietuetta, ei yhtä.
#> 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.
Älä myöskään unohda määrittää ACL:ää oikein. Koska ei ole mitään järkeä ottaa PTR-aluetta itsellesi ja olla vastaamatta kenellekään ulkopuolelta =).
Lähde: will.com