DNS TLS-ზე და VPN: რომელი ნაწილია დაცული

DNS TLS-ზე შიფრავს გაცვლას კლიენტსა და მის მიერ არჩეულ resolver-ს შორის და resolver კვლავ კითხულობს სახელს. ეს წინადადება ხსნის DoT-ისა და VPN-ის გარშემო არსებული დაბნეულობის უმეტეს ნაწილს. გვირაბი განსაზღვრავს, რომელი გზით მიდის შიფრირებული მოთხოვნა, ხოლო resolver კვლავ იგებს, რა იკითხა. არც ერთი მექანიზმი არ ცვლის მეორეს და არც ერთი არ ხდის მეორეს ზედმეტს.

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

შემოწმება 1: რას ფარავს შიფრაცია

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

ეს განსხვავება მნიშვნელოვანია, როცა სამაგიდე პორტალი ან ფილტრავი შუალედური ბლოკი უშვებს 443-ს და ბლოკავს 853-ს. იქ მომუშავე ხელსაწყო არ არის მტკიცება, რომ მეორე იმუშავებს.

შემოწმება 2: რომელი მარშრუტით მიდის მოთხოვნა

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

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

შემოწმება 3: შიდა სახელები

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

შიდა სუფიქსებისთვის შიდა resolver შეინახეთ და ეს ნახტომი შიფრეთ, თუ პოლიტიკა ამას მოითხოვს, ნაცვლად იმისა, რომ ის საჯარო პროვაიდერით შეცვალოთ.

შემოწმება 4: ქცევა მარცხისას

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

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

ენდეთ სერტიფიკატს და არა პასუხს

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

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

რას ტოვებს ეს აუხსნელად

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

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