VPN ছাড়া এনক্রিপ্টেড DNS কোয়েরি লুকায়, আপনার ঠিকানা নয়

আপনার হোম নেটওয়ার্ক দেখানো একটি DNS লিক টেস্ট এনক্রিপ্টেড DNS ব্যর্থ হয়েছে তার প্রমাণ নয়, আর কিছু কাজ করেছে তারও প্রমাণ নয়। টেস্টটি একটি প্রশ্নের উত্তর দেয়: এই কোয়েরি এই নেটওয়ার্ক থেকে কোন রিজলভারে পৌঁছেছে। এটি সমস্যা কিনা তা নির্ভর করে আপনি কী রক্ষা করছিলেন এবং কার থেকে।

যেকোনো টেস্ট চালানোর আগে লক্ষ্যটি লিখে রাখুন।

ধাপ 1: আপনি আসলে যে সুরক্ষা চান তার নাম দিন

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

VPN তৃতীয়টির সেবা করে এবং প্রদানকারীর উপর নির্ভর করে প্রথমটিরও। কোনো টুলই অন্যটির সুপারসেট নয়।

ধাপ 2: একটি রিজলভার বেছে নিন এবং তার পরিচয় যাচাই করুন

DNS over TLS কোয়েরিটিকে রিজলভারের সাথে একটি TLS সেশনে মোড়ায়, আর DNS over HTTPS এটিকে একটি HTTP অনুরোধে মোড়ায়; RFC 7858 এবং RFC 8484 দুটোই বর্ণনা করে, এবং কোনোটিরই টানেল দরকার নেই। পরিচালনাগতভাবে গুরুত্বপূর্ণ হলো সার্টিফিকেটটি আপনার কনফিগার করা নামের বিপরীতে যাচাই করা হয়, কারণ ভুল পক্ষের সাথে এনক্রিপ্টেড সেশন সঠিক পক্ষের সাথে প্লেইনটেক্সটের চেয়ে খারাপ। এর অর্থ হলো প্ল্যাটফর্ম যেখানে অফার করে সেখানে কঠোর মোড, যাচাই ব্যর্থ হলে পিছিয়ে যাওয়া সুবিধাবাদী মোড নয়। সেটিংয়ে ভরসা করার আগে সেশনটি সরাসরি পরীক্ষা করুন: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief।

হ্যান্ডশেকে আপনার কনফিগার করা রিজলভারের নাম থাকা উচিত এবং এমন একটি চেইন ফেরত দেওয়া উচিত যা আপনি যাচাই করতে পারেন।

ধাপ 3: ব্যর্থতার আচরণ নির্ধার করুন

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

systemd-resolved-এ এর অর্থ DNSOverTLS=yes এর বদলে opportunistic; আর Android-এ এর অর্থ স্বয়ংক্রিয়ের বদলে Private DNS হোস্টনাম মোড।

আসলে কী কার্যকর আছে তা যাচাই করতে এই কমান্ডটি ব্যবহার করুন: resolvectl status | grep -i -A1 "dns over tls"। কারণ কখনো পুনরায় লোড ন হওয়া drop-in ফাইল কিছুই বদলায় না।

ধাপ 4: অ্যাপগুলো সিস্টেম রিজলভার অনুসরণ করছে কিনা তা যাচাই করুন

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

প্রাতিষ্ঠানিক ব্যক্তিগত নামগুলো অনুমোদিত অভ্যন্তরীণ রিজলভারেই থাকে। টেস্ট পরিপাটি দেখানোর জন্য সেগুলো পাবলিক সেবায় পাঠানো ইচ্ছাক্রতভাবে আরেকটি সমস্যা তৈরি করে।

ধাপ 5: প্রয়োজনীয়তার বিপরীতে লিক টেস্ট পড়ুন

অপ্রত্যাশিত রিজলভার রিপোর্ট করা একটি টেস্ট ইঙ্গিত, রায় নয়। এটি আপনার অভীষ্ট এনক্রিপ্টেড রিজলভার, অ্যাপ-নির্দিষ্ট সেটিং, অথবা আপনি জানতেন না এমন প্লেইনটেক্সট ফলব্যাক পর্যবেক্ষণ করে থাকতে পারে। রিপোর্ট করা রিজলভারকে ধাপ 2 যা কনফিগার করেছিল তার সাথে তুলনা করুন, এবং ফলাফলকে ধাপ 1-এর লক্ষ্যের সাথে তুলনা করুন।

যদি লক্ষ্য স্থানীয় নেটওয়ার্ক থেকে কোয়েরি দূরে রাখা হয়, তবে আপনার সাধারণ রিজলভার দেখানো একটি টেস্ট সত্যিকারের ফলাফল। যদি লক্ষ্য ব্রাউজিংয়ের সময় নামহীনতা ছিল, তবে কোনো DNS সেটিংই তা দিত না।

গ্রহণযোগ্যতার লাইনটি লক্ষ্যের ভাষায় লিখুন: এই লুকআপগুলো এই শর্তে এই যাচাইকৃত রিজলভার ব্যবহার করে। এর চেয়ে বিস্তৃত যেকোনো কিছু এমন দাবি যা আপনি পরীক্ষা করতে পারবেন না।