შებრუნებული ზონის დელეგირება ქვექსელებზე /24-ზე ნაკლები BIND-ში. Როგორ მუშაობს

ერთ მშვენიერ დღეს დამიდგა დავალება, მიმეცეს ჩემს ერთ-ერთ კლიენტს უფლება დაარედაქტიროს მისთვის მინიჭებული /28 ქვექსელის PTR ჩანაწერები. მე არ მაქვს ავტომატიზაცია BIND პარამეტრების გარედან რედაქტირებისთვის. ამიტომ, მე გადავწყვიტე სხვა მარშრუტის გატარება - კლიენტისთვის გადამეცემა /24 ქვექსელის PTR ზონის ნაწილი.

როგორც ჩანს - რა შეიძლება იყოს უფრო მარტივი? ჩვენ უბრალოდ ვარეგისტრირებთ ქვექსელს, როგორც საჭიროა და მივმართავთ მას სასურველ NS-ზე, როგორც ეს კეთდება ქვედომენით. Მაგრამ არა. ეს არც ისე მარტივია (თუმცა სინამდვილეში ეს ზოგადად პრიმიტიულია, მაგრამ ინტუიცია არ დაეხმარება), ამიტომაც ვწერ ამ სტატიას.

ვისაც სურს საკუთარი თავის გარკვევა, შეუძლია წაიკითხოს RFC
ვისაც სურს მზა გამოსავალი, მოგესალმებით კატა.

კოპირ-პასტის მეთოდის მოყვარულებს რომ არ დავაყოვნო ჯერ პრაქტიკულ ნაწილს დავდებ, შემდეგ კი თეორიულ ნაწილს.

1. ივარჯიშე. დელეგირების ზონა /28

ვთქვათ, გვაქვს ქვექსელი 7.8.9.0/24. ჩვენ გვჭირდება ქვექსელის დელეგირება 7.8.9.240/28 dns კლიენტს 7.8.7.8 (ns1.client.domain).

პროვაიდერის DNS-ზე თქვენ უნდა იპოვოთ ფაილი, რომელიც აღწერს ამ ქვექსელის საპირისპირო ზონას. Იყოს 9.8.7. in- ადრ. არპა.
ჩვენ კომენტარს ვაკეთებთ 240-დან 255-მდე ჩანაწერებზე, ასეთის არსებობის შემთხვევაში. და ფაილის ბოლოს ვწერთ შემდეგს:

255-240  IN  NS      7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240

არ დაგავიწყდეთ სერიული ზონის გაზრდა და ამის გაკეთება

rndc reload

ეს ასრულებს პროვაიდერის ნაწილს. მოდით გადავიდეთ კლიენტის dns-ზე.

პირველი, მოდით შევქმნათ ფაილი /etc/bind/master/255-240.9.8.7.in-addr.arpa შემდეგი შინაარსი:

$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.

და დაასახელა დაამატეთ ჩვენი ახალი ფაილის აღწერა:

zone "255-240.9.8.7.in-addr.arpa." IN {
        type master;
        file "master/255-240.9.8.7.in-addr.arpa";
};

B გადატვირთეთ შეკვრის პროცესი.

/etc/init.d/named restart

ყველა. ახლა შეგიძლიათ შეამოწმოთ.

#>  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.

გთხოვთ გაითვალისწინოთ, რომ მოცემულია არა მხოლოდ PTR ჩანაწერი, არამედ CNAME. ასეც უნდა იყოს. თუ გაინტერესებთ რატომ, მაშინ კეთილი იყოს თქვენი მობრძანება შემდეგ თავში.

2. თეორია. Როგორ მუშაობს.

ძნელია შავი ყუთის კონფიგურაცია და გამართვა. ბევრად უფრო ადვილია, თუ გესმით, რა ხდება შიგნით.

როდესაც ჩვენ ვაძლევთ ქვედომენს დომენში domain, შემდეგ ჩვენ ვწერთ ასეთ რამეს:

client.domain.	NS	ns1.client.domain.
ns1.client.domain.	A	7.8.7.8

ჩვენ ვეუბნებით ყველას, ვინც ითხოვს, რომ ჩვენ არ ვართ პასუხისმგებელი ამ საიტზე და ვამბობთ ვინ არის პასუხისმგებელი. და ყველა მოთხოვნა კლიენტი.დომენი გადამისამართება 7.8.7.8-ზე. შემოწმებისას ჩვენ ვხედავთ შემდეგ სურათს (ჩვენ გამოვტოვებთ იმას, რაც იქ კლიენტს აქვს. არ აქვს მნიშვნელობა):

# host test.client.domain
test.client.domain has address 7.8.9.241

იმათ. გვაცნობეს, რომ არის ასეთი A ჩანაწერი და მისი IP არის 7.8.9.241. არანაირი ზედმეტი ინფორმაცია.

როგორ შეიძლება იგივე გაკეთდეს ქვექსელთან ერთად?

იმიტომ რომ ჩვენი DNS სერვერი რეგისტრირებულია RIPE-ში, მაშინ როდესაც ჩვენი ქსელიდან PTR IP მისამართის მოთხოვნისას, პირველი მოთხოვნა კვლავ ჩვენთან იქნება. ლოგიკა იგივეა, რაც დომენებთან. მაგრამ როგორ შეიყვანოთ ქვექსელი ზონის ფაილში?

შევეცადოთ შევიტანოთ ასე:

255-240  IN  NS      7.8.7.8

და... სასწაული არ მომხდარა. ჩვენ არ ვიღებთ მოთხოვნის გადამისამართებას. საქმე ის არის, რომ bind-მა არც კი იცის, რომ საპირისპირო ზონის ფაილში ეს ჩანაწერები არის IP მისამართები და მით უმეტეს, რომ არ ესმის დიაპაზონის ჩანაწერი. მისთვის ეს მხოლოდ ერთგვარი სიმბოლური ქვედომენია. იმათ. კავშირისთვის არ იქნება განსხვავება "255-240"და"ჩვენი სუპერკლიენტი". და იმისთვის, რომ მოთხოვნა წავიდეს იქ, სადაც უნდა წავიდეს, მოთხოვნაში მისამართი ასე უნდა გამოიყურებოდეს: 241.255-240.9.8.7.in-addr.arpa. ან ასე, თუ გამოვიყენებთ სიმბოლოების ქვედომენს: 241.oursuperclient.9.8.7.in-addr.arpa. ეს განსხვავდება ჩვეულებრივისგან: 241.9.8.7. in- ადრ. არპა.

ასეთი მოთხოვნის ხელით გაკეთება რთული იქნება. და მაშინაც კი, თუ ის მუშაობს, ჯერ კიდევ გაურკვეველია, როგორ გამოიყენოს იგი რეალურ ცხოვრებაში. ყოველივე ამის შემდეგ, მოთხოვნით 7.8.9.241 პროვაიდერის DNS მაინც გვპასუხობს ჩვენზე და არა კლიენტის.

და ეს არის ის, სადაც ისინი თამაშობენ CNAME.

პროვაიდერის მხრივ, თქვენ უნდა გააკეთოთ მეტსახელი ქვექსელის ყველა IP მისამართისთვის იმ ფორმატში, რომელიც გაგზავნის მოთხოვნას კლიენტის DNS-ზე.

255-240  IN  NS      ns1.client.domain.
241     IN  CNAME   241.255-240
242     IN  CNAME   242.255-240
и т.д.

ეს არის შრომისმოყვარეებისთვის =).

და ზარმაცებისთვის, ქვემოთ მოცემული დიზაინი უფრო შესაფერისია:

255-240  IN  NS      ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240

ახლა მოითხოვეთ ინფორმაცია მისამართზე 7.8.9.241 საქართველოს 241.9.8.7. in- ადრ. არპა პროვაიდერის DNS სერვერზე გადაიქცევა 241.255-240.9.8.7.in-addr.arpa და მიდის dns კლიენტთან.

კლიენტის მხარეს დასჭირდება ასეთი მოთხოვნების დამუშავება. შესაბამისად ვქმნით ზონას 255-240.9.8.7.in-addr.arpa. მასში, პრინციპში, შეგვიძლია განვათავსოთ საპირისპირო ჩანაწერები მთელი /24 ქვექსელის ნებისმიერი ip-ისთვის, მაგრამ ისინი გვკითხავენ მხოლოდ მათ შესახებ, რომლებსაც პროვაიდერი გვიგზავნის, ასე რომ ჩვენ ვერ შევძლებთ ვითამაშოთ =).
საილუსტრაციოდ, მე კიდევ ერთხელ მივცემ მაგალითს საპირისპირო ზონის ფაილის შინაარსის კლიენტის მხრიდან:

$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.

ეს იმიტომ ხდება, რომ ჩვენ ვიყენებთ CNAME-ს პროვაიდერის მხრიდან და IP მისამართით მონაცემების მოთხოვნის საპასუხოდ ჩვენ ვიღებთ ორ ჩანაწერს და არა ერთს.

#>  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.

და არ დაგავიწყდეთ ACL-ის სწორად კონფიგურაცია. იმის გამო, რომ აზრი არ აქვს PTR ზონის აღებას თქვენთვის და არავის უპასუხოთ გარედან =).

წყარო: www.habr.com