DNS پتہ کیسے ڈھونڈتا ہے؟ تکراری سوال، بااختیار سرور، TTL اور کیش

فرض کریں کسی ڈومین کے سرور کا پتہ بدل دیا گیا، مگر گھر میں نئی سائٹ کھلتی ہے اور موبائل پر اب بھی پرانے سرور سے اتصال ہوتا ہے۔ دونوں آلات میں ایک ہی نام لکھنے کے باوجود، مختلف DNS کیش سے گزرنے پر کچھ وقت نتائج مختلف ہو سکتے ہیں۔ صفحہ دوبارہ حاصل کرنے والا HTTP کیش اور اتصال کا پتہ معلوم کرنے والا DNS کیش الگ چیزوں کی جانچ چاہتے ہیں۔

اس مضمون میں فرضی کتب خانے کے ہوسٹ www.library.example کے ذریعے نام کے حل اور کیش کا تعلق دیکھیں گے۔ مثال کا نام اور اوقات وضاحت کے لیے بنائے گئے ہیں؛ کسی حقیقی خدمت کے جوابات نہیں ناپے گئے۔ مقصد DNS سے پتہ ملنے، تبدیلی دیر سے نظر آنے کی وجہ، اور نام کا حل ملنے کے بعد کی ناکامی کو الگ کرنا ہے۔

1. DNS میں ایک نام کے لیے کئی قسم کے جواب ہوتے ہیں

DNS ڈومین نام سے متعلق معلومات مختلف قسم کے ریکارڈ میں دیتا ہے۔ A، IPv4 کا پتہ اور AAAA، IPv6 کا پتہ ظاہر کرتا ہے؛ ایک نام کے کئی پتے بھی ہو سکتے ہیں۔ CNAME دوسرے نام کی طرف اشارہ کرنے والا عرف ہے، MX ڈاک وصول کرنے والا سرور، اور NS متعلقہ زون کا بااختیار نام سرور بتاتا ہے۔ اس لیے اسی نام کا جواب مطلوبہ ریکارڈ کی قسم بدلنے سے مختلف ہو سکتا ہے۔

Cloudflare کی DNS ریکارڈ کی وضاحت کے مطابق CNAME کی قدر IP پتہ نہیں بلکہ دوسرا نام ہے۔ پتہ درکار ہو تو اس نام کا حل آگے جاری رہ سکتا ہے۔ اسی طرح https://www.library.example/books میں DNS جس ہوسٹ نام کو دیکھتا ہے وہ www.library.example ہے۔ /books کا راستہ یا صفحے کا متن DNS میں درج نہیں ہوتا۔ CNAME لگانے سے براؤزر کی پتہ پٹی بدلنے والی HTTP ری ڈائریکشن خود بخود نہیں بنتی۔

2. تکراری ریزالور بااختیار سرور تک کیسے پہنچتا ہے

آلے کا نام حل کرنے کا نظام عموماً مقرر کردہ تکراری ریزالور سے جواب مانگتا ہے۔ ضروری معلومات کیش میں ہوں تو ریزالور انہیں استعمال کرتا ہے، ورنہ دوسرے DNS سروروں سے پوچھ کر آخری جواب یا خرابی لوٹاتا ہے۔ DNS اصطلاحات کا معیار RFC 9499 دوسرے کی جانب سے حل کرنے والے اس کردار کو اپنے زون کی معلومات رکھنے والے بااختیار سرور سے الگ کرتا ہے۔ جواب کا ماخذ سمجھتے وقت دیکھنا چاہیے کہ سرور کس کردار میں جواب دے رہا ہے۔

کیش اور درمیانی فارورڈر کے بغیر سادہ صورت میں ریزالور کو روٹ سے بالائی درجے کے ڈومین کے سرور کی راہنمائی ملتی ہے، اور وہاں سے مطلوبہ زون کے بااختیار سرور کی۔ آخری بااختیار سرور مطلوبہ ریکارڈ یا عرف دیتا ہے۔ یہ ایسا نظام نہیں کہ ایک روٹ سرور تمام ویب سائٹوں کے IP پتے رکھتا ہو۔ عملی طور پر پہلے سے محفوظ تفویض کی معلومات سے آغاز یا دوسرے ریزالور کو سوال بھیجنا ممکن ہے، اس لیے ہر بار سائٹ کھولنے پر پورا سلسلہ لازماً نہیں دہرایا جاتا۔

3. TTL کیش میں بچا وقت ہے، دنیا بھر کی گھڑی نہیں

ریکارڈ کا TTL کیش کی عمر کی معلومات ہے جو سیکنڈ میں دی جاتی ہے۔ عام کیش جواب میں محفوظ رہنے کے دوران باقی وقت گھٹتا ہے۔ مثلاً ریزالور نے 10:00 پر TTL 300 سیکنڈ والا پتہ محفوظ کیا تو اسی نقل سے 10:02 پر جواب دیتے وقت تقریباً 180 سیکنڈ باقی ہوں گے۔ نیچے فرضی اوقات ایک ایسے ریزالور کے ہیں جو دوبارہ سوال، پیشگی تجدید یا پرانے جواب کی فراہمی نہیں کرتا۔

کسی دوسرے ریزالور نے ریکارڈ بعد میں محفوظ کیا ہو سکتا ہے یا ابھی کبھی دیکھا ہی نہ ہو۔ تجدید کے اوقات مختلف ہونے سے ایک TTL دنیا کے سب استعمال کنندگان کے بیک وقت بدلنے کا لمحہ مقرر نہیں کرتا۔ کیش مدت پوری ہونے سے پہلے بھی معلومات ہٹا سکتا ہے، اور ویب صفحہ تازہ کرنے سے مشترک ریزالور کی نقل نہیں مٹتی۔ TTL، DNS جواب کے دوبارہ استعمال کو سمجھنے کا اشارہ ہے، پورے ویب اتصال یا اسکرین کی تجدید کی وقت حد نہیں۔

4. TTL کب کم کریں اور «موجود نہیں» جواب کا کیش

جو کیش پہلے پرانا پتہ TTL 3,600 سیکنڈ کے ساتھ لے چکا ہے، اسے یہ بات فوراً نہیں پہنچتی کہ منتظم نے اب TTL 60 سیکنڈ کر دیا ہے۔ طے شدہ پتہ تبدیلی میں TTL پہلے بدلیں اور پرانی طویل مدت سے محفوظ جوابات باقی رہنے کا وقت ملحوظ رکھیں۔ کم TTL تبدیلی کو زیادہ بار چیک کروا سکتا ہے، مگر سوالوں کا بوجھ اور بااختیار سرور پر انحصار بھی بڑھاتا ہے۔ ہر خدمت پر ایک ہی چھوٹا عدد لگانے کے بجائے تبدیلی کا منصوبہ اور خرابی سے نمٹنے کی تیاری ساتھ دیکھیں۔

نام موجود نہ ہونے کا NXDOMAIN اور نام ہونے مگر مطلوبہ قسم کا ریکارڈ نہ ہونے کا NODATA بھی کیش ہو سکتا ہے۔ منفی کیش کا معیار RFC 2308 منفی جواب کی کیش عمر کے لیے بااختیار سرور کے SOA ریکارڈ کے TTL اور SOA کے MINIMUM میں سے چھوٹی قدر لیتا ہے۔ لہٰذا پہلے غیر موجود ہوسٹ شامل کرنے کے فوراً بعد بھی پرانا «موجود نہیں» جواب باقی رہ سکتا ہے۔ صرف نئے A ریکارڈ کے TTL سے اس جواب کی عمر بھی اتنی ہی فرض کریں تو اصل وجہ چھوٹ سکتی ہے۔

5. نام، قسم اور سرور یکساں رکھ کر جانچیں

جانچ میں پوچھا گیا درست نام، A یا AAAA جیسی قسم، جس DNS سرور سے پوچھا وہ، اور وقت ساتھ لکھیں۔ dig نصب ہو تو dig example.com A کی طرح نام اور قسم متعین کر سکتے ہیں۔ حقیقی مسئلے میں example.com کو اپنے مطلوبہ ہوسٹ سے بدلیں۔ یہ کمانڈ طریقۂ کار کی مثال ہے؛ مضمون میں اسے حقیقتاً چلایا یا جواب کا وقت ناپا نہیں گیا۔

جواب کی کیفیت کے ساتھ ANSWER میں نام، قسم، قدر اور TTL دیکھیں۔ اسی ریزالور کو وہی سوال پھر دے کر TTL گھٹنے کو دیکھیں، مگر قدر بڑھ جائے تو فوراً خرابی نہ سمجھیں۔ پیشگی تجدید ہوئی ہو سکتی ہے یا کئی کیش نوڈ میں سے کسی دوسرے نے جواب دیا ہو۔ A اور AAAA کے نتائج ملانے کے بجائے الگ لکھنے سے معلوم ہوتا ہے کہ کس پتہ خاندان میں فرق ہے۔

منتظم یکساں نام اور قسم کے لیے استعمال ہونے والے تکراری ریزالور اور اپنے زیر انتظام زون کے بااختیار سرور کے جواب ملا سکتا ہے۔ فرق ہو تو ترتیب سے کیش کا باقی وقت، بااختیار سروروں کے ڈیٹا کی یکسانیت اور تفویض کی ترتیبات دیکھیں۔ ایک عوامی ریزالور کا جواب سب استعمال کنندگان کی حالت نہیں بتاتا۔ کمپنی نیٹ ورک کا اندرونی DNS یا براؤزر کی علیحدہ DNS ترتیب سوال کا راستہ بدل سکتی ہے، اس لیے تقابل میں اتصال کا ماحول بھی درج کریں۔

6. DNS کی خرابی، اتصال کی خرابی اور استثنا الگ پڑھیں

NXDOMAIN نام نہ ہونے کا جواب ہے، اور NODATA مطلوبہ قسم کے ریکارڈ کی عدم موجودگی ہے۔ اس کے برعکس SERVFAIL سرور کا سوال سنبھال نہ پانا ہے، جبکہ ٹائم آؤٹ مقررہ انتظار میں جواب نہ ملنے کا مشاہدہ ہے۔ ان سب کو «ڈومین حذف ہو گیا» نہ سمجھیں۔ پہلے محفوظ کریں کہ جواب کا کوڈ آیا یا نہیں اور کس سرور سے پوچھا تھا، تاکہ اگلا جانچنے والا مرحلہ طے ہو سکے۔

TTL گزرنے کے بعد پرانا جواب نظر آنا ہمیشہ ضابطے کی خلاف ورزی نہیں۔ RFC 8767 کا serve-stale طریقہ اس استثنائی حالت میں دستیابی بڑھانے کے لیے میعاد ختم شدہ معلومات کے استعمال کو بیان کرتا ہے جب بااختیار سرور سے تجدید ممکن نہ ہو۔ اس کا مطلب سب ریزالوروں کا یکساں ترتیبات سے اسے استعمال کرنا نہیں۔ ایک TTL سے تبدیلی نافذ ہونے کا وقت قطعی قرار دینے کے بجائے حقیقتاً استعمال کردہ ریزالور کا رویہ دیکھیں۔

آخرکار پتہ درست مل جانا بھی ویب سائٹ کھلنے کی ضمانت نہیں۔ اس پتے تک نیٹ ورک، TLS سند، ویب سرور اور ایپلیکیشن الگ مرحلے ہیں۔ DNS سے متوقع پتہ ملے مگر صفحہ نہ کھلے تو اگلے اتصال مرحلے کی طرف تحقیق بڑھائیں۔ نام کے حل اور ویب جواب کو الگ لکھنے سے صفحے کا کیش مٹانے یا DNS ترتیبات بے سوچے بدلنے سے پہلے ناکامی کے مقام کو زیادہ درست طور پر محدود کیا جا سکتا ہے۔