نیم سرورز کی منتقلی تمام کنٹرول پینلز میں کامیاب نظر آ سکتی ہے، لیکن ویب سائٹ پھر بھی ناقابلِ رسائی رہ سکتی ہے۔ ڈومین فعال ہوتا ہے، نئے اتھارٹیٹیو نیم سرورز متوقع IP ایڈریس واپس کرتے ہیں اور ویب سرور میں بھی کوئی تبدیلی نہیں کی گئی ہوتی۔ اس کے باوجود DNSSEC کی توثیق کرنے والے DNS ریزالورز SERVFAIL دکھاتے ہیں۔ اکثر اس کی وجہ DNSSEC کی وہ ڈیلیگیشن ہوتی ہے جو اب بھی پچھلے DNS فراہم کنندہ کی دستخط کرنے والی کلید پر اعتماد کر رہی ہوتی ہے۔
اس تحقیق کی بنیاد بننے والے واقعے میں عام DNS استفسارات ناکام ہو رہے تھے، جبکہ DNSSEC کی توثیق نظرانداز کرنے پر وہی استفسارات کامیاب ہو جاتے تھے۔ پیرنٹ زون میں پرانا DS ریکارڈ بدستور شائع تھا، لیکن نیا اتھارٹیٹیو زون شروع میں غیر دستخط شدہ تھا۔ نئی ترتیب سے مطابقت رکھنے والی کلید شائع کرنے اور نئے زون پر دستخط کرنے کے بعد جانچے گئے ریزالورز دوبارہ تصدیق شدہ جوابات دینے لگے۔ اس واقعے کا سبق DNSSEC بند کرنا نہیں، بلکہ یہ سمجھنا ہے کہ نیم سرورز کی منتقلی اور DNSSEC کے سلسلۂ اعتماد کی منتقلی دو الگ کام ہیں۔
درست A ریکارڈز کے باوجود SERVFAIL کیوں آ سکتا ہے؟
DNS دو مختلف سوالوں کے جواب دیتا ہے۔ A ریکارڈ بتاتا ہے کہ کسی نام سے کون سا IPv4 ایڈریس منسلک ہے۔ DNSSEC توثیق کرنے والے ریزالور کو بتاتا ہے کہ اس جواب پر اعتماد کیا جا سکتا ہے یا نہیں۔ ایڈریس کا درست ہونا خودبخود یہ ثابت نہیں کرتا کہ DNSSEC کا سلسلۂ اعتماد بھی درست ہے۔
دستخط شدہ ڈومین میں یہ سلسلہ قابلِ اعتماد پیرنٹ زون سے DS (Delegation Signer) ریکارڈ کے ذریعے چائلڈ زون کے DNSKEY تک جاتا ہے۔ چائلڈ زون اپنے DNS ڈیٹا کے ڈیجیٹل دستخط RRSIG ریکارڈز میں شائع کرتا ہے۔ DS ریکارڈ میں ایک ڈائجسٹ ہوتا ہے جو مجاز DNSKEY کی شناخت کرتا ہے؛ یہ نہ تو A ریکارڈ ہے، نہ نجی کلید کی نقل اور نہ ہی عام زون فائل ایڈیٹر کی کوئی ترتیب۔
اتھارٹیٹیو نیم سرورز تبدیل ہونے کے بعد بھی پیرنٹ زون پچھلی دستخطی کلید سے متعلق DS ریکارڈ شائع کرتا رہ سکتا ہے۔ اگر نئے زون میں اس سے مطابقت رکھنے والی DNSKEY اور درست دستخط موجود نہ ہوں تو توثیق کرنے والا ریزالور سلسلۂ اعتماد مکمل نہیں کر سکتا۔ عموماً وہ جواب کو ناقابلِ اعتماد، یعنی bogus، قرار دے کر غیر تصدیق شدہ ایڈریس دینے کے بجائے SERVFAIL واپس کرتا ہے۔
یہ HTTP سروس کی بندش سے مختلف مسئلہ ہے۔ ممکن ہے درخواست ویب سرور تک پہنچے ہی نہیں۔ یہ TLS سرٹیفکیٹ کی میعاد ختم ہونے سے بھی الگ ہے: DNSSEC، DNS ڈیٹا کی توثیق کرتا ہے، جبکہ HTTPS اس کے بعد براؤزر اور سرور کے درمیان قائم ہونے والے رابطے کو محفوظ بناتا ہے۔
وہ تشخیصی ٹیسٹ جو DNSSEC کی خرابی اور غائب ریکارڈ میں فرق واضح کرتا ہے
سب سے مفید ٹیسٹ میں ایک ہی ریزالور سے ایک ہی نام کے بارے میں دو بار استفسار کیا جاتا ہے۔ پہلے عام استفسار چلائیں اور صرف جواب نہیں بلکہ اس کی اسٹیٹس بھی دیکھیں:
dig example.com A +noall +comments +answerپھر DNSSEC Checking Disabled (CD) بِٹ فعال کر کے یہی استفسار دہرائیں:
dig example.com A +cdflag +noall +comments +answerمشاہدہ کی گئی خرابی میں عام استفسار کے جواب میں SERVFAIL آیا، مگر CD کے ساتھ استفسار سے متوقع A ریکارڈ مل گیا۔ اس فرق سے مضبوط اشارہ ملا کہ مسئلہ کسی DNS ریکارڈ کی عدم موجودگی یا ایپلی کیشن کے جواب نہ دینے کے بجائے DNSSEC کی توثیق میں تھا۔ +cdflag آپشن اس کی سہولت رکھنے والے ریکرسیو ریزالور سے کہتا ہے کہ اس درخواست کے لیے معمول کی DNSSEC توثیق نہ کرے۔ یہ صرف تشخیص کا طریقہ ہے؛ نہ اس سے براؤزر کی خرابی ٹھیک ہوتی ہے، نہ ویب سائٹ کے زائرین کے لیے DNSSEC بند ہوتا ہے۔
+short کے خالی آؤٹ پٹ سے بہت زیادہ نتیجہ اخذ نہ کریں۔ جواب کا موجود نہ ہونا اور SERVFAIL، دونوں اس مختصر انداز میں خالی دکھائی دے سکتے ہیں۔ خرابی کی تشخیص کے دوران +comments استعمال کرتے رہیں تاکہ status: SERVFAIL اور status: NOERROR واضح نظر آئیں۔
صرف CD کے ساتھ اور اس کے بغیر استفسارات کا موازنہ یہ نہیں بتاتا کہ DNSSEC کے کس حصے میں خرابی ہے؛ اس سے اگلی تفتیش کی سمت ملتی ہے۔ ریزالور کو اپ اسٹریم سے بھی عارضی خرابی پیش آ سکتی ہے، اس لیے ضرورت پڑنے پر ٹیسٹ دہرائیں اور پیرنٹ ڈیلیگیشن کی جانچ کریں۔
صرف DNS ایڈیٹر نہیں، پیرنٹ زون کا DS ریکارڈ بھی دیکھیں
معلوم کریں کہ ڈومین کے لیے DS ریکارڈز موجود ہیں یا نہیں:
dig example.com DS +noall +comments +answerڈیلیگیشن کے راستے کو زیادہ مکمل طور پر دیکھنے کے لیے DNS کے مراتب میں براہِ راست استفسار کریں:
dig +trace example.com DSپیرنٹ کے مخصوص اتھارٹیٹیو نیم سرور کا تعین ٹاپ لیول ڈومین کے مطابق ہوتا ہے۔ اہم چیز پیرنٹ زون کی شائع کردہ DS ریکارڈز کی مجموعی فہرست (RRset) ہے، نہ کہ صرف DNS ہوسٹنگ ڈیش بورڈ کا خلاصہ۔ رجسٹرار منتقل کرنے پر نیم سرورز وہی رہ سکتے ہیں، اور رجسٹرار بدلے بغیر بھی نیم سرورز تبدیل ہو سکتے ہیں۔ دونوں صورتوں میں پیرنٹ کا DS فعال اتھارٹیٹیو زون کے ساتھ ہم آہنگ ہونا ضروری ہے۔
DS ریکارڈ میں چار اہم فیلڈز ہوتی ہیں: کلید کا ٹیگ، الگورتھم، ڈائجسٹ کی قسم اور ڈائجسٹ۔ خرابی تلاش کرتے وقت کلید کا ٹیگ ایک سہولت بخش شناخت ہے، لیکن محض اس سے یہ ثابت نہیں ہوتا کہ DNSKEY مطابقت رکھتی ہے۔ ڈائجسٹ اور الگورتھم کی معلومات کا بھی اس کلید سے مطابقت رکھنا ضروری ہے جو اتھارٹیٹیو زون واقعی فراہم کر رہا ہے۔
اس واقعے میں فیصلہ کن صورتِ حال سادہ تھی: پیرنٹ زون DNSSEC سے متعلق پرانی اعتماد کی معلومات شائع کر رہا تھا، جبکہ نئے اتھارٹیٹیو زون کے انتظامی پینل کے مطابق دستخط کرنے کا عمل غیر فعال تھا۔ A ریکارڈز موجود تھے اور توثیق نظرانداز کرنے پر حاصل بھی ہو رہے تھے۔ ایپلی کیشن کی کنفیگریشن تبدیل کرنے یا بار بار اسی A ریکارڈ میں ترمیم کرنے سے یہ عدم مطابقت ختم نہیں ہو سکتی تھی۔
خراب DNSSEC ڈیلیگیشن بحال کرنے کے دو طریقے
بحالی کے دو درست طریقے ہیں۔ دونوں سلسلۂ اعتماد کی ایک ہی عدم مطابقت دور کرتے ہیں، لیکن عملی نتائج مختلف ہیں۔ سوچ سمجھ کر ایک طریقہ منتخب کریں؛ بلاوجہ کبھی ایک اور کبھی دوسرا طریقہ نہ آزمائیں۔
طریقہ ۱: پرانا DS ہٹا کر عارضی طور پر غیر دستخط شدہ زون چلائیں
موجودہ ڈومین رجسٹرار سے، یا اس کے فراہم کردہ DNSSEC انتظامی انٹرفیس سے، پیرنٹ زون کا پرانا DS ریکارڈ ہٹوائیں۔ جب پیرنٹ محفوظ ڈیلیگیشن کا دعویٰ نہیں کرتا تو DNSSEC کی توثیق کرنے والے ریزالورز غیر دستخط شدہ چائلڈ زون کو ناقص (bogus) سمجھنے کے بجائے غیر محفوظ (insecure) حالت میں قبول کر سکتے ہیں۔ DNS کام کرتا رہتا ہے، لیکن اس ڈومین کی DNSSEC توثیق عارضی طور پر دستیاب نہیں رہتی۔
اگر پیرنٹ کی DS ریکارڈز کی مجموعی فہرست بدلنے کا قابلِ اعتماد طریقہ دستیاب ہو تو ہنگامی حالت میں یہ اکثر آسان انتخاب ہوتا ہے۔ پرانا DS ریکرسیو ریزالورز کی کیش سے ختم ہونے تک موجودہ دستخطی ترتیب مستحکم رکھیں۔ صرف کنٹرول پینل میں DS ہٹایا ہوا نظر آنا کافی ثبوت نہیں: پیرنٹ ریکارڈ کو بیرونی ذرائع سے جانچیں اور اس کے TTL کو مدِنظر رکھیں۔ HTTPS کا کام DNSSEC کی ترتیب سے الگ ہے۔ عارضی غیر دستخط شدہ حالت میں منتقلی کا ذکر RFC 8078 میں بھی موجود ہے۔
طریقہ ۲: نئے زون پر دستخط کریں اور اس سے مطابقت رکھنے والا DS شائع کریں
دوسرا طریقہ یہ ہے کہ نئے اتھارٹیٹیو DNS فراہم کنندہ کے ہاں DNSSEC فعال کیا جائے، DNSKEY سے متعلق کلیدیں تیار کی جائیں، زون پر دستخط کیے جائیں اور متعلقہ DS ریکارڈ پیرنٹ زون میں شائع کیا جائے۔ اس طرح توثیق کرنے والا ریزالور نئی DNSKEY تک اعتماد کا راستہ قائم کر کے A ریکارڈ کی تصدیق کر سکتا ہے۔
مشاہدہ کیے گئے واقعے میں بحالی اسی طریقے سے ہوئی۔ DNS انتظامی انٹرفیس نے بتایا کہ اس نے کلیدیں تیار کر لی ہیں، زون پر دستخط کر دیے ہیں اور نیا DS شائع کر دیا ہے۔ بعد میں پیرنٹ زون سے استفسار کرنے پر پرانے DS کے ساتھ نیا DS بھی نظر آیا۔ DNSSEC کی توثیق کرنے والے ریکرسیو ریزالورز متوقع A ریکارڈ واپس کرنے لگے؛ بعد کے ایک ٹیسٹ میں ad فلیگ کے ساتھ NOERROR بھی ملا، جس کا مطلب تھا کہ اس ریزالور نے ڈیٹا کو تصدیق شدہ قرار دیا۔
مراحل کی ترتیب اہم ہے: شائع کردہ DS تبھی کارآمد ہوتا ہے جب متعلقہ DNSKEY اور درست دستخط پہلے ہی اتھارٹیٹیو DNS سروس سے دستیاب ہوں۔ کنٹرول پینل میں “published” لکھا ہونا بیرونی جانچ کا متبادل نہیں۔ کیش میں موجود DS، DNSKEY، RRSIG اور NS ریکارڈز کے باعث مختلف ریزالورز مختلف اوقات میں بحال ہو سکتے ہیں۔
دو DS ریکارڈز ہونے کے باوجود سائٹ لازماً خراب کیوں نہیں رہی؟
ایک حیرت انگیز بات یہ تھی کہ پیرنٹ زون میں کچھ وقت تک پرانا، غیر مؤثر DS اور نیا درست DS دونوں موجود تھے، پھر بھی DNSSEC کی توثیق کامیاب رہی۔ اس میں کوئی تضاد نہیں۔ DS ریکارڈز کے مجموعے (RRset) میں متعدد ریکارڈز ہو سکتے ہیں، جیسا کہ کلیدیں تبدیل کرتے وقت اکثر ہوتا ہے۔ توثیق کرنے والے ریزالور کے لیے ضروری نہیں کہ ہر DS ریکارڈ کسی فی الحال قابلِ استعمال کلید کی نشاندہی کرے؛ کسی مناسب DS سے DNSKEY اور درست دستخطوں تک ایک معتبر توثیقی راستہ ملنا کافی ہے۔ RFC 6840 واضح کرتا ہے کہ ریزالورز کو ایک درست راستہ ملنے پر اسے قبول کرنا چاہیے۔
اس کا یہ مطلب نہیں کہ پرانی کلیدیں ہمیشہ کے لیے رکھنا مناسب ہے۔ غیر مؤثر DS انتظامی ابہام بڑھاتا ہے، اس لیے نیا سلسلۂ اعتماد جانچ لینے کے بعد اسے بالآخر صاف کر دینا چاہیے۔ لیکن جب توثیق شدہ استفسارات پہلے ہی کامیاب ہو رہے ہوں تو پرانے DS کی صفائی معمول کی دیکھ بھال ہے، دوبارہ خطرناک DNSSEC ری سیٹ کرنے کا جواز نہیں۔
یہاں کنٹرول پینل کا ایک خاص طور پر خطرناک پہلو ہے: “emergency unpublish DS” نامی کارروائی کا مطلب نئے، کام کرنے والے DS سمیت تمام DS ریکارڈز کو ہٹانا ہو سکتا ہے۔ اسی طرح اگر پیرنٹ میں DS بدستور شائع ہو اور آپ زون پر دستخط کرنا بند کر دیں تو خرابی فوراً دوبارہ پیدا ہو سکتی ہے۔ یہ دونوں کارروائیاں کسی ایک مخصوص پرانے DS ریکارڈ کو حذف کرنے کے برابر نہیں۔ اگر انٹرفیس سے ایک ریکارڈ الگ منتخب نہیں کیا جا سکتا تو سب کچھ ہٹانے کے بجائے رجسٹرار کے منظور شدہ مخصوص ریکارڈ کی تبدیلی کا طریقہ استعمال کریں۔
اتھارٹیٹیو نیم سرورز محفوظ طریقے سے کیسے تبدیل کریں
سب سے محفوظ ترتیب اس بات پر منحصر ہے کہ پرانا اور نیا DNS فراہم کنندہ کلیدوں کے انتظام میں آپس میں تعاون کر سکتے ہیں یا نہیں۔ روایتی منتقلی میں، جہاں عارضی طور پر غیر دستخط شدہ وقفہ رکھا جاتا ہے، درج ذیل ترتیب اس واقعے جیسی عدم مطابقت سے بچاتی ہے:
- پہلے نئے زون کو تیار کریں۔ ضروری A، AAAA، CNAME، MX، TXT اور دیگر متعلقہ ریکارڈز نقل کریں۔ ڈیلیگیشن تبدیل کرنے سے پہلے نئے اتھارٹیٹیو نیم سرورز کو براہِ راست جانچیں۔
- پیرنٹ میں DNSSEC کی حالت دیکھیں۔ معلوم کریں کہ DS ریکارڈز موجود ہیں یا نہیں اور انہیں کون تبدیل کر سکتا ہے۔ یہ جانچ تب بھی کریں جب آپ نے خود کبھی DNSSEC فعال نہ کیا ہو؛ کچھ DNS سروسز خودکار طور پر دستخط کرتی ہیں۔
- پرانے دستخط شدہ زون کے چلتے ہوئے پرانا DS ہٹائیں۔ اتھارٹیٹیو پیرنٹ سے تبدیلی کی تصدیق کریں، پھر پہلے سے کیش شدہ DS ڈیٹا کی میعاد ختم ہونے تک مناسب انتظار کریں۔ انتظار کا دورانیہ مشاہدہ کیے گئے TTL پر منحصر ہے، منٹوں کی کسی یکساں مقررہ تعداد پر نہیں۔
- نیم سرورز کی ڈیلیگیشن تبدیل کریں۔ پرانی اتھارٹیٹیو سروس اس وقت تک فعال رکھیں جب تک کیش شدہ NS ڈیلیگیشنز اس کی طرف اشارہ کر سکتی ہوں۔ پیرنٹ کے NS ریکارڈز کے TTL کو مدِنظر رکھیں اور جانچیں کہ مختلف ریزالورز حقیقت میں کون سے سرورز استعمال کر رہے ہیں۔
- فیصلہ کریں کہ DNSSEC دوبارہ فعال کرنا ہے یا نہیں۔ اگر نیا زون غیر دستخط شدہ رکھنا ہے تو DS شائع نہ کریں۔ اگر دستخط شدہ رکھنا ہے تو متعلقہ DS شائع کرنے سے پہلے تصدیق کریں کہ نئی DNSKEY اور دستخط درست طور پر فراہم کیے جا رہے ہیں۔ پرانے NS کی کیش شدہ ڈیلیگیشنز کو بھی سامنے رکھ کر یہ مراحل مربوط کریں تاکہ توثیق کی نئی عدم مطابقت پیدا نہ ہو۔
- آزادانہ تصدیق کریں۔ پیرنٹ کا DS، اتھارٹیٹیو DNSKEY، عام ریکرسیو DNS جواب اور DNSSEC کی توثیق کرنے والے ریزالور سے موصول ہونے والی تصدیق شدہ ڈیٹا کی علامت جانچیں۔
اگر DNSSEC کا تحفظ بغیر وقفے کے برقرار رکھنا ضروری ہو تو عارضی غیر دستخط شدہ مرحلے کی جگہ باقاعدہ مربوط کلیدوں کا رول اوور یا ملٹی سائنر منتقلی بہتر ہے۔ اس کے لیے دونوں DNS فراہم کنندگان کو کلیدوں اور دستخطوں کا متعلقہ انتظام سنبھالنے کی صلاحیت درکار ہوتی ہے؛ پرانے DS ڈائجسٹ کو نئے فراہم کنندہ کے پاس محض نقل کر دینا رول اوور نہیں ہے۔
منتقلی کے بعد تصدیق کی مختصر فہرست
DNSSEC سے متعلق ہر تبدیلی کے بعد DNS ریکارڈز بھی جانچیں اور یہ بھی کہ ریزالورز ان کے ثبوت کو قبول کرتے ہیں یا نہیں:
dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answerتصدیق شدہ جواب کی جانچ کے لیے DNSSEC کی توثیق کرنے والا ریکرسیو ریزالور استعمال کریں۔ اس کے جواب میں NOERROR کے ساتھ متوقع A ریکارڈ ملے تو ڈومین کا نام درست طور پر ریزالو ہوا ہے؛ مزید ad فلیگ ظاہر کرے تو اس کا مطلب ہے کہ ریزالور نے اپنی DNSSEC پالیسی کے مطابق جواب کو تصدیق شدہ بتایا ہے۔ صرف ad فلیگ کا نہ ہونا خرابی کا ثبوت نہیں، کیونکہ ریزالورز کی صلاحیتوں، پالیسیوں اور استفسار کے فلیگز میں فرق ہوتا ہے۔ اگر خرابی کے دوران توثیق کرنے والے ریزالور سے DNSKEY کا استفسار ناکام ہو تو تفتیش کے ایک حصے کے طور پر فعال اتھارٹیٹیو DNS سروس سے براہِ راست سوال کریں۔
صرف ایک ریزالور سے کامیاب جواب ملنے پر جانچ بند نہ کریں۔ مختلف کیشز میں عارضی طور پر مختلف ڈیلیگیشنز اور کلیدیں موجود ہو سکتی ہیں۔ جاری آپریشنل سپورٹ درخواست کو بھی اپ ڈیٹ کریں: نیا، کام کرنے والا DS شائع ہو جانے کے بعد تمام DS ریکارڈز ہٹانے کی پہلے دی گئی ہدایت خطرناک ہو جاتی ہے۔ اگلی درخواست میں واضح کریں کہ فعال کلید برقرار رکھی جائے اور، اگر ضرورت ہو، صرف غیر مؤثر پرانا ریکارڈ حذف کیا جائے۔
یہ خرابی ویب سرور کا ایڈریس غلط ہونے سے پیدا نہیں ہوئی تھی۔ DNS کے جوابات فراہم کرنے کی جگہ تبدیل کر دی گئی تھی، مگر ریزالورز کو یہ بتانے والی اعتماد کی معلومات پہلے ہم آہنگ نہیں کی گئی تھیں کہ کن جوابات پر اعتبار کرنا ہے۔ اس لیے ہر نیم سرور منتقلی سے پہلے بنیادی سوال یہ ہے: پیرنٹ زون کون سے DS ریکارڈز شائع کر رہا ہے، اور کیا نئے زون کی DNSKEY اور دستخط ان کی شرائط پوری کریں گے؟