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

ერთხელ დავალების წინაშე დავდექი, რომ ერთ-ერთი კლიენტისთვის მიმეწოდებინა მისთვის მინიჭებული /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.

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

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 მისამართებია და რა თქმა უნდა, არ ესმის დიაპაზონის ჩანაწერი. მისთვის ეს უბრალოდ რაღაც სიმბოლური ქვედომენია. ანუ, bind-ისთვის არანაირი განსხვავება არ იქნება "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

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