دانلود با لینک مستقیم و پر سرعت .
لینک پرداخت و دانلود *پایین مطلب*
فرمت فایل: Word (قابل ویرایش و آماده پرینت)
تعداد صفحه :19
بخشی از متن مقاله
RFC 1034
به معرفی سیستم حوزه نام CDNS و مفاهیم آن می پردازد و از بعضی مطالب ذکر شده در RFC 1035 که مربوط به پیاده سازی است صرف نظر می کند.
مجموعة توابع و انواع داده ها در DNS ، تشکیل یک پروتکل رسمی و موثق می دهد. که شامل پرس وجوهای استاندارد، پاسخهای آنها و قالب کلاسهای اینترنت می باشد.
با این وجود، سیستم حوزه نام عملاً توسعه پذیر باقی گذاشته شده است. به طور مثال متناوباً پیشنهادهای جدیدی در مورد پیاده سازی، انواع داده، انواع پرس وجود کلاستها و توابع ارائه می شوند.
بنابراین تا زمانی که انتظار می رود پروتکل رسمی بدون تغییر بماند، هرگونه فعالیت آزمایشی باید در امتداد این پروتکل انجام شود.
همچنین خواننده باید آگاه باشد که مثالهای ذکر شده حتماً کامل و اجرایی نیستند و صرفاً جنبه آموزشی دارند.
توزیع این RFC هیچگونه محدودیتی ندارد.
معرفی
این RFC به معرفی قالب نامه های حوزه، استفاده از آنها در پست الکترونیکی و پروتکلها و سرورهای ارائه شده برای پیاده سازی سرویس حوزه نام می پردازد.
تاریخچه نامهای حوزه:
انگیزه توسعه سیستم حوزه نا، با گسترش اینترنت آغاز شد.
- در ابتدا پیدا کردن آدرس ماشین میزبان از طریق فایل hosts. txt انجام می شد و مسئولیت آن بر عهده NIC بود. این فایل به طریق FTP توسط همة میزبانها ارسال می شد. اما پهنای باند مصرف شده در شبکه برای ارسال این فایل با مجوز تعداد میزبانها متناسب است و حتی هنگامی که چند سطح مختلف از FTP استفاده می شود. این پهنای باند بسیار قابل ملاحظه است. با افزایش تعداد میزبانها، این روش عملاً کارایی خود را از دست می دهد.
-مسئله بعد تغییر در خصوصیات اینترنت بود. میزبانهای با زمان اشتراکی دوران Arpanet حال جای خود را به شبکه هایی از ایستگاههای کاری داده بودند. همچنین بسیاری از سازمانها را نام و آدرسهای خود استفاده می نمودند ولی مجبور بودند صبر کنند. NTC hasts.txt را به روز کند تا تغییراتشان اعمال گردد.
- از سوی دیگر کاربردهای اینترنت مرتباً پیچیده تر می شد و نیاز به یک سیستم نام چند منظوره بیش از پیش به چشم می خورد.
در نتیجة این مشکلات ایده های جدیدی دربارة قالب و مدیریت نامها مطرح شد که در اغلب آنها ساختار سلسله مراتبی پیشنهاد شده بود.
در این روش از کاراکتر « . » به عنوان جدا کننده بین سطوح مختلف استفاده می شود.
یک طراحی از این سیستم با استفاده از پایگاه دادة توزیع شده و منابع تعمیم یافته در RFC 882 شرح داده شده است.
واژه « domain» (حوزه) در خیلی متون به چشم می خورد که در اغلب موارد برای ارجاع به نامی که با علامت « .» قسمتهای آن از همه جدای گردند، استفاده می شود ولی ارتباطی به DNC ندارد.
اهداف طراحی DNS:
- هدف اولیه ایجاد یک روش نامگذاری یکسان برای ارجاع به منابع می باشد. برای اجتناب از بعضی مشکلات نامها باید شامل آدرسها، مسیرها، و یا اطلاعات مشابه دیگر باشند.
- حجم پایگاه داده و کثرت به روز رسانی آن باعث می شود که از سیستمهای توزیع شده استفاده شود. که برای کارایی بهتر می توان از کش کردن محلی نیز استفاده نمود.
جمع کردن کل پایگاه به طور متمرکز بسیار پرهزینه و مشکل می باشد و باید اجتناب گردد.
- هنگام سبک سنگین کردن بینا فرینه به دست آوردن داده ها سرعت به روز سانی و دقت کشی ها برتری با داده ها می باشد.
- هزینة پیاده سازی ما را مجبور می کند که یک سیستم چند منظوره ایجاد کنیم که برای بازیابی آدرسهای میزبانها، داده های صندوق های پستی و موارد دیگر قابل استفاده باشد.
- برای اینکه این سیسم برای شبکه های مختلف قابل استفاده باشد. باید قابلیت استفاده از یک سیستم نامگذاری برای پروتکلهای مختلف را فراهم کنیم. برای مثال آدرسهای میزبان در پروتکلهای مختلف، متفاوتند ولی همة آنها مفهوم آدرس را دارند. DNS همة داده ها را در کلاس بر چسب (tag) می زند و اجازه استفاده موازی از قالبهای مختلف را می دهد.
-از دیگر مطالبات ما استقلال تراکنشهای سرور نام از سیستم حامل آنها می باشد بعضی سیستمها ممکن است برای پرس وجو و پاسخ از دیتاگرام استفاده کنند ولی بعضی سیستمها استفادة انحصاری از مدارهای مجازی را در نظر داشته باشند.
- سیستم باید در محدودة وسیعی از قابلیتهای میزبان مفید باشد. هم کامپیوترهای شخصی و هم سیستمهای بسیار بزرگ باید بتوانند از سیستم ولو از راههای متفاوت استفاده نمایند.
- مفروضاتی راجع به استفاده از سیستم:
- سازمان بندی سیستم حوزه از بعضی فرخها راجع به احتیاجات و استفاده کاربران نشأت می گیرد و طوری طراحی شده است که از بعضی مشکلات پیچیده پایگاه داده ها اجتناب شود.
این مفروضات به شرح زیر است:
- حجم پایگا داده کلی به تعداد میزبانهایی که از سیستم استفاده می کنند بستگی دارد.
ولی در نهایت به تعداد کاربران آن میزبانها نیز وابستگی پیدا می کند مثلاً کاربران صندوق پستی و بقیه اطلاعات آن میزبان
- اکثر اطلاعات داخل سیستم به کندی تغییر می یابند ولی سیستم باید قادر باشد تا با تغییرات سریع نیز سرو کار داشته باشد.
- سرویس گیرنده های سرویس حوزه باید قادر باشند تا سرورهای نام مورد اعتماد خود را که ترجیح می دهند از آنها سرویس بگیرند شناسایی کنند و خدمات مورد نیاز خود را از این سرورها اخذ کنند.
- دسترسی به اطلاعات حیاتی از به روز رسانی فوری و یا گارانتی سازگاری است. به روز رسانی اجازة رد شدن اطلاعات از طریق کاربران به سیستم حوزه را می دهد.
هنگامی که به روز رسانی به دلیل نقص فنی دردسترس نیست، داده های فعلی به عنوان قدیمی شناخته می شوند وم تلاش مستمر در جهت به روز رسانی آن باید انجام گیرد.
مدل کلی به این صورت است که کپی ها با یک مدت زمان برای تازه سازی توزیع می شوند توزیع کننده این مدت زمان را تنظیم می کند و گیرنده توزیع مسئولیت تازه سازی را به عهده دارد. در شرایط خاصی می توان مدت زمان بسیار کمی را تنظیم کرد و یا از توزیع کپی ها جلوگیری به عمل آورد.
- در هر سیستم با پایگاه داده توزیع شده ، ممکن است یک سرویس دهنده نام و یک پرس وجو ارائه شود که فقط توسط یک سرور دیگر بتواند پاسخ داده شود.
دو رویکرد کلی در برخورد با این مسأله «بازگشتی» و تکرا شونده می باشند.
در روش اول (بازگشتی) سرور اول پرس وجو سرویس گیرنده را از طریق یک سرور دیگر تعقیب می کند. در روش «تکرار شونده» سرور، سرویس گیرنده را به یک سرور دیگر ارجاع می دهد و اجازه می دهد که سرویس گیرنده خود پرس وجو را دنبال کند.
متن کامل را می توانید بعد از پرداخت آنلاین ، آنی دانلود نمائید، چون فقط تکه هایی از متن به صورت نمونه در این صفحه درج شده است.
دانلود فایل
