له یوې پوښتنې څخه پته خپلې لارښوونې قاعدې ته کاپي کوئ، سایټ کار کوي، او یوه اونۍ وروسته نه کوي۔ په قاعده کې هېڅ نه دی بدل شوی۔ خدمت بل څنډې پتې ته تللی، مراجع بل کوربه نوم حل کړی، یا غونډه IPv6 ته اوښتې۔ ستاسو مخې ته پرېکړه دا ده چې نوم-بنسټه قاعده که روښانه حد د دې خدمت لپاره سمه وسیله ده، او درې شرطونه دا فیصله کوي۔ لاندې برخه نوم له پتې جلا کوي، ځکه چې یوازې یو یې ټینګ دی۔

ولې یوه پوښتنه بشپړ لیست نه ده

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

دوهمه تشه شته۔ یو ښکاره کوربه نوم په ندرت سره ټول اپلیکیشن پوښي، ځکه ننوتل، رسنۍ او API ترافیک ډېری وخت جلا نومونه کاروي۔ د پتې پټي کوربه نوم څخه جوړه قاعده کولای شي پاڼه پوښي او ویډیو له لاسه ورکړي، چې د لارښوونې تېروتنې نه بلکې جزوي ناکامي په توګه لوستل کېږي۔

درېیمه تشه د پتو کورنۍ ده۔ یوازې v4 لپاره قاعده د AAAA ثبت په اړه هېڅ نه وایي، چې مراجع یې غوره کولی شي۔

درې شرطونه چې ډومین قاعده یا حدود فیصله کوي

لومړی، ایا خدمت یو ټینګ مخکښو ټولګه خپروي چې تاسو یې درلودلای او مستند کولای شئ؟ که یې کوي، روښانه حدود صادقانه او ارزانه دي۔ که یې نه کوي، نو ډومین قاعده یوازینۍ لاره ده چې خدمت تعقیبولی شي۔

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

دې درېیو ته ځواب ووایئ او ټاکنه معمولاً روښانه ده۔ اټکل کول هغه قاعده جوړوي چې په ازموینه کې کار کوي او په تولید کې ناکامېږي۔

غونډه وآزموئ، نه پاڼه

پاڼه بار کړئ، بیا هغه مهمه کړنه ترسره کړئ: ننوځئ، غږول پیل کړئ، یو فایل پورته کړئ۔ هر یو یې کولای شي بل کوربه ته ورسیږي، او هغه چې ناکامېږي هغه دی چې ستاسو قاعده یې له لاسه ورکړی۔

هغه څه ولیکئ چې غونډه واقعاً ورسره اړیکه کوي، نه هغه څه چې پاڼه ښیي:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

د پرتله کولو پر مهال حل کوونکی ښکاره وساتئ، ځکه هغه قاعده چې له یو حل کوونکي کار کوي او له بل ناکامېږي تاسو ته د CDN د ځواب په اړه وایي، نه د تونل۔ لنډ TTL هم مانا دا ده چې هغه ځواب چې تاسو ثبت کړی پای نیټه لري۔

هره طریقه واقعاً څه پوښي

دواړه طریقې د تنظیماتو په پاڼه کې د بدلېدو وړ ښکاري او له داخله بېلابېلې چلند کوي۔

MechanismWhat it matchesHow it fails
Domain ruleNames the client resolves, then their addressesMisses subdomains, or goes stale when refresh is off
Address routeA prefix you wrote downKeeps matching an address the service has left

د کرنل پتې لار مخکښونه سره سمون خوري۔ هغه نه پوهېږي چې کوربه نوم څه دی، نو هغه خدمت تعقیبولای نه شي چې پتې بدلوي۔ ډومین قاعده نومونه حل کوي او پایله لارښوونه کوي؛ دا خدمت تعقیبوي خو د حل کوونکي، تازه کولو چلند او مراجع لخوا د فرعي ډومینونو اداره کولو پورې تړلې ده، نو هغه قاعده چې نومونه تعقیبوي باید د هغه حل کوونکي سره وآزمایل شي چې مراجع یې واقعاً کاروي۔

هیڅ یو د بل سوپرسیټ نه دی، ځکه د دوی ګډول پرته له یادښت وروسته ګډوډي جوړوي۔

د خدمت له بدلون وروسته بیا وګورئ

د مراجع تازه کولو یا خدمت بدلون وروسته هماغه غونډې ازموینه بیا وچلوئ۔ هغه پتو لیست چې مخکې کار کاوه د هغې مودې شاهد دی، د خدمت زیربناوو تلپاتې لیست نه۔

ولیکئ چې کومه طریقه کوم کوربه نوم پوښي، او د وروستي کتنې نیټه۔

همدا یادښت د هغې قاعدې ترمنځ توپیر دی چې تاسو یې دفاع کولای شئ او هغې قاعدې چې هیڅوک یې لاس وړلو ته نه جرات کوي۔ که خدمت خپل مخکښ لیست خپروي، هغه وکاروئ او نیټه ذکر کړئ۔ که نه، هماغه ووایئ، او ډومین قاعده د هغې د تازه کولو چلند سره څنګ ته لیکلې وساتئ۔

اړوندې مقالې