ডিএনএস পরিচিতি

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

একটি পেজ HTTPS দ্বারা পুরোপুরি সুরক্ষিত থাকার পরও আপনি কোন কোন সাইট ভিজিট করছেন তার তালিকা ডিএনএস-এর মাধ্যমে লিক বা ফাঁস হয়ে যেতে পারে। ইন্টারনেট প্রকৌশল কাজের সংস্থা IETF-এর ডিএনএস প্রাইভেসি বা গোপনীয়তা সংক্রান্ত বিশ্লেষণ—RFC 9076-এ একটি উদাহরণের মাধ্যমে এটি তুলে ধরা হয়েছে: অ্যালকোহলিক্স অ্যানোনিমাস (মদ্যপানে আসক্তদের নিরাময় কেন্দ্র)-এর ওয়েবসাইটটি জনসমক্ষে উন্মুক্ত হলেও, আপনি যে সেটি ভিজিট করেছেন সেই তথ্য উন্মুক্ত হওয়া উচিত নয়।

এই পেজটি পড়ার পর আপনি জানতে পারবেন কে কে আপনার ডিএনএস অনুসন্ধানগুলো দেখতে পায়, এনক্রিপ্টেড ডিএনএস কী সমাধান করে এবং কী অরক্ষিত রেখে দেয়, ডিএনএসএসইসি (DNSSEC) কোথায় খাপ খায় এবং কোন সেটিংসে দশ মিনিট সময় দেওয়া আপনার জন্য লাভজনক হবে। আমরা নির্দিষ্ট কোনো ডিএনএস প্রোভাইডার নির্বাচন করা, ডিএনএস-ভিত্তিক বিজ্ঞাপন ব্লক করা, বা নিজের রেজালভার নিজে চালানো নিয়ে এখানে আলোচনা করিনি। এগুলোর প্রতিটির জন্য আলাদা পেজের প্রয়োজন।

সহজ কথায় ডিএনএস কী

কম্পিউটারগুলো আইপি ঠিকানা (IP addresses) নামক কতগুলো গাণিতিক সংখ্যার মাধ্যমে একে অপরকে খুঁজে বের করে। কিন্তু মানুষ example.org-এর মতো নাম ব্যবহার করে। ডিএনএস হলো এমন একটি অনুসন্ধান বা লুকআপ সার্ভিস যা এই নামকে সংখ্যার আইপি ঠিকানায় রূপান্তর করে। আপনার ডিভাইসে থাকা সফটওয়্যারকে বলা হয় স্টাব রেজালভার (Stub resolver), যা প্রতিটি প্রশ্নকে একটি রিকার্সিভ রেজালভার (Recursive resolver) বা মূল সার্ভারের কাছে হস্তান্তর করে এবং সেই সার্ভারটি উত্তর খুঁজে আনার কাজ সম্পন্ন করে (RFC 9076)।

একটি বাস্তব উদাহরণ দেখা যাক। আপনি কোনো বিমানবন্দরের ওয়াই-ফাইতে যুক্ত হয়ে আপনার ক্লিনিকের পেশেন্ট পোর্টাল ওপেন করলেন। আপনার ফোন কোনো রেজালভার বেছে নেয়নি। আপনি যখন কানেক্ট হয়েছিলেন, তখন নেটওয়ার্কটি নিজেই বলে দিয়েছিল কোনটি ব্যবহার করতে হবে—যা একটি সাধারণ প্রক্রিয়া, এবং RFC 9076 উল্লেখ করেছে যে অধিকাংশ মানুষ কখনোই এটি পরিবর্তন করেন না। ফলে বিমানবন্দরের সেই রেজালভার অথবা তার ইন্টারনেট সেবাদাতার কাছে একটি রেকর্ড থেকে গেল যে সকাল ৯:১৪ মিনিটে আপনার ফোন থেকে ক্লিনিকের আইপি ঠিকানা জানতে চাওয়া হয়েছিল।

কীভাবে একটি ডিএনএস লুকআপ কাজ করে

ধরা যাক কোথাও কোনো তথ্য সেভ বা ক্যাশে (Cache) করা নেই, সেই অবস্থায় www.example.com-এর অনুসন্ধানের একটি রূপরেখা নিচে দেওয়া হলো:

১. আপনার স্টাব রেজালভার রিকার্সিভ রেজালভারকে প্রশ্ন করে।
২. রিকার্সিভ রেজালভার একটি রুট নেম সার্ভারকে (Root name server) প্রশ্ন করে। রুট সরাসরি উত্তর জানে না, তবে সে .com ডোমেইন পরিচালনার দায়িত্বে থাকা সার্ভারের পথ দেখিয়ে দেয়।
৩. রেজালভার তখন একটি .com সার্ভারকে প্রশ্ন করে, যা example.com ডোমেইনটি পরিচালনা করা সার্ভারের দিকে নির্দেশ করে।
৪. রেজালভার এরপর সেই সার্ভারগুলোকে প্রশ্ন করে। এদেরকে অথরিটেটিভ নেম সার্ভার (Authoritative name servers) বলা হয় কারণ আসল রিকর্ডগুলো এদের কাছেই থাকে, এবং তারা আইপি ঠিকানাটি ফেরত পাঠায়।
৫. রিকার্সিভ রেজালভার প্রাপ্ত উত্তরটি আপনার ডিভাইসে পাঠিয়ে দেয় এবং সীমিত সময়ের জন্য নিজের কাছে একটি কপি রেখে দেয়।

সেই কপিটির কারণেই অধিকাংশ পরবর্তী অনুসন্ধানগুলোতে ধাপ ২ থেকে ৪ এড়িয়ে যাওয়া সম্ভব হয়। এর কারণেই বিভিন্ন সার্ভার ভিন্ন ভিন্ন পরিমাণ তথ্য দেখতে পায়। একটি স্টাব রেজালভার সাধারণত তথ্য সেভ করে রাখে না, ফলে রিকার্সিভ রেজালভার আপনার প্রায় সমস্ত অনুসন্ধান দেখতে পায়; অন্যদিকে অথরিটেটিভ সার্ভারগুলো কেবল সেই অনুসন্ধানগুলোই দেখে যা রেজালভার তার মেমোরি থেকে দিতে পারেনি (RFC 9076)। রেজালভার যদি QNAME মিনিমাইজেশন নামক কৌশল ব্যবহার না করে, তবে ওপরের দিকে থাকা প্রতিটি সার্ভারই আপনার মূল পূর্ণাঙ্গ প্রশ্নটি দেখতে পায়—কেবল তার প্রয়োজনিয় অংশটুকু নয়।

একটিমাত্র পেজ ওপেন করা মানে অনেকগুলো ডিএনএস অনুসন্ধান ঘটা। এমবেড করা ছবি, স্ক্রিপ্ট এবং বিজ্ঞাপনের কারণে একটি একক ওয়েব পেজই ডজন ডজন ডোমেইন নামের অনুসন্ধানের সূচনা করতে পারে; এমনকি ব্রাউজারগুলো আপনি ক্লিক করতে পারেন ভেবে আগেই কিছু নাম অনুসন্ধান করে রাখে (RFC 9076)। ফলে আপনার রেজালভার যে তালিকা তৈরি করে তা আপনার ইচ্ছা করে ভিজিট করা সাইটগুলোর তালিকার চেয়েও দীর্ঘ ও বেশি তথ্য প্রকাশকারী হয়।

কে কে আপনার অনুসন্ধানগুলো দেখতে পারে

এটি নির্ভর করে আপনার রেজালভারটি কোথায় অবস্থিত এবং ট্রাফিক বা ডাটা এনক্রিপ্ট করা কি না তার ওপর।

এই ছকের বিবরণগুলো RFC 9076 থেকে সংগৃহীত, যা “উত্তর পরিবর্তন” অংশটিকেও তুলে ধরে: নেটওয়ার্ক নিয়ন্ত্রণকারী কোনো আক্রমণকারী অরক্ষিত যেকোনো অনুসন্ধানের জবাবে নিজের ভুয়া উত্তর বসিয়ে দিতে পারে।

রেজালভারের অপারেটর এই তথ্যগুলো নিয়ে কী করবে তা সম্পূর্ণ তাদের নীতিগত প্রশ্ন, এবং এই নীতিগুলো প্রতিষ্ঠানভেদে ভিন্ন হয়। RFC 9076 অনুযায়ী স্থানীয় নেটওয়ার্কের দেওয়া রেজালভারগুলোর ক্ষেত্রে গোপনীয়তার নীতিমালা থাকতেও পারে আবার নাও থাকতে পারে, তবে গুগল পাবলিক ডিএনএস, ক্লাউডফ্লেয়ার (Cloudflare) এবং কোয়াড-৯ (Quad9)-এর মতো বড় পাবলিক সার্ভিসগুলো তাদের নীতিমালা জনসমক্ষে প্রকাশ করে। কিছু রেজালভার ইচ্ছা করেও নির্দিষ্ট কিছু ডোমেইন ব্লক করে রাখে—সাধারণত ক্ষতিকারক ম্যালওয়্যার সাইটগুলো। এটি আপনার কাম্য হলে দরকারী, তবে না চাইলে বিভ্রান্তিকর।

এনক্রিপ্টেড ডিএনএস কী সমাধান করে এবং কী অরক্ষিত রাখে

তিনটি মানদণ্ড আপনার ডিভাইস এবং রেজালভারের মধ্যকার অনুসন্ধানকে এনক্রিপশনের মাধ্যমে মুড়িয়ে দেয়:

এই তিনটিই মূলত একই কাজ করে। আপনার এবং রেজালভারের মাঝে থাকা মানুষগুলো আর আপনার অনুসন্ধানগুলো দেখতে বা পরিবর্তন করতে পারে না। বিমানবন্দরে থাকা ওয়াই-ফাই অপারেটর তখন দেখতে পাবে আপনার ফোন কোনো রেজালভারের সাথে কথা বলছে, কিন্তু আপনি যে ক্লিনিকের ঠিকানা অনুসন্ধান করেছেন তা দেখতে পাবে না।

এর সুবিধার পাশাপাশি সীমাবদ্ধতাগুলো জানাও ততটাই গুরুত্বপূর্ণ:

• রেজালভার এখনো সবকিছু দেখতে পায়: RFC 9076 স্পষ্টভাবে জানিয়েছে যে এনক্রিপ্টেড প্রোটোকলগুলো রেজালভারের জানার পরিধি কমায় না, বরং তাকে মেলানোর জন্য আরও বেশি তথ্য এনে দিতে পারে। আপনি পর্যবেক্ষককে সরিয়ে দেননি; বরং কাকে বিশ্বাস করবেন তা বেছে নিয়েছেন মাত্র।
• ডাটা ট্রাফিক বিশ্লেষণ এখনো কিছুটা কাজ করে: এনক্রিপ্ট করা কোয়েরির আকার এবং সময় মিলিয়ে রেজালভার ওপরের দিকে কী পাঠাচ্ছে তা বিশ্লেষণ করা সম্ভব। প্যাডিং (Padding) এটি কিছুটা কমালেও RFC 7858 বলছে কেবল সাধারণ প্যাডিংই সবসময় যথেষ্ট নাও হতে পারে।
• দুর্বল কনফিগারেশনের সুযোগ নিয়ে মান কমিয়ে দেওয়া (Downgrade) সম্ভব: আপনার ডিভাইস যদি নেটওয়ার্ক থেকে এনক্রিপ্টেড রেজালভার সম্পর্কিত তথ্য পায় এবং তা নিশ্চিত না করে, তবে ওই নেটওয়ার্কের একজন আক্রমণকারী এতে বাধা সৃষ্টি করতে পারে (RFC 7858)। অ্যান্ড্রয়েডের “Private DNS provider hostname” মোডটি কিছুটা কঠোর: এটি আপনার উল্লেখ করা সার্ভারে একটি নিরাপদ চ্যানেলের মাধ্যমে তথ্য পাঠায়, অথবা সেই সার্ভারে পৌঁছাতে না পারলে নেটওয়ার্কটিতে “ইন্টারনেট এক্সেস নেই” বলে চিহ্নিত করে (Google Security Blog, 2018)।
• ছোট রেজালভার আপনাকে ট্র্যাক করা সহজ করে তুলতে পারে: RFC 9076 পর্যবেক্ষণ করেছে যে খুব কম ব্যবহারকারী থাকা একটি রেজালভার ব্যবহার করলে (এনক্রিপ্ট করা থাকলেও) কেউ আপনাকে একাধিক নেটওয়ার্কে খুব সহজেই অনুসরণ করতে পারে।
• এটি স্থানীয় ফিল্টার বন্ধ করে দিতে পারে: মজিলা-র ডকুমেন্টেশন অনুযায়ী DoH স্থানীয় রেজালভারগুলোকে বাইপাস বা এড়িয়ে চলে এবং সেগুলোর সাথে থাকা ম্যালওয়্যার ব্লকিং বা প্যারেন্টাল কন্ট্রোলকেও এড়িয়ে যায়; যা ফায়ারফক্স আগে থেকে পরীক্ষা করে এবং এমন কিছু পেলে পিছিয়ে আসে।
• নেটওয়ার্ক এটি ব্লক করতে পারে এবং ডিভাইস আগের অবস্থায় ফিরে যেতে পারে: RFC 7858 সতর্ক করেছে যে পোর্ট ৮৫৩ অনেক ফায়ারওয়াল দ্বারা ব্লক হতে পারে। ফায়ারফক্সের প্রাথমিক রোলআউটে একটি ফলব্যাক (Fallback) মোড ব্যবহার করা হয়, যাতে DoH ব্যর্থ হলে এটি নিঃশব্দে সিস্টেমের সাধারণ ডিএনএস ব্যবহার শুরু করে।

সাইটের নাম দ্বিতীয়বার লিক হওয়া

কেবল অনুসন্ধান এনক্রিপ্ট করলেই কাজ শেষ হয় না। আপনার ব্রাউজার যখন কোনো HTTPS সংযোগ খোলে, তখন এর প্রথম বার্তাতেই ওয়েবসাইটের নাম স্পষ্ট টেক্সট হিসেবে থাকে। এই ফিল্ডটিকে সার্ভার নেম ইন্ডিকেশন (SNI) বলা হয়, এবং কানেকশন পর্যবেক্ষণকারী যে কেউ তা পড়তে পারে (Cloudflare, 2023)।

এনক্রিপ্টেড ক্লায়েন্ট হ্যালো (ECH) এই ফাঁকটি বন্ধ করে। সাইটের নামটি বার্তার একটি এনক্রিপ্ট করা অংশের ভেতরে চলে যায়, এবং দৃশ্যমান অংশে একটি সাধারণ শেয়ার করা নাম থাকে। ক্লাউডফ্লেয়ারে ECH-চালু থাকা প্রতিটি সাইট একই বাইরের নাম দেখায়: cloudflare-ech.com। মজিলা-র FAQ অনুযায়ী ফায়ারফক্স ১১৯ ভার্সন থেকে ডিফল্টভাবেই ECH চালু রয়েছে, এবং তারা জানিয়েছে যখন অনেকগুলো সাইট একই সার্ভার শেয়ার করে তখন এর গোপনীয়তার সুবিধা সবচেয়ে বেশি পাওয়া যায়। ECH কেবল তখনই কাজ করে যখন সাইটটি এটি সমর্থন করে, এবং মজিলা বলছে অনেক সাইট এখনো তা করে না।

ECH একটি উপায়ে ডিএনএস-এর সাথে যুক্ত এবং একটি ফাঁক রেখে দেয়। ফায়ারফক্সে ECH তার এনক্রিপশন কীগুলো একটি ডিএনএস রেকর্ড থেকে সংগ্রহ করে, এবং মজিলা বলে যে DoH-এর পাশাপাশি এটি সবচেয়ে বড় গোপনীয়তার সুবিধা দেয়। থেকে যাওয়া ফাঁকটি হলো সার্ভারের আইপি ঠিকানা—যা আপনার ইন্টারনেট সেবাদাতা এখনো দেখতে পায়। একটি সাইটের যদি নিজস্ব একক সার্ভার থাকে, তবে কেবল ওই ঠিকানা থেকেই সাইটটিকে চিনে ফেলা সম্ভব।

ডিএনএসএসইসি (DNSSEC) কী যুক্ত করে

ডিএনএসএসইসি (DNS Security Extensions)-এর মাধ্যমে একজন ডোমেইনের মালিক তার ডিএনএস রেকর্ডগুলোতে ডিজিটাল স্বাক্ষর করতে পারেন। যে রেজালভারটি এই স্বাক্ষরগুলো পরীক্ষা করে, সে বুঝতে পারে যে আপনার কাছে আসার পথে উত্তরটি পরিবর্তন বা জালিয়াতি করা হয়েছে কি না। RFC 7858 এটিকে ‘রেসপন্স ইন্টিগ্রিটি’ বা উত্তরের অখণ্ডতা হিসেবে বর্ণনা করে। এই স্বাক্ষরের চেইনটি একটি রুট কী (Root key) থেকে শুরু হয় যা ভ্যালিডেটিং রেজালভারগুলো ট্রাস্ট অ্যাঙ্কর হিসেবে সংরক্ষণ করে।

এটি কোনো কিছু এনক্রিপ্ট করে না। RFC 9076 অনুযায়ী ডিএনএসএসইসি স্পষ্টভাবে গোপনীয়তাকে তার লক্ষ্যের বাইরে রেখেছে। এটি কেবল সেই ডোমেইনগুলোকে রক্ষা করে যাদের মালিকরা এতে স্বাক্ষর করেছেন এবং যেসব রেজালভার তা পরীক্ষা করে; আর শেষ প্রান্তে থাকা সাইটটি সৎ কি না সে বিষয়ে এটি কিছুই বলে না। মূল সাইটের মতো দেখতে কোনো ভুয়া ডোমেইনের স্ক্যাম সাইটেও নিখুঁত স্বাক্ষর থাকতে পারে। DoH-এর ক্ষেত্রে আপনার ডিভাইস নিজে ডিএনএসএসইসি ভ্যালিডেট করে অথবা DoH সার্ভারের রিপোর্টের ওপর ভরসা রাখে (RFC 8484)।

২০২৬ সালের অক্টোবরের হিসাব অনুযায়ী এর একটি জীবন্ত উদাহরণ রয়েছে। আইসিএএএন (ICANN) জানায় যে একটি নতুন রুট কী, KSK-2024, ২০২৬ সালের ১১ অক্টোবরে ১৪:০০ ইউটিসি (UTC) থেকে ডিএনএস রুট জোনে স্বাক্ষর করা শুরু করেছে, এবং এতে বড় কোনো বিঘ্ন ঘটার আলামত পাওয়া যায়নি। তাদের নির্দেশনাগুলো প্রধানত ভ্যালিডেটিং রেজালভার পরিচালনাকারীদের উদ্দেশ্যে তৈরি, যাদের নিশ্চিত করতে হবে যে নতুন কীটি তাদের কনফিগারেশনে রয়েছে। আপনি নিজে রেজালভার না চালালে আপনার এখানে কিছুই করার নেই।

সাধারণ কিছু ভুল ধারণা

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

“ডিএনএসএসইসি এবং এনক্রিপ্টেড ডিএনএস একই জিনিস।” এরা সম্পূর্ণ ভিন্ন দুটি সমস্যার সমাধান করে। RFC 7858 এবং RFC 8484 দুটোই বলছে যে এই দুটি সম্পূর্ণ স্বাধীন ও সামঞ্জস্যপূর্ণ, এবং একটি ব্যবহার করলে অন্যটি প্রতিস্থাপিত হয় না।

“DoH হলো প্রাইভেট আর DoT হলো দুর্বল।” কারিগরি স্পেসিফিকেশনগুলো কোনো একটিকে বিজয়ী ঘোষণা করে না। RFC 9076 উল্লেখ করে যে DoH-এ আরও কিছু এইচটিটিপি সুবিধা রয়েছে যা সনাক্তকারী হিসেবে কাজ করতে পারে, এবং তারা বলে যে প্রাইভেসি-সচেতন ব্যবহারকারীরা এমন ইমপ্লিমেন্টেশন পছন্দ করতে পারেন যা তারা কী পাঠাচ্ছে সে বিষয়ে স্পষ্ট। RFC 8484 বলছে যে DoH সাধারণ HTTPS-এর বাইরে অতিরিক্ত কোনো উদ্বেগের কারণ বাড়ায় না। বাস্তবে রেজালভার নির্বাচনের তুলনায় এই দুটির পার্থক্য খুবই সামান্য।

আপনার করণীয়

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

১. নির্দিষ্ট একটি অ্যাপের জন্য না করে পুরো ডিভাইসের জন্য এনক্রিপ্টেড ডিএনএস চালু করুন: যেসব ফোন পাবলিক ওয়াই-ফাইতে যুক্ত হয় সেগুলোতে এর সুবিধা সবচেয়ে বেশি। অ্যান্ড্রয়েডে সেটিংসে গিয়ে ‘Network & internet’-এর নিচে Private DNS অনুসন্ধান করুন (নির্মাতারা এর স্থান পরিবর্তন করতে পারেন)। “Private DNS provider hostname” বেছে নিয়ে আপনার প্রোভাইডারের হোস্টনেমটি লিখুন। অ্যাপলের iOS এবং macOS সিস্টেম-ওয়াইড DoT বা DoH সমর্থন করে; তবে ২০২৬ সালের অক্টোবর পর্যন্ত আমরা কেবল নিশ্চিত হয়েছি যে একটি অ্যাপ এটি সেটআপ করতে পারে এবং আপনাকে সেটি অনুমোদন করতে হবে (Apple Developer)। এর অসুবিধা: কিছু হোটেল এবং বিমানবন্দরের লগইন পেজ নেটওয়ার্কের নিজস্ব ডিএনএস-এর ওপর নির্ভর করে, এবং অ্যান্ড্রয়েড যদি আপনার দেওয়া সার্ভারে পৌঁছাতে না পারে তবে “ইন্টারনেট এক্সেস নেই” দেখাবে। সেই লগইনের সময় এটি বন্ধ রাখুন, কাজ শেষে আবার চালু করুন।
২. উদ্দেশ্যমূলকভাবে রেজালভার বেছে নিন: তাদের প্রাইভেসী পলিসি পড়ে দেখুন তারা কী কী তথ্য সেভ করে, কতদিন রাখে এবং কার সাথে শেয়ার করে। পলিসি একটি প্রতিশ্রুতি মাত্র, কোনো টেকনিক্যাল গ্যারান্টি নয়; যদিও কিছু সার্ভিস চুক্তির মাধ্যমে তা নিশ্চিত করে, যেমনটি মজিলা তার DoH পার্টনারদের সাথে করে থাকে। এই পেজে কোনো প্রোভাইডারকে র‍্যাংক করা হয়নি।
৩. আপনার ব্রাউজার আপডেট রাখুন যাতে ECH কাজ করতে পারে: ফায়ারফক্সে আলাদা করে সেটআপ করার কিছু নেই। মজিলা-র FAQ Cloudflare-এর ব্রাউজার চেকার-এর কথা বলে, যার মাধ্যমে এটি আপনার ক্ষেত্রে কাজ করছে কি না তা দেখতে পারবেন।
৪. প্যারেন্টাল কন্ট্রোল বা ফিল্টারিং রেজালভার ব্যবহার করলে সেটিকে এনক্রিপ্টেড বানান: ব্রাউজারের DoH স্থানীয় ফিল্টারিংকে বাইপাস করে দিতে পারে, এবং মজিলা বলে যে ডিএনএস-ভিত্তিক অ্যাড ব্লকারগুলোর ওপরের দিকে একটি এনক্রিপ্টেড কানেকশন ব্যবহার করা উচিত, অন্যথায় ভিজিট করা সাইটগুলো পরোক্ষভাবে লিক হয়ে যায়।
৫. অফিস বা স্কুলের ডিভাইসে ডিএনএস সেটিংস পরিবর্তন করবেন না: অফিসিয়াল নেটওয়ার্কগুলো তাদের নিজস্ব নীতির কারণে DoH বন্ধ রাখতে পারে, এবং ফায়ারফক্স এধরণের ডিভাইসে স্বয়ংক্রিয়ভাবে সরে আসে। আপনার নিয়োগকর্তার রেজালভার যেকোনো উপায়েই আপনার অনুসন্ধানগুলো দেখতে পাবে।

২০২৬ সালের অক্টোবর পর্যন্ত মজিলা জানিয়েছে যে যুক্তরাষ্ট্র এবং কানাডায় ফায়ারফক্স ডেস্কটপ ব্যবহারকারীরা বাই-ডিফল্ট DoH পাচ্ছেন; ইউক্রেন এবং রাশিয়ায় ২০২২ সালে এর রোলআউট শুরু হয়েছিল, এবং অন্যান্য দেশেও এটি চালুর পরিকল্পনা রয়েছে। ফায়ারফক্সের ডিফল্ট রেজালভার হলো মজিলার একটি বিশ্বস্ত পার্টনার। ফায়ারফক্স সেটিংসের “DNS over HTTPS” অংশ থেকে আপনি এটি থেকে বেরিয়ে আসতে পারেন বা অন্য কোনো প্রোভাইডার বেছে নিতে পারেন।

উৎসসমূহ (Sources)

• DNS Privacy Considerations (RFC 9076), IETF, জুলাই ২০২১
• Specification for DNS over Transport Layer Security (RFC 7858), IETF, মে ২০১৬
• DNS Queries over HTTPS (RFC 8484), IETF, অক্টোবর ২০১৮
• DNS over Dedicated QUIC Connections (RFC 9250), IETF, মে ২০২২
• Root Zone KSK Rollover, ICANN, অবস্থান অক্টোবর ২০২৬ অনুযায়ী
• Firefox DNS over HTTPS, মজিলা সাপোর্ট, ২০২৬
• Encrypted Client Hello (ECH) frequently asked questions, মজিলা সাপোর্ট, আগস্ট ২০২৪-এ আপডেটেড
• Encrypted Client Hello: the last puzzle piece to privacy, ক্লাউডফ্লেয়ার, ২০২৩
• DNS over TLS support in Android P Developer Preview, গুগল সিকিউরিটি ব্লগ, ২০১৮
• DNS settings, অ্যাপল ডেভেলপার ডকুমেন্টেশন, ২০২৬

সম্পর্কিত পেজসমূহ

• থ্রেট মডেলিং (Threat modeling)
• ডিজিটাল নিরাপত্তা ও গোপনীয়তা