DNS ফরওয়ার্ডিং কী? এটি কীভাবে কাজ করে এবং কেন এটি গুরুত্বপূর্ণ

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

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

সূচিপত্র

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

DNS Forwarding এর প্রকৃত অর্থ কী

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

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

DNS আত্মপ্রকাশ করে নভেম্বর ১৯৮৩-তে, যখন RFC 882 এবং RFC 883 ক্রমবর্ধিষ্ণু অনিয়ন্ত্রণযোগ্য HOSTS.TXT মডেল প্রতিস্থাপন করতে একটি অনুক্রমিক নামকরণের সিস্টেম প্রবর্তন করেছিল। DNS-এর আগে, প্রশাসকরা ম্যানুয়ালি রক্ষণাবেক্ষণ করা নাম-থেকে-ঠিকানার ম্যাপের উপর নির্ভর করতেন। নভেম্বর ১৯৮৭-তে, RFC 1034 এবং RFC 1035 মূল স্পেসিফিকেশনগুলোকে প্রতিস্থাপন করে এবং আধুনিক DNS আর্কিটেকচারের জন্য মৌলিক মানদণ্ড হয়ে ওঠে, যা DNS-এর ইতিহাসের টাইমলাইনে রেকর্ড করা আছে।

যেখানে আপনি ফরওয়ার্ডিংয়ের মুখোমুখি হবেন

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

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

ক্লায়েন্ট থেকে উত্তর পর্যন্ত একটি কোয়েরি অনুসরণ করা

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

DNS পরিভাষায়, ফরোয়ার্ডিং-এর সাথে যুক্ত থাকে একটি resolver কর্তৃক recursion-desired (RD) bit সেট করে একটি কোয়েরি পাঠানো। সেই বিটটি নির্দেশ করে যে গ্রহণকারী resolver-কে কোয়েরিটি সমাধান করতে বলা হচ্ছে, সেই অনুরোধ ছাড়া কেবল একটি প্যাকেট রিলে করা হচ্ছে না। RFC 7719-এর গ্লসারি সংজ্ঞায় ব্লাইন্ড প্যাকেট রিলের থেকে ফরোয়ার্ডিং-এর পার্থক্য তুলে ধরা হয়েছে।

ক্যাশ মিস হলে, আপস্ট্রিম রিকার্সিভ রিযলভার লুকআপের কাজটি করে। এটি উত্তরের জন্য তার নিজস্ব ক্যাশ ব্যবহার করতে পারে বা DNS হায়ারার্কির মাধ্যমে কুয়েরি করতে পারে। উত্তরটি তখন ফরোয়ার্ডিং রিযলভারের মাধ্যমে ক্লায়েন্টের কাছে ফিরে আসে।

দুটি সম্ভাব্য পথ

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

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

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

Recursion এবং Authoritative Service থেকে Forwarding যেভাবে আলাদা

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

xb0মিMissing, ভুল, বা সেই জোনগুলির জন্য অনুপলব্ধ রেকর্ডসমূহ

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

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

কেন এই পার্থক্যটি ট্রাবলশুটিং পরিবর্তন করে

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

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

Conditional Forwarding, Split Horizon এবং Loop Prevention

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

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

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

রিজলভার লুপ প্রতিরোধ করা

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

কিছু নামেরও একটি সুস্পষ্ট সীমানা প্রয়োজন। RFC 9539 নির্দেশ করে home.arpa-এর মতো নেমস্পেসগুলোর দিকে যা তাদের উদ্দেশ্যযুক্ত স্থানীয় সীমার বাইরে ফরোয়ার্ড করা উচিত নয়। দ্বিতীয় forwarder যোগ না করা পর্যন্ত কাজ করে এমন একটি resolver হয়তো কোনো লুপ তৈরি করেছে; কোনো লোকাল নাম যা সর্বজনীনভাবে সলভ হওয়া শুরু হয়, সেটির জন্য আরও নির্দিষ্ট ফরোয়ার্ডিং বা লোকাল-জোন নিয়মের প্রয়োজন হতে পারে।

নিচের ভিডিওটি DNS forwarding ধারণার আরেকটি দৃশ্যমান পরিচয় প্রদান করে।

Caching এবং TTL যেভাবে Forwarding Performance গঠন করে

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

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

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

গড় লেটেন্সির চেয়ে বেশি কিছু পরিমাপ করুন

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

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

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

Forwarding, Root-Hints Recursion এবং Encrypted DNS এর মধ্যে নির্বাচন করা

ফরোয়ার্ডিং এবং root-hints recursion ভিন্ন ধরনের সুবিধা-অসুবিধা অফার করে। ফরোয়ার্ডিং-এর মাধ্যমে, একটি প্রতিষ্ঠান উত্তর না পাওয়া কোয়েরিগুলো হ্যান্ডেল করার জন্য upstream resolver নির্বাচন করে। এটি স্থানীয় অপারেশনগুলোকে সহজ করতে পারে এবং নীতিকে কেন্দ্রীভূত করতে পারে, তবে এটি নেটওয়ার্কটিকে নির্বাচিত upstream সার্ভিসগুলোর উপর নির্ভরশীল করে তোলে। root-hints recursion-এর ক্ষেত্রে, একটি resolver নিজেই পুনরাবৃত্তিমূলক লুকআপ সম্পাদন করে, যা একক upstream পুনরাবৃত্তিমূলক সার্ভিসের উপর নির্ভরতা কমায় তবে সেই resolver-এর ওপর রেজোলিউশনের দায়িত্ব বাড়িয়ে দেয়।

ডিজাইন পছন্দ	যেখানে সমাধান ঘটে	প্রধান অপারেশনাল ট্রেড-অফ
Forwarding	নির্বাচিত আপস্ট্রিম রিকার্সিভ রিযলভারে	আপস্ট্রিম নির্ভরতা সহ কেন্দ্রীয় প্রশাসন
Root-hints recursion	স্থানীয় রিকার্সিভ রিযলভারে, যা হায়ারার্কির মাধ্যমে কুয়েরি করে	প্রত্যক্ষ সমাধানের জন্য আরও দায়িত্ব সহ আরও স্থানীয় নিয়ন্ত্রণ
Client-directed encrypted DNS	এনক্রিপ্ট করা কানেকশনের মাধ্যমে ক্লায়েন্ট যে রিযলভারের সাথে যোগাযোগ করে সেখানে	স্থানীয় নেটওয়ার্ক ডোমেইন কুয়েরি দেখতে বা নিয়ন্ত্রণ করতে না-ও পার হতে পারে

এনক্রিপ্টেড DNS সিদ্ধান্তকে কিছুটা জটিল করে তোলে। DNS over TLS এবং DNS over QUIC ট্রানজিটের সময় DNS ট্রাফিক সুরক্ষিত করতে পারে, তবে গুরুত্বপূর্ণ প্রশ্ন হলো এনক্রিপশন কোথায় শেষ হয়। যদি কোনো ক্লায়েন্ট সরাসরি একটি এক্সটার্নাল resolver-এ কোয়েরি এনক্রিপ্ট করে, তবে একটি স্থানীয় forwarder একটি ব্যবহারযোগ্য ডোমেন কোয়েরি দেখতে নাও পেতে পারে। যদি কোনো অনুমোদিত এন্টারপ্রাইজ resolver-এ এনক্রিপশন শেষ হয়, তবে সেই resolver এখনও নেটওয়ার্ক পলিসি প্রয়োগ করতে এবং upstream-এ কোয়েরি ফরোয়ার্ড করতে পারে।

পাবলিক WiFi এর জন্য সুচিন্তিত পলিসি প্রয়োজন

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

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

আপনার নেটওয়ার্কে Forwarding কার্যকর করা

Forwarding একটি সংস্থার নির্বাচিত আপস্ট্রিম পরিষেবাগুলিতে কিছু DNS ওয়ার্কলোডকে ঘনীভূত করে। DNS-OARC's Day in the Life ডেটাসেট ব্যবহার করে করা পরিমাপ অনুসারে দেখা গেছে যে প্রায় 99% রিকার্সিভ রিযলভার মাঝারি পরিমাণের কুয়েরি তৈরি করেছে, যেখানে প্রায় 1% আগ্রাসী আচরণ করেছে। সেই ছোট দলটি 2018 সালে পর্যবেক্ষিত DNS ট্রাফিকের 98% এবং 2019 সালে 93% এর জন্য দায়ী ছিল; গবেষকরা অনুমান করেছিলেন যে এর মধ্যে আনুমানিক 2018 সালে 8,300টি রিযলভার এবং 2019 সালে 14,000টিরও বেশি অন্তর্ভুক্ত ছিল (আগ্রাসী রিযলভার আচরণের অধ্যয়ন)। একটি স্থানীয় রিযলভার আপস্ট্রিম রিকার্সিভ পরিষেবাগুলিতে অনুরোধ পাঠাতে পারে যা উত্তরগুলি ক্যাশ করে এবং পুনরায় ব্যবহার করে, তবে এটি তাদের প্রাপ্যতা এবং আচরণের উপর নির্ভরতাকে ঘনীভূত করে।

ফরওয়ার্ডিং ডিপ্লয় বা পরিবর্তন করার আগে, নিশ্চিত করুন যে:

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

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

---

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