اندرونی میزبان نام dig میں حل کیوں ہوتے ہیں مگر VPN پر curl میں ناکام ہو جاتے ہیں
dig جواب دیتا ہے، مگر curl بتاتا ہے کہ وہ میزبان حل نہیں کر سکتا۔ دونوں تلاش کی زنجیریں موازنہ کریں، پھر nsswitch، فی رابط DNS یا غلط تلاش لاحقہ درست کریں۔
آپ کا لیپ ٹاپ VPN پر ہے، dig service.internal.example 10.x پتے کے ساتھ جواب دیتا ہے، اور curl پھر بھی Could not resolve host کے ساتھ ختم ہوتا ہے۔ سرنگ مسئلہ نہیں: اس نے dig کی استفسار بغیر شکایت منتقل کی۔ فرق اس میں ہے کہ سوال کون پوچھتا ہے۔ dig ایک استفسار آپ کے بتائے ہوئے ایک سرور کو بھیجتا ہے، جبکہ curl آپریٹنگ سسٹم کی تلاش کی زنجیر سے گزرتا ہے، اور اس زنجیر کے اپنے قواعد ہیں کہ کس سرور سے پوچھا جائے۔
ایک ہی نام کے لیے دو تلاشیں
dig اپنا الگ stub resolver ہے۔ یہ /etc/resolv.conf پڑھتا ہے، نام سرور منتخب کرتا ہے، ایک A یا AAAA استفسار بھیجتا ہے اور جواب چھاپتا ہے۔ یہ nsswitch کو مکمل طور پر چھوڑ دیتا ہے اور اس فی رابط حالت سے کچھ نہیں جانتا جو systemd-resolved یا NetworkManager اس فائل سے باہر رکھتے ہیں، اسی لیے dig کا جواب درست ہو سکتا ہے اور پھر بھی آپ کو اس بارے میں کچھ نہ بتائے کہ آپ کی ایپلیکیشن کیا دیکھے گی۔
ایپلیکیشنز getaddrinfo کو پکارتی ہیں، اور getaddrinfo لمبی زنجیر سے گزرتا ہے: nsswitch کے ماڈیولز کی ترتیب، پھر وہ ماڈیول جو نام کو سنبھالتا ہے، اور آخر میں موجودہ رابط کنفیگریشن سے بنایا گیا resolver۔ systemd مشین پر استفسار 127.0.0.53 کو جاتا ہے، اور systemd-resolved tun انٹرفیس سے منسلک روٹنگ ڈومین کی بنیاد پر ہر رابطے کے لیے اوپر کا سرور منتخب کرتا ہے۔
دو کمانڈیں ان تہوں کو بغیر اندازے کے الگ کرتی ہیں:
getent ahosts service.internal.example
resolvectl query service.internal.examplegetent وہی راستہ استعمال کرتا ہے جو curl کرتا ہے، اس لیے کام کرنے والے dig کے ساتھ getent کی ناکامی خرابی کو پیکٹ روٹنگ میں نہیں بلکہ تلاش کی پالیسی میں نشان زد کرتی ہے۔ resolvectl query وہ انٹرفیس اور اوپر کا سرور بھی چھاپتا ہے جس نے جواب دیا، جو دکھاتا ہے کہ سرنگ کا رابطہ جیتا یا طبعی رابطہ۔
وہ resolver پڑھیں جو ایپلیکیشن واقعی استعمال کرتی ہے
/etc/resolv.conf زیادہ تر ڈیسک ٹاپس پر بنایا جاتا ہے، اور VPN کلائنٹ کے پاس اس سے نمٹنے کے تین طریقے ہیں: نام سرور آگے لگانا، فائل کو اوپر لکھنا، یا اپنے سرورز NetworkManager کے حوالے کر کے ڈیمون کو اسے دوبارہ لکھنے دینا۔ صرف تیسرا نمونہ فی رابط DNS محفوظ رکھتا ہے، کیونکہ سرورز ایک عالمی فہرست میں ہموار ہونے کے بجائے انٹرفیس سے جڑے رہتے ہیں۔
NetworkManager نظاموں میں نتیجہ /etc/NetworkManager/NetworkManager.conf میں backend پر منحصر ہے:
[main]
dns=systemd-resolveddns=default کے ساتھ کلائنٹ کے سرورز جیتنے والی ترتیب میں resolv.conf میں ضم ہو جاتے ہیں، اور نجی استفسار پھر بھی عوامی resolver کو جا سکتا ہے۔ ایسے backend کے ساتھ جو روابط سمجھتا ہے، systemd-resolved یا dnsmasq، سرنگ کے سرورز سرنگ تک محدود رہتے ہیں اور وہاں صرف وہ نام جاتے ہیں جو اس کے روٹنگ ڈومین سے میل کھاتے ہیں۔ یہی تحدید عملی طور پر split DNS کا مطلب ہے، اور یہی وہ حصہ ہے جو اکثر غائب ہوتا ہے جب کوئی کلائنٹ اس کی حمایت کا دعویٰ کرتا ہے۔
کچھ بھی بدلنے سے پہلے حالت پڑھیں:
resolvectl status
resolvectl dns tun0آپ tun انٹرفیس کو DNS سرور اور نجی لاحقے کے لیے روٹنگ ڈومین کے ساتھ درج دیکھنا چاہتے ہیں، جو ~internal.example کی صورت میں دکھایا گیا ہو۔ رابطے پر کوئی سرور نہ ہونا بتاتا ہے کہ کلائنٹ نے کچھ نہیں بھیجا۔ ڈومین کے بغیر سرور بتاتا ہے کہ استفسارات یا تو سب وہاں جاتے ہیں یا کوئی نہیں، کلائنٹ کے مطابق، اور دونوں میں سے کوئی بھی split DNS نہیں۔
جہاں nsswitch تلاش کو وقت سے پہلے ختم کرتا ہے
معیاری ڈیسک ٹاپ سطر ایسی دکھتی ہے:
hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostnamemdns4_minimal ملٹی کاسٹ DNS سنبھالتا ہے اور .local پر ختم ہونے والے ہر نام کا دعویٰ کرتا ہے۔ api.infra.svc.cluster.local جیسی Kubernetes سروس بھی .local پر ختم ہوتی ہے۔ جب mDNS ماڈیول NOTFOUND بتاتا ہے، تو عمل [NOTFOUND=return] پوری تلاش ختم کر دیتا ہے بجائے dns ماڈیول کی طرف بڑھنے کے، اس لیے نام کبھی VPN resolver کو نہیں بھیجا جاتا۔ dig فائل کو مکمل طور پر نظرانداز کرتا ہے، اور یہی وجہ ہے کہ دونوں اوزار متفق نہیں۔
یہ اس مسئلے کا سب سے تیز تضاد ہے، اور یہ آپ کے VPN سے پرانی کنفیگریشن فائل کے ایک لفظ پر آ کر ٹھہرتا ہے۔ عمل کو [NOTFOUND=continue] میں بدلنا پرنٹرز اور مقامی آلات کے لیے mDNS برقرار رکھتا ہے جبکہ DNS کو نام دیکھنے دیتا ہے۔ سطر کو hosts: files dns سے بدلنا بھی کام کرتا ہے اور زیادہ کھردرا ہے: یہ اس پرنٹر کے لیے .local حل ہٹا دیتا ہے جو آپ واقعی استعمال کرتے ہیں۔
ایسے نام جو ٹھیک ایک ہی نیٹ ورک میں رہتے ہیں
نجی زون ٹھیک ایک ہی جگہ مستند ہوتے ہیں۔ ip-10-0-4-31.eu-west-1.compute.internal جیسا AWS نام اسی خطے کے VPC resolver کے ذریعے جواب پاتا ہے، اور صرف اس وقت تک جب آپ کا VPN اینڈ پوائنٹ اسی خطے میں ہو جس میں وسیلہ ہے۔ فرینکفرٹ کے اینڈ پوائنٹ سے جڑیں، آئرلینڈ کا compute.internal نام پوچھیں، اور کوئی مقامی ترتیب مدد نہیں کرے گی: ریکارڈ رکھنے والا زون وہاں سے قابل رسائی نہیں۔
تلاش کے ڈومین الٹی تصویر بناتے ہیں۔ خالی service اس لاحقے سے مکمل ہوتا ہے جو resolver قابلِ اطلاق سمجھتا ہے، اور VPN رابطے کے ساتھ مقامی ڈومین کارپوریٹ ڈومین پر بھاری پڑ سکتا ہے۔ اندازہ ختم کرنے کے لیے آخر میں نقطہ لگا کر پوچھیں، getent ahosts service.internal.example.، اور اگر یہ کام کرے جبکہ مختصر نام ناکام ہو، تو درستی سرنگ پر تلاش کا ڈومین ہے، سرور کا پتہ نہیں۔
منظم کلائنٹ سسٹم resolver کے اوپر تیسری تہہ شامل کرتے ہیں۔ Windows VPN پروفائل اپنی نام حل کرنے کی پالیسی، فی ایپ قواعد اور NRPT جدول ساتھ لا سکتا ہے جو سرنگ بند ہونے پر بھی لاگو ہوتا ہے۔ اپنے DNS کیش والی ایپلیکیشنز، جو .NET اور Java ماحول میں عام ہیں، زنجیر درست ہونے کے بعد بھی پرانی ناکامی کو دیر تک تھامے رکھتی ہیں۔ Apple کلائنٹ split DNS کو DNS ترتیبات میں مماثل ڈومینز کے ذریعے ترتیب دیتے ہیں، resolv.conf کے ذریعے نہیں، اور Chromium یا Firefox محفوظ DNS موڈ میں عوامی ناموں کے لیے سسٹم resolver کو نظرانداز کر سکتے ہیں۔ Microsoft کا VPN نام حل کا حوالہ اس پالیسی تہہ کا Windows پہلو بیان کرتا ہے۔
طے کریں کہ کون سی تہہ درست کرنی ہے
درستیوں کو ترتیب سے آزمانے کے بجائے علامت سے تہہ کی طرف چلیں:
| Symptom | What it means | Check first |
|---|---|---|
| dig answers, getent fails | lookup chain, not the packet path | nsswitch line and resolvectl status |
| Timeout rather than NXDOMAIN | private resolver unreachable through the tunnel | resolvectl dns tun0, route to that address |
| NXDOMAIN | an authority answered and does not know the name | zone owner, endpoint region |
| FQDN works, short name fails | search suffix mismatch | resolvectl domain on the tun link |
| getent works, app fails | app cache or its own resolver | restart the app, check secure DNS |
دو سطریں زیادہ تر وزن اٹھاتی ہیں۔ وقت کا ختم ہونا رسائی کا مسئلہ ہے: نجی resolver سرنگ کے ذریعے جواب نہیں دیتا، اس لیے اس کے پتے تک راستہ اور یہ کہ رابطے پر DNS سرور وہی ہے جو آپ سمجھتے ہیں، جانچیں۔ NXDOMAIN اختیار کا مسئلہ ہے: کسی چیز نے جواب دیا اور وہ نام نہیں جانتا، جو زون، خطے یا ایسے resolver کی طرف اشارہ کرتا ہے جسے یہ استفسار کبھی نہیں ملنی چاہیے تھی۔
آخری سطر وہ ہے جو لوگ چھوڑ دیتے ہیں کیونکہ دونوں نصف کامیابی لگتے ہیں۔ FQDN سے مختلف حل ہونے والا مختصر نام لاحقے کا عدم توازن ہے، اور سرنگ دوبارہ جوڑنے سے یہ نہیں بدلے گا کہ کلائنٹ کون سا لاحقہ بھیجتا ہے۔
کنفیگریشن فائل میں ترمیم سے پہلے حالت محفوظ کریں، تاکہ آپ بتا سکیں کہ ترمیم نے کچھ کیا یا نہیں:
resolvectl status > before.txt
getent ahosts service.internal.example >> before.txtجانچیں اس ترتیب سے چلائیں اور پہلی ناکامی پر رک جائیں۔ getent اور resolvectl query کا متفق ہونا ضروری ہے؛ اگر getent ناکام ہو جبکہ dig جواب دے، تو تلاش کی زنجیر میں رہیں اور روٹنگ کو نہ چھیڑیں۔ resolvectl status کو tun انٹرفیس پر DNS سرور اور روٹنگ ڈومین دکھانا چاہیے۔ nsswitch کو زیرِ جانچ لاحقے کے لیے NOTFOUND پر وقت سے پہلے واپس نہیں آنا چاہیے۔ نام کو اس نیٹ ورک میں مستند ہونا چاہیے جس سے آپ کا اینڈ پوائنٹ جڑا ہے، آخر میں نقطے کے ساتھ جانچا گیا۔ ایپلیکیشن کو اپنا کیش یا محفوظ DNS کی اوور رائیڈ نہیں رکھنی چاہیے۔
صرف پہلی ناکام تہہ درست کریں، پھر وہی کمانڈیں دوبارہ چلائیں۔ ایک وقت میں دو تبدیلیاں آپ کو یہ بتانے سے محروم کر دیتی ہیں کہ کون سی اہم تھی، اور اگلی خرابی تحقیق صفر سے شروع کرتی ہے۔