VPN কি DNS ঠিক করেছিল, নাকি শুধু একটি ক্যাশ করা উত্তর পুনরায় ব্যবহার করেছিল?
টানেল পরিবর্তনের পর লোড হওয়া একটি পৃষ্ঠা হয়তো কখনোই কোনো কোয়েরি করেনি। সমাধানের কৃতিত্ব দেওয়ার আগে ক্যাশ করা ও নতুন উত্তর তুলনা করুন।
টানেল ওঠার কয়েক সেকেন্ড পরে একটি পৃষ্ঠা খোলা এই প্রমাণ নয় যে DNS এখন কাজ করছে, যদিও টিকিট সাধারণত তা-ই বলে। সেই পর্যবেক্ষণে কোনো কিছুই কোয়েরি দাবি করেনি: নামটি পরিবর্তনের আগে সমাধান হয়ে থাকতে পারে এবং টানেল যে ক্যাশ স্পর্শ করেনি সেখান থেকে পুনরায় ব্যবহৃত হতে পারে। দুটি ভিন্ন পরীক্ষা একই স্ক্রিন তৈরি করে।
পরিবর্তনকে কৃতিত্ব দেওয়ার আগে প্রতিটি পরীক্ষা আসলে কী চালিয়েছে তা তুলনা করুন।
পৃষ্ঠা লোড করা কোয়েরি নয়
অ্যাপ্লিকেশন ও রিজলভারের মধ্যবর্তী প্রতিটি স্তর তার জীবদ্দশায় একটি উত্তর মনে রাখতে পারে। অপারেটিং সিস্টেম একটি রাখে, ব্রাউজার নিজেরটি রাখে, এবং দীর্ঘস্থায়ী সংযোগযুক্ত অ্যাপ্লিকেশন সেশনে আর কিছু সমাধান না-ও করতে পারে। তাই টানেল পরিবর্তনের পরে সফল লোড রুটিংয়ের বদলে স্মৃতির প্রদর্শন হতে পারে। ব্যর্থতার অনুপস্থিতি কোয়েরির উপস্থিতি নয়।
এই পার্থক্য বদলে দেয় এরপর আপনার কী পরীক্ষা করা উচিত। লক্ষ্য যদি দেখানো হয় যে নতুন রিজলভার উত্তর দেয়, তবে আপনার এমন কোয়েরি দরকার যা আপনি পরিষ্কার করেননি এমন ক্যাশ থেকে পরিবেশন করা যায় না।
ক্যাশ করা সাফল্যকে আগে অপ্রাপ্য সার্ভার পুনরুদ্ধার হয়েছে এমন প্রমাণ হিসেবে পড়া এই ভুলের সবচেয়ে ব্যয়বহুল রূপ, কারণ এটি মিথ্যা ভিত্তিতে ঘটনাটি বন্ধ করে।
সিদ্ধান্তে আসার আগে ক্যাশগুলো গণনা করুন
চারটি নাম উল্লেখযোগ্য: অ্যাপ্লিকেশনের নিজস্ব সমাধান, অপারেটিং সিস্টেমের ক্লায়েন্ট ক্যাশ, ব্রাউজারের অভ্যন্তরীণ অবস্থা, এবং কোয়েরি শেষে যে পুনরাবৃত্ত রিজলভারে পৌঁছায়। প্রতিটির আলাদা জীবদ্দশা ও আলাদা পরিষ্কার করার উপায় রয়েছে। একটি পরিষ্কার করে অন্যটি পরীক্ষা করাই মানুষদের এই সিদ্ধান্তে পৌঁছায় যে ফ্লাশ কিছুই করেনি। একটি ফ্লাশ কমান্ড কখনো প্রশ্নটির মীমাংসা করে না।
নেতিবাচক উত্তরও ক্যাশ হয়। অনুপস্থিত হিসেবে জানানো একটি নাম নেটওয়ার্ক সংশোধনের পরেও অনুপস্থিত থাকতে পারে, যা ভাঙা টানেল হিসেবে পড়া হয় অথচ এটি এমন TTL যা এখনো শেষ হয়নি। DNS স্পেসিফিকেশন বর্ণনা করে এই ডেটা কীভাবে রাখা ও পুনরায় ব্যবহার করা উচিত।
ছাপ নয়, ঘটনাটি লিখুন
তিনটির মধ্যে কোনটি বদলেছে লিখুন: রেকর্ড, রিজলভারের পথ, নাকি ক্লায়েন্ট সেটিং। রেকর্ড সম্পাদনা নিজস্ব সময়সূচিতে ছড়ায়, রুট পরিবর্তন পুনঃসংযোগে কার্যকর হয়, এবং ব্রাউজার সেটিং কেবল সেই ব্রাউজারেই প্রযোজ্য। সেগুলোকে একক আগে-ও-পরে-তে মিলিয়ে দিলে এমন সময়রেখা তৈরি হয় যা কেউ নিরীক্ষা করতে পারে না।
সময়, ব্যবহৃত রিজলভার ও প্রাপ্ত উত্তর লিখুন, উত্তর নেতিবাচক হলে সেই ক্ষেত্রেও। এটি এমন একটি তথ্য যা অন্য কেউ যাচাই করতে পারে।
তুলনাটি দুবার একইভাবে চালান
যে ক্যাশ পরীক্ষা করতে চান তা পরিষ্কার করুন, মূল পর্যবেক্ষণ রাখুন, তারপর যতটা সম্ভব স্মৃতি এড়িয়ে কোয়েরি করুন। রিজলভারের নাম স্পষ্ট বলা আপনাকে বলে সেই রিজলভার কী জানে; এটি বলে না অ্যাপ্লিকেশন কোন রিজলভার বেছে নিত।
resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example
Windows-এ ক্লায়েন্ট ক্যাশ ফ্লাশ DNS ক্লায়েন্ট ক্যাশ পরিষ্কার করে, অন্য কিছু নয়। এটি ব্রাউজারের ব্যক্তিগত অবস্থা বর্ণনা করে না এবং আপস্ট্রিম সার্ভার ফ্লাশ করে না, তাই এর উপর গড়া পরীক্ষা কেবল সংকীর্ণভাবে ব্যাখ্যা করা যায়। ফলাফল জানানোর সময় বলুন কোন ক্যাশ পরিষ্কার করেছেন।
তারপর নতুন অনুরোধ ও লক্ষ্যযুক্ত রিজলভার নীতি সক্রিয় রেখে প্রকৃত অ্যাপ্লিকেশনটি আবার পরীক্ষা করুন। ভিন্ন নীতিতে উৎপাদিত ফলাফল স্থানান্তরিত হয় না।