Pewnego dnia stanęło przede mną zadanie, aby przyznać jednemu z klientów prawo do edytowania zapisów PTR w przypisanej mu podsieci /28. Nie mam automatyzacji do edytowania ustawień BIND zdalnie. Postanowiłem więc pójść inną drogą - delegować klientowi część strefy PTR podsieci /24.
Wydawałoby się - co może być prostszego? Po prostu odpowiednio zapisujemy podsieć i kierujemy na odpowiedni NS, jak to się robi z subdomeną. Ale nie. Nie jest to takie proste (chociaż w rzeczywistości jest to bardzo proste, ale intuicja nie pomoże), dlatego piszę ten artykuł.
Kto chce samodzielnie się zgłębić w temat, może poczytać.
Kto chce gotowego rozwiązania, zapraszam dalej.
Aby nie spóźniać tych, którzy lubią metodę kopiuj-wklej, najpierw umieszczę część praktyczną, a po niej część teoretyczną.
1. Praktyka. Delegujemy strefę /28.
Załóżmy, że mamy podsieć. 7.8.9.0/24Musimy delegować podsieć 7.8.9.240/28 do klienta dns. 7.8.7.8 (ns1.client.domain.).
Na serwerze dns dostawcy należy znaleźć plik opisujący odwrotną strefę tej podsieci. Niech to będzie 9.8.7.in-addr.arpa..
Zapisujemy od 240 do 255 w komentarzach, jeśli są. A na końcu pliku zapisujemy następujące:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240nie zapominamy zwiększyć serial strefy i wykonujemy
rndc reload.Na tym część dostawcy jest zakończona. Przechodzimy do klienta dns.
Na początek stworzymy plik /etc/bind/master/255-240.9.8.7.in-addr.arpa zawartości:
$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.
I w named.conf dodajemy opis naszego nowego pliku:
strefa "255-240.9.8.7.in-addr.arpa." IN {
typ master;
plik "master/255-240.9.8.7.in-addr.arpa";
};B restartujemy proces bind.
/etc/init.d/named restartTo wszystko. Teraz można to sprawdzać.
#> 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.Zwróć uwagę, że zwracany jest nie tylko zapis PTR, ale także CNAME. Tak ma być. Jeśli chcesz wiedzieć dlaczego, zapraszam do następnego rozdziału.
2. Teoria. Jak to działa.
Trudno jest konfigurować i debugować czarną skrzynkę. O wiele łatwiej jest, jeśli rozumiesz, co się dzieje w środku.
Gdy delegujemy subdomenę w domenie domena, zapisujemy coś w stylu tego:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Mówimy wszystkim pytającym, że za ten fragment nie odpowiadamy i wskazujemy, kto odpowiada. Wszystkie zapytania dotyczące client.domain są przekierowywane na 7.8.7.8. Podczas sprawdzania widzimy następujący obrazek (pomijamy, co tam u klienta. To nieistotne):
# host test.client.domain
test.client.domain has address 7.8.9.241Czyli poinformowano nas, że istnieje taki rekord A i jego IP to 7.8.9.241. Żadnych dodatkowych informacji.
A jak można zrobić to samo z podsiecią?
Ponieważ nasz serwer DNS jest zapisany w RIPE, przy żądaniu PTR adresu IP z naszej sieci, pierwszy wniosek i tak będzie skierowany do nas. Logika jest taka sama jak w przypadku domen. Tylko jak wpisać podsieć w plik strefy?
Próbujemy wpisać to w ten sposób:
255-240 IN NS 7.8.7.8I… cud się nie zdarzył. Nie otrzymujemy żadnego przekierowania zapytania. Cała sprawa w tym, że bind w ogóle nie wie, że te zapisy w pliku strefy odwrotnej to adresy IP i już tym bardziej nie rozumie zapisu zakresu. Dla него это просто некий символьный поддомен. Tzn. dla bind nie będzie różnicy między „255-240” i „oursuperclient“. A aby zapytanie poszło tam, gdzie trzeba, adres w zapytaniu musi wyglądać tak: 241.255-240.9.8.7.in-addr.arpa. Lub tak, jeśli używamy symbolicznego poddomeny: 241.oursuperclient.9.8.7.in-addr.arpa. To różni się od zwykłego: 241.9.8.7.in-addr.arpa.
Taki wniosek będzie trudny do zrealizowania ręcznie. A jeśli się uda, to i tak nie wiadomo, jak to zastosować w rzeczywistości. Bowiem na zapytanie 7.8.9.241 odpowiada nam nadal DNS dostawcy, a nie klienta.
A tutaj w grę wchodzą CNAME.
Po stronie dostawcy należy stworzyć alias dla wszystkich adresów IP podsieci w formacie, który przekieruje zapytanie do DNS klienta.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
itd.
To dla pracowitych =).
A dla leniwych lepsza będzie konstrukcja poniżej:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Teraz zapytanie o informacje pod adresem 7.8.9.241 z 241.9.8.7.in-addr.arpa na serwerze DNS dostawcy zostanie przekształcone w 241.255-240.9.8.7.in-addr.arpa i przejdzie do DNS klienta.
Po stronie klienta będzie trzeba obsłużyć takie zapytania. Odpowiednio tworzymy strefę 255-240.9.8.7.in-addr.arpa. W niej w zasadzie możemy umieszczać odwrotne zapisy dla wszelkich IP całej podsieci /24, ale zapytania będą tylko dotyczące tych, które dostawca do nas przekazuje, więc nie będzie można się tym zabawić =).
Dla ilustracji jeszcze raz podam przykład zawartości pliku strefy odwrotnej po stronie 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.
Ponieważ po stronie dostawcy używamy CNAME, otrzymujemy w odpowiedzi na zapytanie dane dotyczące adresu IP dwóch zapisów, a nie jednego.
#> 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. Nie zapominajcie o prawidłowej konfiguracji ACL. Bo nie ma sensu zabierać sobie strefy PTR i nie odpowiadać nikomu z zewnątrz =).
Źródło: habr.com
