আপনি টিভিকে একটি Smart DNS রিজলভারের দিকে ঘুরিয়ে দেন, একটি স্ট্রিমিং অ্যাপ কাজ শুরু করে, আর সিদ্ধান্ত নিজেই লেখা হয়ে যায়: এটি একটি VPN যা কম খরচে ও দ্রুত ইনস্টল হয়। তা নয়, আর এই ব্যবধান নিছক খুঁটিনাটি নয়। যা বদলেছে তা হলো টিভি যখন জিজ্ঞেস করেছিল কোনো হোস্টনেম কোথায় থাকে, তখন সে যে উত্তর পেয়েছিল; যা বদলায়নি তা হলো প্রতিটি প্যাকেট এখনও আপনার বাড়ি ছেড়ে যায় খোলাখুলি, একই পথে, ISP যে ঠিকানাটি আগেই জানে সেখান থেকেই। মিথ হলো এই যে DNS সেটিং একটি টানেল। বাস্তবতা আরও সংকীর্ণ এবং আরও কাজের, একবার আপনি তা দেখলে।

মিথ: DNS পরিবর্তন আপনার ট্রাফিকের পথ ঘুরিয়ে দেয়

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

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

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

আসলে কী নিয়ন্ত্রিত হয়, আর কী হয় না

ডিভাইস অনুযায়ী নয়, প্রবাহ অনুযায়ী তালিকা করলেই পার্থক্যটি সহজে দেখা যায়।

FlowSteered by Smart DNS?Why
A supported streaming hostnameYes, usuallyThe resolver returns a provider address for that name
The same app's other hostnamesOnly if the provider lists themSteering is per-name, and lists are curated
Your browser, email, game downloadsNoTheir names resolve to the ordinary destination
Traffic from devices not using that resolverNoNothing forces a device onto a particular resolver
Payload encryptionNoUnrelated to name resolution

আপনি এটি ঘটতে দেখতে পারেন। প্রোভাইডারের রিজলভারকে একটি হোস্টনেম জিজ্ঞেস করুন এবং একই নামটি একটি পাবলিক রিজলভারকে জিজ্ঞেস করুন:

dig +short @<provider-resolver> example-stream.example
dig +short @1.1.1.1 example-stream.example

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

একই গন্ধযুক্ত দ্বিতীয় ব্যর্থতাও আছে। অনেক প্রোভাইডার আপনি এখন যে পাবলিক ঠিকানা ব্যবহার করছেন তার ভিত্তিতে অনুমোদন দেয়, তাই ঠিকানা বদলানো পর্যন্ত অ্যাকাউন্ট কাজ করে। Carrier-grade NAT ঘূর্ণন, বা উপরে বসানো একটি VPN, ওই ঠিকানা সরিয়ে দেয় এবং রিলে আপনাকে প্রত্যাখ্যান করে, অথচ সমাধান সফল হতে থাকে। রেজিস্ট্রি এন্ট্রি হলো একটি অ্যাক্সেস নিয়ন্ত্রণ, একচেটিয়া এগ্রেসের প্রমাণ নয়।

এনক্রিপ্টেড DNS সম্পূর্ণ তৃতীয় একটি জিনিস

HTTPS-এর উপর DNS এবং TLS-এর উপর DNS আপনার ডিভাইস ও রিজলভারের মধ্যকার বিনিময় রক্ষা করে। তারা কোয়েরি এনক্রিপ্ট ও প্রমাণীকরণ করে যাতে স্থানীয় নেটওয়ার্ক তা পড়তে বা পুনর্লিখন করতে না পারে, এবং DoH এটি সাধারণ HTTPS ট্রাফিকে পোর্ট 443-এ বহন করে, আর এজন্যই এটি ফিল্টারের কাছে ওয়েব ট্রাফিকের মতো দেখায়। এটি লুকআপের জন্য একটি গোপনীয়তার বৈশিষ্ট্য।

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

তাই «এনক্রিপ্টেড DNS» প্রশ্নের উত্তর দেয় কে আপনার কোয়েরি পড়তে পারে। এটি উত্তর দেয় না কে আপনার ট্রাফিক দেখতে পারে, এবং এটি আপনাকে নতুন এগ্রেস ঠিকানা দেয় না। DNS over HTTPS স্পেসিফিকেশন ওই সুরক্ষা কী কভার করে তার সঠিক রেফারেন্স, এবং এটি রাউটিং সম্পর্কে কিছু বলে না।

প্রতিটি ব্যবস্থায় কে কী দেখে

Smart DNS-এ, রিজলভার দেখে আপনি কোন নামগুলো খোঁজেন, প্রোভাইডারের রিলে দেখে সে যে সংযোগগুলো বহন করে, আর আপনার ISP এখনও বাকি সবকিছু দেখে খোলা টেক্সট কাঠামোয়: আপনি কোন ঠিকানায় যোগাযোগ করেছেন, কখন, এবং কতটা। নিয়ন্ত্রিত প্রবাহে কনটেন্ট গন্তব্য পর্যন্ত TLS দিয়ে সুরক্ষিত থাকে, তাই রিলে একটি এনক্রিপ্টেড সেশন ফরওয়ার্ড করে যা সে পড়তে পারে না — কিন্তু সে দেখতে পারে আপনি সংযুক্ত হয়েছেন, কোথা থেকে, এবং কতক্ষণ।

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

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

কখন Smart DNS সঠিক সরঞ্জাম

এটি সত্যিই সঠিক সরঞ্জাম যখন ডিভাইসটি আদৌ VPN ক্লায়েন্ট চালাতে পারে না — একটি টেলিভিশন, একটি কনসোল, লক করা নেটওয়ার্ক স্ট্যাকযুক্ত একটি সেট-টপ বক্স — এবং যখন কেবল একটি নামযুক্ত সার্ভিস গুরুত্বপূর্ণ। এটি তখনও যুক্তিযুক্ত যখন আপনি সচেতনভাবে চান না যে ওই ডিভাইসের প্রতিটি প্যাকেট টানেল হয়ে যাক।

এটি ভুল সরঞ্জাম যখন প্রয়োজন এনক্রিপশন, পুরো ডিভাইসের জন্য একটি এগ্রেস ঠিকানা, বা স্থানীয় নেটওয়ার্ক ও ISP থেকে সুরক্ষা। ওগুলো টানেলের বৈশিষ্ট্য, এবং কোনো রিজলভার সেটিং সেগুলো তৈরি করে না। আর আপনি যদি একই ডিভাইসে VPN চালু রাখেন, রেজিস্ট্রেশনভিত্তিক অনুমোদন ভেঙে যাওয়ার আশা করুন, কারণ আপনার পাবলিক ঠিকানা এখন টানেলের।

এই সিদ্ধান্তটি ক্রমানুসারে চালান এবং যে প্রথম লাইনটি সত্য সেখানেই থামুন:

  • আপনার কি ট্রাফিক এনক্রিপ্টেড এবং পুরো ডিভাইস নতুন এগ্রেসে দরকার? একটি VPN ব্যবহার করুন, এবং এর সংযুক্ত সূচক নয়, এর রুট ও বাদগুলো দেখুন।
  • যে ডিভাইস টানেল করতে পারে না তাতে কি আপনার কেবল কয়েকটি নামযুক্ত সার্ভিস দরকার? Smart DNS সমানুপাতিক।
  • আপনার কি লুকআপ গোপনীয় দরকার কিন্তু ট্রাফিক সরানো নয়? সেটি এনক্রিপ্টেড DNS, যা উপরের কোনোটিই নয়।
  • প্রোভাইডার কি আপনার বর্তমান ঠিকানার উপর নির্ভর করে? এটি বদলানোর মুহূর্তেই বিচ্ছেদ আশা করুন।

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