نجی Route 53 زون عوامی ناموں کے لیے NXDOMAIN کیوں واپس کرتا ہے

نجی Route 53 زون عوامی ریکارڈ کے ساتھ ضم ہونے کے بجائے نام کا جواب بدل دیتے ہیں، اور یہی وجہ ہے کہ لوگ بدترین لمحے میں حیران رہ جاتے ہیں۔ ایک اندرونی ریکارڈ شامل کریں api.example.net کے لیے نجی زون میں example.net، اسے VPC سے منسلک کریں، اور اس والد کے تحت ہر دوسرا نام اب صرف نجی زون سے جواب پاتا ہے۔ جو کلائنٹ کل www.example.net تک پہنچ سکتا تھا، آج اسے منفی جواب ملتا ہے۔ نیچے کی تفصیل اسی ناکام استفسار سے شروع ہوتی ہے اور جواب دینے والے زون کی طرف باہر جاتی ہے۔

کنسول سے نہیں، استفسار سے شروع کریں

مسئلہ رپورٹ کرنے والے کلائنٹ پر ہی خرابی دوبارہ پیدا کریں اور درست نام اور ریکارڈ کی قسم لکھیں۔ جو نام A کے لیے ناکام ہوتا ہے وہ AAAA کے لیے اب بھی حل ہو سکتا ہے، اور کیش شدہ نام دوبارہ آزمانے والا براؤزر چھپا دیتا ہے کہ کون سا ٹوٹا۔ استفسار دو بار چلائیں: ایک بار اس resolver کے ذریعے جو کلائنٹ واقعی استعمال کرتا ہے، اور ایک بار اسے نظرانداز کرنے والی ٹریسنگ کے ساتھ۔

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

دوسرا حکم ہی اہم ہے۔ اس کی اسٹیٹس لائن اور authority حصہ اس زون کا نام دیتے ہیں جس نے جواب بنایا، اس لیے آپ نجی زون سے آنے والے منفی جواب کو ٹائم آؤٹ، بلاک شدہ پورٹ یا ایسے resolver سے الگ کر سکتے ہیں جسے استفسار کبھی نہ ملا۔ resolvectl دکھاتا ہے کہ کس بالائی سرور سے پوچھا گیا، اور اکثر وہ وہی resolver نہیں ہوتا جو آپ نے سمجھا تھا کہ VPN نے بھیجا ہے۔

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

پڑھیں کہ کس زون نے جواب دیا

درج ذیل رکھنے والا جواب: NXDOMAIN اور authority حصے میں نجی زون کا SOA ہو تو یہ اسی زون کا حتمی جواب ہے، ناکام تلاش نہیں۔ Route 53 Resolver نے نجی ہوسٹ شدہ زون اس لیے چنا کہ نام مماثل تھا، پھر مطلوبہ قسم کا کوئی ریکارڈ نہ ملا، اور دستاویزی رویہ یہ ہے کہ سوال عوامی DNS کو بھیجنے کے بجائے منفی جواب واپس کیا جائے۔

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

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

دونوں احکام کو زون کے مالک اکاؤنٹ کی اسناد درکار ہیں، اور دوسرے کو پہلے سے زون ID چاہیے۔ اسے اپنی ID سے بدلیں؛ اوپر دیا گیا پلیس ہولڈر جان بوجھ کر حقیقی نہیں ہے۔

نجی زون کیوں جیتتا ہے

تعلق ہی زون کو VPC کے لیے نظر آنے والا بناتا ہے، اور اسی VPC کا resolver اسے لاگو کرتا ہے۔ جس VPC سے کلائنٹ کی ٹریفک آتی ہے اس سے منسلک نہ ہونے والا نجی زون کوئی اثر نہیں ڈالتا، جبکہ غلط VPC سے تعلق غلط آبادی کے لیے نجی جواب بناتا ہے۔ ریکارڈ میں ترمیم سے پہلے تعلقات کی فہرست دیکھیں، کیونکہ زون درست ہو کر بھی نظر نہ آ سکتا ہے۔

اوور لیپ ہوتے نام کی جگہیں الجھن کا دوسرا ذریعہ ہیں۔ example.net کے لیے نجی زون اور api.example.net کے لیے نجی زون دونوں ایک API استفسار سے مماثل ہوتے ہیں، اور زیادہ مخصوص جواب دیتا ہے۔ یہ تب مفید ہے جب آپ تنگ اندرونی نام کی جگہ چاہتے ہیں، اور تب خطرناک ہے جب تنگ زون میں وہ ریکارڈ نہ ہو جو وسیع میں موجود ہے۔ نجی ہوسٹ شدہ زونوں پر غور و فکر Route 53 دستاویزات میں نیچے گرنے کا رویہ اور قواعد کی ترجیح دونوں بیان کرتے ہیں، اور دوسرا اوور لیپ زون شامل کرنے سے پہلے انہیں پڑھنا مناسب ہے۔

ان میں سے کچھ بھی عوامی زون نہیں بدلتا۔ عوامی resolver اب بھی عوامی ریکارڈوں کا درست جواب دیتے ہیں، اور اسی لیے VPC سے باہر سب کو یہ خرابی کلائنٹ کا مسئلہ لگتی ہے۔

ریکارڈ شامل کرنے سے پہلے نام کی جگہ منتخب کریں

اگر صرف اندرونی خدمات کے نئے خاندان کو نجی نام درکار ہوں تو اسے ایک مخصوص نجی ذیلی ڈومین دیں اور عوامی والد کو چھیڑیں نہیں۔ internal.example.net جیسا نام www.example.net کو سایہ نہیں ڈال سکتا، اور غائب ریکارڈ کا اثر و رسوخ انہی ناموں تک محدود رہتا ہے جو آپ نے اسی مقصد کے لیے بنائے۔ قیمت یہ ہے کہ موجودہ URL اور سرٹیفکیٹ نئے نام سے مطابقت نہ رکھیں۔

جب عوامی اور نجی صارفین کو ایک ہی ہوسٹ نام برقرار رکھنا ہو تو منقسم منظر والا DNS معاون ڈیزائن ہے اور یہ تقاضا کرتا ہے کہ آپ ہر منظر میں ریکارڈ واضح طور پر برقرار رکھیں۔ ایک ہی ریکارڈ والا وسیع نجی زون اس زون کے تحت عوامی انحصار محفوظ نہیں رکھتا؛ وہ انہیں ایک ریکارڈ والے زون سے بدل دیتا ہے۔

کلائنٹ آبادی کو نجی منظر کی طرف موڑنے سے پہلے ان ناموں کی فہرست بنائیں جو کوئی ایپلیکیشن واقعی کال کرتی ہے۔ لاگ ان ہوسٹ، اسٹیٹک اثاثہ ہوسٹ، ری ڈائریکٹ ہدف اور API اینڈ پوائنٹ سب سے پہلے ٹوٹتے ہیں، اور وہ عام طور پر کئی ٹیموں کے ریکارڈ میں بکھرے ہوتے ہیں۔

resolver کا راستہ، پھر روٹ ٹریس کریں

لیپ ٹاپ نجی منظر تبھی دیکھتا ہے جب اس کے استفسارات اس resolver تک پہنچیں جس کے پاس تعلق ہے۔ VPN سرور پر hosts فائل میں ترمیم منسلک کلائنٹس کو کچھ شائع نہیں کرتی، اور عوامی resolver کے ساتھ ترتیب دیا گیا کلائنٹ ٹنل فعال رہنے تک عوامی جوابات وصول کرتا رہے گا۔ کلائنٹ کو ملنے والے resolver پتے کی تصدیق کریں، پھر استفسار سرور سے نہیں، کلائنٹ سے دہرائیں۔

نام حل ہونے کے بعد، واپس آئے پتے تک کا راستہ الگ مرحلے کے طور پر جانچیں، مثلاً ip route get کے ساتھ استفسار کے واپس کردہ پتے کے مقابل۔ پتے تک روٹ کے بغیر درست نجی جواب روٹنگ کا مسئلہ ہے، اور ریکارڈ نہ ہونے کا جواب DNS منظر کا مسئلہ ہے؛ دونوں کو ایک مسئلہ سمجھنے سے ایسی اصلاحات بنتی ہیں جو قائم نہیں رہتیں۔ سروس کے TLS ہوسٹ نام اور سرٹیفکیٹ کی جانچ بغیر تبدیلی کے رکھیں، کیونکہ نجی پتہ بدلتا ہے کہ کنکشن کہاں جاتا ہے اور کون سا سرٹیفکیٹ درست ہے اس بارے میں کچھ نہیں۔

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