Jednou jsem čelil úkolu poskytnout jednomu z klientů právo upravovat PTR záznamy ve svěřené podsíti /28. Nemám automatizaci pro externí úpravy nastavení BIND. Rozhodl jsem se proto jít jinou cestou — delegovat klientovi část PTR zóny podsítě /24.
Na první pohled by to mělo být jednoduché. Stačí správně zapsat podsíť a směrovat na potřebné NS, jak se to dělá s poddoménou. Ale není to tak jednoduché (i když ve skutečnosti je to primitivní, ale intuice nepomůže), proto píšu tento článek.
Kdo chce sám pochopit, může si přečíst.
Kdo chce hotové řešení, vítán pod kat.
Abych nezdržoval ty, kteří mají rádi metodu kopírování a vkládání, nejprve zveřejním praktickou část, a po ní teoretickou.
1. Praxe. Delegujeme zónu /28.
Předpokládejme, že máme podsíť. 7.8.9.0/24. Musíme delegovat podsíť 7.8.9.240/28 na dns klienta. 7.8.7.8 (ns1.client.domain.).
Na poskytovatelském DNS je třeba najít soubor, který popisuje zpětnou zónu této podsítě. Předpokládejme, že to bude 9.8.7.in-addr.arpa..
Záznamy od 240 do 255 komentujeme, pokud existují. A na konec souboru zapíšeme následující:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240nezapomínáme zvýšit serial zóny a provést
rndc reload.Tím končí část poskytovatele. Přecházíme k zákaznickému DNS.
Nejprve vytvoříme soubor /etc/bind/master/255-240.9.8.7.in-addr.arpa následujícího 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 do named.conf přidáme 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 restartujeme proces bind.
/etc/init.d/named restartHotovo. Teď můžeme kontrolovat.
#> 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šimněte si, že se vrací nejen PTR záznam, ale i CNAME. Tak to má být. Pokud vás zajímá proč, vítáni do další kapitoly.
2. Teorie. Jak to funguje.
Je těžké nastavovat a ladit černou skříňku. Je mnohem snazší, pokud rozumíte tomu, co se uvnitř děje.
Když delegujeme poddoménu v doméně domain, zapisujeme něco takového:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Říkáme všem, kteří se ptají, že za tento úsek neodpovídáme a říkáme, kdo odpovídá. A všechny žádosti na client.domain jsou přesměrovány na 7.8.7.8. Při kontrole vidíme následující obraz (necháme stranou, co tam má klient. To není důležité):
# host test.client.domain
test.client.domain has address 7.8.9.241Tedy nám bylo sděleno, že existuje takový A záznam a jeho IP je 7.8.9.241. Žádné další informace.
A jak by se to samé dalo udělat se subnetem?
Jelikož náš DNS server je zapsán v RIPE, při dotazu na PTR IP adresy z naší sítě bude i tak první dotaz u nás. Logika je stejná jako u domén. Jen jak zapsat subnet do zónového souboru?
Zkoušíme zapsat takto:
255-240 IN NS 7.8.7.8A... zázrak se nestal. Nedostáváme žádné přesměrování dotazu. Všechny tyto záznamy v souboru obrácené zóny jsou pro bind cizí a rozhodně nechápe zápis rozsahu. Pro něj je to prostě nějaký symbolický subdomén.255-240“ a „oursuperclient«. A aby dotaz odešel tam, kam má, musí adresa v dotazu vypadat takto: 241.255-240.9.8.7.in-addr.arpa. Nebo takto, pokud používáme symbolický subdomén: 241.oursuperclient.9.8.7.in-addr.arpa. To se liší od běžného: 241.9.8.7.in-addr.arpa.
Takový dotaz se ručně dělá obtížně. A i kdyby se to povedlo, není jasné, jak to použít v reálném životě. Vždyť na dotaz 7.8.9.241 nám stále odpovídá poskytovatelův DNS, a ne klientský.
A tady vstupuje do hry CNAME.
Na straně poskytovatele je potřeba udělat pro všechny IP adresy subnetu alias v formátu, který předá dotaz klientskému DNS.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
atd.
To je pro pilné =).
A pro lenochy se více hodí konstrukce níže:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Nyní bude dotaz na informace o adrese 7.8.9.241 z 241.9.8.7.in-addr.arpa na DNS serveru poskytovatele přetvořen na 241.255-240.9.8.7.in-addr.arpa a odejde na DNS klienta.
Ze strany klienta bude potřeba zpracovávat takové dotazy. V souladu s tím vytváříme zónu 255-240.9.8.7.in-addr.arpa. V ní můžeme teoreticky umístit zpětné záznamy pro jakékoli IP celé podsítě /24, ale dotazovat se na nás budou jen o těch, které nám poskytovatel přesměruje, takže s tím si příliš nezahrajeme =).
Pro ilustraci ještě jednou uvedu příklad obsahu souboru obrácené 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.
Tohoto důvodu, že z naší strany poskytovatele používáme CNAME, dostáváme na dotaz dat odpověď IP adrese ve formě dvou záznamů, nikoli jednoho.
#> 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ě nastavit ACL. Protože nemá smysl brát si PTR zónu a nikomu z vnější strany neodpovídat =).
Zdroj: habr.com
