DNS রিজলভার লগ বনাম VPN সংযোগ লগ: প্রতিটিতে কী থাকে
রিজলভার সেই নামগুলো লিখে রাখে যেগুলোর উত্তর দিতে তাকে বলা হয়; VPN তার নিজের বাস্তবায়ন থেকে টানেলের ঘটনা লিখে রাখে। একটি ধারণনীতি অন্যটিকে ঢেকে দেয় না।
একটি DNS রিজলভার লগ এবং একটি VPN সংযোগ লগ—দুটোই নেটওয়ার্ক রেকর্ড, দুটোই কাজের, এবং একটির বদলে অন্যটি চলে না। রিজলভার সেই নামগুলো গ্রহণ করে যেগুলোর উত্তর দিতে তাকে বলা হয়। VPN প্রান্ত টানেল সংযোগ সামলায় এবং তার বাস্তবায়ন সেগুলো নিয়ে যা লিখে রাখার সিদ্ধান্ত নিয়েছে তাই লিখে রাখে। এরা একই ভবনে থাকতে পারে, একই দল পরিচালনা করতে পারে এবং একই গোপনীয়তা বিজ্ঞপ্তির আওতায় আসতে পারে, তবুও ভিন্ন শনাক্তকারী ও ভিন্ন সংরক্ষণকালসহ ভিন্ন ঘটনা বর্ণনা করে। একটিকে অন্যটি ভেবে পড়াই তদন্তকে ভুল পথে নিয়ে যায়।
দুটি লগ, দুটি ঘটনা
রিজলভারের একটি এন্ট্রি নামকরণ নিয়ে একটি প্রশ্নের উত্তর দেয়: এই ক্লায়েন্ট এই সময়ে এই নামটি চেয়েছিল, এবং উত্তর ছিল এটি। VPN-এর একটি এন্ট্রি সংযোগযোগ্যতা নিয়ে প্রশ্নের উত্তর দেয়: এই পিয়ার একটি টানেল স্থাপন বা হারিয়েছে, এই ঠিকানা বরাদ্দ পেয়েছে, এবং চলে যাওয়ার আগে আনুমানিক এতটা ডেটা স্থানান্তর করেছে। কোনোটিই HTTPS সেশনের ভেতরে ব্যবহারকারী কী করেছে তার রেকর্ড নয়, এবং কোনোটিই অন্যটির বিকল্প নয়।
এই পার্থক্যের প্রতিশ্রুতিতে বাস্তব পরিণতি আছে। VPN সরবরাহকারী টানেল কার্যকলাপ লগ করে না—এমন বক্তব্য তার দেওয়া রিজলভার সম্পর্কে কিছুই বলে না, আর রিজলভারের সংরক্ষণ নীতি টানেলে কে যুক্ত হয়েছিল সে সম্পর্কে কিছুই বলে না। প্রতিটি দাবি তার নিজের অপারেটর ও নিজের সিস্টেমের।
যেকোনো লগ পড়ার আগে কোয়েরিটি অনুসরণ করুন
কোয়েরি কোনো রিজলভারে পৌঁছায় কেবল যদি পথটি সত্যিই তাকে জিজ্ঞাসা করে। একটি অ্যাপ্লিকেশন অপারেটিং সিস্টেমের রিজলভার ব্যবহার করতে পারে, নিজের এনক্রিপ্টেড DNS ক্লায়েন্ট চালাতে পারে, অথবা ক্যাশে করা উত্তর পড়ে কিছুই না পাঠাতে পারে। তাই কিছু না দেখানো রিজলভার লগ এই প্রমাণ নয় যে কোনো নাম কখনো ব্যবহার হয়নি; এটি প্রমাণ যে এই রিজলভারকে জিজ্ঞাসা করা হয়নি।
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pagerশেষ কমান্ডটি স্থানীয় রিজলভারের নিজের জার্নাল পড়ে, যা আপস্ট্রিম সার্ভারের লগের সমান নয়। আপনার কোয়েরিগুলো যদি DNS over HTTPS দিয়ে কোনো সরবরাহকারীর কাছে যায়, স্থানীয় স্টাব কিছুই না দেখাতে পারে অথচ সরবরাহকারীর কাছে সম্পূর্ণ রেকর্ড থাকে, আর সরবরাহকারী ভিন্ন নীতি-সম্পন্ন ভিন্ন অপারেটর।
প্রতিটি রেকর্ড কী দেখাতে পারে আর কী পারে না
| Record | Typically shows | Does not show |
|---|---|---|
| Resolver log | Queried name, client address, time, response | Which page was fetched, or what the tunnel did |
| VPN connection log | Peer identity, assigned address, connect and disconnect times, volume | Which name the application asked for |
| Application or proxy log | Requests, status codes, sometimes full URLs | Resolved addresses for every dependency |
এগুলো জোড়া লাগানোই আসল কাজ, আর জোড়া লাগানো সবসময় সম্ভব নয়। যে রিজলভার ক্লায়েন্ট ঠিকানা লগ করে তাকে এমন VPN-এর সঙ্গে তুলনা করা যায় যা একটি জানা পুল থেকে ঠিকানা বরাদ্দ করে, এবং সেই তুলনা একটি জিজ্ঞাসিত নাম ও একটি টানেলের মধ্যে বিশ্বাসযোগ্য সংযোগ তৈরি করে, যা দুই রেকর্ডের মধ্যে সংযোগ হয়েই থাকে, কোনো ব্যক্তির রেকর্ড নয়।
এনক্রিপ্টেড DNS পরিবহন বদলায়, প্রান্তে দৃশ্যমানতা নয়। রিজলভার যে প্রশ্নের উত্তর দেয় সেই প্রশ্নটি এখনও পায়, যেমন RFC 8484 স্পষ্ট করে, এবং সেই রিজলভারে সংরক্ষণ প্রোটোকলের বৈশিষ্ট্য নয় বরং একটি নীতি-সিদ্ধান্ত।
যেখানে স্প্লিট DNS ও ক্যাশে গল্পটা জটিল করে
একাধিক রিজলভার স্বাভাবিক। একটি স্প্লিট-DNS নকশা অভ্যন্তরীণ নামগুলো অভ্যন্তরীণ সার্ভারে পাঠায় আর বাকি সবকিছু পাবলিক সার্ভারে, তাই একটি তদন্তে এমন দুটি লগ জড়িত হতে পারে যেগুলো একত্র করার কথা কখনো ভাবা হয়নি, এবং এমন দুটি সংরক্ষণ সেটিং যেগুলো তুলনা করার কথা কখনো ভাবা হয়নি। দুটোতেই কোয়েরি দেখা নকশাটি কাজ করছে তার প্রমাণ, ফাঁসের প্রমাণ নয়।
ক্যাশে উল্টো দিক থেকে কাটে। একটি জনপ্রিয় নাম ঘণ্টার পর ঘণ্টা ক্যাশ থেকে উত্তর পেতে পারে, তাই রিজলভারের রেকর্ড প্রথম কোয়েরিটি দেখায় তারপর কিছুই না, অথচ ব্যবহারকারীর অ্যাপ্লিকেশন একই নাম হাসিমুখে রিজলভ করতে থাকে। নির্দিষ্ট সময়ের পরে এন্ট্রি না থাকার অর্থ এই নয় যে সেই সময়ের পরে কেউ নামটি ব্যবহার করেনি।
পটভূমির ট্রাফিক তৃতীয় বিকৃতি। বুটের সময় টেলিমেট্রি নাম রিজলভ করা ফোন, সার্চ সাজেশন ডোমেইন রিজলভ করা ব্রাউজার, এবং প্রতি ঘণ্টায় চেক-ইন করা আপডেটার—সবাই রিজলভার লগে সেই নামের পাশেই দেখা যায় যা আপনার সত্যিই গুরুত্বপূর্ণ। ওই লগের আয়তন মনোযোগ নয়, এবং কোয়েরি গোনা ভিজিট গোনা নয়। রিজলভার লগ প্রশ্নের রেকর্ড, আর প্রশ্ন তৈরি করা সস্তা।
সংরক্ষণ নিয়ে প্রশ্নগুলো আলাদা করে করুন
প্রতিটি সিস্টেমের জন্য তিনটি প্রশ্ন করুন: কে সংগ্রহ করে, কী সংগ্রহ করা হয়, এবং কতদিন তা রাখা হয়. তারপর জিজ্ঞাসা করুন কে এটি পড়তে পারে এবং কোন প্রক্রিয়ায়। DNS over HTTPS নিয়ে RFC 8484-এর আলোচনা ভালো মনে করিয়ে দেয় যে এনক্রিপ্টেড পরিবহন প্রান্তটি সরায় না, এবং অপারেটরের নিজের ডকুমেন্টেশনই সেই প্রান্ত কী রাখে সে সম্পর্কে একমাত্র নির্ভরযোগ্য বিবৃতি।
গোপনীয়তা নিয়ে যখন “VPN”-এর বিষয়ে দাবি করা হয়, তা গ্রহণের আগে উপাদানে ভাগ করুন: টানেল অপারেটর, টানেল যে রিজলভার দেয়, সেই কোয়েরিগুলো যে ঊর্ধ্বস্থ রিজলভারে পৌঁছায়, এবং ডিভাইসের অ্যাপ্লিকেশনগুলো। প্রত্যেকের নিজের উত্তর আছে, এবং একটির জন্য সঠিক দাবি নিয়মিতভাবে চারটিই ঢাকে বলে পুনরাবৃত্ত হয়।
সমস্যা সমাধানের জন্য একই বিভাজন ব্যবহার করুন। জিজ্ঞাসা করুন কোন অ্যাপ্লিকেশন কোয়েরিটি করেছে এবং কোন রিজলভার তার উত্তর দিয়েছে, তারপর যে লগ সত্যিই সেই ঘটনার মালিক তার দিকে তাকান. অন্য লগ থেকে অনুমান করা এক মিনিট বাঁচায় আর এক বিকেল খরচ করে।