Egy nap azzal a feladattal szembesültem, hogy az egyik ügyfelemnek jogot adjak a /28-as alhálózat PTR rekordjainak szerkesztésére. Nincs automatika a BIND-beállítások kívülről történő szerkesztésére. Ezért úgy döntöttem, hogy más utat választok – delegálok az ügyfélnek a /24 alhálózat PTR zónájának egy részét.
Úgy tűnik - mi lehetne egyszerűbb? Egyszerűen szükség szerint regisztráljuk az alhálózatot, és a kívánt NS-hez irányítjuk, ahogy az egy aldomain esetében is történik. De nem. Ez nem ilyen egyszerű (bár a valóságban általában primitív, de az intuíció nem segít), ezért írom ezt a cikket.
Aki rá akar jönni, az elolvashatja
Aki kész megoldásra vágyik, üdvözöljük a macskában.
Hogy a copy-paste módszert kedvelők ne késlekedjenek, először a gyakorlati részt teszem közzé, majd az elméleti részt.
1. Gyakorlat. Átruházó zóna /28
Tegyük fel, hogy van alhálózatunk 7.8.9.0/24. Át kell delegálnunk az alhálózatot 7.8.9.240/28 dns kliensnek 7.8.7.8 (ns1.client.domain).
A szolgáltató DNS-én meg kell találnia egy fájlt, amely leírja ennek az alhálózatnak a fordított zónáját. Hadd legyen 9.8.7.in-addr.harp.
A 240-től 255-ig terjedő bejegyzéseket kommentáljuk, ha van. A fájl végére pedig a következőket írjuk:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240ne felejtse el növelni a soros zónát, és tegye meg
rndc reloadEzzel befejeződik a szolgáltató rész. Térjünk át a kliens dns-re.
Először is hozzunk létre egy fájlt /etc/bind/master/255-240.9.8.7.in-addr.arpa a következő tartalom:
$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 be megnevezett.conf add hozzá az új fájlunk leírását:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B indítsa újra a kötési folyamatot.
/etc/init.d/named restartMinden. Most ellenőrizheti.
#> 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.Kérjük, vegye figyelembe, hogy nem csak a PTR rekord van megadva, hanem a CNAME is. Ennek így kell lennie. Ha kíváncsi, hogy miért, akkor üdvözöljük a következő fejezetben.
2. Elmélet. Hogyan működik.
A fekete doboz konfigurálása és hibakeresése nehézkes. Sokkal könnyebb, ha megérted, mi történik belül.
Amikor egy tartományban aldomaint delegálunk domain, akkor valami ilyesmit írunk:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Mindenkinek azt mondjuk, aki azt kérdezi, hogy nem vagyunk felelősek ezért az oldalért, és megmondjuk, ki a felelős. És minden kérés ügyfél.domain átirányítás a 7.8.7.8-ra. Ellenőrzéskor a következő képet látjuk (kihagyjuk, hogy mi van ott az ügyfélnek. Nem számít):
# host test.client.domain
test.client.domain has address 7.8.9.241Azok. arról értesültünk, hogy van ilyen A rekord és az ip-je 7.8.9.241. Nincs szükségtelen információ.
Hogyan lehet ugyanezt megtenni egy alhálózattal?
Mert DNS szerverünk a RIPE-ben van regisztrálva, akkor hálózatunkból PTR IP cím kérésekor továbbra is hozzánk érkezik az első kérés. A logika ugyanaz, mint a tartományoknál. De hogyan írhat be alhálózatot egy zónafájlba?
Próbáljuk meg így beírni:
255-240 IN NS 7.8.7.8És... a csoda nem történt meg. Nem kapunk átirányítási kérelmet. A helyzet az, hogy a bind nem is tudja, hogy ezek a bejegyzések a fordított zóna fájlban IP címek, és még inkább nem érti a tartomány bejegyzést. Számára ez csak egyfajta szimbolikus aldomain. Azok. a kötéshez nem lesz különbség a "255-240"És"szuperkliensünk". És ahhoz, hogy a kérés oda kerüljön, ahová kell, a kérelemben szereplő címnek így kell kinéznie: 241.255-240.9.8.7.in-addr.arpa. Vagy így, ha karakteres aldomaint használunk: 241.superclient.9.8.7.in-addr.arpa. Ez eltér a szokásostól: 241.9.8.7.in-addr.harp.
Nehéz lesz ilyen kérést manuálisan benyújtani. És még ha működik is, még mindig nem világos, hogyan kell alkalmazni a való életben. Végül is kérésre 7.8.9.241 A szolgáltató DNS-e továbbra is nekünk válaszol, nem az ügyfélé.
És itt jönnek a képbe CNAME.
A szolgáltató oldalán álnevet kell készítenie az alhálózat összes IP-címéhez olyan formátumban, amely továbbítja a kérést az ügyfél DNS-nek.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
и т.д.
Ez a szorgalmasaknak szól =).
A lusták számára pedig az alábbi kialakítás alkalmasabb:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Most kérjen információt a címen 7.8.9.241 A 241.9.8.7.in-addr.harp a szolgáltató DNS-kiszolgálóján a rendszer konvertálni fogja 241.255-240.9.8.7.in-addr.arpa és megy a dns klienshez.
Az ügyféloldalnak kell kezelnie az ilyen kéréseket. Ennek megfelelően zónát hozunk létre 255-240.9.8.7.in-addr.arpa. Ebben elvileg a teljes /24-es alhálózat bármely ip-jéhez elhelyezhetünk fordított bejegyzéseket, de csak azokra kérdeznek ránk, amelyeket a szolgáltató továbbít nekünk, így nem fogjuk tudni kijátszani =).
A szemléltetés kedvéért még egyszer adok egy példát egy fordított zóna fájl tartalmára kliens oldalról:
$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.
Ennek az az oka, hogy a CNAME-t használjuk a szolgáltató oldalán, és az IP-cím szerinti adatkérésre nem egy, hanem két rekordot kapunk.
#> 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.
És ne felejtse el megfelelően konfigurálni az ACL-t. Mert nincs értelme PTR zónát venni magadnak és nem válaszolni senkinek kívülről =).
Forrás: will.com