BIND د VPN له لارې: شرطي لېږد که stub زون؟
د VPN له لارې د یوې شخصي زون د حل درې لارې او هر یو کله مناسب دی: forward، stub یا secondary، د سرچینې پتې هغه څېړنه چې پرېکړه کوي.
ستاسو د دفتر resolver له یوې کارپوریټ نوم فضا پرته هر څه ته ځواب وایي، او هغه کارپوریټ DNS سرور چې دا پېژني د VPN شا ته دی. BIND کولی شي هغه یو زون درې بېلابېلو لارو upstream ته وسپاري، او هغوی بېلابېل ناکامېږي. شرطي لېږد تر ټولو کوچنی ژمنه ده، stub زون د delegation ډاټا ساتي، او secondary بشپړ کاپي ساتي. د دې پر بنسټ وټاکئ چې upstream څه اجازه ورکوي او تاسو غواړئ ستاسو resolver څه وساتي، نه د دې پر بنسټ چې کوم snippet مو لومړی وموند.
د یوې نوم فضا لپاره درې ترتیبات
| 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 اوس د هغه زون کاپي ساتي چې د هغه نه دی، نو د فایل لار، په لومړني کې د انتقال 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 پوښتنه ناکامه شي، stub زون نشي کولی کار وکړي، هر څنګه چې forward زون چلند وکړي.
ځواب وڅېړئ، نه ټنل
د دفتر resolver له لارې د هغه نوم پوښتنه وکړئ چې هېڅکله یې نه دی غوښتی، او د ځواب authority برخه وګورئ چې آیا له کارپوریټ زون څخه راغلی. په کېش کې ځواب د اوسنۍ لارې په اړه هېڅ نه ثابتوي، او upstream ته مستقیمه بریالۍ پوښتنه نه ثابتوي چې ستاسو resolver هغه زون ټاکلی. هغه پوښتنه د TCP له لارې تکرار کړئ ترڅو ډاډ ترلاسه کړئ چې لار د پرې کېدو مقاومت کوي.
کلاینتونه د دفتر resolver په لور وساتئ، او د DNSSEC تصدیقونه فعاله وساتئ. هغه براوزر چې د خپلواک کوډ شوي resolver سره تنظیم شوی وي دا ترتیب په بشپړه توګه پرېږدي، او د تصدیق بندول ترڅو ناڅاپي ځواب سم ښکاره شي، لیدل کېدونکې ناکامي په نه لیدل کېدونکې ناکامي بدلوي.
ولیکئ چې له درېیو څخه کوم ډول مو وټاکه او ولې. بله هغه څوک چې د زون ناکامي وویني، د ترتیب فایل په پرتله هغه جمله ته ډېره اړتیا لري.