د VPN DNS غلط؟ ممکن یو باوري سرور زوړ وي

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

نښه د حل کوونکي سره بدلیږي

یو تکراري حل کوونکی هغه څه بېرته ورکوي چې یوې مرجع ورته ویلي، بیا هغه ځواب د TTL لپاره ساتي۔ که تونل بل حل کوونکی لاسوند کړي، یا لاره داسې بدله کړي چې زوړ نور نه شي رسېدلی، پیرودونکی بله مرجع پوښتي او بل ځواب ترلاسه کوي۔ په هغه شېبه ډومین نه بدل شو؛ ستاسو لید ورته بدل شو۔

نو ځکه یو نوم کولای شي په یو دفتر کې کار وکړي او له هوټله ناکام شي، او نو ځکه د سیمه ییز کیش پاکول یوازې کله ناکله مرسته کوي۔ د کیش پاکول پوښتنه بیا همدې مرجع ته لیږي۔

توپیر کوونکې ازموینه هر خپور شوي سرور ته مستقیمه پوښتنه ده۔

هرې مرجع ته مستقیم وپوښتئ

له یادې لړلیکې نه، له تفویض څخه پیل وکړئ۔ له مورني سرور څخه NS ټولګه وپوښتئ، بیا د هغې ټولګې هر نوم له هغه ریکارډ وپوښتئ چې تاسو ته اړین دی۔ د یو نوم په اړه په بېلو مرجعو کې دوه پوښتنې سمدلاسه وایي چې زون همغږی دی که نه۔

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

د زون د سر NS ریکارډونو لپاره هم همداسې وکړئ، ځکه چې له لېږد وروسته د مور تفویض او د زون خپله NS ټولګه کېدای شي سره ونه ځي۔ په SOA کې ترتیبي شمېرې بله پرتلنه ده، او ډېر شاته پاتې دوهم سرور د لېږد ستونزه ده، نه د ځواب۔

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

نظرې شوې لیدونه له ماتو لیدونو جلا کړئ

ځینې ډومینونه په قصد سره د سیمې یا د حل کوونکو ډلې له مخې بېل ځواب ورکوي، او د وېشل شوي افق ترتیبات په سوداګریزو شبکو کې نورمال دي۔

پوښتنه دا ده چې ایا توپیر مستند او ثابت دی۔ ناارادي لید بېل ښکاري: یوې مرجع کې هغه ریکارډ دی چې نورو هېڅکله نه دی ترلاسه کړی، یا هغه نلري چې ټول یې شریکوي۔ د RFC 2182 د غوراوي او ځای پرځای کولو لارښود باوري شتون د ګډ مسؤلیت په توګه ګڼي، او دلته همدا سم چوکاټ دی۔ زیاتوالی یوازې هغه وخت شته چې هر خپور شوی سرور د نظرې شوو معلوماتو ځواب ورکولای شي، نه یوازې د 53 پورټ پر سر اړیکه منل۔

هغه سرور چې SERVFAIL ځواب ورکوي، د هغه په پرتله چې په ډاډه توګه او غلط ځواب ورکوي، تشخیص یې اسانه دی۔

لېږد هغه څه افشا کوي چې کیش یې پټ کړي وو

د وړاندې کوونکي د بدلون پر مهال دوه باوري ځایونه بدلیږي: د مور تفویض او د زون خپل NS ریکارډونه۔ دواړه باید تازه شي، او دواړه د خپلو TTL لپاره کیش کیږي۔ که زوړ سرور روښانه پاتې شي او پخوانی زون وړاندې کول جاري وساتي، هغه پیرودونکي چې د هغوی حل کوونکي ترې پوښتي به لا هم زوړ ځواب ترلاسه کوي ډېر وروسته له دې چې بدلون بشپړ ښکاره شو۔

دا سم هغه حالت دی چې اوږدمهاله کیش یې پټوي۔ هغه کاري سټیشن چې ټوله اونۍ یې کار کاوه له یو حل کوونکي سره خبرې کولې چې د نوي مرجع تازه ځواب یې درلود، پداسې حال کې چې زوړ لا هم نورو ټولو ته زاړه معلومات ویشل۔

په لپ ټاپ کې د حل کوونکي بدلول یوازې هغه لپ ټاپ سمولای شي، نه بل څه۔

زون سم کړئ، نه حل کوونکی

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

بیا له دواړو شبکو مستقیمې پوښتنې بیا ترسره کړئ او تر هغه انتظار وکړئ چې ستاسو بدل شوي ریکارډ TTL پای ته ورسیږي۔

ډاډ ترلاسه کړئ چې ځواب له هرې مرجع ثابت دی، او نظرې شوې لید د زون مستنداتو کې ولیکئ ترڅو راتلونکی توپیر په اسانه طبقه بندي شي۔