Jednoho dne jsem stál před úkolem dát jednomu z mých klientů právo upravovat záznamy PTR podsítě /28, která mu byla přidělena. Nemám automatizaci pro úpravy nastavení BIND zvenčí. Proto jsem se rozhodl jít jinou cestou – delegovat klientovi kus PTR zóny podsítě /24.
Zdálo by se - co by mohlo být jednodušší? Jednoduše zaregistrujeme podsíť podle potřeby a nasměrujeme ji na požadovaný NS, jak se to dělá se subdoménou. Ale ne. Není to tak jednoduché (i když ve skutečnosti je to obecně primitivní, ale intuice nepomůže), proto píšu tento článek.
Každý, kdo na to chce přijít sám, může číst
Kdo chce hotové řešení, vítejte v kočičce.
Abych nezdržoval ty, kteří mají rádi metodu copy-paste, zveřejním nejprve praktickou část a poté část teoretickou.
1. Praxe. Zóna delegování /28
Řekněme, že máme podsíť 7.8.9.0/24. Potřebujeme delegovat podsíť 7.8.9.240/28 klientovi dns 7.8.7.8 (doména ns1.client).
Na DNS poskytovatele musíte najít soubor, který popisuje reverzní zónu této podsítě. Nech to být 9.8.7.v-addr.arpa.
Komentujeme příspěvky od 240 do 255, pokud nějaké jsou. A na konec souboru napíšeme následující:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240nezapomeňte zvětšit sériovou zónu a udělejte to
rndc reloadTím je část poskytovatele hotová. Přejděme k dns klienta.
Nejprve si vytvoříme soubor /etc/bind/master/255-240.9.8.7.in-addr.arpa následující obsah:
$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 pojmenovaný.konf přidejte popis našeho nového souboru:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B restartujte proces vazby.
/etc/init.d/named restartVšechno. Nyní můžete zkontrolovat.
#> 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.Upozorňujeme, že není uveden pouze záznam PTR, ale také CNAME. Tak to má být. Pokud se ptáte proč, tak vítejte u další kapitoly.
2. Teorie. Jak to funguje.
Je obtížné konfigurovat a ladit černou skříňku. Je to mnohem jednodušší, když pochopíte, co se děje uvnitř.
Když delegujeme subdoménu v doméně doména, pak napíšeme něco takového:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Každému, kdo se zeptá, říkáme, že nejsme odpovědní za tuto oblast, a říkáme, kdo je zodpovědný. A všechny žádosti o klient.doména přesměrování na 7.8.7.8. Při kontrole vidíme následující obrázek (vynecháme, co tam má klient. Je to jedno):
# host test.client.domain
test.client.domain has address 7.8.9.241Tito. byli jsme informováni, že existuje takový záznam A a jeho ip je 7.8.9.241. Žádné zbytečné informace.
Jak lze totéž udělat s podsítí?
Protože náš DNS server je registrován v RIPE, pak při požadavku na PTR IP adresu z naší sítě bude první požadavek stále na nás. Logika je stejná jako u domén. Ale jak zadáte podsíť do souboru zóny?
Zkusme to zadat takto:
255-240 IN NS 7.8.7.8A... zázrak se nestal. Nedostáváme žádné přesměrování požadavku. Věc se má tak, že bind ani neví, že tyto položky v souboru reverzní zóny jsou adresy IP, a ještě více nerozumí zadání rozsahu. Pro něj je to jen nějaká symbolická subdoména. Tito. pro bind nebude žádný rozdíl mezi "255-240"A"náš superklient". A aby se žádost dostala tam, kam má, měla by adresa v žádosti vypadat takto: 241.255-240.9.8.7.in-addr.arpa. Nebo takto, pokud použijeme subdoménu postavy: 241.náš superklient.9.8.7.v-addr.arpa. To se liší od obvyklého: 241.9.8.7.v-addr.arpa.
Ručně takový požadavek podat bude obtížné. A i když to funguje, stále není jasné, jak to aplikovat v reálném životě. Ostatně na požádání 7.8.9.241 Nám stále odpovídá DNS poskytovatele, nikoli klienta.
A tady vstupují do hry CNAME.
Na straně poskytovatele je potřeba vytvořit alias pro všechny IP adresy podsítě ve formátu, který přepošle požadavek na DNS klienta.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
и т.д.
To je pro pracovité =).
A pro líné je vhodnější níže uvedený design:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Nyní požádejte o informace na 7.8.9.241 z 241.9.8.7.v-addr.arpa na serveru DNS poskytovatele budou převedeny na 241.255-240.9.8.7.in-addr.arpa a přejde ke klientovi DNS.
Klientská strana bude muset takové požadavky vyřídit. Podle toho vytvoříme zónu 255-240.9.8.7.in-addr.arpa. V něm můžeme v zásadě umístit zpětné záznamy pro libovolnou ip celé podsítě /24, ale zeptají se nás pouze na ty, které nám poskytovatel přeposílá, takže si nebudeme moci hrát =).
Pro ilustraci uvedu ještě jednou příklad obsahu souboru reverzní zóny ze strany 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.
Je to proto, že na straně poskytovatele používáme CNAME a v reakci na žádost o data podle IP adresy dostáváme dva záznamy, ne jeden.
#> 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 nezapomeňte správně nakonfigurovat ACL. Protože nemá smysl brát si PTR zónu pro sebe a nereagovat na nikoho zvenčí =).
Zdroj: www.habr.com