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

سامع اختیاری ہے اور بطور طے شدہ بند ہے

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

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

A ریکارڈز اور TXT ایک ہی سامعین میں شریک نہیں ہوتے

ان دو قسم کے ریکارڈز کا جواب مختلف شرائط میں دیا جاتا ہے، اور انہیں ایک ہی خدمت سمجھنا وہی غلطی ہے جسے روکنے کے لیے یہ مضمون ہے۔

QueryWhat it returnsWho can reach it
A record for a host nameThat host Nebula IPAny host that can reach the listener, overlay or not
TXT for a host IPCertificate informationOnly over the Nebula network

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

یہ صرف لائٹ ہاؤس کے اپنے ہوسٹس کے بارے میں جواب دیتا ہے

یہ آپ کے دفتر، کلاؤڈ VPC یا عوامی انٹرنیٹ کے لیے عام حل کنندہ نہیں ہے۔ لائٹ ہاؤس اپنے دیے گئے ہوسٹ معلومات سے جواب دیتا ہے، اسی لیے یہ خصوصیت ہر ساتھی پر نہیں بلکہ لائٹ ہاؤس نوڈز پر رہتی ہے۔

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

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

بائنڈ پتہ جانچیں، پھر باہر سے آزمائیں

lighthouse.dns.host اور lighthouse.dns.port طے کرتے ہیں کہ اختیاری خدمت کہاں سنتی ہے۔ ان اقدار کو ہوسٹ فائر وال اور نیٹ ورک پالیسی کے ساتھ مل کر دیکھیں، کیونکہ بائنڈ پتہ ارادے کا اعلان ہے اور بذات خود سلامتی کنٹرول نہیں۔

dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +short

جن نیٹ ورکس کو آپ اجازت دینا چاہتے ہیں وہاں سے استفسار کریں، خود لائٹ ہاؤس سے نہیں۔ لائٹ ہاؤس پر کامیاب تلاش ثابت کرتی ہے کہ عمل چل رہا ہے اور اس بارے میں کچھ نہیں بتاتی کہ باہر کا ہوسٹ کیا پوچھ سکتا ہے، اور اصل اہم سوال وہی ہے۔

اسے جان بوجھ کر ظاہر کریں

نام اور سرٹیفکیٹ میٹا ڈیٹا مفید عملی معلومات ہیں، اور افادیت دونوں طرف کاٹتی ہے۔ طے کریں کہ سامع صرف اوورلے کے لیے ہونا چاہیے یا نہیں، کون سی ریکارڈ اقسام کی اجازت ہو اور ترتیب بدلنے پر کون جائزہ لیتا ہے۔

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

متعلقہ مضامین