TLS-এর উপর DNS ক্লায়েন্ট এবং তার নির্বাচিত রিজলভারের মধ্যে বিনিময়টি এনক্রিপ্ট করে, আর রিজলভার তখনও নামটি পড়ে। এই বাক্যটি DoT এবং VPN নিয়ে বেশিরভাগ বিভ্রান্তি মেটায়। টানেল ঠিক করে এনক্রিপ্টেড কোয়েরিটি কোন পথে যায়, আর রিজলভার তখনও জানে কী জিজ্ঞাসা করা হয়েছে। কোনও প্রক্রিয়াই অন্যটির বিকল্প নয়, এবং কোনওটিই অন্যটিকে অপ্রয়োজনীয় করে না।

চারটি পরীক্ষা ঠিক করে আপনার আছে বলে আপনি যা ভাবছেন, সেটিই আসলে আছে কি না।

পরীক্ষা 1: এনক্রিপশন কী ঢাকে

DoT DNS বিনিময়কে TLS-এ মুড়ে দেয়, তাই পথের পর্যবেক্ষক কোয়েরির ভেতরে নামের বদলে একটি ঠিকানা ও পোর্টে সংযোগ দেখে। রিজলভার নিজেই ডিক্রিপ্ট করে উত্তর দেয়। HTTPS-এর উপর DNS-এর সঙ্গে তুলনা করুন: দুটোই এনক্রিপ্ট করে এবং ভিন্ন ট্রান্সপোর্ট ব্যবহার করে, তাই যে নেটওয়ার্ক ওয়েব ট্রাফিক অনুমোদন করে সে স্বয়ংক্রিয়ভাবে DoT সংযোগ অনুমোদন করে না।

এই পার্থক্যটি গুরুত্বপূর্ণ যখন একটি ক্যাপটিভ পোর্টাল বা ফিল্টারিং মিডলবক্স 443 অনুমোদন করে আর 853 ব্লক করে। যে সরঞ্জামটি সেখানে কাজ করেছে সেটি প্রমাণ নয় যে অন্যটিও কাজ করবে।

পরীক্ষা 2: কোয়েরি কোন রুট নেয়

রুটটি ক্লায়েন্ট নীতির প্রশ্ন। DoT রিজলভারে টানেলের ভেতর দিয়ে, তার বাইরে দিয়ে, বা নেটওয়ার্কের সঙ্গে বদলে যাওয়া পথে পৌঁছানো যায়। কোনটি ঘটবে তা রুটের উপর এবং ক্লায়েন্ট নিজের DNS সকেট সুরক্ষিত রাখে কি না তার উপর নির্ভর করে। যে টানেল সব ট্রাফিক ধরে নেয় সেটি সাধারণত কোয়েরিটিকেও সঙ্গে নিয়ে যায়, রিজলভার ঠিকানা যা-ই বলুক।

পরীক্ষায় তৃতীয় পক্ষের রিজলভার ঠিকানা দেখা বাইপাস প্রমাণ করে না, আর এনক্রিপশন দেখা উদ্দিষ্ট প্রাপককে প্রমাণ করে না। রিজলভার ও পথ আলাদা করে পড়ুন, তারপর সিদ্ধান্ত নিন জোড়াটি আপনার নকশা করা জোড়া কি না।

পরীক্ষা 3: অভ্যন্তরীণ নাম

যে সংস্থা অভ্যন্তরীণ নাম প্রকাশ করে তাদের সেই রেকর্ড ধরে রাখা একটি রিজলভার দরকার। একটি প্রকাশ্য DoT সেবা আপনার ব্যক্তিগত নেমস্পেস জানে না, এবং ক্লায়েন্টকে একটিতে নির্দেশ করা ওই নামগুলো ব্যর্থ হবে তা নিশ্চিত করে। কোনও ম্যানেজড ডিভাইসে কেউ এনক্রিপ্টেড DNS চালু করলে এটিই সবচেয়ে সাধারণ বাস্তব সমস্যা।

অভ্যন্তরীণ সাফিক্সের জন্য অভ্যন্তরীণ রিজলভার রাখুন এবং নীতি চাইলে ওই হপটি এনক্রিপ্ট করুন, এটিকে একটি প্রকাশ্য প্রদানকারী দিয়ে প্রতিস্থাপন না করে।

পরীক্ষা 4: ব্যর্থতার আচরণ

পৌঁছানো যায় এমন রিজলভার ছাড়া কঠোর রিজলভার সেটিং নাম রেজলিউশন ব্যর্থতা তৈরি করে, যখন টানেল চালু থাকে। কী বা সার্টিফিকেট ছোঁয়ার বদলে প্ল্যাটফর্ম মোড এবং তার নথিভুক্ত ফলব্যাক দেখুন।

নিঃশব্দে সাধারণ DNS ব্যবহার করা ফলব্যাক একটি নীতি সিদ্ধান্ত, সুবিধা নয়। সিদ্ধান্ত নিন ব্যর্থতা দৃশ্যমান হওয়া উচিত, না কি আরও দুর্বল কোনও কিছুতে নামা উচিত, এবং উত্তরটি লিখে রাখুন।

উত্তরে নয়, সার্টিফিকেটে ভরসা করুন

সেবার জন্য নথিভুক্ত প্রদানকারীর হোস্টনাম ও যাচাই কনফিগারেশন ব্যবহার করুন। অপরিচিত রিজলভার উত্তর দেবে বলে TLS যাচাই বন্ধ করা আপনাকে একটি অযাচাইকৃত এন্ডপয়েন্টে এনক্রিপ্টেড চ্যানেল দেয়, যা এটি প্রতিস্থাপন করা সাধারণ কোয়েরির চেয়ে একটি নির্দিষ্ট দিক থেকে খারাপ: এটি নিরাপদ দেখায়। DNS over TLS স্পেসিফিকেশন ওই যাচাইয়ের পিছনের প্রমাণীকরণ প্রত্যাশাটি তুলে ধরে।

যে রিজলভার আপনি প্রমাণীকরণ করতে পারবেন না তার উত্তর একটি দাবি, ফলাফল নয়।

এটি যা ব্যাখ্যা করে না

DoT রিজলভার থেকে নামটি লুকায় না, নেটওয়ার্ক থেকে সংযোগের গন্তব্য ঠিকানা লুকায় না, এবং কোয়েরিটি টানেল দিয়ে গেছে কি না তা ঠিক করে না। এগুলো তিনটি আলাদা প্রশ্ন এবং তিনটি আলাদা উত্তর।

রিজলভার পরিচয়, ট্রানজিট পথ ও অভ্যন্তরীণ-নাম নীতি তিনটি লাইন হিসেবে লিখে রাখুন। এরপর আপনার পাওয়া পরবর্তী DNS প্রশ্নটি হবে ওগুলোর একটি।

সম্পর্কিত নিবন্ধ