VPN-এ DNS ভুল? একটি কর্তৃত্বপূর্ণ সার্ভার পুরনো হতে পারে

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

লক্ষণ রিজলভারের সঙ্গে বদলায়

একটি রিকার্সিভ রিজলভার কর্তৃত্বপূর্ণ সার্ভার যা বলেছে তা ফেরত দেয়, তারপর TTL পর্যন্ত সেই উত্তর ধরে রাখে। টানেল যদি অন্য রিজলভার পাঠায়, বা পথ এমনভাবে বদলায় যে পুরনোটি আর পৌঁছনো যায় না, ক্লায়েন্ট অন্য কর্তৃত্বপূর্ণ সার্ভারকে জিজ্ঞাসা করে এবং অন্য উত্তর পায়। সেই মুহূর্তে ডোমেইন বদলায়নি; বদলেছে আপনার দৃষ্টিভঙ্গি।

এজন্যই একই নাম একটি অফিসে কাজ করতে পারে আর হোটেল থেকে ব্যর্থ হতে পারে, এবং এজন্যই স্থানীয় ক্যাশ পরিষ্কার করা কেবল মাঝে মাঝে কাজে লাগে। ক্যাশ পরিষ্কার করলে প্রশ্নটি আবার একই কর্তৃত্বপূর্ণ সার্ভারে যায়।

পার্থক্য নির্ণয়ের পরীক্ষা হলো প্রতিটি প্রকাশিত সার্ভারে সরাসরি কোয়েরি।

প্রতিটি কর্তৃত্বপূর্ণ সার্ভারকে সরাসরি জিজ্ঞাসা করুন

মনে রাখা তালিকা থেকে নয়, ডেলিগেশন থেকে শুরু করুন। প্যারেন্টকে NS সেট জিজ্ঞাসা করুন, তারপর সেই সেটের প্রতিটি নামকে আপনার প্রয়োজনীয় রেকর্ডের জন্য কোয়েরি করুন। একই নামের বিরুদ্ধে ভিন্ন কর্তৃত্বপূর্ণ সার্ভারে দুটি কোয়েরি সঙ্গে সঙ্গে বলে দেয় জোনটি সামঞ্জস্যপূর্ণ কি না।

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

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

এই কোয়েরিগুলো কেবল আপনার ডেস্ক থেকে নয়, যে নেটওয়ার্কে ব্যর্থ হয় সেখান থেকেই চালান।

উদ্দিষ্ট দৃষ্টিভঙ্গিকে ভাঙা দৃষ্টিভঙ্গি থেকে আলাদা করুন

কিছু ডোমেইন অঞ্চল বা রিজলভার গ্রুপ অনুযায়ী ইচ্ছাকৃতভাবে ভিন্ন উত্তর দেয়, আর split-horizon ব্যবস্থা এন্টারপ্রাইজ নেটওয়ার্কে স্বাভাবিক।

প্রশ্ন হলো পার্থক্যটি কি নথিভুক্ত ও স্থিতিশীল। অনিচ্ছাকৃত দৃষ্টিভঙ্গি আলাদা দেখায়: একটি কর্তৃত্বপূর্ণ সার্ভারের কাছে এমন রেকর্ড আছে যা অন্যদের কাছে কখনো পৌঁছায়নি, বা তাদের সবার থাকা একটি রেকর্ড তার নেই। RFC 2182-এর নির্বাচন ও স্থাপনা নির্দেশিকা কর্তৃত্বপূর্ণ উপলব্ধতাকে যৌথ দায়িত্ব হিসেবে দেখে, আর এখানে সেটাই সঠিক কাঠামো। অপ্রয়োজনীয়তা কেবল তখনই থাকে যখন প্রতিটি প্রকাশিত সার্ভার উদ্দিষ্ট ডেটা উত্তর দিতে পারে, কেবল 53 পোর্টে সংযোগ গ্রহণ করলেই নয়।

SERVFAIL উত্তর দেওয়া সার্ভারকে নির্ণয় করা সহজ, যে আত্মবিশ্বাসের সঙ্গে ভুল উত্তর দেয় তার চেয়ে।

মাইগ্রেশন প্রকাশ করে ক্যাশ কী লুকিয়েছিল

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

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

ল্যাপটপে রিজলভার বদলালে কেবল সেই ল্যাপটপই ঠিক হয়, আর কিছুই নয়।

জোন ঠিক করুন, রিজলভার নয়

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

তারপর দুই নেটওয়ার্ক থেকেই সরাসরি কোয়েরিগুলো আবার চালান এবং আপনি যে রেকর্ডটি বদলেছেন তার TTL শেষ হওয়া পর্যন্ত অপেক্ষা করুন।

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