ორი ადგილმდებარეობა, ერთი კერძო DNS ზონა: ვის ეკუთვნის ჩანაწერები?

თქვენ ამატებთ ჰოსტს მწვანე ადგილზე, ის იხსნება მწვანე მომხმარებლებისთვის, ხოლო ყვითელი ოფისი კვლავ იღებს NXDOMAIN-ს. ეს არ არის VPN-ის უკმარისობა და არც გატეხილი რეზოლვერი; ეს არის საკუთრების ხარვეზი კერძო ზონაში. ორი დამოუკიდებლად რედაქტირებადი ჩანაწერის სია ერთ ზონად არ იქცევა მხოლოდ იმიტომ, რომ ადგილებს ერთმანეთის მიღწევა შეუძლიათ. გადაწყვეტა გამოქვეყნების გეგმაა და არა კიდევ ერთი firewall-ის წესი.

სიმპტომი ასახელებს დაკარგულ მფლობელს

ალბათ ყველა ადგილს აქვს ლოკალური გადაფარვა, Pi-hole-ის ჩანაწერი ან dnsmasq-ის ხაზი, რომელიც ვინმემ დაამატა, როცა სახელი იყო საჭირო. მწვანე ჩანაწერი მხოლოდ მწვანე რეზოლვერზე არსებობს, ამიტომ ყვითელ ადგილზე მყოფი კლიენტი კითხულობს საკუთარ რეზოლვერს და იღებს სიმართლის შესაბამის "ასეთი სახელი არ არსებობს". მოძველებული პასუხი სხვაგვარად გამოიყურება: ჰოსტი გადავიდა, ერთმა ადგილმა თავისი ასლი განაახლა, ხოლო მეორე კვლავ ძველ მისამართს აბრუნებს.

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

ასე რომ, დიზაინის კითხვა ვიწრო და პასუხგაცემია: ვის შეუძლია ჩანაწერის შექმნა და როგორ აღწევს ეს ჩანაწერი ყველა რეზოლვერამდე, რომელმაც მასზე პასუხი უნდა გასცეს?

ვარიანტი A: ერთი უფლებამოსილი ზონა მეორადებით

გაუშვით პირველადი internal.example.com-სთვის და მიეცით მხარდაჭერილ მეორადებს ზონის მიღების საშუალება ყველა ადგილზე. თითოეული ადგილის რეკურსიული რეზოლვერი კითხულობს თავის ლოკალურ მეორადს, ამიტომ პასუხები მოდის უფლებამოსილი წყაროდან და არა ქეშიდან, და ერთხელ გაკეთებული ცვლილება გადადის და არა ხელახლა იბეჭდება.

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

შეზღუდეთ ზონის გადაცემები მისამართით ცნობილ მეორადებზე და გამოიყენეთ ტრანზაქციის ხელმოწერები, სადაც იმპლემენტაცია მათ მხარს უჭერს. ღია გადაცემა თქვენი შიდა სახელთა სივრცის ასლია ყველასთვის, ვისაც პორტამდე მიღწევა შეუძლია.

ფასი კოორდინაციაა: ერთი რედაქტირების გზა, ერთი ცვლილების განხილვა და საერთო გაგება იმისა, ვინ არის მორიგეობაზე, როცა ჩანაწერი მცდარია.

ვარიანტი B: ქვედომენი თითოეული ადგილისთვის

დელეგირეთ green.internal.example.com მწვანე ადგილზე და yellow.internal.example.com ყვითელზე. თითოეული ადგილი უფლებამოსილი ხდება საკუთარი სახელებისთვის, ხოლო მშობელი ზონა მხოლოდ დელეგაციის ჩანაწერებს ატარებს. ერთ ფაილზე დავა ქრება და ლოკალურ გუნდს შეუძლია ჰოსტის დამატება ცენტრალური ცვლილების მოლოდინის გარეშე.

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

ფასი გადაადგილდება და არ ქრება: მშობელ ზონას კვლავ სჭირდება მფლობელი, და ახალი ადგილის შექმნა ახლა ორ ადგილას ცვლილებაა და არა ერთში.

დაე, ყველა რეზოლვერმა არჩევანს მიჰყვეს

მიეცით კლიენტებს დამტკიცებული რეზოლვერი და საძიებო დომენი მათი მხარდაჭერილი კონფიგურაციის მეშვეობით და დარწმუნდით, რომ რეზოლვერს აქვს დაშვებული VPN მარშრუტი ნებისმიერი დისტანციური DNS სერვერისკენ, რომელიც მან უნდა გამოკითხოს. აპლიკაციებსაც სჭირდებათ მარშრუტები იმ კერძო მისამართებისკენ, რომლებსაც ეს პასუხები აბრუნებს, რადგან გზის გარეშე სწორი სახელი მაინც გატეხილი კავშირია.

თუ Pi-hole ლოკალურ გადაწყვეტას გვაძლევს, ჩაწერეთ რომელი ჩანაწერები ეკუთვნის და რომელ მოთხოვნებს გადასცემს. ორი დამოუკიდებლად რედაქტირებადი Pi-hole სია კვლავ არ რეპლიკდება. Pi-hole v6-ში მორგებული dnsmasq ხაზები დაყენდება ჰოსტის მხრიდან ოპციებით, როგორიცაა TOML, CLI ან გარემოს ცვლადები და არ ვლინდება API-ის მეშვეობით; /etc/dnsmasq.d/ ფაილების ჩატვირთვა ცალკე ოპციაა, რომელიც ნაგულისხმევად გამორთულია.

შემდეგ გამოსცადეთ ორივე მხრიდან სახელით, რომელიც ყველგან უნდა ჩანდეს:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

SOA პასუხი გეუბნებათ, ყვითელი რეზოლვერი თავს უფლებამოსილად მიიჩნევს, მეორადს კითხულობს თუ უბრალოდ გადასცემს. ეს სხვადასხვა დიზაინია სხვადასხვა მარცხის რეჟიმით და პასუხი ჩვეულებრივ განსაზღვრავს, რომელი დანერგეთ სინამდვილეში.

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