ولې یو خصوصي Route 53 زون د عامه نومونو لپاره NXDOMAIN بیرته راګرځوي

خصوصي Route 53 زونونه د عامه ریکارډ سره د یوځای کیدو پرځای د نوم ځواب بدلوي، او همدا لامل دی چې خلک په تر ټولو بد وخت کې حیران شي۔ یو داخلي ریکارډ اضافه کړئ api.example.net لپاره په یوه خصوصي زون کې example.net، دا له یو VPC سره ونښلوئ، او د هغه مورني لاندې هر بل نوم اوس یوازې له خصوصي زون څخه ځواب ویل کیږي۔ هغه کلاینټ چې پرون یې کولی شو www.example.net ته ورسیږي، نن منفي ځواب ترلاسه کوي۔ لاندې تشریح له هماغه ناکامې پوښتنې پیل او د هغه زون په لور چې ځواب یې ورکړ بهر ځي۔

له پوښتنې پیل کړئ، نه له کنسول

تېروتنه په هغه کلاینټ کې بیا تولید کړئ چې راپور یې ورکړ، او دقیق نوم او د ریکارډ ډول ولیکئ۔ هغه نوم چې A لپاره ناکام کیږي، ممکن AAAA لپاره لا هم حل شي، او هغه براوزر چې کیش شوی نوم بیا هڅوي پټوي چې کوم یو خراب شوی۔ پوښتنه دوه ځله وچلوئ: یو ځل د هغه resolver له لارې چې کلاینټ واقعاً کاروي، او یو ځل د هغې تعقیب سره چې ترې تېریږي۔

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

دوهم امر مهم دی۔ د هغه د وضعیت کرښه او authority برخه هغه زون نوموي چې ځواب یې تولید کړ، نو تاسو کولی شئ له خصوصي زون څخه راغلی منفي ځواب د وخت تېریدو، بند پورټ یا هغه resolver څخه چې پوښتنه یې هیڅکله نه ده ترلاسه کړې بېل کړئ۔ resolvectl ښیي چې کوم پورته سرور وپوښتل شو، او ډیری وخت هغه resolver نه وي چې تاسو فکر کاوه VPN لیږلی دی۔

که تعقیب شوې پوښتنه عامه پته بیرته راوړي او عادي پوښتنه نه، نو عامه ریکارډ بشپړ دی او ځواب خصوصي منظره ورکوي۔ همدا یوه پرتله ټاکي چې د دې پاڼې پاتې برخې کومه نیمه ستاسو په اړه تطبیق کیږي۔

ولولئ کوم زون ځواب ورکړ

هغه ځواب چې NXDOMAIN لري او په authority برخه کې د خصوصي زون SOA لري، د هغه زون حتمي ځواب دی، نه ناکامه پلټنه۔ Route 53 Resolver خصوصي هوسټ شوی زون غوره کړ ځکه چې نوم سمون درلود، بیا یې د غوښتل شوي ډول هیڅ ریکارډ ونه موند، او مستند شوی چلند دا دی چې پوښتنه عامه DNS ته د لیږلو پرځای منفي ځواب بیرته راولي۔

ټاکنه د مشخصیت پیروي کوي۔ کله چې څو خصوصي نوم ځایونه یو بل ته ننوځي، تر ټولو مشخص سمون خوړونکی زون ګټي، او پراختر خصوصي مورني نوم د هغه نوم لپاره دوهمه موکه نه ترلاسه کوي چې ټاکل شوی ماشوم زون یې نه لري۔ د لیږلو قواعد یوه بله طبقه زیاتوي، ځکه چې د یو ځانګړي ډومین لپاره Resolver قاعده کولی شي د خصوصي هوسټ شوي زون تړاو ته ماتې ورکړي۔ د دې پایلې دمخه چې یو زون خالي دی، تړاوونه او قواعد ولیکئ۔

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

دواړه امرونه د هغه حساب اعتبارنامې غواړي چې زون یې لري، او دوهم ته د لومړي څخه د زون ID ته اړتیا ده۔ هغه په خپل ID بدل کړئ؛ پورته ځای نیوونکی په قصد اصلي نه دی۔

ولې خصوصي زون ګټي

تړاو هغه شی دی چې زون د یو VPC لپاره لیدونکی کوي، او په هغه VPC کې resolver هغه پلي کوي۔ هغه خصوصي زون چې له هغه VPC سره تړاو نه لري چې د کلاینټ ترافیک ترې راځي هیڅ اغیزه نه لري، پداسې حال کې چې له غلط VPC سره تړاو غلطې نفوس لپاره خصوصي ځواب تولیدوي۔ د ریکارډونو د سمون دمخه د تړاوونو لیست وګورئ، ځکه چې زون کیدای شي سم وي او بیا هم نه لیدل کیږي۔

یو بل ته ننوځي نوم ځایونه د ګډوډۍ دوهم سرچینه ده۔ example.net لپاره خصوصي زون او api.example.net لپاره خصوصي زون دواړه له یوې API پوښتنې سره سمون خوري، او ډیر مشخص ځواب ورکوي۔ دا ګټور دی کله چې تاسو تنګ داخلي نوم ځای غواړئ، او خطرناک دی کله چې په تنګ زون کې هغه ریکارډ نه وي چې په پراختر کې دی۔ د خصوصي هوسټ شویو زونونو په اړه ملاحظات د Route 53 په اسنادو کې د ښکته کیدو چلند او د قواعدو لومړیتوب دواړه بیانوي، او د دوهم یو بل ته ننوځي زون د زیاتولو دمخه یې لوستل ارزښت لري۔

له دې څخه هیڅ شی عامه زون نه بدلوي۔ عامه resolverونه لا هم عامه ریکارډونو ته سم ځواب ورکوي، او همدا لامل دی چې د VPC څخه بهر هر چا ته دا ناکامي د کلاینټ ستونزه ښکاري۔

د ریکارډونو د زیاتولو دمخه د نوم ځای غوره کړئ

که یوازې د داخلي خدمتونو یوې نوې کورنۍ خصوصي نومونه غواړي، هغې ته یو ځانګړی خصوصي فرعي ډومین ورکړئ او عامه مورنی پریږدئ۔ د داسې نوم په څیر internal.example.net نشي کولی www.example.net سیوری وغورځوي، او د ورک ریکارډ اغیزه یوازې هغو نومونو ته محدوده ده چې تاسو د دې هدف لپاره جوړ کړي وو۔ بیه یې دا ده چې شته URLونه او سندونه ممکن نوي نوم سره سمون ونه خوري۔

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

د کلاینټ نفوس د خصوصي منظرې په لور د لیږلو دمخه هغه نومونه ولیکئ چې یو اپلیکیشن واقعاً یې غواړي۔ د ننوتلو هوسټونه، د ثابتو توکو هوسټونه، د بیاځلي لیږلو هدفونه او د API پای نقطې لومړي مات شي، او معمولاً د څو ټیمونو په ریکارډونو کې خپاره وي۔

د resolver لاره، بیا د مسیر تعقیب کړئ

لیپ ټاپ خصوصي منظره یوازې هغه وخت ویني چې پوښتنې یې هغه resolver ته ورسیږي چې تړاو لري۔ په VPN سرور کې د hosts فایل سمول تړلو کلاینټونو ته هیڅ نه خپروي، او د عامه resolver سره تنظیم شوی کلاینټ به تر هغو چې ټونل پورته وي عامه ځوابونه ترلاسه کوي۔ هغه resolver پته تایید کړئ چې کلاینټ ترلاسه کړې، بیا پوښتنه له کلاینټ څخه تکرار کړئ نه له سرور څخه۔

کله چې نوم حل شي، بیرته راګرځیدلې پتې ته لاره د جلا ګام په توګه وازموئ، مثلاً ip route get سره د هغې پتې پر وړاندې چې پوښتنې بیرته راګرځولې ده۔ سم خصوصي ځواب پرته له پتې ته د لارې د مسیر ستونزه ده، او د ورک ریکارډ ځواب د DNS منظرې ستونزه ده؛ دواړه د یوې ستونزې په توګه ګڼل داسې سمونونه تولیدوي چې نه ټینګیږي۔ د خدمت TLS هوسټ نوم او سند څیړنې بدلې مه کوئ، ځکه چې خصوصي پته بدلوي چې اړیکه کره ځي، او د دې په اړه هیڅ نه چې کوم سند معتبر دی۔

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