আসল উৎস খুঁজে পেতে DNS প্রশ্নের ধাপে ধাপে অনুসরণ করুন
চাপিয়ে দেওয়া রিজলভার ঠিকানা নির্ধারণ করে না রিজলভার কোন উৎস দেখে। ক্লায়েন্ট, ফরওয়ার্ডার ও গ্রহণকারী সার্ভার অনুসরণ করুন, তারপর পথ লিখুন।
ক্লায়েন্টকে রিজলভার ঠিকানা দেওয়া ঠিক করে প্রশ্নগুলো কোথায় যাবে, এই নয় যে রিজলভার কোন উৎস দেখবে। রাউটিং, ফরওয়ার্ডিং ও অনুবাদ দুই প্রান্তের মধ্যে পালা করে আসে। উৎস-সংক্রান্ত প্রশ্নের রানবুক প্রশ্নটির ধাপে ধাপে অনুসরণ করে এবং নথিভুক্ত করে প্রতিটি পর্যবেক্ষক আসলে কী দেখেছে। ক্রম গুরুত্বপূর্ণ, কারণ পর্যবেক্ষণের আগে করা দাবি কেবল ভালো ফরম্যাটের অনুমান।
প্রমাণ সংগ্রহের আগে বিন্যাসটি লিখে রাখুন
চারটি জায়গা DNS উৎস সম্পর্কে আপনাকে কিছু বলতে পারে এবং সবাই একই কথা বলে না। ক্লায়েন্টের কার্নেল জানে সে কোন উৎস ব্যবহার করত, ফরওয়ার্ডার জানে সে উপরে কী পাঠিয়েছে, অনুবাদকারী ডিভাইস জানে সে কী পুনরায় লিখেছে, আর গ্রহণকারী রিজলভার জানে কী এসে পৌঁছেছে। কিছু সংগ্রহের আগে লিখুন এর মধ্যে কোনগুলোতে আপনি সত্যিই পৌঁছাতে পারেন।
| Observation point | What it can prove | What it cannot prove | How to read it |
|---|---|---|---|
| client kernel | which source address it would use for that resolver | anything a device in between rewrote | ip route get against the resolver address |
| forwarder | that it sent an upstream query, and from which source | what the client originally asked for | its own log and its cache state |
| translating device | that a source was rewritten, and to what | whether the query was legitimate | NAT policy and its counters |
| receiving resolver | the address that actually arrived | which client behind that address asked | a scoped capture on port 53 |
আপনার প্রত্যাশাও লিখুন, যে রিজলভার ব্যবহারে আছে বলে আপনি মনে করেন তা সহ। বিভক্ত রুট প্রশ্নটি সম্পূর্ণ অন্য জায়গায় পাঠাতে পারে, আর ক্যাশ কোনো ঊর্ধ্বমুখী বিনিময় ছাড়াই উত্তর দিতে পারে, তাই কেবল স্মৃতিতে রাখা অনুমান প্রথম বিস্ময় পর্যন্ত টিকবে না। ঘোষিত নকশা ও পর্যবেক্ষিত পথ একই নোটের আলাদা কলামে রাখুন; যখন দুটি মেলে না, আপনি সেই প্রশ্নটি খুঁজে পেয়েছেন যা অনুসরণ করার যোগ্য।
কোন প্রক্রিয়া সত্যিই প্রশ্নটি পাঠিয়েছে তা যাচাই করুন
ক্লায়েন্ট থেকে শুরু করুন: রিজলভার ঠিকানা, প্রশ্নের নাম ও সময় নথিভুক্ত করুন, তারপর নিশ্চিত করুন কোন প্রক্রিয়া এটি পাঠিয়েছে। নিচের প্রথম লাইনটি সেই প্রক্রিয়ার নাম বলে যা UDP সকেট ধরে রাখে, এবং এটিই সেই যাচাই যা এই শিরোনাম প্রতিশ্রুতি দেয়। যদি সেই প্রক্রিয়া সিস্টেম রিজলভার-এর বদলে ব্রাউজার সহায়ক বা কন্টেইনার রানটাইম হয়, বাকি ট্রেস এমন একটি পথ বর্ণনা করে যা কেউ চায়নি।
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53একাধিক ইন্টারফেসযুক্ত হোস্টে, অন্য কোথাও তাকানোর আগে জেনে নিন কার্নেল ওই গন্তব্যের জন্য কোন উৎস ঠিকানা বেছে নেয়। এটি শেষ বিন্দু যেখানে পথ সম্পূর্ণ আপনার নিয়ন্ত্রণে, এবং এটিই সেই মান যা আপনি রিজলভার-এর জানানো তথ্যের সঙ্গে তুলনা করবেন। অমিল হলো সংকেত যে মাঝখানে কিছু প্যাকেট পুনরায় লিখেছে, বা দুটি ভিন্ন প্রশ্ন পাঠানো হয়েছে।
পরীক্ষার নামগুলো অভ্যন্তরীণ রাখুন, কারণ প্রকাশ্য রিজলভার-এ পাঠানো অভ্যন্তরীণ নাম অভ্যন্তরীণ পথ সম্পর্কে কিছু প্রমাণ করে না এবং এমন নাম প্রকাশ করে যা প্রকাশ করার দরকার ছিল না। নিরাপদ DNS চালু থাকা ব্রাউজার ওই সকেট তালিকায় একেবারেই দেখা যাবে না, এবং সেই অনুপস্থিতিই নিজে উত্তর।
ফরওয়ার্ডার দ্বিতীয়, আলাদা একটি প্রশ্ন করে
ফরওয়ার্ডার একটি বিনিময়কে দুই করে। নিচ থেকে অনুরোধ আসে, তারপর ফরওয়ার্ডার তার নিজের প্রশ্ন উপরে পাঠায় যে ঠিকানা সে বেছে নেয়। তার কনফিগারেশন, ক্লায়েন্ট নয়, নির্ধারণ করে উপরের রিজলভার কী দেখে।
dnsmasq ম্যানুয়াল এই কারণেই পড়ার যোগ্য: এটি নথিভুক্ত করে কীভাবে ফরওয়ার্ডার উপরের সার্ভার বেছে নেয় এবং নিজের শোনার দিক বাঁধে, আর সেই বিন্যাসে কিছুই ক্লায়েন্টের উৎস উপরে বহন করে না। তাই গেটওয়ে ঠিকানা দেখানো রিজলভার লগ স্বাভাবিক, ত্রুটির প্রমাণ নয়। অনুপস্থিতিও সমান সহজে ভুল পড়া যায়, কারণ ক্যাশ হিট কোনো ঊর্ধ্বমুখী প্রশ্ন তৈরি করে না এবং কখনো না আসা প্রশ্নের মতোই দেখায়। দুটির মধ্যে কোনো সিদ্ধান্তে পৌঁছানোর আগে ফরওয়ার্ডারের কনফিগারেশন ও তার ক্যাশের অবস্থা পড়ুন। দুই প্রশ্ন, দেখার দুই জায়গা।
উৎসটি গ্রহণকারী রিজলভার-এ পড়ুন
এটি নিষ্পত্তি করে এমন একমাত্র পর্যবেক্ষণ সার্ভারের দিকে নেওয়া হয়। ক্লায়েন্টের ইন্টারফেস তালিকা থেকে যা কিছু অনুমান করা হয় তা প্রকল্পই থাকে যতক্ষণ না রিজলভার জানায় সত্যিই কী এসেছে।
tcpdump -ni any port 53 and host 10.20.30.53রিজলভার হোস্টে ক্যাপচার করুন, ক্যাপচার সংক্ষিপ্ত ও সীমিত রাখুন, এবং যেখানে নীতি অনুমতি দেয় সেখানে সংরক্ষণ করুন। যদি পর্যবেক্ষিত উৎস অনূদিত ঠিকানা হয়, পরের প্রশ্ন হলো কোন ডিভাইস অনুবাদটি করেছে এবং তার নীতি কি অভীষ্ট। ক্যাপচার বলে কী এসেছে; এটি ব্যাখ্যা করে না কেন নীতি তা অনুমোদন করেছে। নোটে পর্যবেক্ষক ও ধাপের নাম দিন, কারণ গেটওয়ে সম্পর্কে গোপনীয়তার দাবি ওই ধাপ সম্পর্কে, পুরো পথ সম্পর্কে নয়।
সন্ধানটি পথ হিসেবে লিখুন, ঠিকানা হিসেবে নয়
ক্লায়েন্ট, রিজলভার, যেকোনো ফরওয়ার্ডার, প্রতিটি ধাপে পর্যবেক্ষিত উৎস এবং তা নিয়ন্ত্রণকারী নীতি নথিভুক্ত করুন। এমন রেকর্ড ভবিষ্যতের অধিকাংশ প্রশ্নের উত্তর দেয় আরেকটি ক্যাপচার ছাড়াই। এটি শিকল হিসেবে আঁকুন, কারণ ঠিকানার তালিকা লুকায় কোন ধাপ কোনটি তৈরি করেছে।
চিত্রে তারিখ, ক্লায়েন্ট সংস্করণ ও কনফিগারেশনের সংশোধন যোগ করুন, যাতে পরের পাঠক বলতে পারেন এটি এখনো প্রযোজ্য কি না। পরিবহন উৎসকে সেবা যা প্রক্রিয়া করে তার বাকি সব থেকে আলাদা রাখুন, কারণ গেটওয়ে ঠিকানা দেখা এ সম্পর্কে কিছু বলে না যে আর কী সংরক্ষিত থাকে। রিজলভার-এর অবস্থানও এ সম্পর্কে কিছু বলে না যে কোন ক্লায়েন্ট জিজ্ঞাসা করেছে। এই দাবিগুলো আলাদা রাখাই সিদ্ধান্তটিকে পর্যালোচনায় টেকসই করে।