Split-DNS ক্যাপচার: প্রতিটি পর্যবেক্ষণ কোথায় নেওয়া হয়েছে তা বলুন

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

একটি লুকআপ, কয়েকটি পর্যবেক্ষণ বিন্দু

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

প্রত্যেকে ভিন্ন প্রশ্নের উত্তর দেয়, এবং এর কোনোটিই একা প্রমাণ করে না কোয়েরি কোথায় গেছে।

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

ক্লায়েন্টের ফিল্টার অ্যাপ ও তারের মাঝখানে বসে

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

Cisco-এর Secure Client Split-DNS নির্দেশিকা ডোমেইন মিলানো ও Windows ফিল্টার কভার করে, এবং অ্যাপটি নেটিভ resolver API ব্যবহার করলে কী দেখে তার সঙ্গে nslookup-এর মতো টুল কী দেখে তা আলাদা করে। এই পার্থক্যগুলোই মূল কথা।

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

nslookup অ্যাপের চেয়ে ভিন্ন পথ নেয়

nslookup নিজের DNS কোয়েরি তৈরি করে এবং অপারেটিং সিস্টেমের resolver নীতি এড়িয়ে যেতে পারে। তাই এটি নির্দিষ্ট সার্ভারকে নির্দিষ্ট প্রশ্ন করতে দরকারি, অথচ অ্যাপ্লিকেশন কী অভিজ্ঞতা পাবে তা পরীক্ষা করতে বিভ্রান্তিকর।

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

নীতিটি পড়ুন, তারপর সাধারণ resolver দিয়ে একই প্রশ্ন করুন:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

এনক্রিপ্টেড resolver কোয়েরি লুকায়, সংযোগ নয়

নিজস্ব DNS-over-HTTPS resolver থাকা ব্রাউজার সম্পূর্ণ ভিন্ন ঘটনা। কোয়েরি TLS-এর ভেতরে বের হয়, তাই প্যাকেট ক্যাপচার resolver ঠিকানার সংযোগ দেখায় কিন্তু যে নামটি জিজ্ঞাসা করা হচ্ছে তা দেখায় না।

প্রথমে ব্রাউজারের পরিচালিত নীতি বের করুন, তারপর তা অপারেটিং সিস্টেমের লুকআপের সঙ্গে মেলান। নিজের resolver বেছে নেওয়ার অনুমতি পাওয়া ব্রাউজার Split-DNS নীতি একেবারেই নাও দেখতে পারে।

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

লেবেলযুক্ত পরীক্ষার সঙ্গে তুলনা করুন

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

যেখানে অনুমোদিত, resolver-এর প্রাপ্তির সঙ্গে একটি সংকীর্ণ ক্লায়েন্ট বা গেটওয়ে পর্যবেক্ষণ মেলান:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

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