DNS Over HTTPS ব্যাখ্যা করা হয়েছে: প্রাইভেসি বনাম পাবলিক WiFi ফিল্টারিং

DNS over HTTPS পোর্ট 443-এ সাধারণ HTTPS ট্রাফিকের মধ্যে DNS লুকআপ পাঠায়, যা ডিভাইস এবং রেজালভারের মধ্যে এনক্রিপ্ট করা হয়, এবং এটি 2018 সালে একটি IETF মানদণ্ডে পরিণত হয়েছে।

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

ভেন্যু অপারেটর এবং IT লিডদের জন্য, এটিই DoH-এর প্রধান বিষয়। এটি একটি লুকআপ ভ্রমণের সময় সেটিকে সুরক্ষিত করে, তবে ব্রাউজারের গন্তব্য নির্বাচন সেই লুকআপটিকে আপনার নেটওয়ার্কের ফিল্টারিং পলিসির বাইরেও নিয়ে যেতে পারে।

সূচিপত্র

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

সহজ কথায় DNS over HTTPS এর অর্থ কী

DNS over HTTPS, যাকে সংক্ষেপে DoH বলা হয়, এটি একটি এনক্রিপ্টেড ওয়েব কানেকশনের মাধ্যমে DNS প্রশ্ন এবং উত্তর পরিবহন করে। একটি DNS রিসলভার হলো এমন একটি সার্ভিস যা একটি ডিভাইস একটি ডোমেইন নামকে নেটওয়ার্ক অ্যাড্রেসে রূপান্তর করার জন্য জিজ্ঞাসা করে।

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

একটি পোস্টকার্ড একটি দরকারী এনালজি: এটি যে কেউ হ্যান্ডেল করে সে বার্তাটি পড়তে পারে। DoH প্রশ্নটিকে একটি সিল করা খামে রাখে এবং সাধারণ সুরক্ষিত ওয়েব ট্রাফিকের জন্য ব্যবহৃত একই ধরণের ডেলিভারি ভ্যানের ভিতরে নিয়ে যায়।

শুধু এনক্রিপশন নয়, ট্রান্সপোর্ট তুলনা করুন

DNS over TLS বা DoT-ও ডেটা এনক্রিপ্ট করে, তবে এটি আলাদাভাবে চিহ্নিত ডেলিভারি প্রবেশদ্বার ব্যবহার করে। এটি নেটওয়ার্ক অপারেটরের জন্য গন্তব্য পোর্ট দ্বারা এর ট্রাফিক সনাক্ত করা সহজ করে তোলে।

IETF-এর RFC 8484, যা অক্টোবর 2018-এ প্রকাশিত হয়েছে, DoH-এর HTTPS এক্সচেঞ্জকে সংজ্ঞায়িত করে, যা সাধারণ DNS-এর port 53-এর বিপরীতে সাধারণত port 443 ব্যবহার করে।

ঐতিহ্যবাহী DNS, DNS over TLS এবং DNS over HTTPS-এর তুলনা

বৈশিষ্ট্য	ঐতিহ্যগত DNS	DNS over TLS (DoT)	DNS over HTTPS (DoH)
ট্রান্সপোর্ট	UDP বা TCP	TLS	HTTPS
সাধারণ পোর্ট	53	853	443
স্থানীয় নেটওয়ার্ক দ্বারা পাঠযোগ্য	হ্যাঁ	না	না
পোর্ট দ্বারা সহজেই চিহ্নিতযোগ্য	হ্যাঁ	হ্যাঁ	না, ওয়েব ট্রাফিকের সাথে 443 পোর্ট শেয়ার করে
পোর্ট দ্বারা ব্লক করা সহজ	হ্যাঁ	হ্যাঁ	না, শুধুমাত্র পোর্ট দিয়ে বেছে বেছে ব্লক করা যায় না
সংজ্ঞায়িত করা হয়েছে	মূল DNS স্পেসিফিকেশনে	DNS over TLS স্পেসিফিকেশনে	RFC 8484-এ

একটি ডেডিকেটেড DNS পোর্ট ব্লক করা সহজ। সুরক্ষিত ওয়েবসাইট দ্বারা ব্যবহৃত পোর্ট ব্লক করা বৈধ ওয়েব ট্রাফিককেও থামিয়ে দেবে, তাই DoH-এর আরও সিলেক্টিভ কন্ট্রোল প্রয়োজন।

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

কন্ট্রোলগুলি পর্যালোচনা করার সময় এই তুলনাটি কাছে রাখুন। প্রথাগত DNS বা DoT হ্যান্ডেল করে এমন একটি নিয়ম স্বয়ংক্রিয়ভাবে DoH হ্যান্ডেল করে না।

ডিভাইস থেকে রিভলভারে যেভাবে একটি DoH লুকআপ স্থানান্তরিত হয়

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

এই ডায়াগ্রামটি ব্রাউজার থেকে রিভলভার এবং পুনরায় ফিরে আসার লুকআপ ট্র্যাক করে।

অনুরোধ এবং প্রতিক্রিয়া অনুসরণ করুন

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

2. এটি একটি DNS প্রশ্ন তৈরি করে। যদি এর একটি নতুন উত্তরের প্রয়োজন হয়, ব্রাউজার ডোমেন নামটি ধারণ করে এমন একটি কোয়েরি প্রস্তুত করে। এই মুহূর্তে, প্রশ্নটি এখনও ডিভাইসের ভেতরেই রয়েছে, WiFi জুড়ে ভ্রমণ করছে না।

3. এটি DoH রেজলভার নির্বাচন করে। ব্রাউজার তার কনফিগার করা রেজলভারের জন্য একটি HTTPS অনুরোধ প্রস্তুত করে। স্থানীয় নেটওয়ার্ক গন্তব্য ঠিকানা এবং কানেকশন মেটাডেটা পর্যবেক্ষণ করতে পারে, তবে এটি এনক্রিপ্ট করা DNS বার্তার ভেতরের ডোমেনটি সরাসরি পড়তে পারে না।

4. এটি একটি সুরক্ষিত কানেকশন প্রতিষ্ঠা করে বা পুনরায় ব্যবহার করে। প্রয়োজন হলে, সুরক্ষিত অনুরোধ পাঠানোর আগে ডিভাইসটি একটি TLS হ্যান্ডশেক সম্পন্ন করে। একটি স্থায়ী HTTP কানেকশনের মাধ্যমে, পরবর্তী কোয়েরিগুলো সেই কানেকশনটি পুনরায় ব্যবহার করতে পারে; নেটওয়ার্ক সময় এবং আকার সহ এনক্রিপ্ট করা ট্র্যাফিক দেখতে পায়।

5. রেজলভার উত্তরটি ফেরত পাঠায়। রেজলভার প্রশ্নটি প্রসেস করে এবং এনক্রিপ্ট করা HTTP রেসপন্সের ভেতরে DNS উত্তরটি রাখে। নেটওয়ার্ক রেজলভার থেকে ফেরত আসা ট্র্যাফিক দেখতে পায়, উত্তরের পাঠযোগ্য বিষয়বস্তু নয়।

6. ব্রাউজার ওয়েবসাইটে কানেক্ট করে। এটি ওয়েবসাইট কানেকশন শুরু করতে ফেরত পাওয়া ঠিকানাটি ব্যবহার করে। স্থানীয় নেটওয়ার্ক সেই নতুন গন্তব্যটি পর্যবেক্ষণ করতে পারে, যা আগের DNS প্রশ্ন পড়ার থেকে সম্পূর্ণ আলাদা।

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

ফিল্টারিং পয়েন্টটি চিহ্নিত করুন

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

একটি স্বাধীনভাবে কনফিগার করা ব্রাউজার সেই সিদ্ধান্ত অন্য কোথাও পাঠাতে পারে। ভেন্যুর রিভলভার তখন মূল্যায়ন করার জন্য কোনো প্রশ্ন পায় না।

সংযুক্ত ভিডিওটি প্রক্রিয়াটি অনুসরণ করার জন্য আরেকটি উপায় প্রদান করে।

DoH চালু থাকলে আপনার লুকআপগুলি কারা দেখতে পাবে

DoH সবার কাছ থেকে ব্রাউজিং লুকায় না। এটি ডিভাইস এবং এর নির্বাচিত রিজলভারের মধ্যে সাধারণ পর্যবেক্ষকদের বিরুদ্ধে DNS বিনিময়কে সুরক্ষিত করে, তবে উত্তর দেওয়ার জন্য সেই রিজলভারকে প্রশ্নটি পড়তে হয়।

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

DoH কার ওপর আপনি DNS কার্যক্রমের জন্য বিশ্বাস রাখবেন তা পরিবর্তন করে; এটি কারো ওপর বিশ্বাস রাখার প্রয়োজনীয়তা দূর করে না।

ব্রাউজিং ভিজিবিলিটি থেকে DNS ভিজিবিলিটি আলাদা করুন

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

DoH ব্যবহার করার সময় কারা DNS লুকআপ দেখতে পায়

পর্যবেক্ষক	ডোমেন নাম দেখতে পায়	DoH ব্যবহার করা হচ্ছে তা দেখতে পায়	কেন এটি গুরুত্বপূর্ণ
একই WiFi-তে থাকা অন্যান্য ডিভাইস	না, এনক্রিপ্ট করা লুকআপ থেকে নয়	সাধারণ পেয়ার অ্যাক্সেসের মাধ্যমে খুব কমই দেখতে পায়	DNS বার্তার প্যাসিভ রিডিং ব্লক করা থাকে
ভেন্যু বা ISP নেটওয়ার্ক	না, DoH এক্সচেঞ্জের ভেতরে নয়	প্রায়শই, একটি পরিচিত রিসলভার ঠিকানায় ট্র্যাফিকের মাধ্যমে দেখতে পায়	অন্যত্র পাঠানো ক্যোয়ারীগুলি স্থানীয় DNS নিয়ন্ত্রণ দ্বারা মূল্যায়ন করা যায় না
আপনার ভিজিট করা ওয়েবসাইটগুলি	কেবল যে সাইটে আপনি সংযোগ করছেন	শুধুমাত্র ওয়েবসাইট সংযোগ থেকে নয়	একটি সাইট আপনার সম্পর্কহীন DNS ক্যোয়ারীগুলি গ্রহণ করে না
DoH রিসলভার অপারেটর	হ্যাঁ, প্রতিটি ক্যোয়ারী এটি পায়	হ্যাঁ	একটি সরাসরি সংযোগ আপনার সোর্স অ্যাড্রেসের পাশাপাশি সেই ক্যোয়ারীগুলি উন্মুক্ত করে দেয়
ব্রাউজার বা OS ভেন্ডর	কেবল যদি এটি রিসলভার পরিচালনা করে বা প্রাসঙ্গিক টেলিমেট্রি গ্রহণ করে	সফ্টওয়্যারটি তার কনফিগার করা মোড জানে; ভেন্ডর রিপোর্টিংয়ের জন্য টেলিমেট্রি প্রয়োজন	সফ্টওয়্যার কনফিগারেশন স্বয়ংক্রিয় ভেন্ডর দৃশ্যমানতার মতো নয়

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

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

বিশ্বাসের সিদ্ধান্তটি সুস্পষ্ট করুন

ম্যানেজ করা Firefox ইনস্টলেশনের জন্য, Mozilla-র DNS over HTTPS নীতি ডকুমেন্টেশন সমাধানকারীর কনফিগারেশন এবং ব্যবহারকারীরা এটি পরিবর্তন করতে পারে কিনা তার জন্য নিয়ন্ত্রণ প্রদান করে। কোনো প্রতিষ্ঠানের DNS গভর্ন্যান্সের সাথে ব্রাউজারের আচরণ সারিবদ্ধ করার জন্য এটি একটি ব্যবহারিক উপায়।

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

একটি রিভলভার অনুমোদন করার আগে একটি সংক্ষিপ্ত ট্রাস্ট মূল্যায়ন ব্যবহার করুন:

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

উপকারী প্রশ্নটি এটি নয় যে গোপনীয়তা নাকি পরিচালনাযোগ্যতা বিশদভাবে বেশি গুরুত্বপূর্ণ। এটি হলো আপনার নির্বাচিত DNS পাথ ব্যবহারকারীদের উপযুক্ত গোপনীয়তা প্রদান করে কিনা এবং প্রতিষ্ঠানকে তার উল্লিখিত দায়িত্ব পালন করার সুযোগ দেয় কিনা।

কেন DoH শেয়ার্ড WiFi-এ DNS ফিল্টারিংকে দুর্বল করে দেয়

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

নেটওয়ার্ক DNS একইভাবে কাজ করে। আপনার নেটওয়ার্ক একটি সমাধানকারী সরবরাহ করে, কিন্তু নিজস্ব DoH কনফিগারেশন সহ একটি ব্রাউজার তার বদলে একটি বাহ্যিক সেবাকে জিজ্ঞাসা করতে পারে।

চিত্রটি নেটওয়ার্কের DNS ডেস্কে যাওয়ার বিকল্প রুটটি দেখায়।

বাইপাসটি রুট সম্পর্কিত

সমস্যাটি এটি নয় যে একটি এনক্রিপ্ট করা কুয়েরি কখনই ফিল্টার করা যায় না। সমস্যাটি হলো আপনার ফিল্টারটি এমন একটি কুয়েরিতে পলিসি প্রয়োগ করতে পারে না যা এটি কখনোই গ্রহণ করে না।

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

ফলাফলগুলি নির্ভর করে কোন নিয়ন্ত্রণগুলি DNS-এর ওপর নির্ভর করে তার ওপর:

• নেটওয়ার্ক-নির্দিষ্ট নীতি। একটি SSID বা VLAN-এ অ্যাসাইন করা নিয়মগুলি অনুমোদিত রিসলভার পাথের বাইরে পাঠানো প্রশ্নগুলি পরিচালনা করবে না।
• অনুসন্ধান নিষেধাজ্ঞা। DNS-ভিত্তিক সেফ সার্চ প্রয়োগ বাইপাস করা যেতে পারে, যদিও অ্যাকাউন্ট-লেভেল বা এ্যান্ডপয়েন্ট নিষেধাজ্ঞাগুলি তখনও প্রয়োগ হতে পারে।
• থ্রেট ব্লকিং। একটি DNS ফিল্টার কোনো অদৃশ্য লুকআপ প্রত্যাখ্যান করতে পারে না, এমনকি যদি তার থ্রেট তালিকায় অনুরোধ করা ডোমেনটি থাকে।

একটি এনক্রিপ্টেড-DNS ডিপ্লয়মেন্ট পরিমাপ সম্পর্কিত গবেষণা Firefox টেলিম্যাট্রি রিপোর্ট করে যেখানে ২০২৫ সালে ৯.৫৪ ট্রিলিয়ন ডেক্সটপ হ্যান্ডশেকের মধ্যে প্রায় ১৩.৯১% DoH ব্যবহার করেছে। এটি একটি পরিমাপমূলক ডাটাাসেটকেও বর্ণনা করে যেখানে DoH ছিল DoT-এর তুলনায় প্রায় ৬.৪ গুণ বেশি প্রচলিত।

সেই পর্যবেক্ষণগুলি আপনার ভেন্যুর ফিল্টার বাইপাসকারী ডিভাইসের সঠিক অনুপাত নির্ধারণ করে না। ব্রাউজারের ডিফল্ট সেটিংস, আঞ্চলিক রোলআউট, রিজলভার সামঞ্জস্যতা এবং অ্যাডমিনিস্ট্রেটর নীতিগুলি সবই DoH সক্রিয় কিনা তা প্রভাবিত করে।

অনুমান করার বদলে কভারেজ টেস্ট করুন

একজন কর্মীর ল্যাপটপে একটি সফল ব্লক একজন অতিথির ব্যক্তিগত ফোনে সমতুল্য কভারেজ প্রমাণ করে না। ডিভাইসগুলি বিভিন্ন ব্রাউজার, DNS সেটিংস বা টানেল ব্যবহার করতে পারে।

আপনার WiFi কন্টেন্ট ফিল্টার-কে একটি নির্দিষ্ট ট্র্যাফিক পাথ সহ একটি কন্ট্রোল হিসেবে বিবেচনা করুন। আপনার ভিজিটররা সাথে যে ডিভাইস এবং অ্যাপ্লিকেশনগুলি নিয়ে আসে সেগুলি ব্যবহার করে সেই পাথ পরীক্ষা করুন।

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

DoH-এর কারণে গতির যে ক্ষতি হয় এবং ফিল্টারিং এখনও যা করে

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

একটি DNS ট্র্যান্সপোর্টের অভিজ্ঞতামূলক তুলনা-য় এর নো-ডিলে লোকাল বেসলাইনে UDP এবং TLS রেসপন্স ১ মিলিসেকেন্ডের নিচে রিপোর্ট করা হয়েছে, যেখানে HTTP/2 ধারাবাহিকভাবে ১০ মিলিসেকেন্ডের নিচে ছিল; নিচের ফলাফলগুলি ভেন্যু পারফরম্যান্সের পূর্বাভাস দেওয়ার বদলে গবেষণার পরীক্ষামূলক প্রেক্ষাপটকে ধরে রাখে।

উল্লেখিত গবেষণায় প্রোটোকল অনুযায়ী DNS লুকআপ ল্যাটেন্সি

Protocol	রিপোর্ট করা ফলাফল	প্রসঙ্গ
UDP	1 ms-এর নিচে	বিলম্বহীন লোকাল বেসলাইন
TLS	1 ms-এর নিচে	বিলম্বহীন লোকাল বেসলাইন
HTTP/2	ধারাবাহিকভাবে 10 ms-এর নিচে	কানেকশন পুনরায় ব্যবহার এবং মাল্টিপ্লেক্সিং ওভারহেড কমাতে সাহায্য করে
HTTP/1.1	প্রচুর ওঠানামা করে	পাইপলাইনিং সীমাবদ্ধতার কারণে এটি ঘটে
পাবলিক DoH বনাম প্রথাগত DNS	প্রতিটি নামের জন্য ধীরগতির	সামগ্রিক পেজ লোড টাইমে উল্লেখযোগ্য কোনো বৃদ্ধি পরিলক্ষিত হয়নি

শুধু হ্যান্ডশেক নয়, পুরো সেশন পরিমাপ করুন

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

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

প্রকৃত সমস্যা প্রকাশ করে এমন অপারেশনাল সংকেতগুলি ট্র্যাক করুন:

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

ব্যবহারিক নিয়ম: ব্রাউজিং, নীতি প্রয়োগ এবং ব্যর্থতা থেকে পুনরুদ্ধারের কাজ পৃথক গ্রহণযোগ্যতা পরীক্ষা হিসেবে না দেখে একসাথে পরীক্ষা করুন।

শুধুমাত্র ল্যাটেন্সি ধারণার ভিত্তিতে একটি প্রোটোকল বেছে নেওয়ার চেয়ে একটি নিকটবর্তী, রেজিলিয়েন্ট রেজালভার এন্ডপয়েন্ট একটি ভালো শুরুর পয়েন্ট। বাস্তবসম্মত লোডের অধীনে আপনার নেটওয়ার্কে ফলাফল নিশ্চিত করুন।

সাধারণ ডিভাইসগুলিতে DoH পরীক্ষা এবং পরিবর্তন করুন

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

ব্রাউজার এবং অপারেটিং সিস্টেম পরীক্ষা করুন

1. Chrome: Settings, Privacy and security, Security খুলুন, তারপর Use secure DNS বেছে নিন। এটি বর্তমান প্রোভাইডার অনুসরণ করছে নাকি অন্য কোনো পরিষেবা নির্দিষ্ট করছে তা পরীক্ষা করে দেখুন।
2. Firefox: Settings, Privacy & Security খুলুন, তারপর DNS over HTTPS বেছে নিন। Off, Default Protection বা Max Protection সহ সুরক্ষা মোড এবং নির্বাচিত রিজলভারটি পর্যালোচনা করুন।
3. Edge: Settings, Privacy, search and services, Security খুলুন, তারপর Use secure DNS বেছে নিন। ম্যানেজড পলিসি এই সেটিংটিকে লক করে রাখতে পারে।
4. Android: Settings, Network & internet খুলুন, তারপর Private DNS বেছে নিন। এই সেটিংটি DoH-এর বদলে DoT ব্যবহার করে; ব্রাউজার স্তরের সুরক্ষিত DNS-এর জন্য আলাদা পরীক্ষার প্রয়োজন।
5. iOS এবং macOS: ইনস্টল করা কনফিগারেশন প্রোফাইল, ডিভাইস ম্যানেজমেন্ট সেটিংস এবং DNS সংক্রান্ত অ্যাপগুলি পরীক্ষা করুন। একটি এনক্রিপ্টেড DNS প্রোফাইল ব্রাউজারের থেকে স্বাধীনভাবে কাজ করতে পারে।

কার্যকর পাথটি যাচাই করুন

একটি সিস্টেম VPN ব্রাউজার সেটআপ নির্বিশেষে নিজস্ব টানেলের মাধ্যমে DNS পরিবহন করতে পারে। কোনো অ্যাপ একটি পৃথক এনক্রিপ্ট করা DNS সেবা প্রদান করে কিনা তাও পরীক্ষা করে দেখুন।

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

আপনার DoH কন্ট্রোল নির্বাচন করুন এবং লেয়ার করুন

ডিভাইসের মালিকানা এবং নীতির প্রয়োজন অনুযায়ী লেয়ার নিয়ন্ত্রণ করুন। ম্যানেজ করা কর্মীদের ল্যাপটপ একটি বাধ্যতামূলক কনফিগারেশন অনুসরণ করতে পারে; ব্যক্তিগত গেস্ট ফোন সাধারণত তা পারে না। উভয় গ্রুপে একই বিধিনিষেধ প্রয়োগ করলে এড়ানো সম্ভব এমন ফাঁক তৈরি হয় অথবা অপ্রয়োজনীয় গোলযোগ সৃষ্টি হয়।

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

প্রতিটি কন্ট্রোলকে তার প্রকৃত স্কোপের সাথে মেলান

নেটওয়ার্ক নিয়ন্ত্রণগুলি দরকারী, তবে সেগুলি প্রতিটি এনক্রিপ্ট করা রিজলভারকে শনাক্তযোগ্য করে তোলে না। একটি ব্যক্তিগত রিজলভার, পরিবর্তনশীল ঠিকানা বা VPN টানেল পরিচিত পরিষেবাগুলির একটি তালিকার চারপাশে তৈরি করা ধারণাগুলিকে ব্যর্থ করতে পারে।

শেয়ার্ড এবং পরিচালিত নেটওয়ার্কে DoH-এর জন্য নিয়ন্ত্রণসমূহ

নিয়ন্ত্রণ	এটি কী বন্ধ করে	কোথায় এটি প্রযোজ্য	সুবিধা-অসুবিধা
আউটবাউন্ড পোর্ট 853 ব্লক করুন	স্ট্যান্ডার্ড-পোর্ট DNS over TLS	ফায়ারওয়াল বা গেটওয়ে	সাধারণ HTTPS এর মাধ্যমে হওয়া DoH এর ক্ষেত্রে এটি কিছুই করে না
পোর্ট 53 কে নেটওয়ার্ক রেজলভারে বাধ্য করুন	সাধারণ DNS বাইপাস	গেটওয়ে প্রয়োগ, যা DHCP কনফিগারেশন দ্বারা সমর্থিত	DoH কে সম্পূর্ণ উপেক্ষা করে; কেবল DHCP নিয়ম মেনে চলা নিশ্চিত করতে পারে না
পরিচিত পাবলিক DoH রেজলভার ঠিকানাগুলো ব্লক করুন	তালিকাভুক্ত রেজলভারের সাথে কানেকশন	ফায়ারওয়াল বা সক্ষম গেটওয়ে	তালিকাগুলো পুরনো হয়ে যায়, নতুন রেজলভার হাজির হয়, কিছু অ্যাপ কাজ করা বন্ধ করে দেয়
ম্যানেজড পলিসির মাধ্যমে ব্রাউজার DoH নিষ্ক্রিয় করুন	আওতাভুক্ত ব্রাউজারগুলোতে ব্রাউজার-লেভেল বাইপাস	ম্যানেজড ল্যাপটপ এবং কর্মীদের ডিভাইস	গেস্ট WiFi এ থাকা ব্যক্তিগত ফোনে পৌঁছাতে পারে না
MDM এর মাধ্যমে নেটওয়ার্ক রেজলভার প্রয়োগ করুন	ডিভাইস পলিসির আওতাভুক্ত অননুমোদিত DNS পরিবর্তনসমূহ	নথিভুক্ত কর্মী এবং করপোরেট ডিভাইস	নথিভুক্তি এবং প্ল্যাটফর্ম সমর্থন প্রয়োজন; গেস্টরা এর বাইরে থাকে
DoH গ্রহণ করুন এবং এন্ডপয়েন্টে ফিল্টার করুন	নেটওয়ার্ক সাইডে কিছুই নয়	শুধুমাত্র ম্যানেজড এন্ডপয়েন্ট	গেস্ট ডিভাইসগুলো এন্ডপয়েন্ট পলিসির বাইরে থাকে

একটি রেজালভারের ঠিকানা ব্লক করলে সেই ঠিকানায় হোস্ট করা সম্পর্কহীন পরিষেবাগুলিও ব্লক হয়ে যেতে পারে। একটি ফায়ারওয়ালের এনক্রিপ্ট করা-DNS ক্যাটাগরিকে স্থায়ী, সম্পূর্ণ ইনভেন্টরি হিসাবে বিবেচনা করা এড়িয়ে চলুন।

যেখানে ডোমেন রেজোলিউশনের বাইরে আপনার নিয়ন্ত্রণের প্রয়োজন, সেখানে এন্ডপয়েন্ট এবং নেটওয়ার্ক পলিসির পাশাপাশি একটি secure web gateway মূল্যায়ন করুন। বিশেষ করে যখন ডিভাইসগুলি সংস্থার মালিকানাধীন নয়, তখন ডিপ্লয়মেন্টের প্রয়োজনীয়তাগুলি সাবধানে পরীক্ষা করুন।

একটি টেস্টযোগ্য অপারেটিং পলিসি তৈরি করুন

আপনার প্রয়োজনীয় পরিষেবাটি দিয়ে শুরু করুন। একটি কর্মী প্রশাসনিক নেটওয়ার্ক, একটি পাবলিক লাইব্রেরি সংযোগ এবং শিশুদের কার্যকলাপের ভেন্যুতে যুক্তিসঙ্গতভাবেই বিভিন্ন বিধিনিষেধ এবং ব্যবহারকারীদের জন্য আলাদা ব্যাখ্যার প্রয়োজন হতে পারে।

এই ডিপ্লয়মেন্ট চেকলিস্টটি ব্যবহার করুন:

1. প্রয়োজনীয় নীতিগুলির তালিকা তৈরি করুন। বিষয়বস্তু নিয়ন্ত্রণ বা থ্রেট ফিল্টারিং প্রয়োজন এমন SSID, VLAN এবং ডিভাইস গোষ্ঠী সনাক্ত করুন এবং প্রতিটি ক্ষেত্রে একজন দায়িত্বপ্রাপ্ত ব্যক্তি নির্ধারণ করুন।
2. গেস্ট BYOD থেকে পরিচালিত ডিভাইসগুলি পৃথক করুন। কোথায় ব্রাউজার পলিসি বা MDM প্রয়োগ করা যেতে পারে এবং কোথায় কেবল নেটওয়ার্ক নিয়ন্ত্রণ উপলব্ধ রয়েছে তা রেকর্ড করুন।
3. সাধারণ DNS বাইপাস রুটগুলি বন্ধ করুন। আপনার নীতির যেখানে প্রয়োজন, সেখানে আউটবাউন্ড DoT ব্লক করুন এবং প্রচলিত DNS-কে অনুমোদিত রিসলভারে সীমিত করুন। উভয় সমর্থিত নেটওয়ার্ক অ্যাড্রেস ফ্যামিলি কভার করুন।
4. পরিচালিত ব্রাউজার পলিসি প্রয়োগ করুন। অনুমোদিত DNS পাথ কনফিগার করুন এবং কর্মীদের ডিভাইসে অসমর্থিত ব্যবহারকারী ওভাররাইড প্রতিরোধ করুন।
5. গেস্ট-নেটওয়ার্ক রিসলভার নিষেধাজ্ঞা বজায় রাখুন। ব্লক করা রিসলভার অ্যাড্রেসগুলি নিয়মিত পর্যালোচনা করুন, ব্যতিক্রমগুলি পরীক্ষা করুন এবং যে নিয়মগুলি অনাকাঙ্ক্ষিত সাইড-ইফেক্ট হিসেবে অন্যান্য জিনিস ব্লক করে তা সরিয়ে ফেলুন।
6. সহজ ভাষায় একটি গেস্ট নোটিশ প্রকাশ করুন। কোন বিভাগগুলি ফিল্টার করা হয়েছে, কি নেটওয়ার্ক তথ্য রেকর্ড করা হয়েছে এবং এনক্রিপ্ট করা DNS বা VPN ব্যবহারের যেকোনো নিষেধাজ্ঞা ব্যাখ্যা করুন।
7. প্রতিটি নেটওয়ার্কে একটি আসল ডিভাইস পরীক্ষা করুন। অনুমোদিত সাইট, ব্লক করা বিভাগ, অনুমোদিত নিরাপত্তা পরীক্ষা গন্তব্য, রিসলভার ব্যর্থতা এবং VPN আচরণ পরীক্ষা করুন।

লঞ্চ করার আগে: একটি ব্লক পেজ প্রমাণ করে যে একটি নির্দিষ্ট অনুরোধ ফিল্টার করা হয়েছিল, এটি নয় যে ডিভাইসের প্রতিটি অ্যাপ্লিকেশন একই রুট অনুসরণ করে।

এনক্রিপ্ট করা DNS-কে গ্রহণযোগ্যতা পরীক্ষার অংশ করুন

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

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

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

---

Purple Shield গেস্ট ডিভাইসে কোনো এজেন্ট ইনস্টল না করেই সুরক্ষিত DNS, কন্টেন্ট ফিল্টারিং, থ্রেট ডিফেন্স এবং অ্যাড ব্লকিং প্রদান করে। আপনার SSID, ফিল্টারিং নীতি এবং আপনার নেটওয়ার্ক কীভাবে এনক্রিপ্টেড DNS এবং VPN পরিচালনা করে সে সম্পর্কে ট্রায়াল-পূর্ব আলোচনার আয়োজন করতে Purple Shield ভিজিট করুন।