কে চালায় 1.1.1.1? বিশ্বাস করার আগে একটি DNS ঠিকানা যাচাই
একটি VPN-এর সঙ্গে ব্যবহৃত DNS ঠিকানা অবশ্যই সেই VPN চালায় না। রিজলভারটি শনাক্ত করুন, তারপর পাথ ও প্রাইভেট নামের নীতি আলাদাভাবে যাচাই করুন।
আপনি VPN-এর DNS ফিল্ডে 1.1.1.1 পেস্ট করেছেন, পৃষ্ঠাটি লোড হয়েছে, আর টিউটোরিয়ালটি এখন নিশ্চিত বলে মনে হচ্ছে। এই পর্যবেক্ষণটি যতটা মনে হয় তার চেয়ে সংকীর্ণ: অ্যাপ্লিকেশনটি ভিন্নভাবে আচরণ করেছে, আর পরিবর্তনটি এখনও বলে না কে কোয়েরির উত্তর দিয়েছে বা আগের ব্যবস্থাটি কেন ব্যর্থ হয়েছে। নকল করা টিউটোরিয়াল প্রায়ই একটি পরিচিত পাবলিক ঠিকানাকে “VPN-এর DNS” বলে, যা মালিকানা সম্পর্কে একটি দাবি, পৌঁছানোর ক্ষমতা সম্পর্কে নয়। ঠিকানাটি কী বোঝায় তা যাচাই করতে পাঁচ মিনিট লাগে এবং ভুল কারণে করা স্থায়ী পরিবর্তন ঠেকায়।
কাজ করা একটি সেটিং পরিচয় নয়
সেটিংস ফিল্ডের ঠিকানাটি একটি প্রান্তবিন্দু, আর প্রান্তবিন্দুর একজন পরিচালক থাকে। এই দুটি তথ্য আলাদা, এবং দ্বিতীয়টি মানুষ এড়িয়ে যায়। সবচেয়ে বেশি কপি করা জোড়াটির ক্ষেত্রে উত্তরটি প্রকাশ্য: Cloudflare 1.1.1.1 এবং 1.0.0.1 কে তার রিজলভার ঠিকানা হিসেবে প্রকাশ করে এবং সেগুলো তার অফিসিয়াল ঠিকানা রেফারেন্সে তালিকাভুক্ত করে। তাই পরিচালকের নাম ঠিকানার পাশে থাকে, আলাদা টিউটোরিয়ালে নয়।
টানেল চালু থাকা অবস্থায় ওই জোড়া প্রবেশ করালে VPN কোম্পানি তার পরিচালক হয় না, আর ট্রাফিক বেনামি হয় না। কোয়েরি আপনার মেশিন ছেড়ে যায় একটি কোম্পানির দিকে যা ঠিকানা পরিসর প্রকাশ করে, আর সেই কোম্পানি সম্মানিত হতে পারে এবং তবুও টিউটোরিয়ালটি যে পক্ষ বোঝাচ্ছিল তা নাও হতে পারে। নির্দেশনার লেবেল এবং বাস্তবের পরিচালক ভিন্ন দাবি। কোনোটিই বলে না মাঝখানের নেটওয়ার্ক পাথ কে চালায়।
একটি ঠিকানা জোড়া বা এনক্রিপ্টেড প্রান্তবিন্দু নিশ্চিত করতে রিজলভারের নিজের প্রকাশিত রেফারেন্স ব্যবহার করুন। অন্য বিক্রেতার সুপারিশ বৈধ হতে পারে, আর “দ্বারা সুপারিশকৃত”, “মাধ্যমে পৌঁছানো” এবং “দ্বারা পরিচালিত” এখনও তিনটি ভিন্ন সম্পর্ক বর্ণনা করে।
একটি রেকর্ডের যে তিনটি জিনিস দরকার তা তুলনা করুন
পর্যালোচনার জন্য প্রস্তুত রেকর্ড তিনটি প্রশ্ন আলাদা করে: কে কোয়েরি পাবে, বিনিময়টি সাধারণ না এনক্রিপ্টেড, এবং কোন পাথ এটি বহন করবে। প্রদানকারীর নাম দ্বিতীয় বা তৃতীয়টি পূরণ করতে পারে না, আর দেশের লেবেল এর কোনোটিই পূরণ করতে পারে না। পরিবর্তনের আগে তিনটি এন্ট্রি লিখে রাখুন এবং পরে তুলনা করুন। এই এন্ট্রিগুলো বিনিময়যোগ্য নয়, আর সেগুলোকে একটি হিসেবে দেখা হলো সেই উপায় যেখানে অনুমান ডকুমেন্টেশন হয়ে ওঠে।
তুলনাই একটি কাজ করা সেটিংকে নথিভুক্ত সিদ্ধান্তে বদলে দেয়। এটি ছাড়া পরের ব্যক্তি কোনো কারণ ছাড়াই একটি ঠিকানা উত্তরাধিকারে পায়। নিচের সারণির তৃতীয় কলামটি আগে পড়ুন, কারণ সেখানেই বেশিরভাগ আত্মবিশ্বাসী ব্যাখ্যা সত্যিই থেমে যায়।
| Entry | What it records | What it cannot tell you |
|---|---|---|
| Recipient | Which resolver should answer | Who operates the path to it |
| Transport | Plain DNS or an encrypted variant | Whether names stay private |
| Path | Which interface carries the query | Which upstream answers last |
সারণিটি ইচ্ছাকৃতভাবে সংক্ষিপ্ত। এর মূল কথা হলো প্রতিটি এন্ট্রি ভিন্ন প্রশ্নের উত্তর দেয়, আর কোনো একক ফিল্ড তিনটিই পূরণ করে না।
একটি স্থানীয় ফরওয়ার্ডার আসল উৎস লুকায়
যে ডিভাইসটি তার রাউটারকে DNS হিসেবে ব্যবহার করতে সেট করা, সেটি একটি ফরওয়ার্ডারের দিকে ইঙ্গিত করছে। ওই ঠিকানা কোয়েরির পরবর্তী প্রাপককে চিহ্নিত করে, যে রিজলভার শেষে উত্তর দেয় তাকে নয়। একটি স্থানীয় স্টাব রিজলভার একই অতিরিক্ত ধাপ যোগ করে, আর এটিকে আসল জিনিসের সঙ্গে গুলিয়ে ফেলা সহজ, কারণ এটি প্রতিটি স্ট্যাটাস আউটপুটে দেখা যায়।
স্টাব সেগুলো উৎসের কাছে পাঠায় যেগুলো একই আউটপুটেও তালিকাভুক্ত থাকে, সাধারণত আরও নিচে। পরিচালক সম্পর্কে কিছু সিদ্ধান্তে আসার আগে পুরো চেইনটি পড়ুন, কারণ প্রথম লাইনটিই পুরো উত্তর নয়। অন্যথায় আপনি রিসেপশনকেই কোম্পানি বলছেন।
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'দ্বিতীয় কমান্ডটি একটি রিজলভারের ইকো নাম ব্যবহার করে, যেখানে পরিচালক একটি প্রকাশ করেন, যে উৎস ঠিকানা এটি দেখে তা জানাতে। তৃতীয়টি যে সার্ভার উত্তর দিয়েছে তার নাম বলে, যা প্রায়ই আপনার কনফিগার করা ঠিকানা নয়। পরিচালক লেখার আগে তিনটি আউটপুটই তুলনা করুন।
এনক্রিপ্টেড DNS যা দৃশ্যমান তা বদলায়, কে দেখে তা নয়
DNS over HTTPS এবং DNS over TLS ক্লায়েন্ট ও রিজলভারের মধ্যে বিনিময় রক্ষা করে। রিজলভার এখনও প্রতিটি নাম পড়ে যা তাকে জিজ্ঞাসা করা হয়, কারণ উত্তর দেওয়াই কাজ। যা বদলায় তা হলো কে বিনিময়টি দেখতে পারে: স্থানীয় নেটওয়ার্ক একটি প্রান্তবিন্দুর সঙ্গে সংযোগ দেখে, সাধারণ পাঠ্যের কোয়েরির প্রবাহ নয়।
যা বদলায় না তা হলো বিশ্বাসের সম্পর্ক, যা এখনও যে সংস্থা ওই প্রান্তবিন্দু চালায় তার দিকেই ইঙ্গিত করে। নিজের সুরক্ষিত DNS সেটিংসহ একটি ব্রাউজার অপারেটিং সিস্টেমের রিজলভারকে সম্পূর্ণ এড়িয়ে যেতে পারে। এগুলোকে দুটি কনফিগারেশন হিসেবে দেখুন যা পরস্পরবিরোধী হতে পারে, দুবার প্রয়োগ করা একটি সেটিং হিসেবে নয়।
প্রাইভেট নামের আবার নিজের সিদ্ধান্ত দরকার। একটি কাজের টানেল নির্বাচিত ডোমেইনকে সাংগঠনিক রিজলভারের দিকে পাঠাতে পারে, আর সেটি পাবলিক সেবা দিয়ে বদলে দিলে অভ্যন্তরীণ অনুসন্ধান ভাঙতে পারে বা অভ্যন্তরীণ নাম ভুল পক্ষের কাছে প্রকাশ করতে পারে। পুরো অ্যাডাপ্টারের সেটিংস বদলানোর আগে ডোমেইন নীতি যাচাই করুন।
পর্যবেক্ষণটি সংকীর্ণ রাখুন
তুলনা করার সময় পুরনো কনফিগারেশন সংরক্ষণ করুন এবং একবারে একটি সেটিং বদলান। অ্যাপ্লিকেশন, অপারেশন, রিজলভার নীতি এবং পুনরায় সংযোগের পরে পাবলিক ও অনুমোদিত প্রাইভেট নাম এখনও রিজলভ হয় কি না তা লিপিবদ্ধ করুন। দুটি পরিবর্তনসহ তুলনা কোনোটিই প্রমাণ করে না। ফলাফলটি সেখানে লিখুন যেখানে পরের ব্যক্তি এটি পাবেন, সেটিংটির পাশেই।
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.comযদি অ্যাপ্লিকেশনটি কাজ করতে শুরু করে, প্রমাণ যতটা অনুমতি দেয় ততটা ছোট দাবি রাখুন। ওই পরিবর্তন একটি পরীক্ষায় সাহায্য করেছে, আর এটি বলে না আগের রিজলভার খারাপ বিশ্বাসে কাজ করেছিল কি না, টানেলটি ভাঙা ছিল কি না, বা অন্য ডিভাইসের একই প্রতিস্থাপন দরকার কি না। স্থায়ী ফল হলো এমন একটি কনফিগারেশন যার পরিচালক ও উদ্দেশ্য আপনি ব্যাখ্যা করতে পারেন।