Któregoś dnia stanąłem przed zadaniem nadania jednemu z moich klientów prawa do edycji rekordów PTR przypisanej mu podsieci /28. Nie mam automatyzacji edycji ustawień BIND z zewnątrz. Dlatego zdecydowałem się pójść inną drogą - oddelegować klientowi część strefy PTR podsieci /24.
Wydawałoby się - co może być prostszego? Po prostu rejestrujemy podsieć zgodnie z wymaganiami i kierujemy ją do żądanego NS, tak jak ma to miejsce w przypadku subdomeny. Ale nie. To nie jest takie proste (choć w rzeczywistości jest to na ogół prymitywne, ale intuicja nie pomoże), dlatego piszę ten artykuł.
Każdy, kto chce się o tym przekonać, może przeczytać
Kto chce gotowego rozwiązania, zapraszamy do cat.
Aby nie opóźniać tych, którzy lubią metodę kopiuj-wklej, najpierw zamieszczę część praktyczną, a potem część teoretyczną.
1. Ćwicz. Strefa delegowania /28
Załóżmy, że mamy podsieć 7.8.9.0/24. Musimy delegować podsieć 7.8.9.240/28 do klienta DNS 7.8.7.8 (ns1.domena.klienta).
W DNS dostawcy musisz znaleźć plik opisujący odwrotną strefę tej podsieci. Niech będzie 9.8.7.w-addr.arpa.
Komentujemy wpisy od 240 do 255, jeśli takie się pojawią. A na końcu pliku piszemy co następuje:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240nie zapomnij zwiększyć strefy szeregowej i zrób to
rndc reloadTo kończy część dotyczącą dostawcy. Przejdźmy do dns klienta.
Najpierw utwórzmy plik /etc/bind/master/255-240.9.8.7.in-addr.arpa następującą treść:
$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 nazwa.conf dodaj opis naszego nowego pliku:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B zrestartuj proces wiązania.
/etc/init.d/named restartWszystko. Teraz możesz sprawdzić.
#> 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.Należy pamiętać, że podany jest nie tylko rekord PTR, ale także CNAME. Tak powinno być. Jeśli zastanawiasz się dlaczego, witaj w następnym rozdziale.
2. Teoria. Jak to działa.
Trudno jest skonfigurować i debugować czarną skrzynkę. Dużo łatwiej jest, jeśli zrozumiesz, co dzieje się w środku.
Kiedy delegujemy subdomenę w domenie domena, to piszemy coś takiego:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Każdemu, kto pyta, mówimy, że nie jesteśmy odpowiedzialni za tę witrynę i kto jest za to odpowiedzialny. I wszystkie prośby o domena.klienta przekierowanie do 7.8.7.8. Podczas sprawdzania widzimy następujący obrazek (pominiemy to, co ma tam klient. Nie ma to znaczenia):
# host test.client.domain
test.client.domain has address 7.8.9.241Te. zostaliśmy poinformowani, że istnieje taki rekord A i jego ip to 7.8.9.241. Żadnych zbędnych informacji.
Jak to samo można zrobić z podsiecią?
Ponieważ nasz serwer DNS jest zarejestrowany w RIPE, wówczas przy żądaniu adresu IP PTR z naszej sieci, pierwsze żądanie nadal będzie skierowane do nas. Logika jest taka sama jak w przypadku domen. Ale jak wprowadzić podsieć do pliku strefy?
Spróbujmy wprowadzić to w ten sposób:
255-240 IN NS 7.8.7.8I... cud się nie wydarzył. Nie otrzymujemy żadnego żądania przekierowania. Rzecz w tym, że bind nawet nie wie, że te wpisy w pliku strefy odwrotnej są adresami IP, a już na pewno nie rozumie wpisu zakresu. Dla niego jest to po prostu swego rodzaju symboliczna subdomena. Te. w przypadku wiązania nie będzie różnicy między „255-240 "A"naszsuperklient„. Aby żądanie mogło dotrzeć tam, gdzie powinno, adres w żądaniu powinien wyglądać następująco: 241.255-240.9.8.7.in-adres.arpa. Lub tak, jeśli użyjemy subdomeny znakowej: 241.naszsuperklient.9.8.7.w-addr.arpa. To różni się od zwykłego: 241.9.8.7.w-addr.arpa.
Ręczne złożenie takiego żądania będzie trudne. A nawet jeśli to działa, nadal nie jest jasne, jak zastosować to w prawdziwym życiu. W końcu na żądanie 7.8.9.241 DNS dostawcy nadal nam odpowiada, a nie klienta.
I tu właśnie wchodzą w grę CNAME.
Po stronie dostawcy musisz utworzyć alias dla wszystkich adresów IP podsieci w formacie, który przekaże żądanie do klienta DNS.
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
и т.д.
To jest dla pracowitych =).
A dla leniwych bardziej odpowiedni jest poniższy projekt:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Teraz poproś o informacje pod adresem 7.8.9.241 z 241.9.8.7.w-addr.arpa na serwerze DNS dostawcy zostanie przekonwertowany na 241.255-240.9.8.7.in-adres.arpa i przechodzi do klienta DNS.
Strona klienta będzie musiała obsłużyć takie żądania. W związku z tym tworzymy strefę 255-240.9.8.7.in-adres.arpa. Możemy w nim w zasadzie umieścić odwrotne wpisy dla dowolnego ip całej podsieci /24, ale zapytają nas tylko o te, które dostawca nam przekaże, więc nie będziemy mogli się bawić =).
Dla zobrazowania podam jeszcze raz przykład zawartości pliku strefy odwrotnej od strony 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.
Dzieje się tak dlatego, że po stronie dostawcy korzystamy z CNAME i w odpowiedzi na żądanie danych po adresie IP otrzymujemy dwa rekordy, a nie 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.
I nie zapomnij poprawnie skonfigurować listy ACL. Bo nie ma sensu brać dla siebie strefy PTR i nie odpowiadać nikomu z zewnątrz =).
Źródło: www.habr.com