VPN-ის DNS არასწორია? შესაძლოა ერთი ავტორიტეტული სერვერი მოძველებულია

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

სიმპტომი იცვლება გადამწყვეტის მიხედვით

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

ამიტომ ერთი და იგივე სახელი შეიძლება მუშაობდეს ერთ ოფისში და ჩავარდეს სასტუმროდან, და ამიტომ ლოკალური ქეშის გასუფთავება მხოლოდ ზოგჯერ ეხმარება. ქეშის გასუფთავება კითხვას კვლავ იმავე ავტორიტეტთან აგზავნის.

განმასხვავებელი ტესტია პირდაპირი მოთხოვნა თითოეულ გამოქვეყნებულ სერვერზე.

ჰკითხეთ თითოეულ ავტორიტეტს პირდაპირ

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

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

იგივე გააკეთეთ ზონის მწვერვალის NS ჩანაწერებზე, რადგან მშობლის დელეგირება და ზონის საკუთარი NS-ნაკრები მიგრაციის შემდეგ შეიძლება განსხვავდებოდეს. SOA-ს სერიული ნომრები შემდეგი შესადარებელია, და ბევრად ჩამორჩენილი მეორადი სერვერი გადაცემის პრობლემაა და არა პასუხის.

გაუშვით ეს მოთხოვნები ჩავარდნილი ქსელიდან და არა მხოლოდ თქვენი მაგიდიდან.

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

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

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

SERVFAIL-ით პასუხის გამცემი სერვერის დიაგნოსტიკა უფრო ადვილია, ვიდრე თავდაჯერებულად და არასწორად მპასუხობის.

მიგრაცია ამხელს იმას, რაც ქეშმა დამალა

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

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

ლეპტოპზე გადამწყვეტის შეცვლა ამ ლეპტოპს არემონტებს და სხვა არაფერს.

შეაკეთეთ ზონა და არა გადამწყვეტი

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

შემდეგ კვლავ გაუშვით პირდაპირი მოთხოვნები ორივე ქსელიდან და დაელოდეთ შეცვლილი ჩანაწერის TTL-ის ამოწურვას.

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