درک مفاهیم طراحی Zone ها و سرورها در DNS

همانطور که می دانید قبل از هر طراحی باید کلیه احتمالات و بررسی ها برای داشتن یک طراحی خوب در نظر گرفته شود تا طراحی شما یک طراحی برنامه ریزی شده باشد.این امر در تمامی رشته ها و زمینه ها صادق است و شبکه های کامپیوتری نیز از این امر مستثنی نیست.برای پیاده سازی هر سرور و داشتن هر سرویسی لازم است در ابتدا نیازمندی ها بررسی شود،بستری که قرار است آن سرور بر روی آن ایجاد شود در نظر گرفته شود و کلیه عواملی که هر یک به دلیلی ممکن است خللی در کار سرور ایجاد کند نیز عنوان و برای آنها راهکارهایی مطرح گردد. درمقاله نگاهی بر ویژگیهای DNS در ویندوز سرور 2008، نگاهی مختصر بر ویژگیهای DNS در ویندوز سرور 2008 داشتم و در این مقاله مواردی را که برای طراحی DNS Server و DNS Zone باید در نظر گرفت ، مورد بررسی قرار می گیرد.

طراحی DNS سرورها
با توجه به اینکه اکثر دوستان عزیز که در سازمان های دولتی و خصوصی در ایران و بر طبق عادت همیشگی ، ابتدا ساختارها را پیاده سازی می کنند و سپس به فکر رفع اشکال آن می افتند در این قسمت برای تشریح شیوه طراحی ساختار DNS قبل از اجرا در محیط عملیاتی چندین پیشنهاد را مطرج می کنیم . در مراحل ابتدایی طراحی ساختار DNS سرور در یک سازمان مواردی است که می بایست قبل از انجام هر کاری به آنها فکر شود . همیشه قبل از پیاده سازی سرور میزان فضایی که برای DNS Server در نظر گرفته اید و سخت افزاری که نیاز کاری شما را بر طرف می کند را پیش بینی کنید .توجه کنید که شما به چه تعداد DNS Server در شبکه نیاز دارید و یا بهتر بگوییم پیشبینی شما استفاده از چه تعداد DNS سرور برای برطرف کردن نیاز به این سرویس می باشد . بعد از اینکه تعداد DNS Server های مورد نیازتان را مشخص کردید ،سپس باید تصمیم بگیرید که بر روی کدام سرورها Host Primary و کپی Secondary Zone ها باید قرار بگیرند و اگر از Active Directory Domain Services یا AD DS استفاده می کنید،در نظر بگیرید که کامپیوتر سرور همان دومین کنترلر خواهد بود یا یکی از اعضای سرور در دومین می باشد.با در نظر گرفتن بار ترافیکی یا traffic loads و عمل replication و قابلیت fault tolerance ، بایدمشخص کنیدکه DNS Server شما در کجای شبکه باید قرار بگیرد و حتما محل قرارگیری آن را از قبل پیشبینی کنید.

سیستم عاملی که می خواهید در DNS Server ها استفاده کنید را مشخص کنید. اینکه می خواهید در همه ی DNS Server شما ویندوز سرور 2008 اجرا شود یا از ترکیبی از سیستم عاملها در اجرای DNS Server ها استفاده خواهید کرد.جهت طراحی و توسعه دادن DNS Server درشبکه تان باید جنبه های مختلفی را در نظر بگیرید و نیازمندیهای لازم ظرفیت و حجم برای هر DNS Server را مورد توجه قرار دهید.خوب زمانی که می خواهید مشخص کنید که برای DNS Server ی که میخواهید طراحی کنید چه مقدار فضا لازم دارید،باید سوالهای زیر را از خود پرسیده و به آنها پاسخ دهید:

    در DNS Server ی که می خواهید طراحی کنید،چه تعداد Zone باید نگهداری یا بارگذاری شود؟
    برای هر Zoneی که DNS Server بارگذاری یا load میکند،حجم آن Zone به چه اندازه است ؟ ( این حجم معمولا براساس سایز فایلهای Zone و تعداد رکوردهایی که در Zone قرار دارند مشخص می شود )
    برای Multihomed DNS Server ، چه تعداد interface جهت گوش دادن به درخواستهای کلاینتها و پاسخ دادن به این درخواستها در هر Subnet ای که سرور DNS وجود دارد،باید داشته باشید؟ ( Multihomed DNS Server :معمولا به صورت پیش فرض کلاینتها می توانند درخواستهای خود را به هر DNS Server ی که می خواهند بفرستند،اما در برخی از شبکه ها این پیشفرض اجرا نشده است.در این شبکه ها تنها چند IP آدرس برای سرورهای DNS در نظر گرفته می شود و کلیه درخواستها به IP آدرسهایی فرستاده می شود که درتب Interface ،در Server Properties تعریف شده است.درواقع Multihomed DNS Server این امکان را به شما می دهد که شما کلیه درخواستها را به IP های مربوط به DNS Sever هایی بفرستید که می خواهید آن سرورها در شبکه شما فعال باشند )
    به صورت کلی از DNS Server انتظار می رود که چه تعداد query دریافت کند و به چه تعداد کلاینت باید سرویس بدهد؟


یکی از مورادی که در DNS Server ها نقش به سزایی را دارند میزان حافظه و RAM ی است که سرور دارد. در بیشتر موراد افزودن RAM به DNS Server می تواند پیشرفت قابل ملاحظه ای در کارایی سرور داشته باشد. این امر به این دلیل است که DNS Server کلیه ساختار Zone خود را ،هنگام Startup در حافظه خود بارگذاری خواهد کرد. از اینرو است که حافظه یا مموری در DNS Server ها از اهمیت به سزایی برخوردار است .اگر سرور شما تعداد زیادی Zone و Dynamic Update های کلاینتهای Zone را بارگذاری می کند،Additional Memory یا حافظه های اضافی در بهبود عملکرد آن بسیار موثر خواهند بود.توجه داشته باشید که برای استفاده های معمولی ، حافظه ی DNS Server باید دارای حداقل های زیر باشد:

    تقریبا 4MB ، RAM جهت شروع به کار DNS سرور ،بدون بارگذاری کردن هیچ Zoneی لازم است.
    به ازای اضافه شدن هر Zone یا رکوردها به سرور،DNS Server حافظه های اضافی مصرف خواهند کرد.
    تخمین زده شده است که به ازای افزودن هر رکورد به یک Server Zone ،به طور میانگین تقریبا 100 بایت از حافظه سرور استفاده می شود. (به عنوان مثال،اگر یک Zone شامل 1000رکوردی باشد که به یک سرور افزوده شده است،تقریبا 100 کیلوبایت از حافظه سرور را به خود اختصاص می دهد.)


تعیین محل قرار گیری DNS سرور در شبکه
خوب حال به این قسمت از طراحی خود می رسیم که در کدام قسمت از شبکه DNS Server باید قرار بگیرد؟ در بیشتر مواقع DNS Server بر روی همه دومین کنترلر ها نصب خواهد شد.اگر به هر دلیلی نمی خواهید DNS Server را بر روی همه دومین کنترلرها قرار دهید،درادامه این مقاله همراه باشید. به صورت کلی، DNS Server باید درقسمتی از شبکه قرار بگیرد که به صورت مرکزی برای کلیه کلاینتها در دسترس باشد.همچنین متعارف است که در هر Subnet از یک DNS Server استفاده شود.زمانی که می خواهید محل مناسب برای DNS Serverتان را انتخاب کنید،باید موراد زیر را در نظر بگیرید:

    آیا می خواهید DNS سرورتان، AD DS را نیز پشتیبانی کند ؟
    آیا DNS Server تان نیز یک Domain Controller است یا در آینده یک Domain Controller خواهد شد یا خیر؟
    اگر DNS Server اصلی تان از کار بیافتد،آیا DNS Server دیگری وجود دارد که به Client هایتان سرویس دهد؟
    اگر DNS Server در Subnet ی قرار گرفته است که از بعضی از Client هایش دور می باشد،DNS Server دیگری وجود دارد تا در صورت از کار افتادن روتر ، به Client ها پاسخگو باشد؟


همانطور که از سوالها مشخص است ،در هنگام طراحی و پیاده سازی DNS Server باید کلیه احتمالات ممکن را در نظر بگیرید وتدابیر لازم را انجام دهید تا در صورت از کار افتادن یک DNS Server یا عوامل درگیر با سرویس دادن DNS Server ،شبکه با مشکل مواجه نشود .مثلا ممکن است شما شبکه ای داشته باشید با چندین Subnet که با لینکهای ارتباطی به همدیگر متصل شده اند،به علاوه ممکن است که برای کلیه ی این Subnet ها یک DNS Server وجود داشته باشد.خوب در این شرایط اگر یکی از Subnet ها دارای کلاینت زیادی باشد که هر کدام از آن کلاینتها درخواستهای زیادی از DNS Server دارند،بهترین کار این است در آن Subnet نیز یک DNS Server دیگر راه اندازی کنید . از اینرو در صورت Fail-over شدن روتر یا DNS Server شبکه شما دچار مشکل نمی شود و مسئله مربوط به back up نیز در نظر گرفته شده است.

زمانی که در شبکه ای می خواهید تعداد DNS Server هایی که باید در آن شبکه وجود داشته باشند را مشخص کنید،باید بار ترافیکی حاصل از Zone Transfer و Query ها را نیز در نظر بگیرید.اینکه در آن شبکه DNS و کلیه های رکوردهای آن به صورت Active Directory Integrated است و یا کلیه اطلاعات و رکوردها در خود Zone نگهداری می شوند نیز باید مشخص شود. با وجود اینکه در بیشتر موارد از Incremental Zone Transfer استفاده می شود و آخرین اسامی استفاده شده در سرور cache می شود،بازهم Zone Transfer مسئله ای است که در نظر نگرفتن آن باعث دردسر در شبکه خواهد شد. از اینرو این مسائل باید قبل از طراحی در نظر گرفته شوند تا احتمالات مربوط به حجم ترافیکی که قرار است منتقل شود و سرعت لینک ارتباطی بین Zone ها نیز در طراحی در نظر گرفته شود.

یکی دیگر از مواردی که ممکن است ایجاد ترافیک کند و باید در طراحی ها در نظر گرفته شود DHCP است.با توجه به وظیفه DHCP که اختصاص دادن IP به Client ها می باشد،این IP ها تا مدت زمان خاصی میتوانند در اختیار کلاینتها قرار گیرند و DHCP باید مرتب این Lease Time ها ( یا مدت زمانی که IP به کلاینت اختصاص دارد ) را بررسی کند تا در صورت اتمام این زمان آن را تمدید کند یا IP را پس بگیرد.از اینرو گرفتن Update ها و این رفت و برگشتها خود باعث ایجاد ترافیکی در شبکه میشود که آن نیز باید در نظر گرفته شود.

یکی از دلایل طراحی DNS کاهش ترافیک حاصل از Broadcast بین Local Subnet ها است.این Broadcast باعث ایجاد ترافیکی بین کلاینتها و سرورها میشود به خصوص زمانی که DNS Server در یک LAN یا WAN که دارای یک روتینگ پیچیده است،قرار داشته باشد. خوب حال تصور کنید که کلیه مواردی که در پاراگراف قبلی عنوان کردیم نیز در یک WAN یا LAN ی که از یک لینک ارتباطی ضعیف استفاده میکند نیز وجود داشته باشد ( Zone Transfer ، DHCP Update و .. ) یکی از راههای مقابله با این مشکل این است که DNS Server ی در هر منطقه ی دورافتاده قرار دهیم که تنها قابلیت Caching را داشته باشد.

این نکته را در نظر داشته باشید که در هر DNS Zone باید حداقل دو کامپیوتر سرور وجود داشته باشند تا قابلیت Fault tolerance را داشته باشید.با این قابلیت با از کار افتادن یکی از سرورها دیگری جایگزین آن خواهد شد و بدون هیچ مشکلی چرخه DNS ادامه پیدا می کند.در هر مرحله بعد از مشخص شدن تعداد DNS Server هایی که می خواهید داشته باشید، سطوح مربوط به Fault Tolerance را نیز در نظر بگیرید. توجه داشته باشید که :

    زمانی که شما می خواهید از یک DNS Server در یک LAN کوچک که تنها دارای یک Subnet است استفاده کنید،می توانید آن سرور واحد را طوری کانفیگ کنید که Primary و Secondary سرور را برای هر Zone شبیه سازی کند.
    برای سادگی و مدیریت بهتر DNS Server ها،برای همه سرورهایتان از یک سیستم عامل استفاده کنید.
    پیشنهاد می شود که از DNS Console Tool برای مدیریت فایلهای Zone ی که توسط سرویس DNS ایجاد میشود نیز استفاده شود.گزینه ی دیگری استفاده از هر Application ی است که قابلیت ذخیره سازی فایلها در قالب text را داشته باشد ،است.از یک روش واحد برای به روز رسانی Zone ها به صورت مداوم استفاده کنید، این باعث میشود که Zone Edit ها به روی همدیگر Override نکنند.


طراحی Zone های DNS
یکی از فاکتورهای مهمی که در طراحی zone ها باید در نظر گرفت،ترافیک بین لینکهای ارتباطی بین zone ها و عوامل تاثیرگذار براین ترافیکها میباشد،است خصوصا زمانی که شما برای اولین بار Namespace خود را درون یک zone پارتیشن بندی میکنید.اگرچه Domain Name System ( DNS ) طراحی شده است تا ترافیک حاصل از Broadcast بین local subnet ها کاهش پیدا کند اما باز هم ترافیکی بین سرورها و کلاینتها ایجاد میشود.این مساله زمانی که DNS در شبکه های مسیریابی شده (Routed Network )، استفاده میشود نسبتا صحیح است.برای در نظر گرفتن و بررسی ترافیک DNS ، شما باید مرتبا وضعیت سرور را بررسی کنید و یا از DNS performance counters هایی که system monitor ارائه میدهد ،استفاده کنید. برای بررسی ترافیک حاصل از روتینگ،تاثیر عوامل زیر را در نظر بگیرید،خصوصا زمانی که از یک لینک کم سرعت در یک شبکه WAN استفاده میکنید،این موارد ترافیکهای حاصل از انواع ارتباطات مربوط به DNS را بیان می کند:

    ترافیک Server-to-Server که به دلیل عملیات مربوط به Zone transfer و DNS interoperability با دیگر سرورها ایجاد میشود ( به عنوان مثال زمانی که سرویس WINS فعال است )
    ترافیک Client-to-Server که به دلیل query های صورت گرفته و آپدیتهای درخواست شده توسط DNS کامپیوترهای کلاینتها یا DHCP سرورها که در خواست Dynamic Updates برای ورژنهای قدیمیتر DNS کلاینتهایی که Dynamic Updates را پشتیبانی نمی کنند.


زمانی که شما از یک ساختار Namespace کوچک و فلت استفاده میکنید،ممکن است که در شبکه تان replication بین همه ی zoneها و همه ی سرورهارا به صورت کامل انجام دهید ( نه Incremental )، اما در Namespaceهای بزرگ و سلسله مراتبی این مدل Replication اصلا پیشنهاد نمیشود.در شبکه های بزرگ جهت برنامه ریزی برای zoneها شما نیاز به مطالعه،تست،تجزیه و تحلیل و درنهایت بازبینی و اصلاح طراحی ها براساس مشاهدات و تخمین های ترافیکی صورت گرفته دارید.بعد از انجام مراحل ذکر شده شما میتوانید DNS Zoneها را براساس نیازمندی ها و در راستای ایجاد یک Name service با کارایی بالا و دارای قابلیت Fault-Tolerance برای هر سایت خود اقدام نمایید.

سرویس DNS Server ،انجام عملیات Zone transfer بین سرورها را به صورت Incremental نیز پشتیبانی میکند.این باعث کاهش ترافیکهای ناشی از Replication بین DNS میشود و شما این مورد را باید حتما در طراحی های خود در نظر بگیرید.از دیگر مواردی که میتوانید در طراحی DNS Name service در نظر بگیرید Caching-only serverها میباشند.این سرورها دارای DNS Zone نمی باشند اما آپشن خوبی هستند برای Siteهای کوچکی که استفاده کمی از DNS دارند اما درون یک WAN عمل انتقال Zone های بزرگ در لینکهایی که سرعت بالایی ندارند را انجام میدهند.

خوب در این مقاله بررسی های مرتبط با بستری که سرور قرار است بر روی آن قرار گیرد ،صورت پذیرفت،لازم به ذکر است که در حالت کلی برای طراحی یک سرور مهم مثل DNS Server ،موراد بسیار مهم دیگری نیز وجود دارند که باید در نظر گرفته شوند.به عنوان مثال از جمله این موراد تمهیدات امنیتی سرور مهمی چون DNS سرور است

تشریح مفاهیم Aging و Scavenging در DNS

سرویس DNS سرور شرکت مایکروسافت دارای ویژگی به نام aging and scavenging می باشد که در لغت Aging به معنای سالخوردگی و Scavenging به معنای تمیزکاری می باشد . این ویژگی مکانیزمی برای تمیزکاری و حذف رکوردهای منابع کهنه و قدیمی که به شکل داده های تاریخ مصرف گذشته در zone انباشته می شوند ، ارائه می دهد . هنگامی که یک کامپیوتر در شبکه شروع بکار می کند با انجام شدن عملیات داینامیک آپدیت ( dynamic update ) رکوردهای منابع به صورت اتوماتیک به Zone ها اضافه می شوند . ولی به دلایل زیادی ، هنگامی که کامپیوترها شبکه را ترک می کنند ، رکوردهای مربوطه به شکل اتوماتیک حذف نمی شوند . به عنوان مثال ، اگر یک کامپیوتر رکورد منبع A Record ، مربوط به خودش را در DNS سرور ثبت کند و بعدها آن کامپیوتر به شکل نامناسبی از شبکه قطع گردد ، این رکورد از نوع A ممکن است که حذف نشود . اگر شبکه شما کاربران و کامپیوترهای متحرک یا Portable دارد ، این وضعیت نامطلوب بصورت مکرر می تواند اتفاق بیفتد. اگر این نوع از رکوردهای قدیمی به حال خود رها شوند ، حضور این رکوردهای منبع ( Resource Record) کهنه و فرسوده در zone ممکن است مشکلات بسیاری را به وجود آورد . که از آن جمله می توان به موارد زیر اشاره کرد :

    اگر شمار زیادی از رکوردهای منبع کهنه در zone باقی بمانند ، آنگاه سرانجام می توانند فضای دیسک سرور را اشغال کنند و باعث انتقالات zone غیر ضروری ( zone transfers ) بسیاری شوند.


    سرور Domain Name System یا DNS ، که zone هایی را بارگذاری می کند که شامل رکوردهای منبع قدیمی هستند ، ممکن از اطلاعات تاریخ مصرف گذشته برای پاسخگویی به پرس و جوهای کلاینت ها استفاده کنند و به شکل بالقوه باعث شوند که کلاینت ها در تبدیل نام به آدرس در شبکه دچار مشکل شوند .


    رکوردهای منبع کهنه انباشته شده در DNS سرور ، می توانند کارایی و قدرت پاسخ دهی سرور را کاهش دهند .


    به دلایل زیادی ، حضور رکورد منبع کهنه در یک zone ، می تواند از استفاده یک نام دامین DNS ، توسط دیگر کامپیوترها یا دستگاه های درون شبکه جلوگیری نماید .



برای حل این مشکلات سرویس DNS Server ، ویژگی های زیر را دارا می باشد :

    Time stamping ( مهر زمان زدن ) : که بر مبنای تاریخ اخیر و زمانی است که رکورد در کامپیوتر سرور قرار داده می شود و برای هر رکورد منبعی که به شکل داینامیک به primary-type zones اضافه می شود ، یک Time stamping در نظر گرفته می شود . بعلاوه ، مهر زمان (time stamp ) در standard primary zone هایی ثبت می شود که در آنها aging and scavenging فعال هستند . برای رکوردهای منبعی که شما بصورت دستی اضافه می کنید ، از مقدار صفر برای time-stamp استفاده می شود تا نشان دهد که این رکوردها به وسیله فرآیند aging ( طول عمر ) تحت تاثیر قرار نمی گیرند و آنها بدون هیچ محدودیتی می توانند درون داده های zone باقی بمانند ، مگر اینکه شما time stamp آن رکوردها را تغییر دهید و یا آن رکوردها را دستی حذف نمایید .


    Aging (طول عمر) : رکوردهای منبع در داده های محلی ، که بر مبنای دوره زمانی نوسازی (Refresh Interval) تعیین شده ای می باشد و برای هر zone قابل انتخاب می باشد. تنها primary-type zones هایی که به وسیله سرویس DNS سرور بارگذاری شده اند ، برای شریک شدن در این فرآیند قابل انتخاب می باشند .


    Scavenging ( تمیز کردن ) : برای هر یک از رکوردهای منبعی که اصرار به باقی ماندن فراتر از دوره ی نوسازی مشخص شده (specified refresh period ) دارند. هنگامی که یک سرور DNS یک عملیات scavenging را اجرا می کند ، می توانند تعیین کند که چه رکوردهای منبعی کهنه شده اند و مناسب از بین بردن و حذف کردن می باشند . شما می توانید سرورها را برای تکرار کردن عملیات scavenging به صورت اتوماتیک پیکربندی نمایید ، یا شما می توانید عملیات فوری scavenging را در سرور راه اندازی نمایید . یک سرور با استفاده از محتویات هر یک از resource records time stamps و همچنین سایر تنظیماتی که برای Aging and Scavenging انجام شده است می تواند تصمیم بگیرد که این رکورد را بایستی پاکسازی یا تمیز کند یا خیر.


Aging and Scavenging در DNS چیست


هشدار : بصورت پیشفرض سرویس Aging and Scavenging در DNS سرورها غیرفعال است. صرفا زمانی بایستی این سرویس فعال شود که کلیه پارامترهای مربوط به آن به درستی درک شوند . در غیر اینصورت سرور می تواند بصورت تصادفی و به دلیل عدم انجام تنظیمات درست برای این سرویس ، رکوردهایی که نبایستی حذف شوند را حذف کند . نکته مهم در اینجاست که با حذف یک رکورد در DNS نه تنها سایر کاربران قادر به پیدا کردن اهداف و پاسخ دریافت کردن از Query های خود نخواهند بود بلکه هر کاربری می تواند در این لحظه یک رکورد برای خود در DNS سرور ایجاد کرده و مالکیت آن را بر عهده بگیرد حتی اگر آن Zone ها در حالت Secure Dynamic Update قرار گرفته باشند .


پیشنیازهای Aging and Scavenging

قبل از اینکه شما بتوانید از ویژگی aging and scavenging در DNS استفاده کنید ، چندین شرط را بایستی در نظر بگیرید :

    aging and scavenging باید هم در DNS server و هم بر روی zone فعال باشد . بصورت پیشفرض aging and scavenging رکوردهای منابع غیر فعال می باشند .
    رکوردهای منابع باید یا به شکل داینامیک به zone ها اضافه شده باشند یا بصورت دستی برای استفاده در عملیات aging and scavenging ، تغییر داده شده باشند . بطور معمول تنها رکوردهای منابعی که به شکل داینامیک با استفاده از پروتکل بروزرسانی پویای DNS یا (DNS dynamic update protocol ) اضافه می شوند ، موضوع کار aging and scavenging هستند .


برای رکوردهایی که به شکل غیر دینامیک به یک zone اضافه شده اند ، چه بوسیله یک zone file مبتنی بر متن ( text ) که از طریق یک DNS سرور دیگر اضافه شده باشند و چه به شکل دستی آنها به یک zone اضافه شده باشند ، بطور یش فرض یک time stamp صفر برای این نوع رکوردها فعال است . این نوع تنظیم این رکوردها را برای استفاده در عملیات aging and scavenging نامناسب می سازد . ولی شما می توانید scavenging را برای آن دسته از رکوردهای منابعی که به شکل غیر داینامیک به یک zone اضافه شده اند ، فعال کنید . برای تغییر این پیش فرض ، شما می توانید این نوع رکوردها را برای تنظیم دوباره و اجازه دادن به آنها برای استفاده از یک مقدار time-stamp جدید (غیر صفر) ، شخصا مدیریت نمایید. این تغییر این امکان را برای این نوع از رکوردها فراهم می آورد تا در عملیات aging and scavenging منظور شوند .

نکته : زمانیکه شما یک Zone را از حالت Standard Primary به حالت Active Directory Integrated تبدیل می کنید ، شاید بخواهید که Scavenging برای کلیه رکورد های موجود در این Zone فعال شود . برای فعال کردن این قابلیت برای رکوردهای موجود در این Zone بایستی از دستور خط فرمانی theAgeAllRecords که یکی از زیرمجموعه های ابزار خط فرمانی dnscmd می باشد استفاده کنید.

توضیح اصطلاحات فنی در خصوص Aging and Scavenging

برای اینکه درک بهتری از اصطلاحات بکار گرفته شده در خصوص قابلیت Aging and Scavenging داشته باشید می توانید در ادامه توضیحات مربوط به اصطلاحات فنی بکار گرفته شده در این حوزه را مشاهده کنید تا در هنگام مطالعه در این خصوص دچار ابهام نشوید :

Resource record time stamp : یک مقدار تاریخ و زمان است که وقتی DNS سرور عملیات aging and scavenging را انجام می دهد از آن برای مشخص کردن حذف رکورد منبع استفاده می کند .

Current server time : مقدار کنونی تاریخ و زمان بر روی DNS سرور می باشد. این عدد می تواند به صورت یک مقدار عددی صحیح در هر لحظه ای بیان شود.

No-refresh interval : یک فاصله ی زمانی، برای هر ناحیه ی مشخص شده است که به وسیله دو رویداد زیر محدود شده اند:

    تاریخ و زمان وقتی که رکورد برای آخرین بار refresh شده و time stamp آن تنظیم شده باشد.
    تاریخ و زمان وقتی که رکورد در آینده برای refresh شدن واجد شرایط باشد و time stamp آن ریست شده باشد.


برای کاهش تعداد عملیات نوشتن در پایگاه داده اکتیودایرکتوری این مقدار مورد نیاز است. به طور پیش فرض، این بازه ی زمانی هفت روز تنظیم شده است و نباید به سطح نامعقولی افزایش داده شود زیرا فواید ویژگی aging and scavenging ممکن است از بین رفته یا نقصان پیدا کند .

Refresh interval : یک فاصله ی زمانی، برای هر ناحیه ی مشخص شده است که به وسیله دو رویداد مجزای زیر محدود شده اند:

    نزدیک ترین تاریخ و زمان وقتی که رکورد برای refresh سدن واجد شرایط بوده و time stamp آن ریست باشد.
    نزدیک ترین تاریخ و زمان وقتی که رکورد برای scavenge شدن واجد شرایط بوده و از دیتابیس zone خذف شده باشد.

این مقدار باید به اندازه کافی بزرگ باشد تا به همه ی کلاینت های اجازه دهد رکوردهایشان را refresh کنند. به طور پیش فرض این بازه ی زمانی هفت روز تنظیم شده است و نباید به سطح نامعقولی افزایش داده شود زیرا فواید ویژگی aging and scavenging ممکن است از بین رفته یا نقصان پیدا کند.

Start scavenging time : یک زمان مشخص است که به صورت یک عدد بیان می شود. سرور برای این که مشخص کند چه وقت zone برای scavenging در دسترس است از این زمان استفاده می کند.

Scavenging period : وقتی automatic scavenging در سرور فعال است، این دوره زمانی ( period ) زمان بین تکرار فرآیند scavenging را نشان می دهد. مقدار پیش فرض برای آن هفت روز می باشد. برای جلوگیری از زوال کارایی DNS سرور، کم ترین مقدار مجاز برای آن یک ساعت می باشد.

Record refresh : هنگامی که یک DNS dynamic update برای یک رکورد منبع پردازش می شود . به طور کلی refreshها به دلایل زیر اتفاق می افتند:

    وقتی یک کامپیوتر در شبکه ریستارت شده باشد و اگر در startup ، نام و اطلاعات IP address آن با نام مشابه و اطلاعات آدرسی که قبل از shutdown شدن استفاده می کرده است، سازگار باشد آن یک refresh برای نو کردن رکوردهای منبع مرتبط اش برای این اطلاعات می فرستد
    یک refresh دوره ای به وسیله کامپیوتر وقتی در حال کار کردن است فرستاده می شود. Windows DNS Client service ثبت DNS رکوردهای منبع کلاینت را هر 24 ساعت نوسازی می کند. وقتی این dynamic update اتفاق می افتد، اگر درخواست dynamic update سبب تغییری در پایگاه داده DNS نشود، عاقلانه این است که یک refresh وجود داشته باشد و نه یک update رکورد منبع.
    سرویس های دیگر شبکه سبب تلاش های نوسازی می شود، مانند: سرورهای DHCP که اجاره آدرس کلاینت را نوسازی می کند. سرورهای خوشه که رکوردها را برای یک خوشه ثبت و update می کند و سرویس Net Logon که می تواند رکوردهای منبعی که به وسیله اکتیودایرکتوری کنترولر استفاده می شود را ثبت و update می کند.


Record update: هنگامی یک DNS dynamic update برای یک رکورد منبع مورد پردازش قرار می گیرد که دیگر مشخصات رکورد به علاوه ی time stamp آن اصلاح شده باشد. به روز رسانی ها به طور کلی به دلایل زیر اتفاق می افتند :

    وقتی یک کامپیوتر جدید به شبکه اضافه می شود در زمان startup آن ، یک update برای ثبت رکودهایش برای اولین بار به zone پیکربندی شده در DNS سرور می فرستد .
    وقتی یک کامپیوتر با رکوردهای موجود در zone تغییری در IP address داشته باشد، سبب می شود که update هایی برای نگاشت های اصلاح شده ی name-to-address در داده های DNS zoneفرستاده شوند.
    وقتی سرویس name-to-address ، یک دامین کنترلر اکتیودایرکتوری جدید را به ثبت می رساند.


Scavenging server’s : یک پارامتر پیشرفته ی اختیاری zone است که شما را قادر می سازد که یک لیست محدود شده از IP address ها برای DNS serverهایی که قادر به اجرای scavenging درون zone هستند تعیین کنید. بصورت پیش فرض اگر این پارامتر تعیین نشده باشد، همه ی DNS server هایی که یک directory-integrated zone را بارگذاری می کند (همچنین فعال شده برای فرایند scavenging ) سعی به اجرای فرآیند scavenging در zone دارند. در بعضی موارد این پارامتر می تواند مفید واقع شود اگر آن برتر از این باشد که scavenging تنها در بعضی از سرورهایی که directory-integrated zone را بارگذاری می کنند ، اجرا شده باشد . برای تنظیم این پارامتر، شما شما باید لیستی از IP addressها را برای سرورهایی که قادر به scavenge کردن zone در پارامتر ZoneResetScavengeServers برای zone می باشند را تعیین کنید. می توان این کار را با فرمان dnscmd انجام داد، یک ابزار مبتنی بر خط فرمان برای نظارت بر Windows DNS servers می باشد .

چه زمانی Scavenging شروع به کار می کند
بعد از فعال سازی همه ی پیش نیازها برای aging and scavenging آنگاه می توانیم از قابلیت scavenging استفاده کنیم . هنگامی که زمان کنونی سرور بیشتر از مقدار زمان شروع scavenging برای zone باشد، این فرآیند می تواند برای یک zone از DNS server شروع شود .سرور با توجه به رویدادهایی که در ادامه ذکر می شود ، برای شروع فرآیند scavenging بر اساس هر Zone موجود بر روی سرور زمانی را تعیین و تنظیم می کند :

    Dynamic updates برای zone فعال باشد.


    تغییری در وضعیت چک باکس Scavenge stale resource records داده شده باشد. شما می توانید از DNS Manager برای تغییر این تنظیمات در یک DNS server قابل اجرا یا یکی از primary zone های مربروط به آن استفاده کنید.


    DNS server یک primary zone که عملیات scavenging برای آن فعال است ، را بارگذاری می کند . این اتفاق وقتی که کامپیوتر سرور یا سرویس DNS server شروع شده است، می تواند رخ دهد.


    هنگامی که یک zone سرویس رابعد از متوقف شدن دوباره از سر می گیرد.


    اگر zone یکپارچه با اکتیودایرکتوری (AD DS ) باشد، عملیات تکرار (replication ) برای zone دستکم یکبار از زمانی که سرویس DNS ریستارت شده یا دامین کنترلر ریبوت شده است، باید اتفاق بیفتد. هنگامی که اتفاقات قبل رخ می دهد، DNS sever مقدار زمان شروع scavenging را به وسیله محاسبه ی جمع زیر تنظیم می کند :


Current server time + Refresh interval = Start scavenging time


از این مقدار به عنوان مبنای مقایسه در طول عملیات scavenging استفاده می شود.

فرآیند عملیات Aging and Scavenging بر روی یک رکورد فرضی
برای اینکه درک بهتری از فرآیند عملیات های Aging and Scavenging بر روی سرور داشته باشید فرض کنید که یک رکورد را از لحظه ایجاد بر روی سرور و Zone ای که بر روی آن قابلیت Aging and Scavenging فعال شده است زیر نظر میگیریم و از لحظه ایجاد تا لحظه حذف از پایگاه داده مورد بررسی قرار می دهیم ، ببینیم چه اتفاقی برای این رکورد می افتد :

    یک DNS host نوعی ، مثلا "host-a.example.microsoft.com" ، رکورد منبع host (A) مربوط به خودش را در DNS server ، درون یک zone ای که در آن aging and scavenging فعال است ، ثبت می کند .
    هنگامی که رکورد ثبت می شود ، DNS server یک time stamp بر روی این رکورد بر مبنای زمان فعلی سرور قرار می دهد . بعد از اینکه بر روی رکورد time stamp نوشته شد ، DNS server هیچگونه نوسازی (refresh ) برای این رکورد در مدت زمانی که zone در فاصله no-refresh interval ( مدت زمانی که zone نوسازی نمی شود ) قرار دارد ، نمی پذیرد .هرچند که DNS server ، می تواند بروز رسانی ها را برای رکورد را قبل از این زمان (no-refresh interval) بپذیرد. برای مثال اگر IP address برای "host-a.example.microsoft.com" تغییر کند ، DNS server می تواند این بروزرسانی را بپذیرد . در این وضعیت سرور همچنین time stamp رکورد را بروز رسانی (reset) می کند .
    به محض اینکه دوره no-refresh interval سپری شد ، سرور تلاش ها برای نوسازی این رکورد را شروع به پذیرفتن می کند . هنگامی که نخستین دوره no-refresh interval به پایان رسید ، دوره refresh interval فورا برای رکورد شروع می شود . طی این زمان سرور کلیه تلاش های رکورد برای نوسازی طول عمر باقیمانده خودش را مانع نمی شود .
    در طول و بعد از دوره refresh interval ، اگر سرور یک نوسازی برای رکورد را دریافت کند ، آن تقاضا پردازش می شود . این (reset ) تنظیم دوباره time stamp برای رکورد بر مبنای روشی است که در مرحله 2 توضیح داده شد .
    وقتی scavenging بعدی به وسیله سرور برای zone "example.microsoft.com" اجرا می شود، رکورد به وسیله سرور امتحان می شود. هر رکورد با زمان کنونی سرور بر اساس جمع زیر مقایسه می شود تا مشخص شود که آیا رکورد باید خذف شود یا نه:

    Record time stamp + No-refresh interval for zone + Refresh interval for zone


Aging and Acavenging در DNS


اگر مقدار این جمع بزرگ تر از زمان کنونی سرور است، هیچ عملی انجام نمی شود و رکورد به حیاتش در zone ادامه می دهد.اگر مقدار این جمع کم تر از زمان کنونی سرور است، رکورد هم از هر zone data ای که هم اکنون در حافظه ی سرور بارگذاری شده است و هم از شی اجراشدنی DnsZone که در Active Directory Domain Services یا ( AD DS ) برای directory-integrated "example.microsoft.com" zone ذخیره شده است، خذف می گردد.

روش های اجرا کردن Command Prompt از طریق بوت در Windows 7

تعریف Command Prompt :

Command Prompt یکی از Featureهای ویندوز است که شبیه ساز سیستم عامل MS DOS (Microsoft Disk Operating System) در ویندوز است که فایلهای اجرایی 'exe , com' در آن اجرا می شود. ما میتوانیم دستورات زیادی روی کامپیوترمان از این طریق بدون استفاده از محیط گرافیگی ویندوز 7 Windows 7 graphical interface (GUI) اجرا کنیم. و این نکته را متذکر شوم که این محیط معمولا توسط کاربران حرفه ای مورد استفاده قرار می گیرد.

2 روش اجرا کردن Command Prompt عبارتند از :

    System Recovery Options
    Advanced Boot Options


System Recovery Options :

این روش در Windows 7 installation disc قرار دارد برای بالا آوردن این محیط 2 طریق میتوانیم استفاده کنیم :

    Repair Disk Windows 7
    DVD Windows 7


1. Repair Disk Windows 7

ابتدا DVD Repair سیستم خود را درون DVD RW گذاشته و بوت سیستم را روی CD-ROM Drive می گذارید تا دیسک بوت شود

Command


Command


سپس در شکل زیر گزینه Restore your computer using …. را انتخاب و Next را انتخاب می کنیم

Command


سپس در دو شکل زیر Cancel را انتخاب می کنیم

Command

Command


در نتیجه در صفحه باز شده Command Prompt را انتخاب می کنیم
Command

Command


2. DVD Windows 7

همان گونه که در بالا توضیح داده شده ابتدا DVD ویندوز 7 را گذاشته

1


سپس در شکل زیر Next را انتخاب می کنیم

2


سپس در صفحه باز شده Repair your computer را انتخاب می کنیم

3


4


همانگونه که مشاهده می کنید مراحل بعدی همانند قبل که توضیح دادیم می باشد


Advanced Boot Options:

1


همانطور که در شکل بالا مشاهده می کنید به صفحه Advanced Boot Options می گویند این قسمت وقتی سیستم دارای مشکل می باشد مورد استفاده قرار می گیرد و هر کدام از این گزینه ها کار بخصوصی را انجام می دهند که بحث مورد نظر ما نمی باشد و این نکته هم متذکر شوم که برای ورود به این محیط در هنگام بوت F8 را فشار می دهیم
در اینجا می خواهم در مورد گزینه هایRepair your computer و Safe Mode with Command Prompt صحبت کنم
گزینه Repair your computer تازه در بالا مورد بحث قرار گرفت ولی در اینجا نیازی به DVD ویندوز یا Repair Disk نیست
و اما Safe Mode with Command Prompt
اگر این گزینه را فشار دهیم صفحه زیر باز می شود

2


که باید منتظر شویم تا صفحه زیر که همان صفحه مورد نظرمان می باشد باشیم

3

نگاهی بر ویژگیهای DNS در ویندوز سرور 2008

همه دوستانی که در زمینه شبکه فعالیت می کنند با DNS یا همان Domain Naming System به خوبی آشنایی دارند و به خوبی می دانند که DNS ، این ستون قدرتمند شبکه ،دارای اهمیت به سزایی می باشد. با این حال به خدمت دوستان تازه وارد به عرصه ی شبکه های کامپیوتری عرض می کنم که DNS سیستمی است که ( در حالت خیلی ساده ) وظیفه ی تبدیل نام به IP و IP به نام را بر عهده دارد.درواقع با توجه به اینکه کلیه تعاملات در شبکه به وسیله IP ها انجام می شود و ذهن آدمی ( با بیشمار دغدغه ای که دارد ) نمی تواند IP مربوط به هر سایت با کامپیوتری را در شبکه از بر داشته باشد،از اینرو DNS با تبدیل نام به IP و IP به نام،امکان سیر در شبکه و اینترنت را برای ما آسان کرده است. البته این یکی از ساده ترین وظایفی است که DNS در شبکه انجام می دهد. با مطالعه هرچه بیشتر در مورد این ستون قدرتمند شبکه متوجه می شوید که بدون DNS ،بیشتر فرآیندها موجودیت خود را از دست می دهند و نبود آن موجب فلج شدن برخی از سرویس ها و چرخه ها در شبکه می شود.دوست عزیز جناب مهندس صادقی جم در دو مقاله زیر به معرفی DNS نیز پرداخته اند:

    مفاهیم DNS
    پشت صحنه DNS



DNS از یک ساختار سلسله مراتبی پیروی می کند و در شبکه ها (مثلا شبکه جهانی اینترنت ) از پروتکل TCP/IP جهت نامگذاری سرویس ها و کامپیوترها استفاده می کند.بسیاری از کاربران به خاطر سپردن اسامی خودمانی و صمیمی برایشان از به خاطر بودن اسامی تخصصی و غیرمتعارفی که زیاد با آن اسامی سروکار ندارند ،راحت تر است.به همین دلیل انتخاب برخی از اسامی ( مانند ایمیل و نام های کامپیوتر ها ) برعهده کاربران قرار گرفته است و DNS مسئولیت تبدیل این اسامی و اسامی برخی از سرویسها به IP های متناظر با آنها را بر عهده گرفته است. نقش DNS سرور درویندوز سرور 2008،از پروتکل های استاندارد DNS پیروی می کند و با ساختار اکتیودایرکتوری یا AD DS و دیگر قابلیت های امنیتی ( مانند برخی از قابلیت های بروز رسانی داینامیک و امن بعضی از رکوردهای امنیتی DNS ) و شبکه ای ویندوز یکپارچه می شود. به طبع به دلیل نقش مهم و انکارناپذیر DNS این سرور برای اجرای بی عیب و نقص وظایف خود باید دارای ویژگی ها و امکانات به خصوصی باشد،برخی از امکاناتی که DNS ارائه می دهد عبارتند از :

    DNS Server ها از RFC ها پیروی می کنند
    سازگاری و قابلیت اجرا شدن با DNS Server های دیگر
    نصب و پیاده سازی همزمان AD DS با DNS Server
    ذخیره سازی DNS Zone ها در AD DS یا Application Directory Partition
    Conditional Forwarder یا هدایت شرطی درخواست ها
    Stub Zones
    افزایش امکانات امنیتی DNS
    یکپارچگی با دیگر سرویسهای شبکه ای مایکروسافت
    افزایش سهولت در مدیریت
    پشتیبانی کردن از پروتکلهای به روز رسانی داینامیک RFC
    پشتیبانی از Zone Transferها به صورت Incremental در بین سرورها
    Single-label Host-name resolution without WINS


DNS Server ها از RFC ها پیروی می کنند
در ایتدا بهتر است بگویم RFC دقیقا چیست؟ مستنداتRFC یا Request For Comments بیش از 30 سال است که در اینترنت مورد استفاده قرار می گیرند.محققان دانشگاهی برای دریافتن و فهمیدن بازخورد افراد از تکنولوژی های جدید اینترنت،مستندات RFC را منتشر کردند.بیشتر تکنولوژی های شبکه مانند IP و Ethernet توسط RFC ها مستند شده اند.اولین RFC تحت عنوان RFC1 در آپریل 1969 منتشر شد. DNS نیز یک پروتکل باز است که توسط مجموعه ای از RFC ها استاندارد شده است.مایکروسافت هم از این معیارها حمایت و پشتیبانی می کند .

سازگاری و قابلیت اجرا شدن با DNS Server های دیگر
دوستان مایکروسافتی به خوبی می دانند که مایکروسافت همیشه از محصولات خود ( ولو اینکه قدیمی و از کار افتاده باشند ) حمایت و پشتیبانی می کند. DNS از این امر مستثنی نمی باشد با توجه به اینکه DNS Server ویندوز سرور 2008 ، براساس RFC تعریف شده است ،اما می تواند از داده ها و قالب رکوردهای منابع اطلاعاتی دیگر DNS های استاندارد استفاده و با آنها کار کند.DNS حتی می تواند با BIND نیز به خوبی و به طور هماهنگی فعالیت داشته باشد.( Berkeley Internet Name Domain (BIND در واقع نرم افزاری قدیمی است که در سال 1980 در دانشگاه کالیفرنیا در بریکلی ساخته شده است.این نرم افزار دارای مجموعه پروتکل های DNS برای پاسخگویی به درخواست های تبدیل نام به IP و برعکس می باشد و دارای ساختاری flat می باشد .

نصب و پیاده سازی همزمان AD DS با DNS Server
DNS Server و Active Directory Domain Services یا همان Domain Controller امروزی ،باید با هم و در کنار هم نصب و پیاده سازی شوند.AD DS برای اینکه بتواند فعالیت داشته باشد باید سرویس و نقش DNS را در کنار خود داشته باشد ( همانطور که می دانید برای نصب دومین کنترلر باید ابتدا DNS Server نصب شود ).دلیل این امر بدیهی است چرا که دومین کنترلر برای تعیین محل هر کدام از کامپیوترهای خود در شبکه و اکتیودایرکتوری نیازمند مدیریت DNS است که از طریق آن بتواند به کلیه کامپیوترها و دستگاه های شبکه IP بخصوصی اختصاص دهد و عملیات تبدیل نام به IP و IP به نام را انجام دهد و میان دومین کنترلر جاری و دیگر دومین کنترلرهای موجود یکسان سازی اطلاعات یا همان Replication انجام دهد.شما می توانید از دیگر ساختارهای DNS برای پشتیبانی از AD DS استفاده کنید،اگرچه تصمیم به بکارگیری از ساختارهای قدیمی تر DNS را داشتید،حتما مسائل مربوط به DNS interoperability را نیز در نظر بگیرید.

ذخیره سازی DNS Zone ها در AD DS یا Application Directory Partition
DNS Zone ها می توانند در دومین یا Application Directory Partition های مربوط به AD DS ذخیره شوند.Application Directory Partition از مجموعه داده ها و اطلاعاتی تشکیل شده است که به منظور انجام عمل replication در آن قرار می گیرند.شما می توانید مشخص کنید که در کدامیک از Application Directory Partition ، DNS Zone ها می توانند ذخیره شوند و در نتیجه مجموعه ای از دومین کنترلرها بین داده های کدامیک از Zone ها replicate خواهند شد.و در نهایتDNS Server دارای دوApplication Directory Partition جهت ذخیره سازی Zone ها و انجام یک Replication استاندارد میباشد: DomainDnsZone و ForestDnsZone

Conditional Forwarder یا هدایت شرطی درخواست ها
از دیگرامکاناتی که سرویس DNS Server ارائه می دهد Conditional Forwarders ها می باشد.DNS Server با ارائه این امکان ، قابلیت انجام عملیات مربوط به Standard Forwarders را توسعه داده است.Conditional Forwarder یک DNS Server در شبکه است که Queryهای را براساس DNS Domain name موجود در query به DNS مناسب هدایت می کند.به عنوان مثال شما می توانید DNS سروری طراحی کنید که همه ی query هایی که دریافت می کند و با ITPRO.ir تمام می شوند را به یک DNS خاص یا مجموعه ای از DNS سرورها ارسال کند. برای مطالعه بیشتر در زمینه Conditional Forwarder ها می توانید به مقاله تشریح مفاهیم Forwarder و Conditional Forwarding در DNS و شیوه پیاده سازی آنها در DNS سرور مراجعه کنید.

Stub Zones
یکی از انواع Zone را که به Stub Zone معروف است، DNS ساپورت می کند،Stub Zone کپی است از یک Zoneی که رکوردهای موردنیاز برای شناسایی و احرازهویت DNS Server های معتبر به Zone را در بر دارد.Stub zone یک DNS Server ی را که دارای آپدیتهای یک Parent Zone با DNS Serverهای معتبر برای childهای آن Parent Zone است را در خود نگه میدارد.این باعث بالا رفتن راندمان DNS سرور می شود.

افزایش امکانات امنیتی DNS
DNS امکان مدیریت امنیتی برای Server Service ، DNS Client Service و DNS data را فراهم می کند .

یکپارچگی با دیگر سرویسهای شبکه ای مایکروسافت
سرویس DNS Server بین دیگر سرویس ها یکپارچگی ایجاد می کند و دارای یک سری Features در بین دیگر Featuresهایی است که در RFC ها مشخص شده اند.این Featureها شامل یکپارچگی با سرویسهای AD DS،Windows Internet Name Service (WINS) و Dynamic Host Configuration Protocol (DHCP) میباشد.

افزایش سهولت در مدیریت
DNS Manager یا DNS snap-in در Microsoft Management Console(MMC) با ارائه ی واسط گرافیکی کاربری (GUI)امکان مدیریت سرویس DNS Server را آسانتر کرده است.همچنین Configuration Wizard های مختلفی وجود دارند که وظایف مدیریتی برای سرورها را ایجاد میکنند.به علاوه ابزارهای زیادی وجود دارند که به شما در مدیریت و پشتیبانی هرچه بهتر و بیشتر DNS Server و کلاینتها در شبکه کمک میکنند.

پشتیبانی کردن از پروتکلهای به روز رسانی داینامیک RFC
سرویس DNS Server کلاینتها را قادر می سازد که به صورت داینامیکی Resource Record هارا براساس پروتکلهای بروزرسانی داینامیک (RFC 2136) ، آپدیت نماید. این امکان مدیریت DNS را ارتقاء می دهد و زمان لازم برای به روز رسانی این رکوردها به صورت دستی را کاهش می دهد.کامپیوترها سرویس DNS Client را که به وسیله آن می توانند نام و IP آدرسهای خود را به صورت داینامیکی ثبت کنند ،اجرا می کنند.

پشتیبانی از Zone Transferها به صورت Incremental در بین سرورها
DNS Server هایی که داده ها و فایلهای DNS را ذخیره میکنند از Zone Transfer جهت Replicate کردن اطلاعات خود استفاده میکنند.در برخی موارد که تنها قسمتی از Zone مورد نظر با دومین ویا دومین کنترلرهای دیگر Replicate نشده است، سرویس DNS Server از Incremental Zone Transfer جهت Replicate کردن آن قسمت از Zone استفاده میکند، که این امر باعث آزاد نگه داشته شدن پهنای باند میشود.

Single-label Host-name resolution without WINS
Single-label nameها ،اسامی هستند که شامل دومین والد یا Parent Domain نمیشوند ( مثل .com ).سرویس DNS Server یک Zoneی تحت عنوان GlobalNames را که این Single-label name ها نگهداری میکند ،ساپورت میکند.در شبکه ها استفاده از WINS دیگر یک option نمی باشد از اینرو GlobalName Zone با ارائه این قابلیت مدیریت این سرورهای محدود با IP آدرسهای fix شده را امکانپذیر میکند.

تشریح مفاهیم Forwarder و Conditional Forwarding در DNS و شیوه پیاده سازی آنها در DNS سرور

در این مقاله قصد داریم که پیرامون مبحث Forward یا هدایت درخواستها به وسیله DNS به صورت جامع صحبت کنیم. همانطور که می دانید هر DNS سرور بهنگام دریافت یک Query یک سری مراحل را برای یافتن آدرس مورد نظر طی می کند. دوستان من در این سایت به بررسی جز به جز این مراحل پرداخته اند . امید دارم که قبل از خواندن این مقاله حتما مقالات در خصوص مبحث DNS مطالعه نمایید. ما نیز در اینجا روندی که DNS برای پاسخ به این Query ها طی می کند را به صورت مختصر توضیح خواهیم داد .با یک مثال به توضیح روند کاری DNS می پردازیم : اگر کاربری قصد بازدید از سایت www.itpro.ir را داشته باشد ابتدا بررسی می کند که آیا قبلا به این سایت مراجعه کرده و IP آدرس در Cache سیستم وجودارد یا خیر ؟ اگر IP آدرس مورد نظر یافت نشد Host file سیستم بررسی می شود و در صورت نیافتن آدرس درخواست برای DNS سرور ارسال می شود بنابراین هر DNS Server پس از دریافت یک Query برای یافتن یک آدرس ابتدا در اطلاعات سیستم خود یا به اصطلاح اطلاعات محلی خود به ترتیبی که بیان می شود در جهت یافتن آدرس IP مورد نظر جستجو می کند :

    Zone
    Cache
    اگر تا به این مرحله جواب Query دریافتی پیدا نشد درخواست را برای یک سرور دیگر Forward یا هدایت می کند (که در این مقاله ما به تشریح کامل چگونگی عملیات Forward خواهیم پرداخت )
    اگر DNS به کمک Forwarder نیز موفق به یافتن جواب نشد درخواست را برای Root Hint ها (یا همان سرور های ریشه )ارسال خواهد کرد.


تعریف FORWARDER یا هدایت کننده
Forwarder در واقع DNS سروری در شبکه است که به گونه ای تنظیم شده تا Query هایی که در DNS سرور داخل شبکه،جوابی برای آنها یافت نمیشود را برای آدرس های IP یا سرورهای DNS سرور خارج از شبکه ارسال کند.

وقتی DNS Server یک Query را برای Forwarder ارسال می کند ، در واقع یک فرآیند رفت و برگشت پرسش و پاسخ صورت می گیرد که این فرآیند با ارسال مکرر Query ها در حالت استاندارد ، توسط DNS Server به DNS سرور های دیگر برای رسیدن به هدف اصلی که همان پیدا کردن آدرس IP مقصد است انجام می شود ، در اصطلاح به این فرآیند رفت و برگشت Recursion نیز گفته می شود.در ساختار DNS به فرآیند ارجاع یک نام مثل www.Itpro.ir به IP مربو طه اش اصطلاحا Name Resolution گویند.) هدف DNS در نهایت یافتن IP متناظر با بخش هاست یک آدرس است.) در اینجا DNS سرور مانند یک دفترچه تلفن برای اینترنت عمل می کند که در آن Host Name ها برابر با IP متناظرشان قرار گرفته می شود ویا بالعکس.

میتوان چنین برداشت کرد که با طراحی و در نظر گرفتن یک DNS سرور در یک سازمان یا یک شبکه داخلی بعنوان Forwarder، آن DNS سرور را برای رسیدگی به ترافیک های خارج از سازمان در نظر گرفته ایم .که موجب کاهش ترافیک های اینترنتی در مقابل DNS سرور میشود. یک Forwarder مجموعه ای از اطلاعات DNS های خارجی را در قالب یک cache بزرگ گردآوری میکند بدین معنی که forwarder پاسخ هر Query ای که دریافت کرده را Cache میکند.زیرا باید پاسخ گوی تمامی Queryهای در یافتی از سراسر یک شبکه باشد.بنابراین Forwarder قادر به پاسخ گویی به مجموعه ای از درخواستها به کمک این اطلاعات موجود در کش خود در بازه ی زمانی محدودی خواهد بود. همانگونه که پیشتر ذکر شد این شرایط، ترافیک اینترنت بر روی شبکه و زمان پاسخ به کلاینتها را توسط DNS به حداقل میرساند.

از forwarder برای مدیریت ترافیک ایجاد شده برای DNS سرور ،میان اینترنت و شبکه داخلی یک سازمان نیز استفاده میکنیم .ساختار فایروال در شبکه تنها اجازه ارتباط یک DNS سرور با محیط بیرون و اینترنت را صادر میکند ،بنابراین برای سایر DNS سرور های موجود در شبکه تعیین میکنیم که اگر برای Query دریافتی به کمک اطلاعات لوکال خود پاسخی نیافتند ، درخواست خود را برای DNS سروری که نقش Forwarder را در سازمان ایفا میکند ،ارسال کنند.

مراحل انجام عملیات Forwarding در DNS سرور
همانگونه که میدانیم برای پیاده سازی یک DNS سرور بعنوان Forwarder ، باید لیستی از IP های DNS سرورها ی خارجی را فراهم آوریم که طبق این لیست DNS سرور تشخیص خواهد داد که از کدام آی پی میتواند برای یافتن جواب استفاده کند.پس از اینکه DNS سرور یک Query را برای forwarder ارسال کرد ،فرآیند مقایسه آغاز میشود و درخواست ارسالی با اولین آدرس، مقایسه شده و DNS یک بازه زمانی کوتاه را برای دریافت پاسخ از Forwarder منتظر میماند و اگر جواب حاصل نشد ،فرایند مقایسه با IP آدرس بعدی تکرار میشود واین روند تا زمان دریافت جواب مورد نظر از Forwarder ادامه می یابد تا به جواب صحیح و نهایی برسد.

برای روند جست و جوی DNS در حالت عادی یک بازه زمانی برای ارسال درخواست کلاینت و دریافت پاسخ از سرور در نظر گرفته شده است که به آن Round Trip Time یا RTT می گویند باید در نظر داشته باشیم که لیست IP های موجود در Forwarder ، بر اساس RTT مرتب نشده اند و باید بصورت دستی اولویت IP ها را بر حسب RTT تغییر دهیم .

پیاده سازی یک DNS server بعنوان Forwarder
از حداقل ملزومات ایجاد یک forwarder این است که کاربر بایستی عضو Administrator group باشد. در اولین قدم برای ایجاد و راه اندازی یک DNS server بعنوان forwarder عبارت dnsmgmt.msc را در قسمت Run تایپ می کنیم تا کنسول DNS manager برای ما نمایش داده شود ویا برای مشاهده این کنسول می توانیم از مسیر زیر استفاده کنیم:

Start => Administrative tools => DNS


در این کنسول روی نام سرور کلیک می کنیم ومطابق تصویر روی forwarder راست کلیک کرده و properties می گیریم. در تب forwarder می توانیم تنظیمات لازم را انجام دهیم.

پس از کلیک روی گزینه Edit باید IP مربوط به domain Name مورد نظر را وارد کنیم .

میتوان با مارک دار کردن گزینه مشخص شده در تصویر برای DNS سرور تعیین کرد که اگر موفق به دریافت جواب از forwarder نشد درخواست را به Root hint ها ارسال کند.
هدایت Query ها بصورت شرطی یا Conditional Forwarding
Conditional در لغت ،به معنی شرط هست و مثلا اگر درخواستی برای رجوع به آدرس webmail.itpro.ir توسط کلاینت ارسال شد ،DNS این درخواست را مستقیما به IP مربوطه اش ارجاع می دهد.در واقع می توان با استفاده از قابلیتی بنام Conditional forwarder درخواست را برای یک Domain Name خاص ارسال کرد.

مراحل انجام عملیات Forwarding Conditional در DNS سرور
همانگونه که می دانیم وقتی که DNS Client یک Query برای DNS سرور ارسال می کند DNS ابتدا به جستجو در حافظه ی Cache خود و Host File ها و zone ها می پردازد و در صورت عدم یافتن جواب مناسب ،در صورتیکه DNS Server بعنوان یک Conditional forwarder تعیین شده باشد ، domain Name مورد نظرِ Query را روی IP آدرسی که در ساختار Conditional forwarder برای آن در نظر گرفته شده است ،می فرستد. به بیان ساده ،ما در یک Conditional forwarder یک FQDN خاص و DNS سروری که IP مربوطه آن نام را در بر دارد مشخص و تعیین می کنیم، تا درخواست هر کاربری که قصد مراجعه به آن FQDN را داشت، بطور مستقیم به آن آدرس ، ارجاع داده شود.(این همان تعیین شرط است) و نسبت به forwarder، شرایط بهتری را برای یافتن پاسخ، در حالت forward کردن کلیه درخواستها فراهم می کند و نیز از اولویت بالاتری نسبت به forwarder برخوردار است . با مشخص کردن Domain Name برای DNS سروری که باید Query را ارسال کند و تعیین یک یا چند آی پی آدرس برای Domain Name هایی که در نظر گرفته ایم می توان تنظیمات مربوط به Conditional forwarder را انجام داد.
شیوه پیاده سازی یک DNS server بعنوان Conditional forwarder
برای ایجاد یک Conditional forwarder نیز همانند ایجاد forwarder ، وارد کنسول DNS manager میشویم روی Conditional forwarder مطابق تصویر راست کلیک کرده و عبارت New Conditional forwarder را انتخاب می کنیم.در صفحه باز شده آدرس مورد نظر و IP مربوط به DNS سروری که باید برای یافتن جواب به آن رجوع شود را وارد می کنیم.

تذکر: باید در نظر داشت که نمیتوان Domain Name ای که zone آن در DNS server موجود است را برای Conditional forwarder. تعیین کرد.

از Conditional forwarder میتوان برای برقرار کردن ارتباط میان ساختار Name space های خصوصی با یکدیگر که جز DNS Name spaceهای موجود در اینترنت محسوب نمیشوند نیز استفاده کرد.(Name space به ساختار سلسله مراتبی در نظر گرفته شده برای یک اسم FQDN که بترتیب در بر دارنده بخشهایی چون Roottopsecond level domain و host میباشد اطلاق می گردد). اینگونه Name space ها می توانند در بردارنده ساختار سلسله مراتبی از ادغام چند سازمان و یا شرکت باشند. برای بهتر روشن شدن قضیه دو Name space دو شرکت مجزا را در نظر می گیریم،و برای DNS سرورهایِ ساختار Name space اول تعیین می کنیم که Query های خود را برای DNS سرورهای معتبر درساختارName space دوم ارسال کنند، در اینجا Conditional forwarder کمک خواهد کرد تا فرآیند Name Resolution میان این دو Name space بدون کمک گرفتن از عملیات recursion در DNS Name space موجود درمحیط اینترنت انجام گیرد.این شرایط Name Resolution را افزایش داده و مانع انجام recursion توسط DNS سرور با root های داخلی برای جست و جوی Name space های مختلف موجود در شبکه میشود.

این نکته را نیز باید در نظر داشته باشیم که DNS سرور نمی تواند یک Query را برای Domain Name موجود در zone های خود ارسال کند. ،بعنوان مثال DNS سرور برای zone موجود با نام Itpro.ir قادر به ارسال Query خود برای نام دومین Itpro.ir نخواهد بود و DNS سرور Itpro.ir میتواند Query ها را برای DNS Name هایی که مثلا با Example.Itpro.ir خاتمه می یابند ارسال کند.البته اگر Example.Itpro.ir به DNS سرور های دیگر delegate شده باشد.

اهمیت طول domain Name در Conditional forwarder
فرض را بر این می گذاریم که دو Conditional forwarder برای دو سرور متفاوت با نامهای Itpro.ir و example.Itpro.ir داریم. حال یک Query با محتوای network.example.Itpro.ir برای forwarder ارسال می شود. و تنها برای دو دومینConditional forwarder تعیین شده است. که هر دوی آنها به Itpro.ir ختم شده اند،بنابراین درخواست را برای IP دومینی که نام آن به درخواست موجود در Query نزدیکتر است یعنی example.Itpro.irارسال می کند تا سریعتر به جواب برسد.(با این فرض که در این دومین DNS ای موجود است که می تواند درخواست را به سرور اصلی و مورد نظر برای Query ارجاع دهد)