د Split-DNS ثبت: ووایاست چې هر مشاهده چېرته اخیستل شوې
د resolver API، د کلاینټ فلټر او د بستې ثبت د یوې پلټنې مختلف پړاوونه ښیي۔ د دوی د متناقض بللو مخکې د مشاهدې نقطه ونوموئ۔
دوه کسان د یوې Split-DNS ستونزې څیړنه کوي او جلا resolver پتې ترلاسه کوي۔ یوې د پلټنې وسیله وکاروله، بلې په اډاپټر باندې بستې ثبت کړې، او دریمې د کلاینټ خپله تشخیص ولوست۔ له دوی څخه هیڅوک درواغ نه وایي، او هیڅوک د یوې پړاو بیان نه کوي۔ د مشاهدې نقطې نومول تناقض په نقشه بدلوي۔
یوه پلټنه، څو مشاهدې نقطې
د یوې داخلي نوم لپاره لږ تر لږه پنځه ځایونه دي چې وګورو: اپلیکیشن او هغه resolver API چې هغه یې بولي، په کلاینټ باندې اغیزمنه ډومین پالیسي، په اډاپټر یا فلټر باندې ثبت، کنټرول شوې ګیټوې پوله، او هغه resolver چې په رښتیا پوښتنه ترلاسه کوي۔
هر یو بل پوښتنې ته ځواب وایي، او هیڅ یو یوازې ثابتولی نشي چې پوښتنه چېرته لاړه۔
په اډاپټر باندې ثبت بستې ښیي، نه نیت۔ نه وایي چې کلاینټ کوم resolver غوره کړ، او تش ثبت کیدای شي د کیش شوي ځواب یا بل resolver API معنا ولري، نه د غورځول شوې بستې۔ هر مشاهده د یوې پړاو ثبوت وګڼئ۔ بیا پړاوونه په یوه لار کې یوځای کړئ۔
د کلاینټ فلټر د اپلیکیشن او تار ترمنځ دی
د Split-DNS سره VPN کلاینټ د بستې له ماشین وتلو مخکې ډومین سمون پلي کوي۔ په تونل شوي وروستاړي کې نومونه داخلي resolver ته ځي؛ نور هر څه محلي ته ځي۔ فلټر پالیسي ده، او پالیسي د پلیټفارم او کلاینټ نسخې له مخې توپیر کولی شي۔
د Cisco Secure Client Split-DNS لارښود ډومین سمون او د Windows فلټر پوښي، او هغه څه چې اپلیکیشن د اصلي resolver API په کارولو سره ویني د هغه څه څخه جلا کوي چې د nslookup په څیر وسیله ویني۔ همدا توپیرونه مهم دي۔
د اغیزمن پروفایل او د اپلیکیشن یوې عادي پلټنې څخه پیل وکړئ۔ هر هغه ازموینه چې ځانګړی سرور نوموي، په قصد شوې لاره اوړې؛ هغه د کلاینټ په خپله تشخیص سره تشریح کړئ، او مه پرېږدئ چې د منلو معیار شي۔
nslookup له اپلیکیشن څخه بله لار نیسي
nslookup خپله DNS پوښتنه جوړوي او کولای شي د عملیاتي سیستم resolver پالیسي له پامه وغورځوي۔ دا هغه د یوې ځانګړې پوښتنې د یو ځانګړي سرور څخه د پوښتلو لپاره ګټوره وسیله جوړوي، او د دې ازموینې لپاره چې اپلیکیشن به څه تجربه کوي، ګمراه کوونکې وسیله۔
په Windows کې د نوم حل پالیسي جدول فیصله کوي چې کوم وروستاړی کوم سرور کاروي۔ لوستل یې هغه پالیسي ښیي چې اپلیکیشن به تعقیبوي، او ډیری وخت همدا ورکې ټوټه ده۔
پالیسي ولولئ او بیا هماغه پوښتنه د عادي resolver له لارې وکړئ:
Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example
کوډ شوي resolver پوښتنه پټوي، نه اړیکه
هغه براوزر چې خپل DNS-over-HTTPS resolver لري، بشپړ بل قضیه ده۔ پوښتنه د TLS دننه وځي، نو د بستې ثبت resolver پتې ته اړیکه ښیي خو پوښتل شوی نوم نه ښیي۔
لومړی د براوزر مدیریت شوې پالیسي ومومئ، بیا یې د عملیاتي سیستم پلټنې سره پرتله کړئ۔ هغه براوزر چې خپل resolver غوره کولو اجازه لري، ممکن Split-DNS پالیسي هېڅکله ونه ویني۔
هماغه احتیاط د هر هغه کلاینټ لپاره صدق کوي چې خپل resolver راوړي۔ هغه ثبت چې لیرې اړیکه پیژني، د پوښتنې نوم ثبوت نه دی۔ که نوم ته اړتیا لرئ، هغه د resolver خپلو لاګونو یا د اپلیکیشن تشخیص څخه واخلئ، د پلي کیدونکو محرمیت قواعدو سره۔
د نښه شوې ازموینې سره پرتله کړئ
د ازموینې لپاره منل شوی داخلي نوم، او همدارنګه هغه عامه نوم چې حساس معنا نه لري غوره کړئ۔ د هر یو لپاره وخت، د ریکارډ ډول، ځواب او هغه پالیسي چې تمه یې لرله ولیکئ۔
چیرته چې اجازه وي، د resolver ترلاسه کول د کلاینټ یا ګیټوې د یوې تنګې مشاهدې سره پرتله کړئ:
nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List
هېڅکله شخصي نومونه یوازې د پرتلې جوړولو لپاره نامربوطه عامه resolver ته مه لیږئ، او هر هغه څه سم کړئ چې شریکوئ یې۔ په پای کې، سم DNS ځواب له هغه خدماتي اړیکې څخه جلا کړئ چې وروسته راځي: حل شوې شخصي پته لا هم لار او د اپلیکیشن اجازې ته اړتیا لري۔