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