DNS Lookup কী এবং নেটওয়ার্কগুলো কেন এটি ব্যবহার করে

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

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

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

সূচিপত্র

• একটি DNS Lookup প্রকৃতপক্ষে কীভাবে কাজ করে
  • একটি ডিরেক্টরি কোয়েরি, কোনো পেজ রিকোয়েস্ট নয়
• একটি DNS Lookup-এর অভ্যন্তরীণ ধাপসমূহ
  • Cache hit নাকি cache miss
  • TTL ক্যাশ করা উত্তরগুলোকে আপডেট রাখে
• যে হায়ারার্কি লুকআপগুলোকে প্রসারিত করে
  • রুট সিস্টেম যেভাবে উন্নত হয়েছে
• কেন একটি DNS Lookup একটি এনফোর্সমেন্ট পয়েন্ট
  • DNS পলিসি যা কভার করতে পারে এবং পারে না
• এনক্রিপ্টেড DNS প্রকৃতপক্ষে কী পরিবর্তন করে
  • শেয়ার্ড WiFi-এ ট্রেড-অফ
• যখন শেয়ার্ড WiFi-এ একটি DNS Lookup ব্যর্থ হয়
  • সেটিংস পরিবর্তন করার আগে লক্ষণগুলো আলাদা করুন
• পরবর্তীতে কীভাবে প্রোটেক্টিভ DNS বেছে নেবেন
  • পলিসি এবং অপারেশনাল ফিট তুলনা করুন

একটি DNS Lookup আসলে কী করে

একজন অতিথি একটি হোটেল WiFi নেটওয়ার্কে একটি লিঙ্কে ট্যাপ করেন। ব্রাউজার ডোমেন নামটি জানে, তবে নেটওয়ার্ক ডিভাইসগুলি IP ঠিকানা ব্যবহার করে ট্র্যাফিক রুট করে। একটি DNS লুকআপ হলো রিজলভারের সেই মানুষ-পাঠযোগ্য নামের সাথে সম্পর্কিত তথ্য (সবচেয়ে বেশি একটি IP ঠিকানা) খুঁজে বের করা, যাতে ডিভাইসটি পরিষেবায় পৌঁছাতে শুরু করতে পারে।

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

মৌলিক DNS স্পেসিফিকেশনগুলো নভেম্বর ১৯৮৭-এ প্রকাশিত হয়েছিল, যখন ইন্টারনেট ইঞ্জিনিয়ারিং টাস্ক ফোর্স RFC 1034 প্রকাশ করে। সেই নথিতে চার ধাপের একটি অ্যালগরিদম বর্ণনা করা হয়েছিল: স্থানীয় তথ্য পরীক্ষা করা, সেরা সার্ভারগুলো খুঁজে বের করা, কোনো প্রতিক্রিয়া না আসা পর্যন্ত সেগুলোতে কোয়েরি পাঠানো এবং উপযুক্ত ক্ষেত্রে ফলাফল রিটার্ন ও ক্যাশ করা (RFC 1034)। ক্যাশিং গুরুত্বপূর্ণ কারণ একটি রিজলভারের কাছে পূর্ববর্তী অনুরোধ থেকে ইতিমধ্যে একটি ব্যবহারযোগ্য উত্তর থাকতে পারে।

একটি ডিরেক্টরি কুয়েরি, কোনো পেজ অনুরোধ নয়

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

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

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

একটি DNS লুকআপের ভেতরের পর্যায়সমূহ

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

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

Cache hit নাকি cache miss

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

একটি ওয়েবসাইটের জন্য, উত্তরটি সাধারণত একটি IPv4 ঠিকানা ধারণকারী A record বা একটি IPv6 ঠিকানা ধারণকারী AAAA record হয়। অন্যান্য রেকর্ডের ধরন মেইল রাউটিং এবং অ্যালিয়াসের মতো কাজগুলি কভার করে।

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

TTL ক্যাশে করা উত্তরগুলিকে সাম্প্রতিক বা আপডেট রাখে

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

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

কিছু নেটওয়ার্ক সরাসরি হায়ারার্কি অনুসরণ করার বদলে অন্য একটি রিজলভারে অনুসন্ধান পাঠিয়ে এই অনুক্রমের মধ্যে একটি ফরওয়ার্ডিং ধাপ যুক্ত করে। কিভাবে DNS ফরওয়ার্ডিং সেই পথ পরিবর্তন করে তার এই ওয়াকথ্রুটি ব্যাখ্যা করে যে কোথায় পথ পরিবর্তন ঘটে।

যে হায়ারার্কি লুকআপগুলিকে স্কেল করতে সাহায্য করে

DNS হায়ারার্কি দায়িত্ব ভাগ করে দেয়। শীর্ষে রয়েছে রুট-সার্ভার আইডেন্টিটিগুলি, যা রিজলভারগুলিকে সঠিক টপ-লেভেল ডোমেনের দিকে পরিচালিত করে। TLD সার্ভারগুলি .com এবং .org-এর মতো ডোমেনগুলি পরিচালনা করে, যখন প্রতিটি ডোমেনের অথরিটেটিভ সার্ভার সেই ডোমেনের ভেতরের নামগুলির রেকর্ড সরবরাহ করে।

১৩টি মূল সার্ভারের সাধারণ ধারণাটি বিভ্রান্তিকর হতে পারে। ঐতিহাসিক মান অনুসারে A থেকে M পর্যন্ত চিহ্নিত ১৩টি সত্তা রয়েছে, যা ১২টি স্বতন্ত্র সংস্থা দ্বারা পরিচালিত হয়। এগুলো কেবল ১৩টি ফিজিক্যাল কম্পিউটার নয়। Anycast রাউটিংয়ের মাধ্যমে এই একই সত্তাগুলোর পরিষেবা বিশ্বব্যাপী ৯০০টিরও বেশি ডিস্ট্রিবিউটেড ইনস্ট্যান্স থেকে প্রদান করা যায়, যা কুয়েরিগুলোকে নিকটস্থ ইনস্ট্যান্সে পৌঁছাতে সাহায্য করে এবং স্থিতিস্থাপকতা বৃদ্ধি করে (ICANN's overview of root servers)।

root সিস্টেম কীভাবে উন্নত হয়েছে

নেটওয়ার্কের চাহিদা পরিবর্তনের সাথে সাথে রুট সিস্টেমের বিকাশ ঘটেছে। প্রথম রুট সার্ভারটি ১৯৮৪ সালে ইউনিভার্সিটি অফ সাউদার্ন ক্যালিফোর্নিয়ার ইনফরমেশন সায়েন্সেস ইনস্টিটিউটে প্রতিষ্ঠিত হয়। ১৯৮৫ সালের মধ্যে সিস্টেমটিতে চারটি, ১৯৮৭ সালের মধ্যে সাতটি, ১৯৯৩ সালের মধ্যে নয়টি এবং ১৯৯৭ সালের মধ্যে ১৩টি সার্ভার ছিল। আজ, রুট সিস্টেমটি IPv4 এবং IPv6 উভয়ই ব্যবহার করে। একটি প্রযুক্তিগত বিবরণ অনুযায়ী ডিস্ট্রিবিউটেড anycast ইনস্ট্যান্সের পাশাপাশি ২৬টি প্রধান অ্যাড্রেস এন্ডপয়েন্ট রয়েছে, প্রতিটি প্রোটোকলের জন্য ১৩টি করে।

এই পরিসংখ্যানগুলি ডিজাইনের বিভিন্ন অংশ ব্যাখ্যা করে। ১৩টি আইডেন্টিটি হলো সনাক্তযোগ্য রুট-সার্ভারের নাম; ঠিকানা এন্ডপয়েন্টগুলি IPv4 এবং IPv6 সমর্থন করে; এবং বিতরণ করা ইনস্ট্যান্সগুলি বিশ্বজুড়ে বিভিন্ন অবস্থান থেকে পরিষেবা দিতে সহায়তা করে। একটি ইনস্ট্যান্সে অ্যাক্সেস হারানো মানে সব জায়গা থেকে একটি রুট আইডেন্টিটি হারানো নয়।

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

কেন একটি DNS লুকআপ একটি প্রয়োগকারী বিন্দু

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

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

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

DNS নীতি কী কভার করতে পারে এবং কী পারে না

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

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

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

নেতিবাচক উত্তরগুলোর দিকেও মনোযোগ দেওয়া প্রয়োজন। একটি রিজলভার একই অনুপস্থিত নামের জন্য বারবার আপস্ট্রিম সার্ভারগুলোকে জিজ্ঞাসা না করে একটি NXDOMAIN প্রতিক্রিয়া ক্যাশ করতে পারে, যা উল্লেখ করে যে অনুরোধ করা ডোমেইনটির কোনো অস্তিত্ব নেই। RFC 8020 একটি NXDOMAIN cut-এর বর্ণনা দেয়, যেখানে একটি যাচাইকৃত নেতিবাচক উত্তর এটিও নিশ্চিত করে যে অনুপস্থিত ডোমেইনের অধীনে থাকা নামগুলোরও কোনো অস্তিত্ব নেই (RFC 8020)। নতুন IETF নির্দেশিকায় রেজোলিউশন ব্যর্থতাগুলো ক্যাশ করার জন্য বলা হয়েছে, যা অহেতুক বারবার কুয়েরি পাঠানো হ্রাস করে।

এনক্রিপ্টেড DNS প্রকৃতপক্ষে যা পরিবর্তন করে

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

ডিভাইসটি একটি রিকার্সিভ রিজলভারে তার অনুসন্ধান পাঠায়, যা উত্তর খুঁজে বের করে তা ফেরত দেয়। DNS over HTTPS (DoH) ডিভাইস এবং সেই রিজলভারের মধ্যকার সংযোগকে এনক্রিপ্ট করে। WiFi পর্যবেক্ষণকারী কারো পক্ষে অনুসন্ধানটি পড়া বা পরিবর্তন করা কঠিন হতে পারে, তবে রিজলভার এখনও অনুরোধ করা ডোমেনটি গ্রহণ করে।

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

শেয়ার করা WiFi-এর ট্রেড-অফ

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

ব্যবহারিক পার্থক্যটি স্পষ্ট: DoH রিজলভারের পথে অনুসন্ধান সুরক্ষিত করে; এটি সেই রিজলভারের কাছ থেকে অনুসন্ধানটি লুকায় না। DNSSEC স্বাক্ষরিত উত্তরগুলি যাচাই করতে সহায়তা করে। একটি ভেন্যু শুধুমাত্র তখনই DNS নীতি প্রয়োগ করতে পারে যখন প্রাসঙ্গিক অনুসন্ধানগুলি এমন একটি রিজলভারের মাধ্যমে যায় যা এটি নিয়ন্ত্রণ করে বা যার সাথে একত্রিত হয়েছে, এবং কোনো প্রযুক্তিই একজন ব্যবহারকারীকে বেনামী করে না।

শেয়ার করা WiFi-এ যখন একটি DNS লুকআপ ব্যর্থ হয়

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

একটি resolver নাগালের বাইরে চলে যেতে পারে, অসম্পূর্ণ উত্তর ফেরত দিতে পারে, অথবা কোনো সংস্থার নেটওয়ার্কের ভেতরে থাকা কোনো নাম রিমুভ বা সলভ করতে অক্ষম হতে পারে। কোনো নেটওয়ার্ক UDP বা TCP পোর্ট 53-এর মাধ্যমে প্রথাগত DNS ট্র্যাফিক ব্লকও করতে পারে, অথবা নীতিগত কারণে অনুরোধ করা ডোমেনটি ব্লক থাকার ফলে ইচ্ছে করেই ব্যর্থতার মেসেজ ফেরত দিতে পারে।

সেটিংস পরিবর্তন করার আগে উপসর্গগুলি আলাদা করুন

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

এনক্রিপ্টেড DNS আরও একটি ব্যর্থতার পয়েন্ট যোগ করতে পারে। ২০২৫ সালের একটি গবেষণায় দেখা গেছে যে HTTPS DNS কুয়েরিগুলো পর্যবেক্ষিত DNS ট্রাফিকের প্রায় ৮% জুড়ে ছিল এবং অসম্পূর্ণ প্রতিক্রিয়া কুয়েরির পরিমাণ বাড়িয়ে দিয়েছিল (study of encrypted DNS traffic)। পৃথক রিজলভার গবেষণায় দেখা গেছে যে বিজ্ঞাপিত প্রতি তিনটি এনক্রিপ্টেড রিজলভারের মধ্যে একটি উত্তর দিতে ব্যর্থ হয়েছে, যা পূর্বে উল্লেখ করা হয়েছে। তাই ভেন্যুর নির্ধারিত রিজলভার উপলব্ধ থাকা সত্ত্বেও, একজন ক্লায়েন্ট এমন একটি এনক্রিপ্টেড রিজলভার ব্যবহার করতে পারে যা প্রত্যাশা অনুযায়ী সাড়া দেয় না।

ট্রাবলশুটিং নিয়ম: গেস্টকে DNS সেটআপ পরিবর্তন করতে বলার আগে ক্লায়েন্ট প্রকৃতপক্ষে কোন resolver ব্যবহার করছে তা নিশ্চিত করুন।

অপারেটরদের জন্য, প্রতিটি লুকআপ ত্রুটিকে একইভাবে না দেখে সম্ভাব্য কারণগুলো সাজিয়ে নিন:

• Captive Portal: ডিভাইসটি WiFi সাইন-ইন বা শর্তাবলী সম্পর্কিত পেজ সম্পন্ন করেনি।
• পুরোনো ক্যাশ: ক্লায়েন্ট বা resolver একটি পুরোনো উত্তর ধরে রেখেছে।
• আপস্ট্রিম আউটেজ: কনফিগার করা resolver রিকোয়েস্টটি সম্পন্ন করতে পারছে না।
• ব্লক করা পোর্ট 53: ঐতিহ্যবাহী DNS ট্র্যাফিক ব্লক করা হয়েছে বা resolver-এ পৌঁছাতে পারছে না।
• অসমর্থিত DoH বা DoT: ক্লায়েন্টের এনক্রিপ্টেড DNS আচরণ নেটওয়ার্ক দ্বারা সমর্থিত বা পরিচালিত নয়।
• পলিসি ব্লক: resolver ইচ্ছাকৃতভাবে একটি উত্তর প্রদান স্থগিত রেখেছে।

একটি DNS ত্রুটি resolver সমস্যার চেয়ে বরং একটি WiFi নিরাপত্তা সমস্যাও নির্দেশ করতে পারে। একটি প্রতারণামূলক অ্যাক্সেস পয়েন্ট শনাক্ত করার নির্দেশিকা পেতে, RDE Technologies-এর evil twin প্রতিরোধ গাইড দেখুন।

এরপর কীভাবে সুরক্ষামূলক DNS বেছে নেবেন

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

পদ্ধতি	আনম্যানেজড ডিভাইসসমূহ	সিদ্ধান্ত নেওয়ার পয়েন্ট	অপারেটর প্রমাণ
ক্লায়েন্ট-নির্বাচিত সমাধানকারী (resolvers)	প্রায়শই ভেন্যুর DNS পলিসির বাইরে থাকে	ডিভাইস বা ব্রাউজার দ্বারা নির্বাচিত resolver	সীমিত নেটওয়ার্ক-ব্যাপী দৃশ্যমানতা
শুধুমাত্র পুরোনো ফায়ারওয়াল	কভারেজ ফায়ারওয়াল নিয়ম এবং ট্র্যাফিক পাথের ওপর নির্ভর করে	সেই নেটওয়ার্কের জন্য উপলব্ধ ফায়ারওয়াল নিয়ন্ত্রণসমূহ	ফায়ারওয়াল লগ এবং অ্যালার্টসমূহ
ক্লাউড প্রোটেক্টিভ DNS resolver	নেটওয়ার্ক-অ্যাসাইন করা resolver ব্যবহার করে ডিভাইসগুলোকে কভার করতে পারে	ঠিকানা ফেরত দেওয়ার আগে ডোমেন লুকআপ	resolver থেকে লুকআপ এবং ব্লক সম্পর্কিত রিপোর্ট

হসপিটালিটি, শিক্ষা, স্বাস্থ্যসেবা, পাবলিক সেক্টর এবং মাল্টি-সাইট নেটওয়ার্কের জন্য, পূর্বে যেমন উল্লেখ করা হয়েছে, Purple Shield হলো একটি সুরক্ষামূলক DNS বিকল্প। এটি সংযোগ শুরু হওয়ার আগেই লুকআপগুলো মূল্যায়ন করে, অ্যাডাল্ট এবং জুয়ার মতো বিষয়বস্তু ক্যাটাগরি প্রয়োগ করে, Google, Bing এবং YouTube-এ Safe Search বাধ্যবাধকতামূলক করে এবং কমান্ড-অ্যান্ড-কন্ট্রোল, ফিিশিং ও ম্যালওয়্যার ডোমেইনগুলোকে ব্লক করে। ভেণ্ডর AI-সহায়ক সিগন্যালের বিবরণও দেয় যা সাধারণ ব্লকলাইস্টের আগেই উদীয়মান হুমকি চিহ্নিত করার জন্য তৈরি, পাশাপাশি এটি DNS লেয়ারে বিজ্ঞাপন ও ট্র্যাকার ব্লক করে যা পেজের ওয়েট এবং ট্রাফিকের পরিমাণ হ্রাস করে বলে দাবি করা হয়।

নীতি এবং অপারেশনাল মানানসইতা তুলনা করুন

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

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

একটি অতিথি SSID দিয়ে শুরু করুন। আজ এর ডিভাইসগুলি কোন রিজলভার ব্যবহার করে তা রেকর্ড করুন, তারপর স্থান জুড়ে পলিসি বা নীতি প্রসারিত করার আগে সেই নেটওয়ার্কে Purple Shield পরীক্ষা করুন।