Jedného dňa pred mnou stála úloha, odovzdať jednému z klientov právo na úpravu PTR záznamov prideleného jej podsiete /28. Nemám automatizáciu na úpravu nastavení BIND zvonka. Preto som sa rozhodol ísť inou cestou – delegovať klientovi kus PTR zóny podsiete /24.
Niekto by si pomyslel – čo môže byť jednoduchšie? Stačí správne nastaviť podsieť a smerovať na požadovaný NS, ako to robíme s subdoménou. Ale nie. Nie je to také jednoduché (aj keď v skutočnosti je to úplne primitívne, ale intuícia nepomôže), preto píšem tento článok.
Kto chce sám pochopiť, môže si prečítať
Kto chce hotové riešenie, vitajte pod kat.
Aby som nezdržoval tých, ktorí majú radi metódu kopírovania a vkladania, najskôr zverejním praktickú časť, a po nej teoretickú.
1. Prax. Delegujeme zónu /28
Predpokladajme, že máme podsieť 7.8.9.0/24. Musíme delegovať podsieť 7.8.9.240/28 na DNS klienta 7.8.7.8 (ns1.client.domain).
Na providerovom DNS je potrebné nájsť súbor, ktorý popisuje spätnú zónu tejto podsiete. Nech je to 9.8.7.in-addr.arpa.
Záznamy od 240 do 255 komentujeme, ak existujú. A na koniec súboru píšeme nasledujúce:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240nezabúdame zvýšiť serial zóny a vykonáme
rndc reloadNa tom je providerova časť skončená. Prechádzame k klientskému DNS.
Najskôr vytvoríme súbor /etc/bind/master/255-240.9.8.7.in-addr.arpa nasledujúceho obsahu:
$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.
A v named.conf dopíšeme popis nášho nového súboru:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B reštartujeme proces bind.
/etc/init.d/named restartVšetko. Teraz môžeme kontrolovať.
#> 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.Všimnite si, že sa odovzdáva nielen PTR záznam, ale aj CNAME. Tak to má byť. Ak vás zaujíma prečo, vitajte v ďalšej kapitole.
2. Teória. Ako to funguje.
Je ťažké nastaviť a ladenie čierneho boxu. Je to oveľa jednoduchšie, ak chápete, čo sa deje vo vnútri.
Keď delegujeme subdoménu v doméne domain, píšeme niečo takéto:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Povieme všetkým, ktorí sa pýtajú, že za tento segment nezodpovedáme a povieme, kto zodpovedá. A všetky žiadosti sa client.domain preposielajú na 7.8.7.8. Pri kontrole vidíme nasledujúci obraz (vynechajme to, čo má klient, je to nepodstatné):
# host test.client.domain
test.client.domain has address 7.8.9.241T.j. dostali sme informáciu, že existuje taký záznam A a jeho IP 7.8.9.241. Žiadne ďalšie informácie.
A ako to isté môžeme spraviť s podsieťou?
Keďže náš DNS server je zaregistrovaný v RIPE, pri požiadavke PTR na IP adresu z našej siete, prvý požiadavok bude aj tak smerovať k nám. Logika je rovnaká ako pri doménach. Lenže ako zapísať podsieť do zónového súboru?
Pokúšame sa zapísať to takto:
255-240 IN NS 7.8.7.8A... divá čarovnosť sa nedostavila. Nedostávame žiadne presmerovanie požiadavky. Všetko je o tom, že bind vôbec netuší, že tieto záznamy v súbore reverznej zóny sú IP adresy, a už vôbec nechápe záznam rozsahu. Preň je to jednoducho nejaký symbolický subdomén.255-240“ a „oursuperclient«. A aby požiadavka odišla tam, kam má, adresa v požiadavke musí vyzerať takto: 241.255-240.9.8.7.in-addr.arpa. Alebo takto, ak používame symbolický subdomén: 241.oursuperclient.9.8.7.in-addr.arpa. To sa líši od bežného: 241.9.8.7.in-addr.arpa.
Ručne by bolo ťažké takúto požiadavku splniť. A aj keby sa podarilo, aj tak nie je jasné, ako to uplatniť v reálnom živote. Veď na požiadavku 7.8.9.241 nám naďalej odpovedá poskytovateľský DNS, nie klientský.
A tu prichádzajú do hry CNAME.
Na strane poskytovateľa je potrebné vytvoriť alias pre všetky IP adresy podsiete v formáte, ktorý presmeruje požiadavku klientskému DNS.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
atď.
To je pre pracovitých =).
A pre lenivých sa viac hodí nasledujúca konštrukcia:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Teraz požiadavka na informácie o adrese 7.8.9.241 z 241.9.8.7.in-addr.arpa na DNS serveri poskytovateľa bude pretransformovaná na 241.255-240.9.8.7.in-addr.arpa a pošle sa na DNS klienta.
Na strane klienta bude potrebné spracovávať takéto požiadavky. Podľa toho vytvoríme zónu 255-240.9.8.7.in-addr.arpa. V nej môžeme v podstate umiestniť reverzné záznamy pre akékoľvek IP celej podsiete /24, ale pýtať sa nás budú len na tie, ktoré k nám poskytovateľ preposiela, takže nebude možné sa s tým moc zdržať =).
Pre ilustráciu ešte raz uvediem príklad obsahu súboru reverznej zóny na strane klienta:
$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.
Pretože na strane poskytovateľa používame CNAME, dostávame v odpovedi na požiadavok údajov o IP adrese dvoch záznamoch, nie jednom.
#> 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. A nezabudnite správne nastaviť ACL. Pretože nemá zmysel si vziať PTR zónu a neodpovedať nikomu z vonku =).
Zdroj: habr.com
