له VPN له لارې NXDOMAIN د ټانل د قطعېدو معنی نه لري

د یوې ناکامې پوښتنې لوستل د دې ثبوت چې ټانل ونړېد، هڅوونکې ده، په ځانګړې توګه کله چې نوم لس دقیقې مخکې کار کاوه۔ ځواب بل څه وایي۔ NXDOMAIN یو بشپړ شوی DNS راکړه ورکړه ده چې پکې حل کوونکي اعلان وکړ چې پوښتل شوی نوم شتون نه لري; خراب ټانل معمولاً غلطۍ، د وخت پای یا د غلط سرور په وړاندې د حل هڅه رامنځته کوي۔ د wireshark پرته د استدلال بڼه یوه پوښتنه، یو ځواب ورکوونکی او یو ځواب کوډ دی، او هر کانفیګوریشن بدلون دمخه دا درېګړې ثبتول ارزښت لري۔

ځواب په رښتیا څه ثابتوي

DNS هغه پایلې جلا کوي چې کلینټان یې اکثراً په یوې ناکامۍ کې یوځای کوي۔ هغه نوم چې شتون نه لري د NXDOMAIN کوډ سره منفي ځواب ورکوي، په داسې حال کې چې شتون لرونکی نوم چې د غوښتل شوي ډول ریکارډ نلري، د خالي ځواب برخې سره بریالی ځواب ورکوي۔ دواړه اپلیکیشن ته بې ګټې ښکاري، او یوازې یو یې د دې معنی لري چې نوم غلط دی۔

دا توپیر فیصله کوي چې ترمیم چېرته اړه لري۔ په هغه هوسټ کې چې A ریکارډ لري، د AAAA ریکارډ نشتوالی د هوسټ نشتوالی نه دی، او د هغې پسې د سند بیا صادرول یا د ټانل بیا جوړول یوازینی شته نښه ضایع کوي۔ دا توپیر د راتلونکي ګام بڼه هم ټاکي: د نوم اېښودنې ستونزه په زون کې سمېږي، او د ډول ستونزه د سم ریکارډ په غوښتنې یا د دې په منلو چې د پتې کورنۍ یوازې نشته، سمېږي۔

افسانه: د شخصي نوم نشتوالی د ټانل ناکامي ده

دا افسانه ژوندۍ پاتې ده ځکه چې دا دوه پېښې ډېری یوځای رارسي۔ کلینټ VPN ته نښلوي، عملیاتي سیسټم هغه حل کوونکی ساتي چې دمخه یې باور درلود، او هغه داخلي نوم چې اوس ورته اړتیا لري له هغه سرور څخه پوښتل کیږي چې کله یې هم د شخصي زون په اړه نه دی اورېدلی۔ هغه سرور په رښتینې او منفي توګه ځواب ورکوي۔ ټانل پاکټ وړي; ځواب یوازې د هغه نوم ځای په اړه دی چې ځواب ورکوونکی یې خدمت نه کوي۔

split-horizon تنظیمات دا عادي کوي: ورته زون نوم په عامه او داخلي ډول د بېلو منځپانګو سره شتون لري، او شخصي ریکارډونه یوازې داخلي حل کوونکی پېژني۔ له همدې امله د باوري ښکاري منفي ځواب ترلاسه کول د دې ثبوت دی چې کوم حل کوونکي ځواب ورکړ، نه د انټرفیس د حالت ثبوت۔

دوه کانفیګوریشن توضیحات پایله ټاکي۔ ټانل باید داخلي حل کوونکی وټېله یا یې غوره کړي, او کلینټ باید هغه غوره توب په پوښتل شوي نوم باندې تطبیق کړي۔ هره ډومین لپاره هغه قاعده چې ستاسو د ټایپ شوي ریکارډ څخه لږ توپیر لرونکی پسنډ نوموي، پوښتنه عامه لارې ته لېږي، او ځواب به سم او بې ګټې وي۔

له سم نوم سره له سم حل کوونکي وپوښتئ

د پرېکړې ثبتولو دمخه ځواب ورکوونکی ثبت کړئ۔ هغه پوښتنه چې نه ښیي کوم سرور ځواب ورکړ، د پالیسۍ ستونزه له نوم ځای ستونزې نه شي جلا کولی، او دواړو ترمیمونه نااړوند دي۔

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

لومړنۍ دوه کرښې ښیي چې ځایي حل کوونکي څه پرېکړه وکړه او له چا به وپوښتي۔ +search پوښتنه هغه څه بیا تولیدوي چې اپلیکیشن یې کوي کله چې د لټون پسنډ ورزیاتوي، کوم چې اکثراً ریښتینې پوښتنه ده نه هغه چې په تشخیصي وسیله کې ټایپ شوې۔ وروستې کرښه له داخلي سرور څخه مستقیم پوښتي، د کلینټ پالیسۍ څخه تېرېږي; که هغه بریالی شي او ساده پوښتنه ناکامه شي، زون سم دی او د پوښتنو لارښوونه نه۔

منفي کیشینګ د ترمیم وروسته ځنډ تشریح کوي

منفي ځوابونه د ډیزاین له مخې کیش کیږي، او RFC 2308 تشریح کوي چې د منفي کیش عمر د زون د واک ریکارډ څخه څنګه اخیستل کیږي۔ نو د ریکارډ یا حل کوونکي قاعدې سمول په کلینټ کې سمدستي بدلون تضمین نه کوي، او هغه پوښتنه بیا هڅول چې کیش شوی ځواب بیرته راوړي نوی څه ثابتوي نه۔ یوازې بل ځواب ورکوونکی، بل نوم یا خالي شوی کیش تازه ثبوت ورکوي۔

ځایي کیش خالي کړئ، بیا هماغه پوښتنه هماغه ځواب ورکوونکي ته تکرار کړئ۔ په هغو سیسټمونو کې چې د ځایي حل کوونکي خدمت کاروي دا یو حکم دی; په نورو کې دا د خدمت بیا پیل یا د پلیټفورم وسیله ده، او ځانګړې وسیله له دې څخه کم مهمه ده چې وروسته ورته ازموینه تکرار شي۔

نوم له لارې جلا کړئ

کله چې نوم اټکل شوي شخصي پتې ته حل شي، DNS د موضوع په توګه پای ته رسېږي او راتلونکې پوښتنه د اپلیکیشن لار کیږي۔ هغه هوسټ چې پوښتنو ته ځواب ورکوي خو اړیکه ردوي بېله ستونزه لري، او له سم ځواب وروسته هم حل کوونکي تنظیمول هغه لار ده چې یوه پېښه درې نااړوند بدلونونه ترلاسه کوي۔ د دواړو د برابرېدو د انګېرنې دمخه حل شوې پته له هغې پتې سره پرتله کړئ چې خدمت په رښتیا ورباندې اوري۔

ریکارډ وساتئ: پوښتنه، ځواب ورکوونکی، کوډ او حل شوې پته۔ همدا ریکارډ وروسته راپور د تایید وړ کوي، او همدا د تشخیص او د ورو ټانل په اړه د کیسې ترمنځ توپیر دی۔