د resolvectl له وتنې څخه د هرې اړیکې VPN DNS لارښوونه څنګه ولوستل شي
resolvectl status د هرې اړیکې لپاره سرورونه، ډومینونه او ډیفالټ لاره ښیي. هغه یوځای ولولئ، بیا نوم وپوښتئ او یاد کړئ کومه اړیکه ځواب ورکړ.
resolvectl status وچلوئ او د هرې اړیکې لپاره د بلاکونو یو دیوال ترلاسه کوئ، هر یو خپل سرورونه او خپله ډومین کرښه لري. هغه کرښه چې لارښوونه ټاکي د ډومینونو لیست دی، نه د نوم سرور پته، ځکه چې سیمهایز stub هر پوښتنه هغې اړیکې ته لیږدوي چې نوم غوښتنه کوي. د ځواب لوستلو دمخه هغه غوښتنې ولولئ، بیا نوم وپوښتئ او وګورئ کومې اړیکې جوړ کړ. له سمې اړیکې غلط ځواب له غلطې اړیکې سم ځواب څخه بېله ستونزه ده.
هر د اړیکې بلاک تاسو ته څه وایي
هر بلاک هغه سرورونه لیستوي چې حل کوونکی به د هغې انټرفیس لپاره کاروي، د ډومینونو لیست او دا چې اړیکه ډیفالټ لاره ده که نه. د ډومینونو لیست د غوښتنو یوه ټولګه ده، او حل کوونکی د ترټولو اوږد پایښت مطابقت کاروي: د host.corp.example پوښتنه هغه اړیکه غوښتنه کوي چې corp.example لري، مخکې له هغې چې یوازې ډیفالټ لاره لري. دوه اړیکې چې یو شان پایښت غوښتنه کوي پایله لومړیتوب او ترتیب ته پرېږدي، نو ځله تکرارونه لومړی پاملرنې وړ دي. د اوسني سرور کرښه ښیي چې له لیست شوو سرورونو کوم یو په هغه شیبه کې کارول کیږي.
د /etc/resolv.conf په 127.0.0.53 ډول stub پته یوازې وایي چې stub مخ ته دی. هغه د ځواب ورکوونکي پورتنۍ سرچینې نوم نه اخلي، نو یوازې پر resolv.conf ولاړه تشخیص بند پاتې کیږي.
د ډومین د درې ډوله ننوتونو سمه لوستنه
| ننوت | څه غوښتنه کوي | عامه تېروتنه |
|---|---|---|
| corp.example | د لارښوونې ډومین او د لټون پایښت: ترې لاندې نومونه دې اړیکې ته ځي، او تار بربنډو نومونو ته ورزیات شی | لرې شو ځکه چې لارښوونه هرومرو کار کوي ښکاري |
| ~corp.example | یوازې لار: ترې لاندې نومونه دې اړیکې ته ځي، خو پایښت نه ورزیات شی | د لارښوونې لپاره اړین ګڼل شوی |
| ~. | ډیفالټ لاره: هغه پوښتنې غوښتنه کوي چې بله هېڅ اړیکه نه پوښي | په ویشل شوي پروفایل کې فعال پاتې شو، نو عامه نومونه تونل تعقیبوي |
ټیلډ د لټون چلند بدلوي، لارښوونه نه. پرته له ټیلډ ننوت هم د لارښوونې ډومین دی او هم د لټون ډومین، نو ترې لاندې نومونه هغې اړیکې ته لیږل کیږي او یو-لیبل نومونو ته پایښت ورزیات شی. ټیلډ لرونکی ننوت هماغه پایښت لارښوونه کوي خو له لټون لیست څخه یې بېل ساتي. نو ځکه ټیلډ لرې کول بدلوي چې کوم بربنډ نومونه حل کیږي، او نو ځکه ټیلډ نه شتون د لټون ستونزه ده، د ویشل شوي DNS ناکامي نه.
د ډیفالټ لارې ننوت هغه هر څه غوښتنه کوي چې بله هېڅ اړیکه نه پوښي. بشپړ-تونل پروفایل معمولاً هغه غواړي او ویشل شوی پروفایل معمولاً نه، ځکه عامه نومونه بیا شخصي حل کوونکي ته ځي او هلته ناکام کیدای شي. جدول د پروفایل د نیت پر وړاندې ولولئ، نه دا چې بیرغونه د پروفایلونو ترمنځ کاپي کړئ. کله چې دوه اړیکې یو پایښت غوښتنه کوي، مخکې له دې چې بل څه سم کړئ د لومړیتوب پوښتنه حل کړئ.
نوم وپوښتئ او وګورئ کومې اړیکې ځواب ورکړ
query فرعي کمانډ پته، پروتوکول او هغه اړیکه یا ساحه چاپوي چې ځواب یې جوړ کړ. یو نوم چې شخصي پایښت یې غوښتنه کوي او یو عادي عامه نوم وآزمویئ، بیا راپور شوې سرچینې پرتله کړئ. که شخصي نوم له بېتارې اړیکې ځواب ورکړي، غوښتنه نه شته یا تونل بند دی؛ که په ویشل شوي پروفایل کې عامه نوم له تونل ځواب ورکړي، ډیفالټ لاره ډېره پراخه ده. دا دوه ناکامۍ په براوزر کې یو شان او په دې وتنه کې برعکس ښکاري.
resolvectl status
resolvectl query host.corp.exampleراپور شوي پروتوکول ته هم پام وکړئ، ځکه له کاش یا hosts فایل څخه ځواب کیدای شي پرته له دې چې کومه پورتنۍ سرچینه وپوښتل شي راشي. له کاش ځواب ثابتوي چې نوم یو وخت حل شوی و، نه دا چې اوسنی سیاست یې سمه لارښوونه کوي.
د نومونو لارښوونه له پاکټ لارښوونې جلا وساتئ
د حل کوونکي پریکړه لار نه جوړوي. ټاکل شوی سرور لا هم خپلې پتې ته لار ته اړتیا لري، او راستنېدلې پته لا هم شخصي شبکې ته لار ته اړتیا لري، نو سم DNS سیاست کیدای شي له هغې اړیکې سره یوځای وي چې هېڅکله نه خلاصیږي. کله چې نوم حل شي او اپلیکیشن ناکام شي، پرته له دې چې بیا DNS بدل کړئ پته او لاره وګورئ. نوم حل کول او رسیدنه دوه پوښتنې دي چې دوه بېل مالکان لري.
اپلیکیشنونه کولای شي د خپل امن DNS تنظیم یا ځای پرځای شوي حل کوونکي له لارې سیسټم حل کوونکی په بشپړه توګه واوړي. د resolvectl پایله د سیسټم لاره بیانوي، او هغه براوزر چې له پامه یې غورځوي به ستاسو له هر ازموینې سره مخالف وي. مخکې له دې چې نتیجه واخلئ چې سیاست مات دی هغه تنظیم وګورئ.
هغه پته چې نوم ورته حل شو د اړیکې ترڅنګ ولیکئ. سم نوم چې غلطې پتې ته اشاره کوي د ریکارډ ستونزه ده، نه د لارښوونې.
له اړیکې بدلیدو وروسته بیا وګورئ
بیا نښلیدل یا بېتار بدلول د اړیکې حالت بیا جوړوي، او شبکه مدیر کولای شي خپل ډومینونه او سرورونه پر هر هغه څه بیا نصب کړي چې لاسي تنظیم شوي. بیا هماغه دوه نومونه وپوښتئ او له ثبت شوې اساس کرښې سره پرتله کړئ. که لاسي سمون ورک شو، سمون باید د اړیکې پروفایل کې وي نه د shell کمانډ کې. مخکې او وروسته ثبتول هماغه څه دي چې دا ښکاره کوي.
یوازې هغه نومونه او د سرور زمینه شریک کړئ چې راپور ورته اړتیا لري، ځکه داخلي پایښتونه توپولوژي افشا کوي. د systemd-resolved د ډومین لارښوونې اسناد د ترټولو اوږد مطابقت قاعده او د ټیلډ چلند پوښي، او یو ځل لوستل پورتنیو جدول تېروتنو څخه ډېرې مخنیوی کوي: په systemd-resolved کې د پوښتنو لارښوونه.