dnsmasq კერძო DNS პასუხს უგდებს: ბრალი rebinding-ის დაცვასაა?

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

პასუხის მიღება და მისი დაბრუნების არჩევა ორი სხვადასხვა ნაბიჯია.

შეადარეთ ერთი და იგივე სახელი ორივე რეზოლვერზე

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

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

წაიკითხეთ უარი და არა სიმპტომი

dnsmasq-ის stop-dns-rebind პარამეტრი უარყოფს ზემოდან მოსულ შესაბამის კერძო მისამართიან პასუხებს და ამის კეთებისას ჟურნალში იწერს მათ. ამ დაცვას კარგი მიზეზი აქვს: საჯარო სახელი, რომელიც უცებ კერძო მისამართზე გადადის, კლასიკური rebinding შეტევაა. თუმცა ის გადაიკვეთება განზრახ კერძო სერვისთანაც, და ეს თქვენი შემთხვევაა.

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

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

შეზღუდეთ გამონაკლისი ერთი დომენით

დადასტურებული დომენისთვის dnsmasq-ის სახელმძღვანელო გვთავაზობს დომენით შეზღუდულ გამონაკლისს და არა გლობალურ გადამრთველს.

rebind-domain-ok=corp.example

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

rebinding-ის ამოცნობის გამონაკლისი ზუსტად ერთ რამეს აკეთებს: უშვებს ამ დომენის პასუხებს.

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

შეამოწმეთ საზღვრის მოხსნის გარეშე

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

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

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