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ریزولور کے ہوسٹ پر کیپچر کریں، کیپچر مختصر اور محدود رکھیں، اور اسے وہاں محفوظ کریں جہاں پالیسی اجازت دے۔ اگر مشاہدہ شدہ ماخذ ترجمہ شدہ پتہ ہے تو اگلا سوال یہ ہے کہ کس آلے نے ترجمہ کیا اور کیا اس کی پالیسی مطلوبہ ہے۔ کیپچر بتاتا ہے کہ کیا پہنچا؛ یہ نہیں بتاتا کہ پالیسی نے کیوں اجازت دی۔ نوٹ میں مبصر اور قدم کا نام لیں، کیونکہ گیٹ وے کے بارے میں رازداری کا دعویٰ اسی قدم کے بارے میں ہے، پورے راستے کے بارے میں نہیں۔
تلاش کو راستے کے طور پر لکھیں، پتے کے طور پر نہیں
کلائنٹ، ریزولور، ہر فارورڈر، ہر قدم پر مشاہدہ شدہ ماخذ اور اسے چلانے والی پالیسی درج کریں۔ ایسا ریکارڈ زیادہ تر آئندہ سوالات کا جواب بغیر کسی اور کیپچر کے دے دیتا ہے۔ اسے زنجیر کی طرح بنائیں، کیونکہ پتوں کی فہرست چھپاتی ہے کہ کس قدم نے کون سا پیدا کیا۔
نقشے کے ساتھ تاریخ، کلائنٹ کا ورژن اور ترتیب کا نظرثانی شامل کریں، تاکہ بعد میں پڑھنے والا بتا سکے کہ کیا یہ اب بھی لاگو ہے۔ نقل و حمل کے ماخذ کو ہر اس چیز سے الگ کریں جو سروس پر کارروائی کرتی ہے، کیونکہ گیٹ وے کا پتہ دیکھنا اس بارے میں کچھ نہیں کہتا کہ اور کیا محفوظ رکھا جاتا ہے۔ ریزولور کا مقام بھی اس بارے میں کچھ نہیں کہتا کہ کس کلائنٹ نے پوچھا۔ ان دعوؤں کو الگ رکھنا ہی نتیجے کو جائزے میں قابل دفاع بناتا ہے۔