VPN پر BIND: مشروط فارورڈ یا stub زون؟
VPN کے ذریعے ایک نجی زون حل کرنے کے تین طریقے اور ہر ایک کب موزوں ہے: forward، stub یا secondary، نیز فیصلہ کرنے والی ماخذ پتے کی جانچ۔
آپ کا دفتری resolver ایک کارپوریٹ نام کی جگہ کے سوا سب کا جواب دیتا ہے، اور اُسے جاننے والا کارپوریٹ DNS سرور VPN کے پیچھے ہے۔ BIND اُس واحد زون کو upstream تک تین مختلف طریقوں سے دے سکتا ہے، اور وہ مختلف انداز میں ناکام ہوتے ہیں۔ مشروط فارورڈ سب سے چھوٹا عہد ہے، stub زون delegation ڈیٹا رکھتا ہے، اور secondary مکمل نقل رکھتا ہے۔ آپ نے پہلے کون سا snippet دیکھا اُس کی بنیاد پر نہیں، بلکہ upstream کیا اجازت دے گا اور آپ اپنے resolver میں کیا رکھنا چاہتے ہیں اُس کی بنیاد پر چنیں۔
ایک نام کی جگہ کے لیے تین ترتیبیں
| Type | What your resolver keeps | Upstream must | Fails when |
|---|---|---|---|
forward | a forwarder list | answer queries from your source address | upstream is down and forward only is set |
stub | the zone's NS records and addresses | answer NS queries for the zone | delegation data goes stale after an NS change |
secondary | a full copy of the zone | permit AXFR or IXFR from your source | transfer is blocked by ACL or firewall |
مشروط فارورڈ: سب سے چھوٹا عہد
فرض کریں دفتری resolver 192.168.10.53 پر ہے اور کارپوریٹ سرور 10.40.0.53 پر، جو منظور شدہ ٹنل سے قابل رسائی ہے۔ اعلان تین سطروں کا ہے، اور دلچسپ بات forward only ہے، کیونکہ یہ راستہ نہیں، ناکامی کا رویہ بدلتا ہے۔
zone "corp.example" {
type forward;
forward only;
forwarders { 10.40.0.53; };
};forward only کے ساتھ، ناقابل رسائی upstream اس زون کے لیے دہرائے جانے والے حل کی طرف واپسی کے بجائے SERVFAIL دیتا ہے۔ نجی نام کی جگہ کے لیے عام طور پر یہی چاہیے ہوتا ہے، کیونکہ واپسی نجی ناموں کو عوامی resolver بھیجتی اور انٹرنیٹ سے بیکار جواب لاتی۔ BIND حوالہ دونوں پالیسیوں کی دستاویز کرتا ہے، اور فرق snippet کے اشارے سے زیادہ اہم ہے۔ زون کو موجودہ کنفیگریشن میں شامل کریں، اُس زون کو بدلنے کے بجائے جو اسی نام کے لیے پہلے سے موجود ہے۔
stub یا secondary: جب delegation اہم ہو
stub زون کارپوریٹ سرور سے زون کے NS ریکارڈ پوچھتا ہے اور پھر بااختیار سرورز سے براہ راست پوچھتا ہے۔ اُسے تب چنیں جب upstream علاقہ بڑا یا منقسم ہو اور آپ چاہیں کہ آپ کا resolver delegation کی پیروی کرے، ہر چیز کو ایک پتے پر کیل نہ لگائے۔ قیمت یہ ہے کہ NS ڈیٹا تازہ رہے اور فہرست شدہ ہر نام سرور آپ کے resolver کے ماخذ پتے سے قابل رسائی ہو، اِس پر انحصار۔
zone "corp.example" {
type stub;
masters { 10.40.0.53; };
};
zone "corp.example" {
type secondary;
primaries { 10.40.0.53; };
file "corp.example.db";
};secondary مقامی ڈیٹا سے جواب دیتا ہے اور upstream کی بندش سہتا ہے، اور یہی انتقال پر انحصار قبول کرنے کی وجہ ہے۔ اس کا مطلب یہ بھی ہے کہ آپ کا resolver اب ایسے زون کی نقل رکھتا ہے جو اس کا نہیں، لہٰذا فائل کا راستہ، بنیادی سرور پر transfer ACL اور ریفریش ٹائمر سب آپ کی عملی سطح کا حصہ بن جاتے ہیں۔
وہ جانچ جو اِن کے درمیان فیصلہ کرتی ہے
BIND اپنی باہر جانے والی استفسار خود بناتا ہے، لہٰذا سوال یہ نہیں کہ لیپ ٹاپ 10.40.0.53 تک پہنچ سکتا ہے، بلکہ یہ کہ resolver کا ہوسٹ کارپوریٹ سرور کے دیکھے جانے والے ماخذ پتے سے پہنچ سکتا ہے۔ پہلے کرنل سے پوچھیں، پھر سرور سے، اسی ترتیب میں۔
ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.exampleراستے پر UDP اور TCP کی اجازت دیں: کٹا ہوا جواب TCP پر مجبور کرتا ہے، اور صرف UDP کی اجازت دینے والی پالیسی وقفے وقفے سے ناکامیاں پیدا کرتی ہے جو پیکٹ ضائع ہونے جیسی لگتی ہیں۔ کارپوریٹ فریق کو آپ کے resolver کے ماخذ کے لیے قبولیت کا قاعدہ اور اُس تک واپسی کا راستہ، دونوں درکار ہیں؛ وہ ماخذ resolver کا روٹ شدہ پتہ یا واضح طور پر ترجمہ شدہ پتہ ہو سکتا ہے، اور یہ شاذ و نادر ہی کلائنٹ پول کا پتہ ہوتا ہے۔ اگر NS استفسار ناکام ہو، تو forward زون کیسا بھی رویہ رکھے، stub زون کام نہیں کر سکتا۔
ٹنل نہیں، جواب کی تصدیق کریں
دفتری resolver کے ذریعے ایسے نام کی استفسار کریں جو آپ نے کبھی نہیں مانگا، اور جواب کا authority حصہ دیکھیں کہ آیا یہ کارپوریٹ زون سے آیا۔ کیش میں موجود جواب موجودہ راستے کے بارے میں کچھ ثابت نہیں کرتا، اور upstream سے براہ راست کامیاب استفسار یہ ثابت نہیں کرتا کہ آپ کے resolver نے وہ زون چنا۔ وہی استفسار TCP پر دہرائیں تاکہ یقین ہو کہ راستہ کٹائی سہہ جاتا ہے۔
کلائنٹس کو دفتری resolver کی طرف رکھیں، اور DNSSEC تصدیق کو فعال رکھیں۔ خودمختار خفیہ resolver کے ساتھ ترتیب دیا گیا براؤزر اس ترتیب کو مکمل طور پر نظرانداز کرتا ہے، اور غیر متوقع جواب کو درست دکھانے کے لیے تصدیق بند کرنا نظر آنے والی ناکامی کو نظر نہ آنے والی ناکامی سے بدل دیتا ہے۔
لکھیں کہ تین میں سے کون سی قسم چنی اور کیوں۔ زون کی ناکامی دیکھنے والے اگلے شخص کو کنفگ فائل سے زیادہ اُس جملے کی ضرورت ہوگی۔