نجی DNS نام یا صرف ایک IP؟ شیئر کرنے سے پہلے فیصلہ کریں

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

پہلی شرط: کلائنٹ کے پاس کون سا resolver راستہ ہے؟

نجی نام تبھی کام کرتا ہے جب کلائنٹ کا resolver اُس کا جواب دے سکے۔ اس کا مطلب یہ ہے کہ مجاز دور دراز کلائنٹ کو زون رکھنے والے DNS سرور تک پہنچنا چاہیے، یا سرنگ کے ذریعے یا اُس resolver کے ذریعے جو تنظیم پہلے سے دور دراز صارفین کے لیے چلا رہی ہے۔ سرنگ ایک نقل و حمل ہے، ڈائریکٹری نہیں۔ یہ کلائنٹ کو resolver تک راستہ دیتی ہے، اور یہ نہیں بتاتی کہ کون سا زون پوچھنا ہے۔

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

لپ ٹاپ کے VPN سے جڑنے کی وجہ سے عوامی resolver نجی زون نہیں سیکھے گا۔

لاحقہ بھی اسی توجہ کا حقدار ہے۔ تنظیم کے زیرِ کنٹرول ڈومین کا ذیلی ڈومین استعمال کریں، تاکہ ملکیت اور سرٹیفکیٹ کی منصوبہ بندی واضح رہے۔ .local سے بچیں: ملٹی کاسٹ DNS تفصیل اُس لاحقے کو لنک لوکل حل سے باندھتی ہے، اور روٹ شدہ سرنگ وہ رویہ آپ کے لیے دوبارہ پیدا نہیں کرتی۔

دوسری شرط: سروس کون سا ماخذ وصول کرتی ہے؟

رسائی کے قواعد پتوں کے خلاف لکھے جاتے ہیں، اس لیے مفید سوال یہ ہے کہ روٹنگ اور ترجمے کے بعد سروس کون سا پتہ دیکھتی ہے۔ 10.20.30.40 پر ایک مثال سروس کے لیے، دفتری کلائنٹ 10.20.30.0/24 سے آتے ہیں اور دور دراز کلائنٹ 10.99.0.0/24 جیسے الگ پول سے آتے ہیں۔

اگر گیٹ وے دور دراز پول کا ترجمہ کرے تو سروس مترجم کو دیکھتی ہے، اور 10.99.0.0/24 کے لیے لکھا قاعدہ میل نہیں کھائے گا۔

یہ کلائنٹ کی طرف سے نہیں بلکہ سروس کی طرف سے پڑھیں۔ سروس ہوسٹ پر سننے والے کا لاگ یا پیکٹ کیپچر وہ ماخذ دکھاتا ہے جو واقعی پہنچا؛ کلائنٹ کا اپنا پتہ صرف ایک اندازہ ہے کہ راستے میں کیا بچا۔

تیسری شرط: نام سروس سے جڑا ہے یا ہوسٹ سے؟

ایک مشین کے پتے کی طرف اشارہ کرنے والا نام ہر کلائنٹ کو اُس مشین سے باندھ دیتا ہے۔ لوڈ بیلنسر یا مستحکم سروس پتے کی طرف اشارہ کرنے والا نام اُس کے پیچھے ہوسٹ بدلنے پر بھی قائم رہتا ہے۔ سوچ سمجھ کر چنیں، کیونکہ اسے بعد میں بدلنے کا مطلب ہر کلائنٹ کے بُک مارکس اور ہر سرٹیفکیٹ کا موضوع بدلنا ہے۔

ایک اندرونی سروس کے لیے، براہِ راست ریکارڈ عام طور پر مناسب ہوتا ہے اور سوچنا آسان ہوتا ہے۔

ہر اُس چیز کے لیے جو بدلی، دوبارہ بنائی یا اسکیل ہوگی، مستحکم فرنٹ اینڈ اضافی کنفیگریشن کے قابل ہے۔ امتحان سادہ ہے: اگر آپ صارفین کو بتائے بغیر بیک اینڈ بدل سکتے ہیں تو نام سروس سے جڑا ہے؛ اگر نہیں، تو یہ ہوسٹ سے جڑا ہے۔

دونوں فیصلوں کو الگ الگ جانچیں

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

curl -sv --max-time 5 https://files.corp.example/health

پھر ایک بار ممنوع ماخذ کی جانچ کریں، اور نتیجہ لکھیں۔

اپنی دستاویزات میں دونوں ریکارڈ الگ رکھیں: نام اور اُس کا زون، قبول شدہ ماخذ اور قاعدے کا مالک۔ جب ایک بدلے تو دوسرے کا بدلنا ضروری نہیں۔

فیصلہ عام طور پر کہاں غلط ہوتا ہے

عام ناکامی وہ سروس ہے جو صرف دفتری نیٹ ورک پر حل ہونے والے نام کے تحت شائع ہو، ساتھ ایسا رسائی قاعدہ جو صرف دفتری حد قبول کرے۔ تب دور دراز صارفین ٹوٹی سروس کی شکایت کرتے ہیں، جو درحقیقت دو الگ کوتاہیاں ہیں۔ دوسری عام ناکامی اُلٹ ہے: نام کے مسئلے کو دور کرنے کے لیے شامل کیا گیا وسیع رسائی قاعدہ سروس کو ایسے ماخذوں سے قابلِ رسائی رکھتا ہے جو کسی نے نہیں چاہے۔ دونوں کنفیگریشن کی کوتاہیاں ہیں، اور صارف کی کرسی سے دونوں ایک جیسے دکھتے ہیں۔

ایک کامیاب امتحان سے کوئی بھی غلطی نظر نہیں آتی۔ اسی لیے دونوں فیصلے الگ ریکارڈ اور الگ امتحان کے حقدار ہیں، چاہے ایک ہی شخص دونوں کرے۔

سروس شروع ہونے سے پہلے دونوں لکھیں، کیونکہ اگلی تبدیلی پر سوچنا آسان ہوگا۔ ریکارڈ مختصر ہے: نام اور اُس کے زون کے لیے ایک سطر، قبول شدہ ماخذوں اور قاعدے کے مالک کے لیے ایک سطر۔